VOGONS


EGA Questions

Topic actions

Reply 20 of 29, by GloriousCow

User metadata
Rank Oldbie
Rank
Oldbie
superfury wrote on Yesterday, 12:11:

Also interesting to note is, that when I compare the values ending up in the BDA (from said MK_ENV call) when the switches are in inversed order on the graphics card, that the "monochrome" bits (switch 3 open and others closed) actually matches the VGA documented 0010b that's documented to appear there on VGA monochrome monitors (reported by grounding just the ID1 pin). Seeing as the VGA is supposed to be EGA-compatible, it looks like the EGA indeed flips the switch numbers (or wiring them inversed).

I showed you how they are reversed on the PCB just a few posts up. It was just a wiring convenience, I figured to wire them in order they'd have had to have flipped the 153 around compared to all of the other chips that face left, or have the wiring take a different, longer path. Looking at the PCB though, the DIP traces run on one of the inner layers and there would have been room between U15 and U6 to run them from the top which would have put them in order.

So who knows, really. IBM probably didn't care what order they were in as it would only ever confuse emulator authors decades later.

Another optimization that led to a quirk is that all the address lines coming off the ISA bus are passed through inverters and so for most of the address logic on the board, the addresses are inverted. So when chips like the graphics controllers and the sequencer get the A0 line to handle odd/even mode they actually get ~A0. To avoid reversing everything in VRAM they used 74LS258 multiplexers to generate the row and column addresses, which are just like 74LS257's but have inverted outputs.

But this means that the address lines to the BIOS ROM are inverted. It would have cost them an extra chip to invert these addresses back, so what they did is just reverse the contents of the ROM.

Last edited by GloriousCow on 2025-12-24, 17:31. Edited 4 times in total.

MartyPC: A cycle-accurate IBM PC/XT emulator | https://github.com/dbalsom/martypc

Reply 21 of 29, by GloriousCow

User metadata
Rank Oldbie
Rank
Oldbie

We can get our terminology mixed because the EGA dip switches are both *reversed in position* and *inverted*.

Many dip switches are logically inverted because this is a common way to hook them up:

The attachment dip_diagram.PNG is no longer available

You tie one side of the DIP switch to ground, then you stick a pull-up resistor network to +V on the traces to whatever is reading the DIPs.
When a DIP switch is OFF, there is no connection to ground, so the resistor network pulls the output line up to +V and the switch reads logical 1.
When a DIP switch is ON, a circuit is completed to ground and the switch reads a logical 0.

Nothing forces you to wire it this way, but the convenient thing about it is that you can put your DIP switch pretty much anywhere there is access to the ground plane and the position of the DIP switch usually has some considerations for user accessibility. Especially on the EGA where they wanted you to be able to access it through the ISA card bracket.

MartyPC: A cycle-accurate IBM PC/XT emulator | https://github.com/dbalsom/martypc

Reply 22 of 29, by GloriousCow

User metadata
Rank Oldbie
Rank
Oldbie

Another fun fact is that the same 153 multiplexer, U15, is used both to read the DIP switches and select the clock source.
It's a dual package multiplexer so it can do that. The main problem is that it only has one set of input selection lines.

That means if you want to read all the DIP switches, you have to change the EGA clock. This is of course not of much concern if you do it quickly, once, during POST. Reading them in a tight loop afterwards might have ... interesting results. I suspect your monitor will not enjoy it.

Also you'll recall that you set the clock source using two bits of the Miscellaneous Output Register. Value '11' is not defined for good reason - you'll end up selecting output 3 of U15 which isn't connected. So now your EGA has no clock and just stops running altogether. I have run into a few titles, mostly demos, that actually do this (probably on accident) so I assume that clone cards and the VGA handled it a bit more gracefully.

MartyPC: A cycle-accurate IBM PC/XT emulator | https://github.com/dbalsom/martypc

Reply 23 of 29, by superfury

User metadata
Rank l33t++
Rank
l33t++
GloriousCow wrote on Yesterday, 17:37:
Another fun fact is that the same 153 multiplexer, U15, is used both to read the DIP switches and select the clock source. It's […]
Show full quote

Another fun fact is that the same 153 multiplexer, U15, is used both to read the DIP switches and select the clock source.
It's a dual package multiplexer so it can do that. The main problem is that it only has one set of input selection lines.

That means if you want to read all the DIP switches, you have to change the EGA clock. This is of course not of much concern if you do it quickly, once, during POST. Reading them in a tight loop afterwards might have ... interesting results. I suspect your monitor will not enjoy it.

Also you'll recall that you set the clock source using two bits of the Miscellaneous Output Register. Value '11' is not defined for good reason - you'll end up selecting output 3 of U15 which isn't connected. So now your EGA has no clock and just stops running altogether. I have run into a few titles, mostly demos, that actually do this (probably on accident) so I assume that clone cards and the VGA handled it a bit more gracefully.

But isn't a clock select 3 required to read the 4th dipswitch? If it crashes the chip, doesn't that make the 4th dipswitch unreadable?

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 24 of 29, by GloriousCow

User metadata
Rank Oldbie
Rank
Oldbie
superfury wrote on Yesterday, 20:39:

But isn't a clock select 3 required to read the 4th dipswitch? If it crashes the chip, doesn't that make the 4th dipswitch unreadable?

I didn't say it crashes, I said it stops running. This is the dot clock, to be specific - it's not needed for reading the register. You just get no video.
Maybe "stops rasterizing" is a more accurate way to phrase it.

