The myth of the vertical retrace interrupt on EGA/VGA

Discussion about old graphics cards, monitors and video related things.

Re: The myth of the vertical retrace interrupt on EGA/VGA

Postby Tiido » 2018-2-17 @ 19:25

PLCC is lot easier to deal with than the QFPs I had to mess with. It will be very easy to solder a wire to a pin and very easy to clear out any bridge (desoldering braid/wick makes it super easy). Lacking a pad like on my Trident cards makes things incovenient, I had to shove a wire directly to ISA slot, but if there is a pad (that isn't connected) it will be very easy to solder a wire to its top as seen here : http://www.tmeeco.eu/BitShit/FlashAndSRAMcart.jpg

That BIOS function makes things mech easier, just got to know what particular INTx line your card is connected to and hope there aren't other cards signalling ints there. Each slot changes order of the INTA/B/C/D lines so depending on what slot your card is in the PCI INT assigment will change. i.e one slot has ABCD order, second slot BCDA, another CDAB and then DABC and things start over and some cards will then share INT line at that point. Another option would be just to use the IRQ that BIOS assigned if it did. The assignment should stay static as long as no new hardware is added, though this won't help with any software explicitly wanting IRQ9.

MIDI or other sound stuff sitting on IRQ2/9 will most probably intefere too...
User avatar
Tiido
Oldbie
 
Posts: 800
Joined: 2018-1-14 @ 04:40
Location: Estonia

Re: The myth of the vertical retrace interrupt on EGA/VGA

Postby Scali » 2018-2-18 @ 02:38

Tiido wrote:PLCC is lot easier to deal with than the QFPs I had to mess with. It will be very easy to solder a wire to a pin and very easy to clear out any bridge (desoldering braid/wick makes it super easy).


Not in this case, I'd say.
The soldering is under the chip, so you can't reach it. And you can't really solder anything to the sides of the pins either, because the card I have is so tightly packed that there's not enough room to get the soldering iron between the chip and the other components. I'm not going to try anyway.
I might have more luck if I just try to tape a wire to the right pin with some sticky tape :)

Tiido wrote:Lacking a pad like on my Trident cards makes things incovenient, I had to shove a wire directly to ISA slot


Yea, no pad on the Paradise either.

Tiido wrote:Another option would be just to use the IRQ that BIOS assigned if it did. The assignment should stay static as long as no new hardware is added, though this won't help with any software explicitly wanting IRQ9.


Well, at the very least I can extend my test-program a bit, and let the user specify the IRQ they want to test on the command line.
That way you can test if your card generates the interrupt on the IRQ that the BIOS assigned, without having to try to get the card configured at IRQ2/9.

Tiido wrote:MIDI or other sound stuff sitting on IRQ2/9 will most probably intefere too...


