PDA

View Full Version : Trident VGA and IBM PC



sergey
September 20th, 2013, 11:08 PM
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

Stone
September 21st, 2013, 03:30 AM
My XT works fine with a TVGA9000B.

Malc
September 21st, 2013, 10:15 AM
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.

fatwizard
September 21st, 2013, 10:56 PM
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.

mmruzek
September 24th, 2013, 03:08 AM
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

mmruzek
September 28th, 2013, 03:21 AM
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.

Chromedome45
September 28th, 2013, 07:56 AM
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.

archeocomp
November 3rd, 2013, 08:40 AM
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.

sergey
November 27th, 2013, 09:50 AM
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.

Mike Chambers
November 27th, 2013, 11:00 AM
It may come down to BIOS revision.

sergey
November 27th, 2013, 03:28 PM
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...

modem7
June 6th, 2014, 10:05 PM
I need to debug it :-) Hopefully during Thanksgiving I'll find a few hours to do so...
Your web site (here (http://www.malinov.com/Home/sergeys-projects/isa-supervga)) suggests suitability for the "IBM PC".
Does that mean that you discovered the cause of the 5150 incompatibility?

sergey
June 10th, 2014, 08:01 AM
Your web site (here (http://www.malinov.com/Home/sergeys-projects/isa-supervga)) 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.

newold86
November 4th, 2017, 08:55 AM
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 :)

Trixter
November 4th, 2017, 10:00 AM
Please tell the whole story here, as what you found might help other homebrew people making cards for the 5150.

Tronix
November 4th, 2017, 11:26 AM
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.

https://habrastorage.org/webt/zn/ne/ry/znneryawy1n0ufxibbdh1rjnopo.jpeg

As you can see, addition board at left bottom corner fix the problem.

Xacalite
November 4th, 2017, 12:08 PM
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!

newold86
November 4th, 2017, 11:50 PM
Everything started while I was troubleshooting very weird behavior of my universal card (http://www.vcfed.org/forum/showthread.php?46427-Modern-XT-compatible-PC-on-FPGA-with-real-8088&p=482366#post482366). 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):

41760

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 (http://www.nedopc.org/forum/viewtopic.php?p=140348#p140348) 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:

41762

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

Vic3Dexe
November 5th, 2017, 01:07 AM
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).
41765

pietja
November 5th, 2017, 07:13 AM
That is a good find and easy to implement in Sergey's design ;)

Also what is that red motherboard in your photo? it looks awesome :cool:

Tronix
November 5th, 2017, 07:44 AM
Also what is that red motherboard in your photo? it looks awesome :cool:

This is new replica of the old Soviet computer named Poisk-2. Full length AT mainboard based on KM1810VM86M (8086) CPU with some usable things, such us 2 Mb onboard RAM (640Kb base memory and ~1400Kb for EMS), onboard RTC. BIOS contain "Set-Up" program like "Set-Up" in AT class machines for configure Time, Date, FDD, HDD and other settings. Also for some reasons BIOS contain build-in memory remapping procedures. When one of the DRAM chips is out of order, BIOS correct buildin "DRAM deffect map" and shift up logical memory space up. Thus, computer still usable. KM1810VM86M processor is not 100% clone Intel 8086. He contain some 80186 instruction (pusha, popa) and one very important thing - when invalid opcode occured he generate exception. Therefore, there are 80286 processor emulators exist.

There is description with photos about replica creation: https://geektimes.ru/post/294155/ (in Russian languarge). Project now open-source. Gerber, circuit and other files here: https://github.com/Haper/poisk-2-mainboard .

pietja
November 5th, 2017, 11:54 AM
I have designed a simple modchip style board based on the circuit Tronix posted on nedopc.org (http://www.nedopc.org/forum/viewtopic.php?f=87&t=17349&start=150#p140497)
Its designed with 5 SMD parts so that you can stick the board with some dual sided tape on your VGA card.

I have uploaded the board to OSH park and it should cost only $2.60 for 3 but its not tested!
https://oshpark.com/shared_projects/r7J7OVea
41791

Tronix
November 5th, 2017, 10:42 PM
delete pls

reenigne
November 6th, 2017, 12:28 AM
Interesting stuff! Now that you mention it, I can see the same thing on my XT with my ISA bus sniffer card. Looking through the 5160 technical reference, it seems like none of the IBM cards use ALE (except the extender and receiver cards, which just replicate it onto the expansion unit). http://pinouts.ru/Slots/ISA_pinout.shtml says "This signal is forced high during DMA cycles." but that's clearly not true for 5150/5160 - it must have been a change made in later machines, after the original ALE signal was found to be useless.

So the mystery is why IBM put a signal on the bus that wasn't actually usable for anything. I guess the answer must be that they mistakenly thought it would be useful and it was a signal that they were generating anyway so it didn't cost anything to expose it.

Vic3Dexe
November 6th, 2017, 01:44 PM
Ithey mistakenly thought it would be useful
Maybe it supposed to be useful for pre-DMA era? I mean - when there is no DMA on the bus, back front of (B)ALE is good to latch and decode address. But even in this case front of /MRD (/MWR etc) is much more suitable for me.

sergey
November 7th, 2017, 06:23 AM
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


Fixed that, also added a note about IBM PC not working...

sergey
November 7th, 2017, 07:30 AM
Everything started while I was troubleshooting very weird behavior of my universal card (http://www.vcfed.org/forum/showthread.php?46427-Modern-XT-compatible-PC-on-FPGA-with-real-8088&p=482366#post482366). 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):

41760

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 (http://www.nedopc.org/forum/viewtopic.php?p=140348#p140348) 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.


Actually, on both IBM PC and IBM XT all DMA cycles, not only memory refresh cycles, are performed this way - by inserting wait cycles to stop the CPU.
The reason for this is that in these systems 8088 runs in so called maximum mode, using 8288 bus controller. In this mode neither processor, nor bus controller generate HOLD/HLDA signals required for 8237 DMAC. Instead 8088 implements a fairly complicated arbitration protocol to support additional bus masters, for example 8087 or 8089.
Now, IBM could have used 8089, or at least implemented the 8088 maximum mode arbitration protocol using logic ICs, but instead they just used wait logic to stop the CPU during DMA.

Generally speaking, the DMA implementation in IBM PC (and XT, and AT) is pretty much broken... Sometimes I wonder why they even went through the trouble of implementing DMA.



Of course, it raised another question - why do they even need ALE signal on the bus at all, if it's impossible to use ???


Comparing PC schematic vs. XT schematic - the ALE is implemented in exactly the same way - it is connected directly to the 8288 bus controller. So it is likely that the differences in behavior are the result of the wait logic implementation differences between PC and XT. Quite possible that wait logic was broken (as far as ALE timing goes) on PC, and IBM fixed it in XT...

ALE is really comes useful in AT type of systems, that provide unlatched LA17-LA23 signals. In this case ALE is needed to determine when the address is valid. Technically, either on XT or AT, it also allows determining that address is valid sometime before /MEMR, /MEMW, /IOR, or /IOW go active.

sergey
November 7th, 2017, 08:12 AM
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).
41765

Nice work!
I think it all can be implemented in a single SPLD...

newold86
November 7th, 2017, 08:38 AM
Quite possible that wait logic was broken (as far as ALE timing goes) on PC, and IBM fixed it in XT...
At least it's not fixed in my XT board from DTK. And it's not fixed in your single board XT :) I'm pretty sure (of course, could be wrong) if you slightly modify your XT to start fake memory refresh cycles, it stops working with your VGA adapter. Too bad it's not very straightforward to conduct this experiment - will require some trace cutting and soldering...

sergey
November 7th, 2017, 11:17 AM
At least it's not fixed in my XT board from DTK. And it's not fixed in your single board XT :) I'm pretty sure (of course, could be wrong) if you slightly modify your XT to start fake memory refresh cycles, it stops working with your VGA adapter. Too bad it's not very straightforward to conduct this experiment - will require some trace cutting and soldering...

But it works on most XT's, including the original IBM XT ;-)

And I am not quite sure what is broken on my XT... Can you elaborate?

newold86
November 7th, 2017, 04:15 PM
But it works on most XT's, including the original IBM XT ;-)

And I am not quite sure what is broken on my XT... Can you elaborate?
It works on your XT because there is NO memory refresh cycle, so nothing to brake ALE signal. But I re-created your XT in FPGA, and see that with refresh cycle active the ALE is broken as well. Of course, can’t be 100% sure, be I think I replicated all your wait state and DMA logic very accurately...

Vic3Dexe
November 7th, 2017, 11:26 PM
Actually, on both IBM PC and IBM XT all DMA cycles, not only memory refresh cycles, are performed this way - by inserting wait cycles to stop the CPU.

Comparing PC schematic vs. XT schematic - the ALE is implemented in exactly the same way - it is connected directly to the 8288 bus controller. So it is likely that the differences in behavior are the result of the wait logic implementation
Well... I don't think so, because the problem is not in wait states themselves. Behavior would be same at the end cause wait states *should* be inserted after T2, therefore after ALE, therefore there will always be a situation when ALE mismatched with bus address (if CPU in wait state then someone else has the bus). So only one possibility - wait state logic also delays ALE signal to the end of DMA cycle.

Have someone timings from real XT or AT with DMA exchange? Very interesting how would BALE look like.

sergey
November 8th, 2017, 08:50 AM
Still, I am pretty much confused why Trident TVGA cards work fine on IBM XT and don't work on IBM PC.

Yesterday evening I fetched the original IBM PC and IBM XT motherboards from my storage and connected them to my oscilloscope/logic analyzer.

And, surprisingly, I didn't notice any differences in ALE behavior between these two boards.

Below are signal captures from both boards: Yellow is the ALE signal, Blue is /DACK0 (meaning that memory refresh is in progress), Purple is lower 16 bits of address (as seen on the ISA bus).

IBM XT:
41847

IBM PC:
41848

As you can see, in both of them ALE appears in the middle of memory refresh cycle - it is not always the case, more frequently it does not appear there. Nevertheless every so often it does on both IBM PC and IBM XT.

In both IBM PC and IBM XT ALE is connected directly to the 8288 bus controller. According to the documentation, the 8288 pulses ALE every the processor transitions from T4 state to T1 state. This transition is signaled by the CPU status lines changing from S0==S1==S2==1 to anything else.

The bus arbitration and wait logic, that is used to pause the CPU during the DMA cycles monitors CPU status signals as well. In case of IBM PC, it pauses the DMA only when the current CPU bus cycle is T4 (S0==S1==S3==1). In case of IBM XT, it can be either T4, or a halt cycle (S0==S1==1, S2=don't care).

So, no major differences between PC and XT here...

Stone
November 8th, 2017, 09:17 AM
Still, I am pretty much confused why Trident TVGA cards work fine on IBM XT and don't work on IBM PC...I've observed the same results here, as well.

newold86
November 8th, 2017, 09:22 AM
So, no major differences between PC and XT here...
Actually, there is a huge difference in your pictures regarding to ALE signal...
Just imagine that a card uses ALE signal to latch the address. If you look at the picture of your XT, everything looks right - ALE starts just before the address bus gets the address, and goes down when the address is fully established on the bus.

But look at the PC picture now ! Yes, it works in the same way with the address 7410, but 740B (which is immediately after the refresh cycle) is completely different story. If the card uses ALE to latch the address, instead of latching 740B it will latch 4C59 - the address of the memory being refreshed...

Actually, I'm very surprised that XT picture is showing correct ALE - I can't believe it comes directly from 8288... Possibly in later XT models they added something to fix this issue...

Do you think my explanation has a sense ?

Tronix
November 8th, 2017, 09:22 AM
I see a noticeable difference between IBM XT and IBM PC at your pics. I think internal Trident's logic monitoring ALE falling edge and latch address into internal latches. Then if MEMR/MEMW/IOR/IOW signal accured TVGA chip decoding address from internal latches, not from adress bus. So, at your first picture address for TVGA decoder = 740B, seems to be ok. At your second picture address for TVGA decoder = 4C59, looks wrong. Must be 740B. But it never happens. 740B address lost. Next address for TVGA decoder = 7410.

sergey
November 8th, 2017, 01:02 PM
Right... It might be a bad picture ;-) I've seen ALE pulsing while DMA was outputting the address as well. The image below shows ALE and AEN (which goes high during DMA cycles) on my IBM XT board:
41858

What I think, is that during the initialization TVGA chip tries to auto-detect the bus type, more specifically whether it has unlatched LA23-LA17 (as it would on 16-bit ISA), or just latched SA19-SA17, as on an XT system.

Update: Here is what IBM has to say about ALE signal in the IBM XT Technical Reference (a very similar description is also present in the IBM PC Technical Reference):
ALE (0)
Address Latch Enable: This line is provided by the 8288 Bus Controller and is used on the system board to latch valid addresses from the microprocessor. It is available to the I/O channel as an indicator of a valid microprocessor address (when used with AEN). Microprocessor addresses are latched with the falling edge of ALE.

Note the "when used with AEN" comment. The way I understand it, is that ALE should not be relied upon, and the address is not valid if AEN is inactive.

Update 2: TVGA9000i Datasheet, Table 4 shows that RMD7 is used to configure 8-bit (RMD7 pulled down) or 16-bit memory access (RMD7 open). I am not quite sure what it means, but this signal is open on my SVGA board, and on other Trident based cards that I've checked... So I am wondering if pulling that down would force the TVGA chip into 8-bit/latched addresses mode.

mmruzek
November 9th, 2017, 02:14 AM
Hi, I just tried pulling RMD7 low with a soldered 10K resistor to ground on two different Sergey VGA cards that work OK in 16 bit bit systems. Neither card worked on a 5150 motherboard running the Anonymous Bios. BTW: Both cards still work on a 16 bit motherboard. Also, I tried a TSENG VGA card with ET4000AX in the same 8 bit system just to make sure the other parts of the setup were OK and the VGA output is working fine. My only caution is that it is REALLY hard to see and solder this pitch on a PCB, but the connections checked OK when probed with a meter.

Michael

alecv
November 9th, 2017, 04:47 AM
According to the "IBM 5160 - Technical Reference - APR83"
http://minuszerodegrees.net/manuals.htm#IBM
page D-3
ALE goes from the pin.5 ALE of the 8288 to the 74LS373 address latches and to the B28 pin of the ISA-8 slot.
There is no another source of the ALE signal.

8288's bus Command signals are controlled by the pin.6 ^AEN and pin.15 CEN
Intel's 8288 documentation is very brief, I've used Siemens 8288 datasheet
http://pdf1.alldatasheet.com/datasheet-pdf/view/45589/SIEMENS/8288.html

As far as I understand ^AEN and CEN does not affect ALE (they control Bus Command signals only like MEMR/MEMW/IOR/IOW)

Can anyone explain extra ALE pulse during DMA cycle on the 5160 ?

Anyway, it shoul be enought to do disable extra ALE with AND-gate: TRIDENT_ALE=ALE & ^AEN


P.S. There was a report that Trident 9000i works on the Commodore PC III (XT-class machine with chipset motherboard).
Faraday 2010 chipset may not generate extra ALE too (nobody tested).

sergey
November 9th, 2017, 08:37 AM
According to the "IBM 5160 - Technical Reference - APR83"
http://minuszerodegrees.net/manuals.htm#IBM
page D-3
ALE goes from the pin.5 ALE of the 8288 to the 74LS373 address latches and to the B28 pin of the ISA-8 slot.
There is no another source of the ALE signal.

8288's bus Command signals are controlled by the pin.6 ^AEN and pin.15 CEN
Intel's 8288 documentation is very brief, I've used Siemens 8288 datasheet
http://pdf1.alldatasheet.com/datasheet-pdf/view/45589/SIEMENS/8288.html

As far as I understand ^AEN and CEN does not affect ALE (they control Bus Command signals only like MEMR/MEMW/IOR/IOW)

Can anyone explain extra ALE pulse during DMA cycle on the 5160 ?


Right, /AEN and CEN do not affect ALE signal. And I think that's exactly why it is being generated during DMA. As I explained above, for DMA operations, the bus arbitration logic in PC and XT inserts CPU wait cycles. Apparently, in some cases CPU's READY signal doesn't go inactive in time, and the CPU proceeds with the bus cycle, changing its status lines (S0-S2) and causing 8288 to generate ALE pulse. Normally it won't affect the operation, since the address that CPU outputs gets latched properly (it just doesn't go to ISA until the completion of DMA operation), and most of the devices don't care about ALE signal, and only care about the address then /MEMR, /MEMW, /IOR, or /IOW go low/active (or perhaps a slightly before that).

I need to find some time to hook up the logic analyzer and confirm this theory :-)



Anyway, it shoul be enought to do disable extra ALE with AND-gate: TRIDENT_ALE=ALE & ^AEN

It might not work, because in this case TVGA might loose some of the memory requests.



P.S. There was a report that Trident 9000i works on the Commodore PC III (XT-class machine with chipset motherboard).
Faraday 2010 chipset may not generate extra ALE too (nobody tested).

I've actually tested it... The Micro 8088 project (https://github.com/skiselev/micro_8088), I am working on now, and my previous Intel Wildcard 88 Motherboard (http://www.malinov.com/Home/sergeys-projects/wildcard-88-motherboard) project, are both based on Faraday FE2010A chipset, and they work fine with my TVGA9000i card. I also have a Turbo XT motherboard based on a Proton PT8010AF (which seems to be FE2010A knock-off), and it also works with TVGA.

Faraday FE2010A implements DMA the "proper" way. It doesn't use the CPU wait states for the DMA operation, instead it implements 8088's maximum mode RQ/GT arbitration protocol.

P.S. Intel's AP-67 "8086 System Design" has a lot of details on 8086/8088 bus operations. I have it, but unfortunately it is too big to be attached on this form. PM me if you want a copy.

sergey
November 9th, 2017, 08:42 AM
Hi, I just tried pulling RMD7 low with a soldered 10K resistor to ground on two different Sergey VGA cards that work OK in 16 bit bit systems. Neither card worked on a 5150 motherboard running the Anonymous Bios. BTW: Both cards still work on a 16 bit motherboard. Also, I tried a TSENG VGA card with ET4000AX in the same 8 bit system just to make sure the other parts of the setup were OK and the VGA output is working fine. My only caution is that it is REALLY hard to see and solder this pitch on a PCB, but the connections checked OK when probed with a meter.

Michael

Yes, tried the same yesterday evening, doesn't seem to help :-(

alecv
November 9th, 2017, 12:33 PM
I've actually tested it... Sorry, I meant nobody tried to catch extra ALE pulses with logic analyzer on the "chipset" XT motherboards.

AFAIK, AT schematic is rather different and does not put CPU into wait state on DMA although uses similar 82288 bus controller.

sergey
November 9th, 2017, 04:30 PM
Sorry, I meant nobody tried to catch extra ALE pulses with logic analyzer on the "chipset" XT motherboards.

Good question. Faraday FE2010/FE2010A chipset specifically has two separate ALE signals: one that goes to the address latches (ALE), and one that goes to the ISA bus (BALE).
The chipset pulses the ALE signal during DMA bus cycles because it shares address latches with the CPU. (I know for sure, I had to redo the board because of that - see the last item in the Known Issues for V1.0 (https://github.com/skiselev/micro_8088) list)
I am not sure about BALE signal, but it is quite possible that it only gets activated during CPU bus cycles.



AFAIK, AT schematic is rather different and does not put CPU into wait state on DMA although uses similar 82288 bus controller.


IBM AT uses old-fashioned HDLA/HOLD bus arbitration mechanism.

sergey
November 9th, 2017, 10:50 PM
So, I tested the original IBM XT board, and it is not working with any of the Trident TVGA cards I have (TVGA8900CL, TVGA8900D, TVGA9000A, TVGA9000I-1, TVGA9000I-3). I was sure I tested some of these cards in an IBM XT before, but apparently I was using an XT clone motherboard that doesn't have ALE issue. I apologize for confusion. :-(

I guess now I have to redesign my Trident TVGA9000i board, and include the ALE workaround...

Speaking about that - it should be possible to extend ALE using AEN signal (perhaps add slight delay, e.g. half a clock to that).

newold86
November 10th, 2017, 12:02 AM
Speaking about that - it should be possible to extend ALE using AEN signal (perhaps add slight delay, e.g. half a clock to that).
I'm thinking about exactly the same thing - was planning to do some research this weekend...

Quite funny we are still learning new things about 35+ years old design :)

Scali
November 10th, 2017, 01:10 AM
Faraday FE2010A implements DMA the "proper" way. It doesn't use the CPU wait states for the DMA operation, instead it implements 8088's maximum mode RQ/GT arbitration protocol.

That is interesting.
I have a Commodore PC20-III, with a Faraday FE2010 chipset. One thing I noticed is that it crashes out on the endpart of 8088 MPH. That endpart is cycle-exact, and assumes that certain code is already in the prefetch-buffer when it modifies it, so that the unmodified code is executed.
The crash on the FE2010 is most probably because it's not cycle-exact, and it actually executes the modified code. But I have not been able to find an explanation why.
What was even more strange was that removing any writes to the CGA card would prevent it from crashing.
But if it does different things for DMA transfers (and thereby memory refresh), that may explain something. Perhaps it also handles wait states from the CGA card slightly differently?
And this RQ/GT arbitration protocol, could it also affect prefetching in some way?

Stone
November 10th, 2017, 03:01 AM
So, I tested the original IBM XT board, and it is not working with any of the Trident TVGA cards I have (TVGA8900CL, TVGA8900D, TVGA9000A, TVGA9000I-1, TVGA9000I-3).http://www.vcfed.org/forum/showthread.php?39291-Trident-VGA-and-IBM-PC&p=294571#post294571

Vic3Dexe
November 10th, 2017, 09:53 AM
Speaking about that - it should be possible to extend ALE using AEN signal (perhaps add slight delay, e.g. half a clock to that).
You can extend ALE to the front of /MRD signal (as Tronix did).
Or just use front of /MRD to latch address - I think this will also work.

sergey
November 10th, 2017, 10:39 AM
I'm thinking about exactly the same thing - was planning to do some research this weekend...

Quite funny we are still learning new things about 35+ years old design :)

Here is what I came up with. Haven't tested it yet though:

41894

It should work as follows:
- If AEN is low (inactive, no DMA operation), it supposed to pass the ALE signal through to BALE
- If ALE pulses while AEN is high, it will switch BALE to high, and keep it high as long as AEN remains high, and a little bit more. AEN low to BALE low delay can be set with the jumper.

(There is a question what circuit should do if ALE goes high first, after that AEN goes high, and after that ALE goes low... I am not sure if this situation can happen, but I don't think the circuit handles this case correctly).

sergey
November 11th, 2017, 12:01 AM
I've prototyped and tested my circuit. It works nicely with original IBM PC, PC-Retro, and IBM XT boards. It also works with a chipset based XT clone and an AT/286 board.

Here is the schematic: 41899. I uploaded the PCB design to OSH Park (https://oshpark.com/shared_projects/3U96oZ0C).

The PCB is designed in such a way that it can be glued on the bottom right corner of back side of the VGA card, and then GND, VCC, and ALE signals can be connected directly to the ISA edge connector. AEN and TALE (ALE to TVGA chip) would need to be wired to the board.

sergey
November 11th, 2017, 12:23 AM
You can extend ALE to the front of /MRD signal (as Tronix did).
Or just use front of /MRD to latch address - I think this will also work.

I implemented an easier approach - it only uses ALE and AEN signals.
I believe this approach is also more reliable. It doesn't change ALE (other than adding a slight delay) when AEN is inactive, and therefore it will not break AT systems. (Most likely Tronix's schematic will not work on an AT in 16-bit slot, because LA17-LA23 will not be valid when /MEMR or /MEMW are activated).

Tronix
November 13th, 2017, 04:52 AM
Some people reported ultra light solution - just pull up TVGA9000 ALE pin to +5V....

Kazblox
November 14th, 2017, 07:43 AM
Some people reported ultra light solution - just pull up TVGA9000 ALE pin to +5V....
Cool! I assume you do this with a resistor as always?

This trick would be useful to get this working on any XT I have in the future; but does the TVGA8900D/9000 chipset have any compatibility with the Olivetti M24's byteswapped BIU implementation? I fear it's what breaks most "XT compatible" video cards from VGA and up on this machine.

sergey
November 16th, 2017, 08:03 AM
Some people reported ultra light solution - just pull up TVGA9000 ALE pin to +5V....

Huh, tested this on the boards I have available: IBM PC, IBM XT, PC-Retro, a chipset-based Turbo XT, 286-AT, and it works perfectly.
Apparently Trident TVGA has transparent latches on the address lines, tying ALE pin high keeps these latches in "transparent" mode, and it works as long as the address remains valid during I/O or memory operation.

That's indeed a very easy fix.

sergey
November 16th, 2017, 08:12 AM
Cool! I assume you do this with a resistor as always?

Resistor is not needed (but won't hurt), just disconnect TVGA ALE pin from ISA, and connect it to +5V.



does the TVGA8900D/9000 chipset have any compatibility with the Olivetti M24's byteswapped BIU implementation? I fear it's what breaks most "XT compatible" video cards from VGA and up on this machine.

I don't think it is something that a VGA chipset could possibly fix it. The problem is that VGA registers are accessed by writing register index to a lower byte of a 16-bit port and value to the higher byte. If bytes are swapped, it will write the value first... (likely to the wrong register)

Kazblox
November 26th, 2017, 04:35 AM
Well, most, if not all Tseng ET4000 cards somehow manage to maneuver this bug. I don't know how, as I never looked into tracing the problem myself.

gekaufman
November 27th, 2017, 08:40 AM
Does the card still work fine in XT/AT etc with TVGA ALE tied high?

- Gary


Resistor is not needed (but won't hurt), just disconnect TVGA ALE pin from ISA, and connect it to +5V.

SkydivinGirl
November 27th, 2017, 04:21 PM
Resistor is not needed (but won't hurt), just disconnect TVGA ALE pin from ISA, and connect it to +5V.
Will this fix allow your SVGA card to work with the IBM XT 5160?

Thanks!

Heather

sergey
November 28th, 2017, 06:50 AM
Will this fix allow your SVGA card to work with the IBM XT 5160?

Thanks!

Heather

Yes, that makes the card work in IBM PC, IBM XT, and compatibles.
On my board, I put a piece of tape to cover the ALE pad on the ISA connector - 4th pad from the right, when looking at the back side of the board, and then I soldered a piece of wire between pin 19 (VCC) and pin 21 (ALE) of the TVGA9000I ICs:
42155

SkydivinGirl
November 28th, 2017, 08:47 AM
That's really great news! Your card worked perfectly in my Commodore PC10-III but wouldn't work at all in the 5160. Hopefully I'll have time to mod my card this weekend. I'll report back with the results. :)

Heather

keropi
December 1st, 2017, 04:00 AM
Thanks to SkydivingGirl's heads up I was able to do the modification on my card and it works now on my Hyundai clone :D
I improvised a little to make it a little cleaner, after severing the ALE trace I just made a small solder bridge to the +5v plane at the backside since both the former ALE via and +5v planes are really close.

http://i.imgur.com/B7KEZXvl.jpg (https://imgur.com/B7KEZXv)


edit:
a piece of advice -> count the Trident IC pins and don't rely on the silkscreen indicating pin20 , it's a little offset and it actually points to pin19

ibmapc
December 1st, 2017, 06:57 AM
...I improvised a little to make it a little cleaner, after severing the ALE trace I just made a small solder bridge to the +5v plane at the backside since both the former ALE via and +5v planes are really close.

http://i.imgur.com/B7KEZXvl.jpg (https://imgur.com/B7KEZXv)


I like that better. I'm not a big fan of putting tape on the finger. It could come off when pulling the card out and stay down in the ISA connector, causing problems with the next card to be plugged in there. It also looks easier putting the solder bridge on the back of the card instead of the wire on the chip.

SkydivinGirl
December 2nd, 2017, 03:19 AM
Nice job keropi! :D

Does anyone know if there would ever be a need to undo this mod to use the card in some systems or should it work in everything with this mod done?

Heather

Scali
December 2nd, 2017, 03:39 AM
Does anyone know if there would ever be a need to undo this mod to use the card in some systems or should it work in everything with this mod done?

Well, given sergey's extensive testing above (including a 286, which should have way different handling of ALE anyway), I think it should be fine in everything. Of course, there are so many PCs that you never know for sure.

keropi
December 2nd, 2017, 02:21 PM
For what it's worth I also tested on my 386DX build, worked fine

sergey
December 4th, 2017, 08:56 AM
Thanks to SkydivingGirl's heads up I was able to do the modification on my card and it works now on my Hyundai clone :D
I improvised a little to make it a little cleaner, after severing the ALE trace I just made a small solder bridge to the +5v plane at the backside since both the former ALE via and +5v planes are really close.

http://i.imgur.com/B7KEZXvl.jpg (https://imgur.com/B7KEZXv)


edit:
a piece of advice -> count the Trident IC pins and don't rely on the silkscreen indicating pin20 , it's a little offset and it actually points to pin19

That's a good idea for implementing this mod. Thank you for the picture!

archeocomp
December 8th, 2017, 10:03 AM
Sergey will you be making new design? I finally want to make your VGA (working:-))

sergey
December 8th, 2017, 11:28 AM
Sergey will you be making new design? I finally want to make your VGA (working:-))

Eventually I'll do a board re-spin. Perhaps early next year.

sergey
December 20th, 2017, 08:18 PM
Sergey will you be making new design? I finally want to make your VGA (working:-))

I fixed the schematic, connecting TVGA controller ALE signal to 5V, and updated the PCB layout. The new design files are available on the project page (http://www.malinov.com/Home/sergeys-projects/isa-supervga). Look for version 1.1.

I haven't reordered the PCBs, and I don't plan to do that in the near future. Meanwhile the PCB can be ordered from OSH Park (https://oshpark.com/shared_projects/M9jRwsu1)

SkydivinGirl
December 21st, 2017, 03:15 PM
Excellent work by everyone in this thread! I was super impressed with this card in my Commodore PC10-III and now I'm able to use one in my 5160. Thanks everyone!

I'd be willing to put together a group buy if people were interested in getting a batch of PCBs made. Otherwise, I'll probably order a few from Oshpark. :)

Heather

sergey
January 2nd, 2018, 09:43 AM
I'd be willing to put together a group buy if people were interested in getting a batch of PCBs made.


Todd Goodman (RetroBrew Computers (https://retrobrewcomputers.org/doku.php?id=boardinventory#xi_8088_project_sergey_ kiselev)) put an order for the revised ISA SVGA PCBs. He should have the new PCBs in about three weeks.

SkydivinGirl
January 3rd, 2018, 01:18 PM
That's great news! I've bought many PCBs from Todd so I'll contact him to get one. :)

Thanks for letting us know!

Heather

EleDip
January 27th, 2019, 07:31 PM
Hi, I'm working on building an XT compatible system including sergey's ISA Super VGA (http://www.malinov.com/Home/sergeys-projects/isa-supervga). I am also new to the vcfed forums *wave* :)

Just noticed in Kicad that the v1.1 board specifies a 1uf capacitor for C17, but the BOM specifies a 1nf cap for C17. Then I also noticed that C17 is omitted in the example board shown there on the website (https://78462f86-a-cd92480b-s-sites.googlegroups.com/a/malinov.com/www/Home/sergeys-projects/isa-supervga/ISA%20SVGA%20-%20Board.jpg). Does anyone know for sure what the correct capacitance value is for C17, and why it has not been soldered in on the board shown on sergey's website?

Also, please let me know if there's a better place to be posting questions about sergey's ISA Super VGA card (surprisingly I couldn't find another more suitable thread about the project).

Cheers!

modem7
January 30th, 2019, 12:11 AM
Just noticed in Kicad that the v1.1 board specifies a 1uf capacitor for C17, but the BOM specifies a 1nf cap for C17. Then I also noticed that C17 is omitted in the example board shown there on the website. Does anyone know for sure what the correct capacitance value is for C17, and why it has not been soldered in on the board shown on sergey's website?
Welcome to these forums. Hopefully, sergey will see your post soon.

sergey
February 6th, 2019, 03:14 PM
I don't think it even matters :-)
C17 is a part of a filter on a Monitor ID pin. That pin was used by a really old VGA monitors to identify color vs. monochome monitor.
Newer monitors (since late 90's) do not use this pin at all.