• Please review our updated Terms and Rules here

The myth of the vertical retrace interrupt on EGA/VGA

S

Scali

Veteran Member
Joined
Dec 13, 2014
Messages
2,024
Location
The Netherlands
Over the years, I've heard various stories on the vertical retrace interrupt on EGA/VGA cards, and how this may or may not be supported, is broken, or whatever...
So I want to put this myth to bed and find out what's what.
To begin at the beginning... IBM first implemented a vertical retrace interrupt on the PCjr in 1984. This is implemented on IRQ5. The interrupt is always enabled on the video chip, but is masked on the 8259A PIT by default.
Later that year, IBM introduced EGA. It also has a vertical retrace interrupt, but it works differently. It is implemented on IRQ2, but it is not enabled by default.
EGA has an extended/enhanced version of the 6845 CRTC. The IRQ control is implemented in bits 4 and 5 of register 11h (vertical retrace end) of the 6845, which is on port 3D4h.
Bit 5 is set by default, which disables(!) the IRQ. Set it to 0 to enable the IRQ.
Bit 4 is used to acknowledge the interrupt. When an interrupt occurs, you first write a 0 to bit 4 to clear the interrupt, then you write a 1 again, so a new interrupt can be triggered.
See the IBM EGA manual at page 72 for the description: http://minuszerodegrees.net/oa/OA - IBM Enhanced Graphics Adapter.pdf

While I have never found the original VGA manual, I did find the IBM VGA/XGA manual from 1992, which fully documents VGA as well: http://mcamafia.de/pdf/ibm_vgaxga_trm2.pdf
And if you look at page 2-69, it documents this functionality in the exact same way as EGA. So this proves that VGA/XGA are fully backwards compatible with the vertical retrace interrupt of EGA.

However... if you run DOSBox, the IRQ only works if you set machine=ega. Why is that?
Also, if you check OSDev.org, they do not document these bits and the functionality at all: https://wiki.osdev.org/VGA_Hardware#Registers
The same goes for osdever.net: http://www.osdever.net/FreeVGA/vga/crtcreg.htm#11
This seems to be revisionist history...

So, I decided to make a little test-program: https://www.dropbox.com/s/bzobfyhmppin435/vretirq.zip?dl=0
It basically enables the vertical retrace IRQ, and installs a handler that increments a counter every time it is triggered.
The program constantly prints the value of this counter in the top left corner of the screen. So you can easily verify whether it works or not: if it works, it should increment at the refresh rate of the screen (generally 60 or 70 Hz).
The following keys are supported:
ESC - exit the program
1 - switch to 80x25 textmode (mode 03h)
2 - switch to 320x200x16 mode (EGA mode 0Dh)
3 - switch to 320x200x256 mode (VGA mode 13h)

I tested it on my 486 with Diamond SpeedStar PRO VLB, and as expected, the counter counts up in all three modes.
So I would like everyone with an EGA, VGA, SVGA or XGA system to run this program, and report their video card and whether or not the counter counted up.
 
I remember Dave Haynie talking about this on Usenet. IIRC he mentioned that in his experience some devices that at first appear to trigger the interrupt correctly actually do so with no apparent relationship with the vertical retrace, i.e. the interrupt could occur at any time. Dave seemed pretty horrified by the situation. I'll see if I can find the post.
 
cthulhu said:
I remember Dave Haynie talking about this on Usenet. IIRC he mentioned that in his experience some devices that at first appear to trigger the interrupt correctly actually do so with no apparent relationship with the vertical retrace, i.e. the interrupt could occur at any time. Dave seemed pretty horrified by the situation. I'll see if I can find the post.
Click to expand...

That is interesting... perhaps for version 2 of my test-program, I should change the palette when the IRQ fires, and turn it off again at the next scanline.
Then you will have a visual cue of the raster position at which the IRQ is triggered.
 
Is this the optional IRQ 9 enable jumper I've seen on a few SVGA cards..... and in the configuration for my old Matrox G400? All the documentation states its for some EGA software, but not much else.
 
Couple results:

386DX/25, no-name board based on a "Solutions" chipset, ET4000AX ISA (Diamond SpeedStar), PC-DOS 2000 - works in all three video modes

P233MMX, i430TX (Advantech single-board PC on a 14-slot ISA backplane), S3 Virge DX PCI, FreeDOS 1.1 - doesn't work in any mode (i.e doesn't count any interrupts & sits at zero)
^^ I tried both FreeDOS's JEMMEX and Microsoft's HIMEM/EMM386 just in case that made any difference. Same result.

I'll try it on a couple more DOS PCs I have around when I get some more time.
 
modem7 said:
Probably. See [here].
Click to expand...

