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

Very cool, congratulations! As for the "non-PC compatible peripherals" in the 80x88/86s, I think it's pretty standard PC-compatible stuff, but at different I/O addresses.

jal wrote on 2024-06-04, 12:29:

Very cool, congratulations! As for the "non-PC compatible peripherals" in the 80x88/86s, I think it's pretty standard PC-compatible stuff, but at different I/O addresses.

There are significant differences in operation of the 186 peripherals besides different ports.

Cool, I must've read wrong information then. Is there some documentation somewhere about the differences specifically?

jal wrote on 2024-06-04, 13:18:

Cool, I must've read wrong information then. Is there some documentation somewhere about the differences specifically?

Other then looking through the manual and just spotting the differences myself, I haven't seen anything that described the differences in detail.
They're similar in concept, different enough you would have to rewrite code specifically for them.
http://www.bitsavers.org/components/intel/808 … Manual_1985.pdf

Note the internal DMA controller has full 20-bit address support, so no page register needed. Each timer channel has its own mode register compared to the shared mode register of the 8253. The timer channels do not have the vast selection of modes like on the 8253.

Thanks, I'll give that a read. Interesting!

MartyPC v0.2.1 is out! Lots of new stuff in here.
https://github.com/dbalsom/martypc/releases/latest/

Party! 😁

Working on fixing up the Tandy and PCJr machines for 0.2.2.

I added proper support for PCJr cartridges, in JRipCart (http://www.oldskool.org/pc/tand-em/jripcart/) format. They are stored in /media/cartridges and enjoy the same file browser system with subdirectory support, in case you need help organizing so many cartridges... 😉

There's another format floating around but I haven't found specs for it. This one has a 512 byte header, i think the other one has a 256 byte header? maybe someone here can illuminate me.

Both cartridge slots are available, and like the real thing, inserting or removing a cartridge reboots the system. I haven't tried the more esoteric BIOS replacement carts, but in theory they should work...

River Raid requires a joystick to be connected or you get a black screen, so I implemented enough of a game port to get it working. Currently I am mapping certain keys to the joystick buttons and inputs (right alt, right control, and the arrow keys), although you can change these mappings. Proper joystick support shouldn't be too far behind.

Cool. How far along is cycle-corrected emulation of the PCJr? And how easy/difficult would it be to also support the Tandy?

Apart from that, consider having settings for the joystick emulation to have different timings, so MartyPC can be used to emulate different joysticks (so we can test calibration screens with different "joysticks").

jal wrote on 2024-06-19, 08:28:

Cool. How far along is cycle-corrected emulation of the PCJr? And how easy/difficult would it be to also support the Tandy?

It inherits the same cycle-accurate, hardware validated 8088 core as the other machines, so it has a good base to work from. What it currently lacks is accurate wait state emulation for the conventional 128k that was refreshed by the video gate array. I have to redesign things a bit to support wait states in that 128k but allow for add-on memory via sidecar that is faster. Still working out those details.

Other than that, the high resolution 2-color mode is missing, and the 3-voice sound chip isn't implemented, and like the 5150, I have not attempted yet to implement the cassette port. The NMI based, serialized keyboard input is still a bit glitchy, and I only have basic PIO mode implemented for the floppy read sector command. So a lot of work left to do.

I have been implementing the Tandy at the same time. The differences between the two are not huge, but one advantage the Tandy has is that as of the 1.03 BIOS it will avail itself of a DMA controller if one is present on an expansion card and use DMA to operate the floppy drives, so at least we have solid floppy emulation for Tandy. Hard drives also work, since the Tandy fixed disk adapter was xebec-based like IBM's.

jal wrote on 2024-06-19, 08:28:

Apart from that, consider having settings for the joystick emulation to have different timings, so MartyPC can be used to emulate different joysticks (so we can test calibration screens with different "joysticks").

If there are some titles that don't work well with the defaults we can look at 'trim' settings or adjusting the potentiometer values, but I would really rather not burden the configuration file with such minutiae unless it is actually needed. I do have a few controllers now I can measure the range, response and deadzones of so it might be possible to build controller 'profiles' that bundle those settings. Like you could select a "Gravis Gamepad", perhaps.

I can't ever concentrate on one thing for very long, so I started working on VGA.

with our new V20, we can even get Wolf3D to run:

What you're seeing here in typical MartyPC style is the entire display field including hblank and vblank. There's no room for 'debug bits' so my normal colors get palettized by the DAC, alas. I might put debug bits in a separate framebuffer.
VGA poses an interesting challenge for my 'aperture-into-field' method as it must support 8 and 9 dot character clocks, as well as 350, 400, and 480 scanline modes. So a fixed set of apertures won't quite work. I'm sure I can figure out a reasonable solution.

Great progress, man. Thanks for continuing to work on this really cool project.

GloriousCow wrote on 2024-06-26, 18:36:

I can't ever concentrate on one thing for very long, so I started working on VGA. […]
Show full quote

I can't ever concentrate on one thing for very long, so I started working on VGA.

vga_mode13.png

with our new V20, we can even get Wolf3D to run:
vga_modeY.png

What you're seeing here in typical MartyPC style is the entire display field including hblank and vblank. There's no room for 'debug bits' so my normal colors get palettized by the DAC, alas. I might put debug bits in a separate framebuffer.
VGA poses an interesting challenge for my 'aperture-into-field' method as it must support 8 and 9 dot character clocks, as well as 350, 400, and 480 scanline modes. So a fixed set of apertures won't quite work. I'm sure I can figure out a reasonable solution.

You know there's a hacked 8088 wolf3d version as well (with reduced viewport)? Optionally, by patching out the CPU check directly to make it run on a 808x CPU (it does run with the CPU check disabled! It's just there because of speed required, not due to instruction set used (only 808x opcodes). A simple JMP at the CPU check routine should be enough from what I remember).

superfury wrote on 2024-06-26, 21:07:

You know there's a hacked 8088 wolf3d version as well (with reduced viewport)? Optionally, by patching out the CPU check directly to make it run on a 808x CPU (it does run with the CPU check disabled! It's just there because of speed required, not due to instruction set used (only 808x opcodes). A simple JMP at the CPU check routine should be enough from what I remember).

I'm aware of Mike Chamber's Wolf8086 port
https://forum.vcfed.org/index.php?threads/wol … 088-cpus.17472/

and the more recent WolfCGA
https://github.com/jhhoward/WolfensteinCGA

It's not as simple as patching out the CPU check. Wolf3d uses several 186 instructions: shifts w/ immediates, OUTS to write the palette, PUSHA, etc.

Got a working aperture defined for 320 column mode, and fixed a glitch with ModeY, and now Wolfenstein 3D is completely playable:

Albeit very, very slowly. The V20 is currently using 8088 timings, so has no real advantage, and we get about 3fps. I'm hoping as I tune the V20 to be more accurate that number goes up a bit 😀

GloriousCow wrote on 2024-06-26, 18:36:

I can't ever concentrate on one thing for very long, so I started working on VGA.

Ouch, this is so relatable 😁. Nevertheless, great work as always!

JAL