• Please review our updated Terms and Rules here

Trident VGA and IBM PC

sergey

Veteran Member
Joined
Jul 15, 2010
Messages
873
Location
Silicon Forest, Oregon, USA
Hi,

I am wondering if anyone has/had the original IBM PC 5150 working with Trident TVGA8900 or TVGA9000 cards? How about IBM XT? (Not clones).

Michael and I made a weird discovery that TVGA9000i based card that I designed doesn't work in IBM PC 5150/Retro-PC, but it appears to be working in XT systems (or at least Turbo-XT clones). I tried some other Trident cards (TVGA8900D, TVGA9000A), and they also don't work in my 5150 motherboard...

Is it possible that something on PC bus is different from XT bus that will make card not to work? If I remember correctly bus control signals (/IOR, /MEMR, /IOW, /MEMW) have termination resistors in PC, but not in XT. Also in PC 8259/PIC data bus is connected directly to the CPU, while in XT it sits on the X-bus, behind ISA. Any other ideas?

What it is not:
- It is not 8088/V20 compatibility issue. Trident cards will work with either one of them (on XT systems)
- Most likely it is not a BIOS issue. Other VGA cards work with my 5150, and Retro-PC uses ERSO-like BIOS.

Thanks,
Sergey
 
A while back i tried a Trident TVGA9000i card in my IBM PC 5150 and IBM XT 5160 and it didn't work in either, However it worked fine in my IBM 5170 in an 8-bit / 16-bit slot, i put it down to the bios on the card needing a 286 or better. I have also found that some cards i have work fine in my XT 5160 but don't work in my PC 5150 and a few work in both 5150/5160.
 
I have Trident TVGA9000C and a TVGA9000i based cards and can't get either of them to work in a 5160 motherboard currently on the bench.
 
I have several of Sergey's 8 bit ISA video cards, which work OK in a 386, 486, etc, but do not work in an original stock IBM PC, the PC-Retro running the Anonymous/Generic BIOS, or in an IBM stock XT. I have tried both versions of the Trident Video BIOS (Version D4.01E and D3.51). Just for the heck of it, I also tried booting with the Compaq Portable BIOS, just to see if it would make a difference: No dice. Trying to boot with the video card gives a characteristic error: One long beep, followed by two short beeps. As a cross check: I can boot fine in all my systems with a 16 bit VGA video card based on the ET4000AX from Tseng Labs.

Going through my collection of VGA cards I found a single card based on the TVGA9000B using the Quadtel V3.00 lH Bios that does provide video output in a fashion on the PC... The screen is readable, but has a red background and vertical lines. I pulled the BIOS off that card and tried in the Sergey Card, but again: no dice.

If anyone has an idea or suggestion of something to try... Thanks, Michael
 
I have also tried the Sergey 8 bit ISA video card in an IBM 5150 PC with the 8088 CPU replaced by a BREAKTHRU 286 Upgrade card. (Replaces the CPU at the socket with a plug-in cable going to an ISA card with onboard 286 CPU). The VGA video card is not working, and the system seems to hang about at the point that I would expect it to be loading the video bios. No beeps.
 
FWIW I have also never had any of those 2 models of Tridents working in an XT. Supposedly the TVGA8800 will work. But that was something I heard.
 
I have also tried the Sergey 8 bit ISA video card in an IBM 5150 PC with the 8088 CPU replaced by a BREAKTHRU 286 Upgrade card. (Replaces the CPU at the socket with a plug-in cable going to an ISA card with onboard 286 CPU). The VGA video card is not working, and the system seems to hang about at the point that I would expect it to be loading the video bios. No beeps.
What a pitty. I missed this thread. A month ago or so I assembled Sergey's VGA card and tried it in a TurboXT system that works with 9000B and 9000C Trident cards. Sergey's card did not work. I was pretty sure, I soldered it well. So I went to a friend with hot air rework station, removed the chip. Soldered second chip. (I bought two at UTsource) That chip did not work neither. I removed that chip and ordered third chip from UTSource, this time from another batch. Well I am still waiting for the chip. But today I have made a discovery. I tried 16bit 9000i card in my TurboXT and it does not work. So I pulled Commodore PC20-III (XT clone) from basement where this card worked before and .. yep it works. I am pretty sure, Sergey's card was all well, but I did not test in Commodore unfortunately .. What a mess.
 
What a pitty. I missed this thread. A month ago or so I assembled Sergey's VGA card and tried it in a TurboXT system that works with 9000B and 9000C Trident cards. Sergey's card did not work. I was pretty sure, I soldered it well. So I went to a friend with hot air rework station, removed the chip. Soldered second chip. (I bought two at UTsource) That chip did not work neither. I removed that chip and ordered third chip from UTSource, this time from another batch. Well I am still waiting for the chip. But today I have made a discovery. I tried 16bit 9000i card in my TurboXT and it does not work. So I pulled Commodore PC20-III (XT clone) from basement where this card worked before and .. yep it works. I am pretty sure, Sergey's card was all well, but I did not test in Commodore unfortunately .. What a mess.
Sorry about this mess... Still I am wondering what makes Trident 9000i to work in some XT clones but not in other.
 
