The IBM AT will refuse to POST if your 286 is running above 8 MHz due to an artificial BIOS limitation. IBM didn't want people overclocking their ATs.

jal wrote on 2024-05-15, 06:13:

I think the main problems are 1) the whole protected mode shenanigans (though you could just forego on that) and 2) that there isn't a single standard 286 like the 8088 was. There's countless manufacturers and clock speeds (6 MHz up to 25MHz), so there's not one single target.

Clock speed of the CPU doesn't really matter so much - it affects wait states, but for an instruction that doesn't access the bus, 10 clock cycles is 10 clock cycles. The CPU doesn't even have to know how fast it is. Right now if you mush the turbo button on an XT in MartyPC it will run the 8088 at ~7Mhz with 0 wait states, but it would theoretically still be completely accurate to that speed, assuming you had fast enough RAM. Eventually I will have RAM response times in machine configurations, and I'll be able to calculate the appropriate wait states based on the CPU frequency and response time, recalculating on clock changes. You could always specify some mythical 0ns RAM if you didn't ever want to have wait states.

As for 286 protected mode, figuring out all that stuff interests me, so I'll probably do it. Otherwise I could just implement V20/186 and call it a day.

It is true that as we enter in on the 286 and beyond the proliferation of steppings and CPU versions and 3rd party chipmakers increases dramatically, so there's no one clear target to be "cycle-accurate" to. I somehow doubt we'll ever see a 286 demo with perfectly cycle-counted effects like we saw in 8088MPH and Area 5150. So a cycle-perfect 286 emulator will probably never be necessary to run any software that can't otherwise be emulated. But I don't think that makes the endeavor useless - it's still academically interesting and potentially useful for programmers. The CPU I will probably be using in my validation work is a Harris 80c286. So assuming I can pull it off, you'll basically get that specific CPU in MartyPC.

Also, paradoxically, as CPUs get faster the problem almost becomes easier because the microcode gets more capable and thus shorter. DIV on the 8088 is a nightmare to implement; but if you look at a CPU with division hardware like the V20, it's much simpler.
Would you rather emulate the instruction on the left, or on the right?

Would you rather emulate the instruction on the left, or on the right?

Well, I wouldn´t know where to begin in either case 😀 but even I can see that the right one has a result after a short while. So yes! Fascinating stuff.

Ah no, I didn´t read the diagram correctly. Plenty of additional stuff on the right side. I´ll take the left one!

The general strategy of producing V20 tests (A Test Suite for the NEC V20 CPU) and then using them to develop my V20 emulation was a success.

MartyPC now has a functional V20 CPU that can be chosen as a CPU upgrade for any 8088-based machine:

8080 emulation mode is not yet implemented, but MartyPC might have one of the first V20-aware disassemblers in an emulator; while single-stepping you can see proper mnemonics for NEC's new prefixes and instructions.

The bus timings and unmodified instructions are all still based on the 8088 cycle counts, so it will take a bit of work to get the V20 performance somewhat accurate, but I believe I can get it quite close if not equivalent to the real chip over time. Not having the microcode is a challenge, but most of the troublesome complexities of the 8088 have been excised via various optimizations NEC made, so I'm optimistic.

Less exciting but perhaps more important is that a framework was put in place by which MartyPC can now handle different CPU types. The V20 is not implemented by adding to the 8088 via runtime flags, it is an entirely standalone CPU implementation. I don't plan on emulating a whole galaxy of different CPUs, but this opens the way forward toward the 286, and possibly backwards to the 8080.

I am giving serious consideration to the 188/186, as well. The 18X CPUs have the requisite QS status pins which means I can generate tests for them using the same code, although I will need to design a new PCB for the 186's PLC68 pinout. The CPU part of the 186 doesn't scare me so much as the built-in, non-PC compatible peripherals, but Tandy 2000 emulation would be cool.

I wrote a blog post on my findings about the V20, if you're interested.
https://martypc.blogspot.com/2024/05/explorin … ec-v20-cpu.html