I don't agree with that explanation though.
Only real CGA suffers from snow on VRAM access, and only in 80x25 textmode. Many clone CGA cards already solved the snow-issue.
Neither the PCjr nor the EGA suffer from snow on VRAM access.
The use for the IRQ is more to facilitate tear-free animation (eg page-flipping), and changing the palette outside of the visible area.

I don't know of any software that uses it, but it seems that at least for VGA it's not very important, as there are various cards that either don't support it at all, or have a jumper to enable it, and are configured with the IRQ disabled by default. DOSBox also doesn't emulate it, unless you configure it to machine=ega.
Yet all VGA software appears to run fine on such machines.

I have tested three of my own machines so far:
Diamond SpeedStar PRO VLB, CL5426 chipset: works fine in all modes, IRQ generated directly at the end of the visible area.
Unbranded Tseng Labs ET4000AX ISA: works fine in all modes, IRQ generated directly at the end of the visible area.
Paradise PVGA1A 8-bit ISA: IRQ is generated in all modes, but seems to appear at 'random' places on screen, jumping all over the place, so it does not seem to be synchronized with the refresh rate at all (although I cannot rule out that there is other hardware that also generates IRQ2, since I tested in a Commodore PC20-III with a custom chipset and Amiga-compatible bus mouse, which may use IRQ2 as well. I will have to try the card in the ET4000-machine to be sure).
 
An update on the Paradise PVGA1A card:
I have tested the card in my 486, which is known to work correctly with the CL5426 card. The PVGA1A did not work in it.
My suspicions were correct: the card's PCB does not have the 'B4' pin on the ISA bus for IRQ2, so it physically cannot generate an IRQ2 at all. So the IRQ2s in the Commodore PC20-III must have been generated by some other hardware (question is: what? Must be something onboard, since there were no other ISA cards installed).

I found the datasheet for the PVGA1A here: http://datasheet.datasheetarchive.com/originals/scans/Scans-091/DSAHI000175793.pdf
And yes, it documents pin 35 as being the vertical retrace IRQ pin.
It also says this: "In an AT system IRQ is not connected, but it may be connected if desired".
They say that IRQ9 is used in Microchannel mode. What exactly does that mean then? VGA is originally a standard from PS/2, so it is normally connected. Why would you not connect it in an AT? EGA had it connected, and that has nothing to do with PS/2 or MCA.

The chip apparently has separate 'AT' and 'MCA' modes... perhaps they mean that in AT mode, the IRQ isn't generated? Weird.

Over at the Vogons forum, someone has been testing with Trident 8900 and 9000 cards, and found the same thing: the IRQ2 line was not connected on the PCB at all, but the chips do have IRQ pins. So he connected a wire from the Trident chips to the proper ISA pin on both cards, and in both cases the IRQs worked fine.
 
Scali said:
That it behaved correctly, and signaled an interrupt at the end of the visible area every frame, as per the IBM EGA, VGA and XGA specification.
Click to expand...

Not to nit-pick, but what would the observer see? Would performance or viewing be noticeably enhanced?
 
Agent Orange said:
Not to nit-pick, but what would the observer see? Would performance or viewing be noticeably enhanced?
Click to expand...

I don't think the user would notice a difference. It seems that because of the poor support of this functionality on clone VGA systems, that it was rarely used by software, if at all.
My intention with this thread is two-fold:
1) To see if we can get a decent idea of how well-supported this feature really is, and whether developers in the past were right to avoid this functionality.
2) If it is supported widely enough, I might use it in my future DOS demos. The PC platform has a nasty shortage of timers. Being able to use the 8253 PIT for music and timing the graphics on the vertical retrace would make some things a lot easier/more accurate.
 
I've updated the code: https://www.dropbox.com/s/bzobfyhmppin435/vretirq.zip?dl=0
It now supports an optional parameter, so you can specify the IRQ (between 0 and 15):
Code: 
vretirq 11
If you don't specify anything, it still defaults to IRQ 2, as before (on a standard AT, it should work with both IRQ2 and IRQ9, since the AT BIOS has a default IRQ9 handler which redirects to a software IRQ2, to remain backward-compatible with the PC and XT).

Interestingly enough, some modern Plug&Play systems do actually still support the vertical retrace IRQ, but it is just not configured at IRQ2/9 where you expect it. It may be at IRQ10, 11 or wherever the BIOS saw fit. But it does get generated properly, so it can be used.
 
Another update:
Someone over at Vogons had a PVGA1A card as well, and connected a wire from pin 35 on the PLCC to pin B4 on the ISA slot (IRQ2). Vertical retrace interrupt works fine, just like the Trident.
He also tested an ET3000... and it is the first card that actually seems broken. As in, it generates a few IRQs, and then just stops for no apparent reason.
All other cards tested so far, either worked just fine, or didn't work at all (where some just lacked a trace on the PCB and could be patched with a simple wire).
 
You must log in or register to reply here.
Back
Top