Technically it shouldn't.
Since IBM designed the EGA card in the age of the AT, they already knew about IRQ2 and interrupt sharing.
So even in the manual they specifically say that when the interrupt fires, you should check the EGA status register to see if the IRQ bit is set there as well.
If it is, then you know the EGA card generated the interrupt. If not, it was some other hardware.
My test program at least checks the status register, so it should filter out interrupts generated by MPU-401 or whatnot.
(which didn't work on my Commodore PC20-III with the Paradise card, since apparently the Paradise card did generate an IRQ, and so it did set its internal bit... the IRQ was not connected to the ISA bus though, so the CPU never knew. When another device triggered IRQ2, I checked the status bit on the Paradise card, and it said it generated an IRQ... which it did, just not at the time my handler got triggered).
Scali
l33t
 
Posts: 4108
Joined: 2014-12-13 @ 14:24

Re: The myth of the vertical retrace interrupt on EGA/VGA

Postby Tiido » 2018-2-18 @ 07:13

Right, I forgot there's that socket in the way. You could take out the chip, then use a wire strand from one of the 80 wire HDD cables and stick it behind the socket pin then put the chip back, the wire should stay in place very well.
http://www.tmeeco.eu/BitShit/PLCCwire.jpg

Allowing custom IRQ set would be good, it will be lot easier to test newer setups without changing any settings or hardware in significant manner.

I was more thinking about multiple cards not being allowed to physically drive the pin at the same time. The IRQs are active high and cards drive the signal to get an IRQ, two cards one driving it low (to prevent IRQ) and another high (to get an IRQ) will cause contention and it isn't healthy for the things involved. Perhaps some newer things do the driving only when absolutely needed but when I have looked some older card schematics there's no sort of "drive only when IRQ needed" circuit involved. Life would be lot easier if the IRQs were active low and supposed to be driven in open drain/collector manner, which won't cause any headaches to anyone involved. Intel/IBM and their odd active high logic choices....
User avatar
Tiido
Oldbie
 
Posts: 800
Joined: 2018-1-14 @ 04:40
Location: Estonia

Re: The myth of the vertical retrace interrupt on EGA/VGA

Postby Scali » 2018-2-19 @ 09:56

I've updated the code: https://www.dropbox.com/s/bzobfyhmppin4 ... q.zip?dl=0
It now supports an optional parameter, so you can specify the IRQ (between 0 and 15):
Code: Select all
vretirq 11

If you don't specify anything, it still defaults to IRQ 2, as before.
Scali
l33t
 
Posts: 4108
Joined: 2014-12-13 @ 14:24

Re: The myth of the vertical retrace interrupt on EGA/VGA

Postby Tiido » 2018-2-19 @ 13:10

My C2D with PCI-E Radeon X550 shows IRQs when I specify 10, but it only works in pure DOS, in Windows the machine will show no counting and then reset shortly after as it seems to upset all the other devices that IRQ10 is shared with. On the other machines IRQs do count and there's no crashes in Windows as long as you go full screen.
The NeoMagic128 based laptops behave the same way, crashing in windows lol. Pure DOS is ok.
User avatar
Tiido
Oldbie
 
Posts: 800
Joined: 2018-1-14 @ 04:40
Location: Estonia

Re: The myth of the vertical retrace interrupt on EGA/VGA

Postby Scali » 2018-2-19 @ 13:16

Yea, this binary is pure 16-bit DOS and really not meant for anything else.
It could be that Windows installs its own interrupt handlers, and if I take over an interrupt with my handlers, something breaks.
I take over both the keyboard and the specified VGA IRQ.
I could call the old handlers just in case. But I don't see too much of a point in that. It is not reliable to test under Windows, because it may virtualize some of the hardware (it may actually use the IRQ for the GUI and/or DirectX). The only reliable way to test is pure DOS.

Anyway, it is interesting to see that the newer Plug&Play devices do actually still generate the IRQ, just not on IRQ2/9 where you expect it.
This means that if I develop software with this functionality, and allow configurable IRQs (or try to autodetect myself), it will be compatible with a wider range of hardware.
Scali
l33t
 
Posts: 4108
Joined: 2014-12-13 @ 14:24

Re: The myth of the vertical retrace interrupt on EGA/VGA

Postby ripsaw8080 » 2018-2-19 @ 14:51

Scali wrote:if you run DOSBox, the IRQ only works if you set machine=ega. Why is that?

I believe the history of that, at least in part, is here: viewtopic.php?f=32&t=18585
User avatar
ripsaw8080
DOSBox Author
 
Posts: 4374
Joined: 2006-4-25 @ 23:24

Re: The myth of the vertical retrace interrupt on EGA/VGA

Postby Scali » 2018-2-20 @ 10:43

ripsaw8080 wrote:I believe the history of that, at least in part, is here: viewtopic.php?f=32&t=18585


Yea, I guess it's just an arbitrary decision...
Given that we have proof that quite a number of VGA cards implement the IRQ correctly, I would like to have it enabled by default, at least in the 'vgaonly' configuration. You could argue that it won't work in all of the SVGA modes, because perhaps not all chipsets/boards implement it.
Perhaps it could also be made a configuration setting.

Also what I really want is someone to test it on a real IBM PS/2. That is our reference. If it works there (and I'm pretty sure it will) then it MUST work in the emulator, if you ask me. Because that is the VGA standard. Why disable something in an emulator because some clones are broken? You don't want to emulate broken clones, you want to emulate VGA. IBM VGA.
Scali
l33t
 
Posts: 4108
Joined: 2014-12-13 @ 14:24

Re: The myth of the vertical retrace interrupt on EGA/VGA

Postby Jo22 » 2018-2-20 @ 16:39

Hi, that's an interesting thread! :)
I did a few tests with my ISA cards, too..

OTI37C w/ IRQ2/9
Jumper JP1
oti037c_irq2.jpg
oti037c_irq2.jpg (32.81 KiB) Viewed 323 times


ET3000AX w/ IRQ2/9
Jumper JP2
*counter stops at 4
et3000ax_irq2.jpg
et3000ax_irq2.jpg (30.9 KiB) Viewed 323 times


TVGA8900s w/ IRQ2/9
Jumper J1
8900s_irq2.jpg
8900s_irq2.jpg (31.91 KiB) Viewed 323 times


TVGA8900B w/ IRQ2/9
Jumper J2 ?
8900b_irq2.jpg
8900b_irq2.jpg (31.29 KiB) Viewed 323 times
Last edited by Jo22 on 2018-2-20 @ 17:18, edited 1 time in total.
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//
User avatar
Jo22
l33t
 
Posts: 3558
Joined: 2009-12-13 @ 07:06
Location: Europe

Re: The myth of the vertical retrace interrupt on EGA/VGA

Postby Jo22 » 2018-2-20 @ 16:41

ET4000AX w/ IRQ2/9
Jumper J3
*may vary; wasn't soldered (I added pins+jumper)
et4000ax_irq2.jpg
et4000ax_irq2.jpg (30.55 KiB) Viewed 322 times


F82C451 w/ IRQ2/9
f83c451_irq2.jpg
f83c451_irq2.jpg (31.05 KiB) Viewed 322 times


>> Fail
PVGA1A1 8-bit
*prepared for jumpers
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//
User avatar
Jo22
l33t
 
Posts: 3558
Joined: 2009-12-13 @ 07:06
Location: Europe

Re: The myth of the vertical retrace interrupt on EGA/VGA

Postby Scali » 2018-2-20 @ 17:58

Jo22 wrote:ET3000AX w/ IRQ2/9
Jumper JP2
*counter stops at 4


Thanks for testing!
It seems that so far, there are more cards that work than ones that don't.
The ET3000 surprises me... Why would it count to 4 and then suddenly stop? Could be a synchronization issue.
Did you try switching between the three modes with the 1, 2, 3 keys? If so, what happens then? Does it count to 4 everytime you switch?

The ET3000 might be the first bugged chipset we've found so far. Whatever the issue is, they fixed it in the ET4000.
Scali
l33t
 
Posts: 4108
Joined: 2014-12-13 @ 14:24

Re: The myth of the vertical retrace interrupt on EGA/VGA

Postby BloodyCactus » 2018-2-20 @ 18:18

vretirq on 11 works for me now on a g400 max. I get a little very short white line over the "IRQ" in IRQs printout, not quite making it to the 's'.
--/\-[ Stu : Bloody Cactus :: http://kråketær.com :: http://mega-tokyo.com ]-/\--
User avatar
BloodyCactus
Oldbie
 
Posts: 842
Joined: 2016-2-03 @ 13:34
Location: Lexington VA

Re: The myth of the vertical retrace interrupt on EGA/VGA

Postby Jo22 » 2018-2-20 @ 18:34

I'm glad I could contribute a bit to the topic. :)
Scali wrote:Did you try switching between the three modes with the 1, 2, 3 keys? If so, what happens then? Does it count to 4 everytime you switch?

Sorry, I have missed to try different modes. Due to space limits, my desk was quite crowded,
and so I added the program to autoexec.bat and connected no keyboard to the mainboard (socket 7, Pentium 133MHz).
But as far as I can tell, the counter always stopped at either 3 or 4 (I checked about 5 times).
Also, the jumper did work at least. Without jumper set, the counter was zero.
I'll try the ET3000AX again tomorrow.. :)
Scali wrote:The ET3000 might be the first bugged chipset we've found so far. Whatever the issue is, they fixed it in the ET4000.

Yes, quite possible. The ET3000 had some -uhm- experimental features that were removed in the later ET4000 for some reason.
That hardware window feature comes to mind. it was related to textmode, I belive, but I'm not sure anymore.
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//
User avatar
Jo22
l33t
 
Posts: 3558
Joined: 2009-12-13 @ 07:06
Location: Europe

Re: The myth of the vertical retrace interrupt on EGA/VGA

Postby Jo22 » 2018-2-20 @ 22:55

Update. I tested the ET3000AX again. Unfortunately, the issue still persists.
This time, however, the numbers changed more than before.

What I did so far :
- Cleaned the contacts with a rubber
- Disabled L1 und L2 caches in CMOS Setup.
- Changed the ISA Bus frequency to 7.159 MHz
- Tried modes 1,2,3

Video: http://youtu.be/69H1DSKldIg

Card: http://www.vgamuseum.info/index.php/new ... g-et3000ax
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//
User avatar
Jo22
l33t
 
Posts: 3558
Joined: 2009-12-13 @ 07:06
Location: Europe

Re: The myth of the vertical retrace interrupt on EGA/VGA

Postby Jo22 » 2018-2-20 @ 23:08

Inspired by the posts of Tiido and you, I modified the PVGA1A I tested earlier (it looks like yours, btw.)
It turns out the good ol' Paradise card does indeed support IRQ2, even it isn't very stable. :)

After I connected pin #35 to the 4th lower ISA pin, I got weird glitches during POST.
At first, I was a bit scared of a short-circuit, since IRQ2 is surrounded by -5v and +5v,
but gratefully, the piece of wire was aligned perfectly..

Werid. Perhaps I overheated the wire and conductivity went bad ?
Anyway, after a bit of waggling and a few resets, the IRQ counter was running fine.
In all three modes. Even CheckIt! attested that IRQ was indeed active.

pvga_card.jpg
PVGA1A 8-Bit
pvga_card.jpg (33.19 KiB) Viewed 283 times


pvga_mod.jpg
Modifications
pvga_mod.jpg (35.72 KiB) Viewed 283 times
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//
User avatar
Jo22
l33t
 
Posts: 3558
Joined: 2009-12-13 @ 07:06
Location: Europe

Re: The myth of the vertical retrace interrupt on EGA/VGA

Postby Jo22 » 2018-2-20 @ 23:10

Some more pictures.

pvga_checkit.jpg
PVGA1A, CheckIt! detects IRQ2/9
pvga_checkit.jpg (26.04 KiB) Viewed 282 times


pvga_glitch.jpg
PVGA1A, Glitch
pvga_glitch.jpg (50.01 KiB) Viewed 282 times


pvga_mode1.jpg
PVGA1A, Mode 1
pvga_mode1.jpg (31.83 KiB) Viewed 282 times


pvga_mode2.jpg
PVGA1A, Mode 2
pvga_mode2.jpg (30.94 KiB) Viewed 282 times


pvga_mode3.jpg
PVGA1A, Mode 3
pvga_mode3.jpg (30.62 KiB) Viewed 282 times
"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//
User avatar
Jo22
l33t
 
Posts: 3558
Joined: 2009-12-13 @ 07:06
Location: Europe

Re: The myth of the vertical retrace interrupt on EGA/VGA

Postby Scali » 2018-2-21 @ 07:30

Okay, so like the Trident, the Paradise actually works fine, it's just the PCBs that don't allow the IRQ to work.
As for the ET3000, I think the issue may be that it loses sync. I can add a special option to vretirq which doesn't check if the interrupt was actually coming from the EGA/VGA card. There is a chance that this 'fixes' the problem on the ET3000.
Namely, if vretirq doesn't see the status bit indicating that the EGA/VGA card generated an interrupt, it will not reset the interrupt either, so a new one will never fire.
My guess is that the status bit on the ET3000 is broken, so after a while, we miss an interrupt, and we stop resetting it, so it stops firing. If we just ignore the status bit and always reset the interrupt, it may 'work' on the ET3000.
I'll add a commandline switch to ignore the status.
Scali
l33t
 
Posts: 4108
Joined: 2014-12-13 @ 14:24

Re: The myth of the vertical retrace interrupt on EGA/VGA

Postby Scali » 2018-2-21 @ 18:13

I've created a new version, which has an extra commandline parameter: https://www.dropbox.com/s/bzobfyhmppin4 ... q.zip?dl=0
Code: Select all
vretirq 9 /nostatus


With the '/nostatus' parameter (you need to specify the IRQ first, because I was too lazy to make fancy commandline parsing) you skip the check of the EGA input status register. I suspect that this register is somewhat broken on ET3000, so it fails the check after a few times.
Scali
l33t
 
Posts: 4108
Joined: 2014-12-13 @ 14:24

Re: The myth of the vertical retrace interrupt on EGA/VGA

Postby Ozzuneoj » 2018-2-22 @ 17:36

I've read through this thread and it's very interesting but I still don't understand the actual purpose of the "vertical retrace interrupt".

What do the discoveries in this thread actually mean for the less-technically-savvy retro enthusiasts here, such as myself?
Time Machine = FIC PA-2013 2.1 - K6-2 500 - 256MB PC-100 - TNT2 Pro 16MB AGP - Labway Yamaha YMF719-E - Midiman MM401
Amibay For Sale Threads
I have lots of PC stuff for sale on Mercari! Get $10 off your first purchase with my invite link!
User avatar
Ozzuneoj
Oldbie
 
Posts: 1524
Joined: 2016-3-16 @ 21:33

Re: The myth of the vertical retrace interrupt on EGA/VGA

Postby Scali » 2018-2-22 @ 18:42

Ozzuneoj wrote:I've read through this thread and it's very interesting but I still don't understand the actual purpose of the "vertical retrace interrupt".


Well, if you want to know the basics of how CRT displays work, and why we need horizontal and vertical retrace, this may be a good introduction: https://www.youtube.com/watch?v=l4UgZBs7ZGo
In a nutshell, these are periods when the cathode ray is not drawing a picture, because it is being repositioned from right to left, or from bottom to top.

This is relevant for computer software, because various things need to be done while the CRT is not drawing. For example, if you want to adjust the palette, you generally want to do that during the vertical retrace, else the palette will change at whatever point the CRT is at the moment, so one part of the screen is showing the old palette, and the other part is showing the new palette.

Now, normally you would need to constantly read the status register of the videocard to see if it is in vertical retrace or not, which means you can't use the CPU for anything else.
If however the videocard can generate an interrupt when the vertical retrace starts, you can just let the CPU do whatever you want, and it will automatically get interrupted at the right time, so you just install an interrupt handler to change the palette or whatever else it is you want to do during vertical retrace. You don't lose any valuable CPU time with constantly polling the videocard status until vertical retrace.

What it means... not that much in practice. It seems that various videocards were broken, so the vertical retrace interrupt didn't work. Therefore, not a lot of software made use of it. It could also be that some developers didn't know how to use it correctly, making matters worse.

I'm just trying to figure out what the real story is. So far it seems rather positive:
- We found out that at least two popular chipsets, namely Paradise and Trident, actually seem to support the interrupt just fine, but the PCB traces are just missing, which can be patched with a wire.
- We found out that various modern systems (PCI/plug&play and newer) actually do support the interrupt, it is just not mapped on IRQ2/9.
Scali
l33t
 
Posts: 4108
Joined: 2014-12-13 @ 14:24

PreviousNext

Return to Video

Who is online

Users browsing this forum: eric1992 and 3 guests