It may come down to BIOS revision.

With Retro PC it doesn't work either with IBM BIOS or with (C) Anonymous one. It very well could be that the Anonymous BIOS simply copied BIOS extension scan code or something like that. But on the other hand I just can't figure out what hardware difference between IBM PC and IBM XT could break the card... Unless it is some very subtle signal timing problem...

I need to debug it :) Hopefully during Thanksgiving I'll find a few hours to do so...
 
Your web site (here) suggests suitability for the "IBM PC". Does that mean that you discovered the cause of the 5150 incompatibility?

I think it was written before we've discovered incompatibility. I was assuming that if the board works with IBM XT and XT clones it will also work with IBM PC. For whatever reason it doesn't. I tried checking various things, but still haven't found the reason for such incompatibility.... I need to update that page one day.
 
Exciting news - the mystery finally solved ! :)
As you know, the topic of incompatibility of certain video adapters (mostly based on Trident 9000) with certain PCs (mostly really old PC and PC/XT) was raised a number of times on different forums (including this one). Seems like now we have a definitive answer why it's happening and how to fix it. If anyone interested, I tell the whole story here :)
 
Yes, please tell the story, because my English very bad. The only thing I can say that the fix is not easy. You need an additional circuit and cut trace on Trident board.

znneryawy1n0ufxibbdh1rjnopo.jpeg


As you can see, addition board at left bottom corner fix the problem.
 
Uhm, I just found a funny mistake on that project's website:
"Supports 256 MiB or 512 MiB video memory using two or four 256 Mbit x 4 DRAM ICs."
Made me think about using CUDA with an 8088 :D

Anyway, I'm also interested in the story, of course!
 
Everything started while I was troubleshooting very weird behavior of my universal card. Finally in order to troubleshoot a software (as I thought at that moment) issue I had to use a logic analyzer. The picture of one specific signal (B)ALE was different, than I expected (this is a picture of "jmp $", running between addresses D000A - D000C):

bus.jpg

On this picture the ALE just before the time stamp 1216 appeared to be in a wrong place - way before "its" address D000A (time stamp 1246). I knew that the address 0CB97 between the ALE and "its" address was a memory refresh cycle, but couldn't figure how the DMA cycle did manage to get inserted inside of another cycle ??? Luckily a fellow Vic3Dexe from another forum kindly reminded me, that the DMA cycle for the memory refresh logic is not "real" DMA cycle, but rather a "wait state" delay cycle. Of course, this explained everything... At that moment, my card used ALE signal to latch the address bus for own needs, but during the refresh cycle the latched address was completely wrong ! I introduced a minor change to my FPGA design eliminating ALE usage, and everything started working flawlessly. Of course, it raised another question - why do they even need ALE signal on the bus at all, if it's impossible to use ???

And then here comes the Tronix ! :) He somehow connected the abovementioned issue with Trident 9000 issues in old PCs. From this point Tronix took things into his hands, so I'm just telling his story...

Quick look at working (in old PC) and not working Tridents immediately revealed the absence of ALE signal on working adapters. Probably, even then we already could safely assume that the ALE is the reason, but Tronix decided to prove it completely. First step was to increase the interval between memory refresh cycles on his PC clone. And the miracle happened - previously completely dead Trident card started waking up ! Longer refresh interval could provide enough time for the card to start.

After that, small board was designed and assembled to generate a substitute for the ALE:

schem.jpg

After a bit torture to the Trident (cutting off the ALE line and connecting Tronix' board) everything started working completely reliably.

Bottom line - PCs with "old style" memory refresh logic don't work with cards that require ALE signal. Newer PCs either handle a memory refresh differently, or don't need it at all - Sergey's XT project uses static memory, no refresh required.

The fix... For existing adapters, it's a bit ugly - requires cutting lines and attaching a small board. For Sergey's SVGA card - a small addition can be easily introduced to the design, that makes the card compatible.

The end :)
 

Attachments

  • 1.jpg
    1.jpg
    92.5 KB · Views: 18
  • 2.jpg
    2.jpg
    91.4 KB · Views: 16
  • 3.jpg
    3.jpg
    89.4 KB · Views: 15
  • bus2.jpg
    bus2.jpg
    15.9 KB · Views: 11
Last edited:
More shortly - all this additional board does is prolongates back front of BALE signal to the front of /MEMRD (or /MEMWR, /IORD, /IOWR) signal, so the card can latch correct address from bus (and not that from DMA).
BusALE.jpg
 
Back
Top