Here on page 20 (in the PDF it's page 24) for bit 3 it says: "9 MHz for mode D". How can that be the frequency for mode D?
https://drive.google.com/file/d/1WouBG1qGe9Eh … iew?usp=sharing

Considering EGA uses 14.318MHz from the ISA slot and 16.257MHz from onboard oscillator - there's no reasonable ways to make 9MHz out of it with the tech of the period.
Maybe it's just blatant rounding, a figure of speech to say it's "faster than 8MHz"?
Or it's just someone's though train had derailed while writing that doc, because mode 0dh should have exactly same pixel clock as any other 320x200 mode.

Maybe something like it already exists, but would it be useful to create an EGA compatibility test tool that could verify the extent of EGA compatibility of (VGA) cards, including the many more undocumented and obscure features and corner cases that you mentioned?

The EGA BIOS (which I have a source code copy of, don't remember from where) seems to interpret the switches in an odd way. From what I can see, it reads the dipswitches in reverse order from how the lookup table seems to expect them? So the four bits are read in reverse order, with misc output register set to bit 0's result being stored into bit 3, bit 2 into bit 1, bit 1 into bit 2 and bit 0 into bit 3.
Anyone knows why it's doing that?
Edit: I think it was from here.
I did find some encoding errors which required some "db" manual code injection to make it match the official bios though, at least on newer masm versions.
I think I documented that somewhere on this forum.

digger wrote on 2025-12-21, 09:36:

Maybe something like it already exists, but would it be useful to create an EGA compatibility test tool that could verify the extent of EGA compatibility of (VGA) cards, including the many more undocumented and obscure features and corner cases that you mentioned?

That would be wonderful, an EGA version of the CGA Compatibility Tester! ^^

Because so far, I merely know of Commander Keen (such as Keen IV) and STS Orbit Plus which do trigger EGA compatibility issues on poor VGA cards.

The latter is an orbit prediction program that used to be popular in the 90s.
To predict when MIR or ISS are passing by above your home.
It was also useful to see when weather or ham satellites are in your range, so you can listen to them, receive data..

Anyway - In motion tracking mode (M key) it rotates the earth globe below the satellite, using an rarely used EGA mode (two video pages, 640x350 pels).
It calls it EGA "Dual-Page Mode", if memory serves.

Unfortunatelly, this EGA mode does rarely work correctly on emulators or modern VGA cards (DOSBox is fine).
On a cheap thin client I'm using, the screen goes black every time the program switches to the other video page.

That's why I'm using the normal orthographic mode (O key) most of time.
It does move the satellite, but rarely re-draws the globe.
It also doesn't switch modes (remains in 640x480 pels VGA mode).

vstrakh wrote on 2025-12-21, 09:35:

Considering EGA uses 14.318MHz from the ISA slot and 16.257MHz from onboard oscillator - there's no reasonable ways to make 9MHz out of it with the tech of the period.
Maybe it's just blatant rounding, a figure of speech to say it's "faster than 8MHz"?
Or it's just someone's though train had derailed while writing that doc, because mode 0dh should have exactly same pixel clock as any other 320x200 mode.

On the EGA graphics card, in all 320x200 modes, the CRTC parameters correspond to a pixel frequency of 7.159 MHz.

digger wrote on 2025-12-21, 09:36:

Maybe something like it already exists, but would it be useful to create an EGA compatibility test tool that could verify the extent of EGA compatibility of (VGA) cards, including the many more undocumented and obscure features and corner cases that you mentioned?

Yes, I thought about that too.

superfury wrote on 2025-12-21, 11:00:

The EGA BIOS (which I have a source code copy of, don't remember from where) seems to interpret the switches in an odd way. From […]
Show full quote

The EGA BIOS (which I have a source code copy of, don't remember from where) seems to interpret the switches in an odd way. From what I can see, it reads the dipswitches in reverse order from how the lookup table seems to expect them? So the four bits are read in reverse order, with misc output register set to bit 0's result being stored into bit 3, bit 2 into bit 1, bit 1 into bit 2 and bit 0 into bit 3.
Anyone knows why it's doing that?
Edit: I think it was from here.
I did find some encoding errors which required some "db" manual code injection to make it match the official bios though, at least on newer masm versions.
I think I documented that somewhere on this forum.

The EGA BIOS listing is here at the end.
https://drive.google.com/file/d/1WouBG1qGe9Eh … iew?usp=sharing

Jo22 wrote on 2025-12-21, 11:34:

That would be wonderful, an EGA version of the CGA Compatibility Tester! ^^ […]
Show full quote

That would be wonderful, an EGA version of the CGA Compatibility Tester! ^^

Because so far, I merely know of Commander Keen (such as Keen IV) and STS Orbit Plus which do trigger EGA compatibility issues on poor VGA cards.

The latter is an orbit prediction program that used to be popular in the 90s.
To predict when MIR or ISS are passing by above your home.
It was also useful to see when weather or ham satellites are in your range, so you can listen to them, receive data..

Anyway - In motion tracking mode (M key) it rotates the earth globe below the satellite, using an rarely used EGA mode (two video pages, 640x350 pels).
It calls it EGA "Dual-Page Mode", if memory serves.

Unfortunatelly, this EGA mode does rarely work correctly on emulators or modern VGA cards (DOSBox is fine).
On a cheap thin client I'm using, the screen goes black every time the program switches to the other video page.

That's why I'm using the normal orthographic mode (O key) most of time.
It does move the satellite, but rarely re-draws the globe.
It also doesn't switch modes (remains in 640x480 pels VGA mode).

Thank you for the link to STS Orbit Plus and the mention of EGA "Dual-Page Mode".

superfury wrote on 2025-12-21, 11:00:

The EGA BIOS (which I have a source code copy of, don't remember from where) seems to interpret the switches in an odd way. From what I can see, it reads the dipswitches in reverse order from how the lookup table seems to expect them? So the four bits are read in reverse order, with misc output register set to bit 0's result being stored into bit 3, bit 2 into bit 1, bit 1 into bit 2 and bit 0 into bit 3.
Anyone knows why it's doing that?

Due to the orientation of the DIP switch and the 74LS153 multiplexer that reads them, it just worked out that was the simplest way to wire them up.

SoftCat wrote on 2025-12-21, 00:25:

Here on page 20 (in the PDF it's page 24) for bit 3 it says: "9 MHz for mode D". How can that be the frequency for mode D?
https://drive.google.com/file/d/1WouBG1qGe9Eh … iew?usp=sharing

i have no idea what that was in reference to but IBM technical reference are somewhat notorious for mistakes

the Compaq EGA reference is quite good though
https://archive.org/details/trg-enhanced-colo … s-board-1986-12

GloriousCow wrote on 2025-12-22, 01:14:

i have no idea what that was in reference to but IBM technical reference are somewhat notorious for mistakes

the Compaq EGA reference is quite good though
https://archive.org/details/trg-enhanced-colo … s-board-1986-12

Thank you for the link!

This Compaq CGA graphics card has an 18.981 MHz crystal oscillator. Your EGA documentation also lists the same frequency.
https://drive.google.com/drive/folders/11x0_- … qSVxjlH1TgFTciw
This corresponds to 720x350 60Hz mode.

I've read through the Compaq EGA reference and eventually found Figure 5-9 on page BIOS 5-51.
It literally lists BDA 40:88 bits 0-3 as:
0001: MDA/Mono secondary EGA(80)/RGBI
1000: CECG(x200)/RrGgBb secondary MDA/Mono
If the bits were truly read inversed, this wouldn't be true? So the bits shouldn't be read inversed on EGA?

superfury wrote on 2025-12-23, 05:24:

I've read through the Compaq EGA reference and eventually found Figure 5-9 on page BIOS 5-51. It literally lists BDA 40:88 bits […]
Show full quote

I've read through the Compaq EGA reference and eventually found Figure 5-9 on page BIOS 5-51.
It literally lists BDA 40:88 bits 0-3 as:
0001: MDA/Mono secondary EGA(80)/RGBI
1000: CECG(x200)/RrGgBb secondary MDA/Mono
If the bits were truly read inversed, this wouldn't be true? So the bits shouldn't be read inversed on EGA?

It's just better to check this code on a real EGA card.

1
2....................................................
3
4INFO_3	DB	?
5
6; INFO_3
7;	D7-D4 FEATURE BITS
8;	D3-D0 SWITCHES
9
10....................................................
11
12	MISC_OUTPUT	EQU	0C2H
13	IN_STAT_0	EQU	0C2H
14
15....................................................
16
17;----- POST FOR COMBO VIDEO CARD
18
19	MOV	INFO,00000100B
20	CALL	RD_SWS
21	MOV	INFO_3,BL
22	CALL	F_BTS
23	OR	INFO_3,AL
24	MOV	BL,INFO_3
25	CALL	MK_ENV
26	JMP	POST
27SKIP:
28	RET
29VIDEO_SETUP	ENDP
30
31
32POR_1	PROC	NEAR
33	OUT	DX,AL
34	PUSH	AX
35	POP	AX
36	IN	AL,DX
37	AND	AL,010H
38	SHR	AL,1
39	RET
40POR_1	ENDP
41
42;----- READ THE SWITCH SETTINGS ON THE CARD
43
44RD_SWS	PROC	NEAR
45	ASSUME	DS:ABS0
46	MOV	DH,3
47	MOV	DL,MISC_OUTPUT
48	MOV	AL,1
49	OUT	DX,AL
50
51;----- COULD BE 0,4,8,C
52
53	MOV	AL,0DH
54	CALL	POR_1
55	SHR	AL,1
56	SHR	AL,1
57	SHR	AL,1
58	MOV	BL,AL
59
60	MOV	AL,9

61	CALL	POR_1
62	SHR	AL,1
63	SHR	AL,1
64	OR	BL,AL
65
66	MOV	AL,5
67	CALL	POR_1
68	SHR	AL,1
69	OR	BL,AL
70
71	MOV	AL,1
72	CALL	POR_1
73	OR	BL,AL
74
75	AND	BL,0FH
76	RET
77RD_SWS	ENDP
78
79;----- OBTAIN THE FEATURE BITS FROM DAUGHTER CARD
80
81F_BTS	PROC	NEAR
82	MOV	DH,3
83	MOV	DL,0BAH
84	MOV	AL,1
85	OUT	DX,AL
86	MOV	DL,0DAH
87	OUT	DX,AL
88	MOV	DL,IN_STAT_0
89	IN	AL,DX				; READ FEATURE BITS
90	AND	AL,060H
91	SHR	AL,1
92	MOV	BL,AL
93	MOV	DL,0BAH
94	MOV	AL,2
95	OUT	DX,AL
96	MOV	DL,0DAH
97	OUT	DX,AL
98	MOV	DL,IN_STAT_0
99	IN	AL,DX				; READ FEATURE BITS
100	AND	AL,060H
101	SHL	AL,1
102	OR	AL,BL
103	RET
104F_BTS	ENDP

superfury wrote on 2025-12-23, 05:24:

If the bits were truly read inversed, this wouldn't be true? So the bits shouldn't be read inversed on EGA?

There's no reason to jump to that conclusion. The switches can be read in one order and written to the BDA in different order.

GloriousCow wrote on 2025-12-23, 19:19:

superfury wrote on 2025-12-23, 05:24:

If the bits were truly read inversed, this wouldn't be true? So the bits shouldn't be read inversed on EGA?

There's no reason to jump to that conclusion. The switches can be read in one order and written to the BDA in different order.

Just read the above code. Bits 2,3 are the used dipswitches to read.
Bit 4 from the read is the bit containing the result.
Thus:
switch 11b(3) bit 3 shr 3=>bit 0(=>BL)
switch 10b(2) bit 3 shr 2=>bit 1(=>BL)
switch 01b(1) bit 3 shr 1 =>bit 2(=>BL)
switch 00b(0) bit 3 shr 0=>bit 3(=>BL)
The resulting BL is anded with 0xF(filtering out upper bits) and then stored into address 488h I think I can remember. Which is documented to be having a SW1 order there, thus the conclusion.
It's definition is:
Bit 0=SW1(1=off)
Bit 1=SW2
Bit 2=SW3
Bit 3=SW4

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.

1mov ax,40h
2mov es,ax
3and byte ptr es:[87h],9Fh
4mov ax,0Eh
5int 10h
6.....

Those bits are literally written to the BDA as-is, combined with the 4 bits (shifted left) of the F_BTS function.
That literally is the source code (decompiled I think, but not sure) of the EGA BIOS itself that SoftCat posted.
The only issue with the source code is a newer MASM versions compiling slightly different on one instruction (requiring manual db bytes for the encoding there to 100% match the binary file gotten from minuszerodegrees, for example).

the MK_ENV literally stores it at said BDA address, nothing more (from BL).

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).

One nice thing about the publicly avaiable disassembly of the EGA BIOS is that I can create a mapping file with all the addresses of the instructions, thus allowing me to set breakpoints at specific addresses I'm interested in while debugging the EGA POST.