The myth of the vertical retrace interrupt

This is a draft from March 18th, 2019. We’re slowly cleaning out the backlog. The few remaining drafts are going to take more time to work into an article though, as actual code or configuration is required to work out the idea I wanted to write about. This article was also like that, except that someone else ‘adopted’ it along the way.

The topic is vertical retrace interrupts, specifically on the early PC platform. The first few display standards on PC did not have any kind of display interrupt. For MDA, CGA and clones based on these standards, such as Hercules and Plantronics ColorPlus, the only way to get any indication of the video signal was to poll the status registers. In 1984 this changed, because two things happened in 1984: the IBM PCjr, and the EGA standard.

Both the IBM PCjr and EGA introduced a vertical retrace interrupt (or vsync interrupt), but in good IBM tradition, they were incompatible with each other. On the IBM PCjr I can be short about things: there was only one IBM PCjr, and only one successful clone of its video standard: the Tandy 1000. On the real PCjr the vertical retrace interrupt works flawlessly. And on the Tandy 1000 it is the same. With one small exception: the PCjr uses IRQ5 for its vertical retrace. This was also used by certain other hardware, such as printer ports, harddisk controllers and sound cards. This is why certain Tandy 1000 models allow you to disable the vsync interrupt on the motherboard, so it can be used by other hardware without problems. Clearly, this will break compatibility with the PCjr’s vsync interrupt. But as long as IRQ5 is enabled for vsync, it will work fine on Tandy machines as well.

So what is this titular myth then? In the documentation of EGA and VGA, the vsync IRQ is clearly documented. But in software it seems to be elusive. No software seems to actually use it. So what is going on? Why wouldn’t you use such a feature?

The can of worms is with EGA, for multiple reasons. Firstly, the EGA standard was cloned by numerous vendors. Secondly, VGA was a superset of EGA, and as such backward-compatible with its vsync IRQ (or at least it should be), and VGA was also cloned and extended by numerous vendors, and lives on in PC display controllers to this day. Lastly, even IBM made a mess of things with VGA.

A few years ago, I got a PCjr myself, and started using the vsync IRQ on it. It can be quite a useful way of synchronizing the screen with audio and other routines. Since I vaguely knew about a vsync IRQ on EGA, I wanted to find out if I could use it on EGA/VGA systems as well. But I also knew that nobody seemed to be doing that, and was vaguely familiar with issues regarding its use. I tried to do a survey, to figure out what’s what. I wrote some small test utilities and created some threads on retro-computing forums, asking people to test on all kinds of EGA and VGA cards, and report their findings.

I managed to get quite a bit of useful information. I had already come to the conclusion for myself that indeed using the vsync IRQ for EGA/VGA was not feasible, as there would be too many compatibility issues in practice. So my interests in the vsync IRQ issue shifted to just documenting what I had found. Which would have been this blog, but it never got written at the time, and was more or less forgotten.

However, since my threads and utilities were out in the open, other people also got interested in the issue. And a few months ago, PCRetroTech posted this video on their YouTube channel:

It pretty much wraps up my experiments and presents all the information you need to know about the vsync IRQ, which had been scattered around some threads on some forums, or only known by a few people who bothered to dig into it.

In short I suppose we can mention these problems:

1. Real IBM EGA seems to work reliably, but clone chipsets may or may not. At any rate, the interface is really clumsy because it’s not a fire-and-forget mode like on the PCjr. You have to acknowledge every interrupt and then set up the CRTC to generate the next interrupt. It will always be somewhat error-prone.
2. Some clones appear to have some states inverted, so they may work reliably, but you’d need to use alternative code.
3. IBM VGA was designed for PS/2, which has level-triggered interrupts, instead of the edge-triggered interrupts on classic ISA systems. IBM produced a VGA adapter for ISA systems (pictures here), but left the IRQ line disconnected from the ISA bus. This may have been because the chip was not designed to work reliably in an edge-triggered configuration. At any rate, this means that even the original IBM VGA standard does not support IRQ in all configurations.
4. Various clone chips do implement the IRQ, but whether or not it is connected to the ISA bus depends on who integrated the VGA chipset on the ISA board. There are boards where there is a jumper to enable/disable the IRQ. There are also boards where the line is not connected at all. People have experimented with running a wire from the ISA slot to the correct pin on the VGA clone chip, and in some cases this actually worked reliably.
5. EGA chose IRQ2 for the vsync IRQ. This is the same IRQ that is used for the AT to cascade its second interrupt controller. In effect the real IRQ2 line on the ISA bus is rerouted to IRQ9 (you will often see it listed as IRQ2/9) on an AT, and the IRQ trigger on the second controller is connected to IRQ2 on the first controller. This means there are even more potential problems for using the vsync IRQ on ATs and newer systems, as the IRQ signal actually travels through both controllers, and they both have to be signaled and acknowledged correctly.

All these potential problems related to the vsync IRQ explain why nobody ever seems to have used it on EGA/VGA. Developers probably all came to the same conclusion sooner or later: it’s just never going to work reliably on a wide range of configurations.

I guess all the low hanging fruit of drafts is now gone, so it will take a bit longer to address the few remaining ones (and I have already pulled this one ahead, so we are no longer working in chronological order). Hopefully that won’t mean they’ll just lie there in waiting for some more years, as the earlier ones have.

Advertisement