MartyPC: A cycle-accurate IBM PC/XT emulator | https://github.com/dbalsom/martypc

Reply 25 of 29, by superfury

User metadata
Rank l33t++
Rank
l33t++
GloriousCow wrote on Yesterday, 21:20:
superfury wrote on Yesterday, 20:39:

But isn't a clock select 3 required to read the 4th dipswitch? If it crashes the chip, doesn't that make the 4th dipswitch unreadable?

I didn't say it crashes, I said it stops running. This is the dot clock, to be specific - it's not needed for reading the register. You just get no video.
Maybe "stops rasterizing" is a more accurate way to phrase it.

Isn't the same true for clock #2? Since only clocks #0 and #1 are connected?
My emulator indeed stops rendering entirely once the 3rd and 4th clocks are set (as they're set to 0Hz on EGA/VGA. The Tseng SVGA chips do have all clocks (16 in fact) however).
Somewhat interesting is that my emulation of the Tseng chips is seemingly the most accurate of all Tseng ETx000(/W32) emulators, even emularing more hidden stuff like the extra CGA translation ROM and enhanced 8 font text mode.

Author of the UniPCemu emulator.
UniPCemu Git repository
UniPCemu for Android, Windows, PSP, Vita and Switch on itch.io

Reply 26 of 29, by GloriousCow

User metadata
Rank Oldbie
Rank
Oldbie
superfury wrote on Today, 10:44:

Isn't the same true for clock #2? Since only clocks #0 and #1 are connected?
My emulator indeed stops rendering entirely once the 3rd and 4th clocks are set (as they're set to 0Hz on EGA/VGA. The Tseng SVGA chips do have all clocks (16 in fact) however).
Somewhat interesting is that my emulation of the Tseng chips is seemingly the most accurate of all Tseng ETx000(/W32) emulators, even emularing more hidden stuff like the extra CGA translation ROM and enhanced 8 font text mode.

Yes, that's correct - it's just that this isn't set by accident as often as 11 is, for whatever reason.

MartyPC: A cycle-accurate IBM PC/XT emulator | https://github.com/dbalsom/martypc

Reply 27 of 29, by mkarcher

User metadata
Rank l33t
Rank
l33t
GloriousCow wrote on Yesterday, 21:20:

I didn't say it crashes, I said it stops running. This is the dot clock, to be specific - it's not needed for reading the register. You just get no video.
Maybe "stops rasterizing" is a more accurate way to phrase it.

As a side effect, it also stops refreshing the video RAM, as everything the EGA card does on its own is synchronized to the dot clock. As this also is true for video memory requests from the iSA bus, you get better text mode performance in the high-res EGA text mode (16.257MHz) than in the low-res SGA text mode (14.318 MHz).

On the other hand, some S3 Super-VGA graphics chips, e.g. the 928, do lock up if you select a non-present dot clock.

Reply 28 of 29, by mkarcher

User metadata
Rank l33t
Rank
l33t
SoftCat wrote on Yesterday, 00:54:
The easiest way to do it is like this. […]
Show full quote
mkarcher wrote on 2025-12-16, 22:53:

While I previously claimed that the bit likely exists, I'm actually unsure whether you can have the CRTC address counter wrap around at 16K (the CRTC address counter counts 32-bit units of video RAM, so 16K in that counter is 64KB of RAM). I will check documentation and report back what I find.

The easiest way to do it is like this.

mov ax,40h
mov es,ax
and byte ptr es:[87h],9Fh
mov ax,0Eh
int 10h
.....

I would be surprised if that works. What that code does, if I understand it correctly, is to fake a 64K EGA before setting mode 0Eh. As far as I know, mode 0Eh is programmed exactly the same way by the EGA BIOS, no matter what memory size is indicated in the BIOS data area. In the mean time, I checked the CRTC EGA register documentation, and couldn't find any bit that makes the CRTC address counter wrap from 3FFF to 0000 to allow cyclic access to the first 64K, but I did find something that should be good enough for "infinite scroll" purposes: There is the "Hercules compatibility" bit in the CRTC mode register (Index 0x17, bit 1). If you set that bit, the video memory address bit 14 (the one that distinguishes between 4000 and 0000) will be replaced by bit 1 of the character scanline counter - which will be 0 all the time in EGA graphics modes, so 0000..3FFF is accessed when the address counter actually is 4000..7FFF, but after reaching 7FFF, you will get to 8000, not to 0000 again. So you don't get infinite repetitions of the first 64K, just two of them, which should be enough.

Reply 29 of 29, by mkarcher

User metadata
Rank l33t
Rank
l33t
SoftCat wrote on 2025-12-21, 00:14:

Is it possible to set 640x200 mode with at least two pages (4 or 2 colors) on an EGA graphics card with 64 KB of VRAM? If so, how exactly do I do this?
Will this mode work on EGA graphics cards with more VRAM? Will this mode work on original VGA graphics cards?

Check how 64K mode 10h differs from standard mode 10h, and apply those differences to mode 0Eh. If I understand it correctly, you will need to enable odd/even mode, and configure the CRTC to word mode with 14-bit rotation. That will result in a 4-color 2-page variant of mode 0Eh, and is supposed to work the same way on the original VGA card as well.

The VGA hardware also provides the necessary functionality to get a 2-color 4-page mode, whilst the EGA hardware does not. As VGA always has at least 256K of RAM, which provides a 16-color 4-page mode, this is likely not interesting.