anttir wrote on 2025-08-26, 16:51:

Hello! First time poster here. Just wanted to drop in to say that MartyPC is AWESOME!

Also, I really hope that someday MartyPC will support 286 and 386. You see, I've been doing a little assembly programming lately, and I've found that Dosbox is not accurate at all. For example, I made two versions of a the same smooth scrolling vga game "engine". On DosBox they were equally fast, but on real hardware the other one was waaay slower.

Thanks for your kind words. I have started a 286 branch, but work is very preliminary. I believe cycle-accurate emulation of the 286 is possible and it intrigues me to attempt it. I'll leave the debates about the usefulness of that to others.
If nothing else, being able to watch the progress of the prefetch and instruction queues on the 286 would be interesting.

I've been a bit distracted with the 386 lately and working on making emulator CPU tests for the 386. I hope to get back to MartyPC by the end of the year.

286 already gets complicated there. Things like various recursive descriptor loads (for example IDT->GDT/LDT recursive descriptors). One the 386 it gets even more crazier, as each access includes optional paging lookups as well (multi-level memory access trees and TLBs that cache them all).
And there's the different timings of the local caches (descriptor cache references) as well.
All built on top of the normal segmentation system (and yes, all segment descriptors are always active, even in real mode).

In my emulator's case, I simply make them all instant as it gets way too complicated to cycle-accurately implement those all (due to counting and stepping becoming very complicated due to various recursiveness).
So mine is effectively only 'cycle-accurate' in real mode (using officially documented timings however).

I have the benefit of having a 286 (and a 386) under Arduino control for analyzing cycle by cycle operations.

I gave MartyPC a try today and it helped me spot that I had accidentally compiled some programs with 286 optimizations (they worked with v20 selected, but not without). I do have one question - when I pick CGA overlay from the launcher, is it supposed to still show VGA when booting the emulator? I didn’t test any CGA specific programs, but I was hoping I could still spot something like a font difference.

BinaryDemon wrote on 2025-09-05, 22:07:

I gave MartyPC a try today and it helped me spot that I had accidentally compiled some programs with 286 optimizations (they worked with v20 selected, but not without). I do have one question - when I pick CGA overlay from the launcher, is it supposed to still show VGA when booting the emulator? I didn’t test any CGA specific programs, but I was hoping I could still spot something like a font difference.

No, the font should be recognizably different.

GloriousCow wrote on 2025-09-05, 13:51:

Thanks for your kind words. I have started a 286 branch, but work is very preliminary. I believe cycle-accurate emulation of the 286 is possible and it intrigues me to attempt it. I'll leave the debates about the usefulness of that to others.
If nothing else, being able to watch the progress of the prefetch and instruction queues on the 286 would be interesting.

I've been a bit distracted with the 386 lately and working on making emulator CPU tests for the 386. I hope to get back to MartyPC by the end of the year.

Well that is great news for sure, thank you!

One suggestion concerning the VGA debugging, don't know if it has been brought up before:

It would be great to be able to see the contents of the entire video ram. If I'm understanding correctly, we can currently see only the memory map at a0000h, but not the contents of different planes. Would be nice if, for example, on Mode Y (320x200x256) there would be a memory visualizer that could show all planes, maybe even so that it would be possible to arrange bytes or bits according to your needs. Well, that is just a suggestion, I'm sure you're having your hands full with the 286 (and the 386)!

anttir wrote on 2025-09-09, 09:22:

It would be great to be able to see the contents of the entire video ram. If I'm understanding correctly, we can currently see only the memory map at a0000h, but not the contents of different planes. Would be nice if, for example, on Mode Y (320x200x256) there would be a memory visualizer that could show all planes, maybe even so that it would be possible to arrange bytes or bits according to your needs. Well, that is just a suggestion, I'm sure you're having your hands full with the 286 (and the 386)!

I would like this to be possible too. There are also other memory sources you'd like to see, such as the contents of an EMS card, various device buffers, etc.

I have in mind a memory reflector service that devices that own memory send their memory operations to, in a separate thread. This service will keep track of changes to memory sources per frame and also provide bitmap visualizations of memory. Just have to write the code for it!

GloriousCow wrote on 2025-09-09, 16:07:

I would like this to be possible too. There are also other memory sources you'd like to see, such as the contents of an EMS card, various device buffers, etc.

