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 Yesterday, 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.