SoftCat wrote on 2025-12-19, 16:00:

GloriousCow wrote on 2025-12-18, 23:04:

I'm afraid I never really implemented monochrome support for the EGA, because dealing with the 9-dot character timings annoyed m […]
Show full quote

I'm afraid I never really implemented monochrome support for the EGA, because dealing with the 9-dot character timings annoyed me at the time as I had (what i thought to be) a nice optimized 64-bit, 8-pixel-at-time drawing pipeline. I did eventually figure that out for VGA but never back ported it to EGA.

Here's what I have for DIP switches, for what its worth. These are the physical switch states. They read inverted as closing the switch pulls the circuit to ground.

pub const EGA_DIP_SWITCH_EGA: u8 = 0b1001; // EGA 'enhanced color'
pub const EGA_DIP_SWITCH_MDA: u8 = 0b1011; // MDA emulation
pub const EGA_DIP_SWITCH_NORMAL: u8 = 0b1000; // EGA 'normal color'
pub const EGA_DIP_SWITCH_CGA: u8 = 0b0111; // EGA on CGA monitor

9-dot characters require a 72-bit processor.

There's only 8 pixels being fetched from a 32-bit VRAM location in graphics modes though. Text mode uses different buffers and only planes 0 and 1 (and plane 2 for loading a latch of 8 pixels, with the 9th pixel being a duplicate of the 8th or zeroed). Then it's simply shifted out one font pixel at a time to the display, much like with monochrome graphics modes. The only difference here is that the attribute is combined with that for font/background color to send to the attribute controller. And of course the whole deal with the CRT timings being affected as well by this setting (720 pixels of active display horizontally).

superfury wrote on 2025-12-20, 00:36:

There's only 8 pixels being fetched from a 32-bit VRAM location in graphics modes though. Text mode uses different buffers and only planes 0 and 1 (and plane 2 for loading a latch of 8 pixels, with the 9th pixel being a duplicate of the 8th or zeroed). Then it's simply shifted out one font pixel at a time to the display, much like with monochrome graphics modes. The only difference here is that the attribute is combined with that for font/background color to send to the attribute controller. And of course the whole deal with the CRT timings being affected as well by this setting (720 pixels of active display horizontally).

Yes, I'm aware of all this. I was just joking about the 72-bit processor.

I created a new topic here.
EGA Questions

Does MartyPC correctly emulate odd/even mode for EGA? If so, which emulator version is best?

SoftCat wrote on 2025-12-23, 22:23:

Does MartyPC correctly emulate odd/even mode for EGA? If so, which emulator version is best?

It should. Just use the last release.

Tried the last exe (win64) release of the MartyPC to have a look at it's EGA emulation (for comparing to what the BIOS is supposed to do in the MDA monitor case, even if the monitor colors are incorrect in that case). But I couldn't get the EGA BIOS ROM to load into it? It keeps not finding the ROM? Any idea where I should place the ROM (I tried putting it in the EGA directory next to the VGA ROM directory and even renaming it to the MartyPC's manual's ROM filename, but I couldn't get it to load?

superfury wrote on 2025-12-24, 14:42:

Tried the last exe (win64) release of the MartyPC to have a look at it's EGA emulation (for comparing to what the BIOS is supposed to do in the MDA monitor case, even if the monitor colors are incorrect in that case). But I couldn't get the EGA BIOS ROM to load into it? It keeps not finding the ROM? Any idea where I should place the ROM (I tried putting it in the EGA directory next to the VGA ROM directory and even renaming it to the MartyPC's manual's ROM filename, but I couldn't get it to load?

Yeah, sorry, this is a bug - i need to push out a fixed version soon. Get the md5 of your ega ROM, then go into romdef_ega.toml and delete the line with the rom with the md5 you don't have.

GloriousCow wrote on 2025-12-23, 22:49:

It should. Just use the last release.

Got it, thank you!

Maybe you've already answered this question before, but it's been a while, and I'm currently dabbling with pseudo-floppy disk emulation for a retro fantasy console, but does MartyPC try to emulate the FDD including seek time (stepper motor) and delays for the right sector moving under the head?

jal wrote on 2026-01-01, 22:19:

Maybe you've already answered this question before, but it's been a while, and I'm currently dabbling with pseudo-floppy disk emulation for a retro fantasy console, but does MartyPC try to emulate the FDD including seek time (stepper motor) and delays for the right sector moving under the head?

Not currently, no. A huge rewrite of the floppy system is coming, eventually.

Ok, cool, thx. Do you have any technical information about seek times etc.? I can only find information about data transfer rates, but not about the time the stepper motor takes.

jal wrote on Yesterday, 18:34:

Ok, cool, thx. Do you have any technical information about seek times etc.? I can only find information about data transfer rates, but not about the time the stepper motor takes.

I'd imagine it could vary a bit with drive models, and obviously stepping on 5.25" and 3.5" drives will have very different timings.
I am planning on collecting what timing info I can glean from various datasheets and having a sort of "average drive" with 5.25 and 3.5 variants.

TEAC often published useful timing info in their datasheets.
https://deramp.com/downloads/floppy_drives/te … c%20FD-55BV.pdf

stuff like this is helpful to consider in a precise model:

(b) The access motion (head seek operation) is initiated at the trailing edge of the pulse and completes within 21msec after starting the access including the settling time. For the successive access motion in the same direction, the pulses shall be input with the space of more than 6msec, while the pulses shall be input with the space of more than 21msec for the access motion in a different direction.