I have in mind a memory reflector service that devices that own memory send their memory operations to, in a separate thread. This service will keep track of changes to memory sources per frame and also provide bitmap visualizations of memory. Just have to write the code for it!

Very nice, can't wait! It would be interesting indeed to see how different programs and games use EMS and other memory resources. Also, I've been learning some XMS and EMS programming lately, so it might prove useful in that regard too.

By the way, maybe you could add some kind of "Show every debug/resource window at once" command to the debug menu? I've found that while using MartyPC, I somehow always end up opening just about every possible debug window. I guess it is just some much fun to watch the machine working 😀

anttir wrote on 2025-09-10, 11:08:

By the way, maybe you could add some kind of "Show every debug/resource window at once" command to the debug menu? I've found that while using MartyPC, I somehow always end up opening just about every possible debug window. I guess it is just some much fun to watch the machine working 😀

I eventually plan to have a concept of 'workspaces' that would record what windows you have open and their positions, so you can save debugging sessions, etc.

There's also lots of stuff on the 286/386 instructions that aren't explicitly mentioned in the official documentation.
Like stack switches loading SP vs ESP (depending on the B-bit of the target stack segment descriptor loaded just before it). Complicated by truncating or zero-extending from the TSS of course.
Then there's also the stack pushes during far calls to higher privilege levels (target effective CPL < instruction CPL), which also complicates things.
Combine with paging checks and various descriptor loads also using paging to make it even more complicated to implement in a step-wise approach (in my emulator's case it's a simple counter for keeping track of instruction state, checked again during each cycle to be executed (only interrupted during multi-cycle waiting on the BIU).
Segmentation checks also go several levels deep, complicating it even more (interrupt performing segment load as well as stack switches, all loading paging TLB values from RAM if needed). A big recursive mess to implement cycle-accurately (which is why I didn't do that, except for some basics like intersegment returns to lower privilege levels and real-mode style calls).

BinaryDemon wrote on 2025-09-05, 22:07:

I gave MartyPC a try today and it helped me spot that I had accidentally compiled some programs with 286 optimizations (they worked with v20 selected, but not without). I do have one question - when I pick CGA overlay from the launcher, is it supposed to still show VGA when booting the emulator? I didn’t test any CGA specific programs, but I was hoping I could still spot something like a font difference.

I had a typo in the configuration file for the launcher, that was using VGA when you selected CGA.

here's a corrected version.

GloriousCow wrote on 2025-09-11, 17:41:

BinaryDemon wrote on 2025-09-05, 22:07:

I gave MartyPC a try today and it helped me spot that I had accidentally compiled some programs with 286 optimizations (they worked with v20 selected, but not without). I do have one question - when I pick CGA overlay from the launcher, is it supposed to still show VGA when booting the emulator? I didn’t test any CGA specific programs, but I was hoping I could still spot something like a font difference.

I had a typo in the configuration file for the launcher, that was using VGA when you selected CGA.

here's a corrected version.

Ah thanks for looking into it, I wasn't going to bother you further - I figured it was just an issue with my setup.

BinaryDemon wrote on 2025-09-12, 10:35:

Ah thanks for looking into it, I wasn't going to bother you further - I figured it was just an issue with my setup.

You technically don't need an overlay for CGA since it's the default so I guess that is how I didn't notice.

superfury wrote on 2025-09-11, 09:17:

There's also lots of stuff on the 286/386 instructions that aren't explicitly mentioned in the official documentation.
Like stack switches loading SP vs ESP (depending on the B-bit of the target stack segment descriptor loaded just before it). Complicated by truncating or zero-extending from the TSS of course.
Then there's also the stack pushes during far calls to higher privilege levels (target effective CPL < instruction CPL), which also complicates things.

Yes, 286 is much more complex. I've hired someone to decap a 286, delayer the metal covering the microcode and image it, then I plan to extract the microcode, and with the help of some friends, decode it.
Together with having a 286 under Arduino control, I think that I can make a pretty accurate 286 emulator, even if it isn't cycle-perfect.

GloriousCow wrote on 2025-09-12, 11:49:

Yes, 286 is much more complex. I've hired someone to decap a 286, delayer the metal covering the microcode and image it, then I plan to extract the microcode, and with the help of some friends, decode it.
Together with having a 286 under Arduino control, I think that I can make a pretty accurate 286 emulator, even if it isn't cycle-perfect.

Wow, super cool! You have probably already seen this die shot of the Intel 80286: http://visual6502.org/images/pages/Intel_8028 … _die_shots.html.

There was a thread on VCFed forums where a member, who had decoded the 186 microcode using a die shot from the same website, speculated that it might even be possible to extract the microcode from that die shot, although it would be difficult: https://forum.vcfed.org/index.php?threads/808 … ly.77933/page-2

anttir wrote on Yesterday, 07:49:

GloriousCow wrote on 2025-09-12, 11:49:

Yes, 286 is much more complex. I've hired someone to decap a 286, delayer the metal covering the microcode and image it, then I plan to extract the microcode, and with the help of some friends, decode it.
Together with having a 286 under Arduino control, I think that I can make a pretty accurate 286 emulator, even if it isn't cycle-perfect.

Wow, super cool! You have probably already seen this die shot of the Intel 80286: http://visual6502.org/images/pages/Intel_8028 … _die_shots.html.

There was a thread on VCFed forums where a member, who had decoded the 186 microcode using a die shot from the same website, speculated that it might even be possible to extract the microcode from that die shot, although it would be difficult: https://forum.vcfed.org/index.php?threads/808 … ly.77933/page-2

Yes, I've seen it. I don't think the bits are extractable.
The bad news is that it is still unreadable even after delayering. So that might be a dead end.

GloriousCow wrote on Yesterday, 17:08:

anttir wrote on Yesterday, 07:49:

GloriousCow wrote on 2025-09-12, 11:49:

Yes, 286 is much more complex. I've hired someone to decap a 286, delayer the metal covering the microcode and image it, then I plan to extract the microcode, and with the help of some friends, decode it.
Together with having a 286 under Arduino control, I think that I can make a pretty accurate 286 emulator, even if it isn't cycle-perfect.

Wow, super cool! You have probably already seen this die shot of the Intel 80286: http://visual6502.org/images/pages/Intel_8028 … _die_shots.html.

There was a thread on VCFed forums where a member, who had decoded the 186 microcode using a die shot from the same website, speculated that it might even be possible to extract the microcode from that die shot, although it would be difficult: https://forum.vcfed.org/index.php?threads/808 … ly.77933/page-2

Yes, I've seen it. I don't think the bits are extractable.
The bad news is that it is still unreadable even after delayering. So that might be a dead end.

Can you provide some examples of what you got out from the delayering process, with shots of the rom region? Also, what exact version of the 286 did you decap? The HMOS version should definitely be readable. I went down the rabbit hole of M68000 decap analysis and microcode extraction years ago. I'm pretty familiar with how to interpret HMOS/NMOS visually.

DivByZero wrote on Today, 10:06:

GloriousCow wrote on Yesterday, 17:08:

anttir wrote on Yesterday, 07:49:

Wow, super cool! You have probably already seen this die shot of the Intel 80286: http://visual6502.org/images/pages/Intel_8028 … _die_shots.html.

There was a thread on VCFed forums where a member, who had decoded the 186 microcode using a die shot from the same website, speculated that it might even be possible to extract the microcode from that die shot, although it would be difficult: https://forum.vcfed.org/index.php?threads/808 … ly.77933/page-2

Yes, I've seen it. I don't think the bits are extractable.
The bad news is that it is still unreadable even after delayering. So that might be a dead end.

Can you provide some examples of what you got out from the delayering process, with shots of the rom region? Also, what exact version of the 286 did you decap? The HMOS version should definitely be readable. I went down the rabbit hole of M68000 decap analysis and microcode extraction years ago. I'm pretty familiar with how to interpret HMOS/NMOS visually.

The whole thing is here:
https://siliconpr0n.org/map/intel/80286-10/in … _poly_nikpa20x/
https://siliconpr0n.org/map/intel/80286-10/in … cdj_mz_nikpa20x

attached is the chip used.

from what I understand, it looks like they used an implant rom, and to extract the bits may require some nasty chemicals such as hydrofluoric acid.

Perhaps early chips would be easier?

keenmaster486 wrote on Today, 17:03:

Perhaps early chips would be easier?

It's possible. I initially wanted an E-stepping imaged because there was a ton of errata fixed on the 286 that I didn't care to emulate.
Could also try a 2nd-source CMOS version.