I **think** that is IBM speak for "no new addresses will be generated during the blanking period". But I am not 100% sure.

If it's the same as the VGA, then blanking should only affect the DAC(it's a direct input line on the DAC), clearing the RGB signals of the monitor(analog) to a near-zero level. That doesn't affect VRAM fetching in any way. Since the VGA should be EGA-compatible, the EGA will probably do the same?

Bit 0 is set at all times when the EGA is not actively fetching and displaying data. In your case this would be for all of lines 350-364, or in lines 0-349 when the horizontal counter is less than display end.

I'm assuming by bit 7 you mean bit 3? Bit 7 of 3da isn't used. Bit 3 should be set purely during the vertical retrace - lines 351 to 362 in your diagram. Though I'd expect the retrace period to be shorter than blanking.

IBM do seem to have got their terms a bit mixed up in their documentation - bit 0 has nothing to do with retrace! I think by display enable they also mean from the perspective of the CRTC - ie time actively spent fetching and displaying data - rather than the user perspective, which would include the border as well. I'd certainly only expect 350 1->0 transitions on bit 0 in your example frame.

Looking at your timings again, they seem correct. Only bit 7 of the status byte won't clear until acnowledged by clearing bit 4(or 5) of the vertical retrace end register(bit7 is also the interrupt line output). Also only when bit 4/5 is reset/set is the IRQ/bit 7 raised.

I've spent far too much time reading IBM EGA reference and I can't find who drives bits 0 and 3 when the Status Register 1 (0x3DA/0x3BA) is read!
Or even how reading that port is detected by attribute controller so the address/data latch is reset. This drives me crazy, it's got to be an error.
I have the August 2, 1984 manual.

So, not knowing how specifically EGA handles the DE since the CRTC is a custom LSI albeit based on the Motorol CRTC, usually DE means active data from graphics memory.
So in my opinion in a 640x350 graphics mode, DE would be high only during the 640 active pixels per row, on the 350 active scanlines, and on the rest of the non-active pixels and scanlines, it will be low.
And it appears the EGA has DE, while VGA has inverted DE signal for some reason (maybe software that wait for DE to be offscreen to write data is faster on VGA because of this?)

So, any area between DE active and BLANK is border.

Isn't the VGA supposed to be (100%) EGA-compatible? So far already found a few differences(Feature control related results(unexistant on VGA?), MUX output results(DAC index bits 6-7 only), DAC nonexistant or fixed entries on EGA(64 DAC entries, rest is wrapped like DAC Mask register being 0x3F?), Misc Output register bit 4(Use Feature Control register as output instead of DAC Index?). Is that correct?

Also, currently working on a strange memory error(Misc Output Register is cleared!) causing missing font in text mode plane 2 and BIOS unable to display itself?

I think VGA can't be 100% EGA compatible, ever. First of all the pixel clocks are different, so therefore if software assumes something about horizontal or vertical rates being EGA it works differently on VGA. If the software programs a custom mode, it better know if the card is EGA or VGA.
EGA is 60Hz only, while on a VGA the modes are 70Hz and even the 350-line mode is in reality a 400-line mode but the sync polarities are set so that VGA monitor displays the 350 lines like an EGA monitor.
Yup, there sure is no DAC on an EGA.

Also, the Video Load Rate and Memory Adress clocks are based on 'half-character' clocks(every 4/5(at 9 pixel width every other half-character clock) pixels) in much the same way, being parallel(in my VGA emulation).

Jepael wrote:

sync polarities are set so that VGA monitor displays the 350 lines like an EGA monitor.

640x350@70 and 640x400@70 differ in the vertical active time and the vertical backporch (the sync time and the vertical frame size are same). A monitor can use this to detect.

Gamecollector wrote:

Jepael wrote:

sync polarities are set so that VGA monitor displays the 350 lines like an EGA monitor.

640x350@70 and 640x400@70 differ in the vertical active time and the vertical backporch (the sync time and the vertical frame size are same). A monitor can use this to detect.

Of course they differ, but the monitor can't detect it because there is no information to monitor which lines are active, it has only syncs.

So to the monitor, a full screen 640x350 photo in 640x350 mode is identical to same 640x350 photo centered on 640x400 mode with 25 black lines on top and bottom, so monitor can only detect which mode is used from the sync polarities.

Jepael wrote:

there is no information to monitor which lines are active

Maybe. The full black line and the blank line looks similar (R = G = B = 0 V).
But as the example - Voodoo2 640x400@70 uses the NN polarity. And is displayed ok on my LCD...

The correct test must be something like "set mode 10h, set MOR[6] to 0, set MOR[7] to 1, draw the picture".

SarahWalker wrote:

IBM do seem to have got their terms a bit mixed up in their documentation - bit 0 has nothing to do with retrace! I think by display enable they also mean from the perspective of the CRTC - ie time actively spent fetching and displaying data - rather than the user perspective, which would include the border as well.

As I understand it, DISPLAY_ENABLE was introduced on CGA for one reason: CGA snow.
It is a direct indicator of whether or not the CGA logic is fetching memory, so you can use it to determine when it is 'safe' to write to memory without causing snow.
In practice this means that it does include both horizontal and vertical borders, since CGA only fetches memory for the active display area. It cannot draw in the borders.
It is indeed not exactly the same as horizontal blank or horizontal retrace, but with lack of other bits to indicate such a status, people interpreted it as such in practice, when they wanted to detect the start/end of a scanline for whatever reason.

I suspect that EGA and VGA still work in the same way, for backward compatibility.

