VOGONS


Reply 20 of 73, by Tiido

User metadata
Rank l33t
Rank
l33t

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

T-04YBSC, a new YMF71x based sound card & Official VOGONS thread about it
Newly made 4MB 60ns 30pin SIMMs ~
mida sa loed ? nagunii aru ei saa 😜

Reply 21 of 73, by Scali

User metadata
Rank l33t
Rank
l33t
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).

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 22 of 73, by Tiido

User metadata
Rank l33t
Rank
l33t

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

T-04YBSC, a new YMF71x based sound card & Official VOGONS thread about it
Newly made 4MB 60ns 30pin SIMMs ~
mida sa loed ? nagunii aru ei saa 😜

Reply 23 of 73, by Scali

User metadata
Rank l33t
Rank
l33t

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

vretirq 11

If you don't specify anything, it still defaults to IRQ 2, as before.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 24 of 73, by Tiido

User metadata
Rank l33t
Rank
l33t

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 🤣. Pure DOS is ok.

T-04YBSC, a new YMF71x based sound card & Official VOGONS thread about it
Newly made 4MB 60ns 30pin SIMMs ~
mida sa loed ? nagunii aru ei saa 😜

Reply 25 of 73, by Scali

User metadata
Rank l33t
Rank
l33t

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.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 26 of 73, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author
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: unsupported port 3c2h access

Reply 27 of 73, by Scali

User metadata
Rank l33t
Rank
l33t
ripsaw8080 wrote:

I believe the history of that, at least in part, is here: unsupported port 3c2h access

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.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 28 of 73, by Jo22

User metadata
Rank l33t++
Rank
l33t++

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
Filename
oti037c_irq2.jpg
File size
32.81 KiB
Views
1845 views
File license
Fair use/fair dealing exception

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

et3000ax_irq2.jpg
Filename
et3000ax_irq2.jpg
File size
30.9 KiB
Views
1845 views
File license
Fair use/fair dealing exception

TVGA8900s w/ IRQ2/9
Jumper J1

8900s_irq2.jpg
Filename
8900s_irq2.jpg
File size
31.91 KiB
Views
1845 views
File license
Fair use/fair dealing exception

TVGA8900B w/ IRQ2/9
Jumper J2 ?

8900b_irq2.jpg
Filename
8900b_irq2.jpg
File size
31.29 KiB
Views
1845 views
File license
Fair use/fair dealing exception
Last edited by Jo22 on 2018-02-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//

Reply 29 of 73, by Jo22

User metadata
Rank l33t++
Rank
l33t++

ET4000AX w/ IRQ2/9
Jumper J3
*may vary; wasn't soldered (I added pins+jumper)

et4000ax_irq2.jpg
Filename
et4000ax_irq2.jpg
File size
30.55 KiB
Views
1844 views
File license
Fair use/fair dealing exception

F82C451 w/ IRQ2/9

f83c451_irq2.jpg
Filename
f83c451_irq2.jpg
File size
31.05 KiB
Views
1844 views
File license
Fair use/fair dealing exception

>> 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//

Reply 30 of 73, by Scali

User metadata
Rank l33t
Rank
l33t
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.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 31 of 73, by BloodyCactus

User metadata
Rank Oldbie
Rank
Oldbie

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 :: [ https://bloodycactus.com :: http://kråketær.com ]-/\--

Reply 32 of 73, by Jo22

User metadata
Rank l33t++
Rank
l33t++

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//

Reply 33 of 73, by Jo22

User metadata
Rank l33t++
Rank
l33t++

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/news/item … -tseng-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//

Reply 34 of 73, by Jo22

User metadata
Rank l33t++
Rank
l33t++

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
Filename
pvga_card.jpg
File size
33.19 KiB
Views
1805 views
File comment
PVGA1A 8-Bit
File license
Fair use/fair dealing exception
pvga_mod.jpg
Filename
pvga_mod.jpg
File size
35.72 KiB
Views
1805 views
File comment
Modifications
File license
Fair use/fair dealing exception

"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//

Reply 35 of 73, by Jo22

User metadata
Rank l33t++
Rank
l33t++

Some more pictures.

pvga_checkit.jpg
Filename
pvga_checkit.jpg
File size
26.04 KiB
Views
1804 views
File comment
PVGA1A, CheckIt! detects IRQ2/9
File license
Fair use/fair dealing exception
pvga_glitch.jpg
Filename
pvga_glitch.jpg
File size
50.01 KiB
Views
1804 views
File comment
PVGA1A, Glitch
File license
Fair use/fair dealing exception
pvga_mode1.jpg
Filename
pvga_mode1.jpg
File size
31.83 KiB
Views
1804 views
File comment
PVGA1A, Mode 1
File license
Fair use/fair dealing exception
pvga_mode2.jpg
Filename
pvga_mode2.jpg
File size
30.94 KiB
Views
1804 views
File comment
PVGA1A, Mode 2
File license
Fair use/fair dealing exception
pvga_mode3.jpg
Filename
pvga_mode3.jpg
File size
30.62 KiB
Views
1804 views
File comment
PVGA1A, Mode 3
File license
Fair use/fair dealing exception

"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//

Reply 36 of 73, by Scali

User metadata
Rank l33t
Rank
l33t

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.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 37 of 73, by Scali

User metadata
Rank l33t
Rank
l33t

I've created a new version, which has an extra commandline parameter: https://www.dropbox.com/s/bzobfyhmppin435/vretirq.zip?dl=0

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.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/

Reply 38 of 73, by Ozzuneoj

User metadata
Rank l33t
Rank
l33t

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?

Now for some blitting from the back buffer.

Reply 39 of 73, by Scali

User metadata
Rank l33t
Rank
l33t
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.

http://scalibq.wordpress.com/just-keeping-it- … ro-programming/