@vladstamate: I just looked at the CAPE source code on the public git repository. I don't see any traces of your EGA emulation to compare my (S)VGA emulation to, to check for errors(assuming the CPU itself is working without problems). If the VGA vs EGA incompatibilities are fixed, then if it doesn't work after that, the CPU emulation(happens on all my x86 CPU emulators in UniPCemu) must be at fault(thinking logically).

@Jepael: Besides the actual clocking being different, isn't the rough effects of the register bits the same(except those few bits I've found that differ comparing EGA vs (free)VGA documentation)? Comparing the EGA documentation on minuszerodegrees to the freeVGA documentation shows that only a few bits in a few register are entirely different(the VGA adding more bits to the same registers to apply to bigger ranges and adding extra functionality, like the 8-bit sequencer mode bit in the graphics registers). So it should be enough to simply mask those bits off when interpreting them on the EGA(making them simply buffer bits that are unused by the emulation)? Or are those EGA bits actually unmapped memory, making all values written them become zeroes when read back? In that case, a simple mask on all VGA registers should be enough to emulate VGA(the same can be done when applying them to rendering, memory mapping etc. to make the byte values partially ineffective, archieving EGA compatibility)

superfury wrote:

@vladstamate: I just looked at the CAPE source code on the public git repository. I don't see any traces of your EGA emulation to compare my (S)VGA emulation to, to check for errors(assuming the CPU itself is working without problems). If the VGA vs EGA incompatibilities are fixed, then if it doesn't work after that, the CPU emulation(happens on all my x86 CPU emulators in UniPCemu) must be at fault(thinking logically).

The changes are not yet in the public repository. I will provide you with the current code in a personal message.

superfury wrote:

@Jepael: Besides the actual clocking being different, isn't the rough effects of the register bits the same(except those few bits I've found that differ comparing EGA vs (free)VGA documentation)? Comparing the EGA documentation on minuszerodegrees to the freeVGA documentation shows that only a few bits in a few register are entirely different(the VGA adding more bits to the same registers to apply to bigger ranges and adding extra functionality, like the 8-bit sequencer mode bit in the graphics registers). So it should be enough to simply mask those bits off when interpreting them on the EGA(making them simply buffer bits that are unused by the emulation)? Or are those EGA bits actually unmapped memory, making all values written them become zeroes when read back? In that case, a simple mask on all VGA registers should be enough to emulate VGA(the same can be done when applying them to rendering, memory mapping etc. to make the byte values partially ineffective, archieving EGA compatibility)

Well, first of all, I am not an EGA expert - most of my experience is about VGA. But yes, VGA does have extra bits of certain EGA registers in so called "Overflow" registers, and the special mode of concatenating fetched 4-bit pixels to 8-bit pixels. And at least some (most?) of EGA registers were write only and cannot be read back, but you should resort to specs about them - I don't know what is read back from them. And no DAC on EGA, so all pixels are basically 4-bit but converted to 6-bit for displaying on EGA monitor (which is 6-bit only in 350-line mode, and only 4-bit in 200-line mode). And what's most important is that in every case the dark brown color is dark brown, not dark yellow - unless the 350-line mode palette is changed.

@vladstamate: I see one BIG difference between your code and my code: the VRAM enable bit in your code(misc output register bit 1 if I'm not mistaken, check EGA/VGA/freeVGA manuals for that) isn't emulated: in your case VRAM is always visible to the CPU, thus no problems. In my case, the register is fully cleared, causing the CPU to not be accessing VRAM anymore(memory hole). This might cause the problem in my case.

@Jepael: The VGA DAC is loaded with the Dosbox EGA DAC colors when initialized(DAC Mask register being 0x3F) to simulate the EGA color outputs. Since the DAC I/O is disabled in EGA mode, the EGA should work like a normal EGA, color- and register-wise.

The read operation mapping for I/O ports of the VGA have been partly disabled on the EGA emulation(Indexed registers etc.) to simulate the EGA more accurately. The VGA registers aren't masked yet, though, so VGA outputs are still possible if those values are written to the registers(EGA undefined but VGA defined bits are handled as VGA bits).

I've just found a little bug in the Dosbox EGA palette(which i use with my EGA emulation): the EGA palette is invalid! The first 32 entries are replicated accross the second 32 entries! Thus actually generating a 32 color palette/DAC instead of 64 color palette/DAC! Anyone has the correct values to load into the VGA(or EGA with VGA-compatible palette generation)?

superfury wrote:

@vladstamate: I see one BIG difference between your code and my code: the VRAM enable bit in your code(misc output register bit 1 if I'm not mistaken, check EGA/VGA/freeVGA manuals for that) isn't emulated: in your case VRAM is always visible to the CPU, thus no problems. In my case, the register is fully cleared, causing the CPU to not be accessing VRAM anymore(memory hole). This might cause the problem in my case.

That is not it. I just added support for that and EGA still works in both XT and AT configuration. In fact I tried default off and on for bit 1 and it was still fine. The EGA BIOS sets that properly.

You really need to log the 0xC0000->0xF0000 and compare that against the BIOS listing. No point guessing.

superfury wrote:

I've just found a little bug in the Dosbox EGA palette(which i use with my EGA emulation): the EGA palette is invalid! The first 32 entries are replicated accross the second 32 entries! Thus actually generating a 32 color palette/DAC instead of 64 color palette/DAC! Anyone has the correct values to load into the VGA(or EGA with VGA-compatible palette generation)?

Yes you can look at my palette. It matches what I found on the web (wikipedia) as well as what PCEm uses.

EDIT: although PCEm's is dynamicaly generated and mine is static. The values match.