I've downloaded your .ZIP file and compared it with my own TVGAUTIL directory that remained basically intact ever since I got the MiTAC-brand AMD Am486DX2-50 with a Jaton JAX-8232D/V3 with Trident TVGA8900D (naturally and unfortunately, no floppy came with that machine). Most files were the same but those under \UTILITY were quite different, with many new utilities in your newer files. Thanks for uploading contents of that floppy!

dormcat wrote on 2024-11-02, 22:37:

I've downloaded your .ZIP file and compared it with my own TVGAUTIL directory that remained basically intact ever since I got the MiTAC-brand AMD Am486DX2-50 with a Jaton JAX-8232D/V3 with Trident TVGA8900D (naturally and unfortunately, no floppy came with that machine). Most files were the same but those under \UTILITY were quite different, with many new utilities in your newer files. Thanks for uploading contents of that floppy!

You might find a package a bit more tailored to that card here http://files.mpoli.fi/hardware/DISPLAY/TRIDENT/ the UC51 maybe, or that might be the same one you've got.

My system is haunted... serves me right for raising the dead on Hallowe'en I guess...

I can't get the 9000s to go slow any more, reproduce the earlier results on 7.15 Mhz, no cache. I thought at first it was something sticking in RAM with a warm boot, so left power off for 30 secs, a minute, nope, still fast, double check BIOS set to no caching and 7.15, still fast, check my autoexec and config to see if a trident util put something in there, nope, start figuring, oh, I know what, it must be that there's some kind of non volatile RAM in the stupid 9000C and it got semi-permanently set... okay, check I'm still at 7.15, no caches setting, power off... pull out it's 9000A near twin, and swap it over, and this one hasn't had the trident util run on it yet, power on, at should be 7.15 ISA.... run 3Dbench, 19.2 FPS... what??? run doom 7,611 realtics... Why the hell is it close to the 8900s now??? After running util 3Dbench dropped to 18.5....

What I was doing immediately before this when I got suspicious something was weird was trying to get fast as possible 13.333 run for the 9000C and there was no diff between that and caches off, so I tried and failed to get it back to slow... Anyhow, best numbers on the 9000c from that, though caches set on, but I don't know if anything is set how it says any more, but that was.
LM60 2340.57
Topb 321
Snooper 59,858
3D bench 19.2
Doom 6,767

So yah, not sure what is happening now, whether the trident util "knocked something loose" as it were that was knocking performance down, or a noise reduction cap just started to cap again or what the hell else could be happening. I did check a couple of cards after the I/O card and HDD change and they hit their same numbers plus or minus tiny tiny percentages.

Anyway, really hard to tell if SETBOARD did or does anything, or whether SVM stealth loaded a BIOS shadow of it's own

BitWrangler wrote on 2024-11-02, 23:23:

You might find a package a bit more tailored to that card here http://files.mpoli.fi/hardware/DISPLAY/TRIDENT/ the UC51 maybe, or that might be the same one you've got.

Exactly! Thanks for the link.

Hah ha, this is so ridiculous, I couldn't figure out the real reason the system went fast, I put the 8900D 1024MB back in at 13.3333 ISA and got 25.9 3DBench and 4,417 realtics on it, squeaking ahed of GD5434 in some things and just levelling in others. But, nothing was showing me WHY. I went over BIOS settings twice with a fine toothed comb but nothing was showing as set different than it was before.... I finally hit reload from defaults... and everything looks the same again... but it is slow now... and I can't make it fast again 🤣

Yeah I was doing a lot on that system running this and that checking things out, SOMETHING must have pushed a stray bit to the CMOS by mishap, strange crash or something, or even by design thinking it was doing something else.... some things I ran were diags... I'm randomly running stuff hoping to hit on it again, but no luck so far..

I realised within a second of finding out it was slow again, my big mistake, I should have run a util to dump the CMOS settings... doh!

Okay, now I'm slightly certain what almost definitely probably maybe happened....

I could not recreate what situation caused it, and reloading from defaults in CMOS returns it to test configuration. However, the most likely setting, in fact I think the only one that speeds anything up apart from the system and video BIOS shadowing, is the hidden refresh setting, which appears to give identical results when enabled. So somehow I had hidden hidden refresh on, where it was only showing "normal" in setup, but was flipped on in some manner.

Prior to this discovery I went on a "running everything on the disk" rampage to try and make it happen again, then began to wonder if the CPU got initialised weird because it is a late D stepping SX, Sspec SX902 with SL enhancements, and I thought maybe it had initialised badly, by old board/BIOS but something had "fixed" it and it became a tad faster.... doesn't actually show in all things, apart from quite strongly in the video benchmarks which was why I thought SETBOARD juiced up the RAM speed, Landmark didn't show it in CPU speed, Speedsys might have given it a fraction more, Snooper went from 109 to 112, in the CPU and I've seen that vary within a range like that from run to run, so wasn't suspicious enough of that.

Anyway, current status, able to set board back to initial testing config should any more boards appear, able to run balls out and super balls out speed testing on them also. But, don't have anything else to test right now.

What I am trying to do now, is use the 9000C to test some DRAMs, so am going through a bunch of test programs trying to find one that isn't some mickey mouse "yay look I done a graphics" test.

If you ever come to a solution for the slightly to the right shifted image on the et4000 cards in lowres-vga 320x200 256colors compared to vga textmode 80x25 please let me know! Don't know if this is on CRT's too, on TFT's it's always. From the very early ET4000(AX) up to the very latest W32(i/p) VLB/PCI Thx!

I'd imagine the C&T F82C451 would be even slower or something on the line with OTI-037.

I use to have it in 286-16 and when I've upgraded the motherboard to 486slc-33 there was like no change in performance - tested with a F1GP and in-game CPU usage. You can imagine I was very disappointed with 486slc.

kixs wrote on 2024-11-06, 08:10:

I'd imagine the C&T F82C451 would be even slower or something on the line with OTI-037.

I use to have it in 286-16 and when I've upgraded the motherboard to 486slc-33 there was like no change in performance - tested with a F1GP and in-game CPU usage. You can imagine I was very disappointed with 486slc.

I had one way back in the day, think it was one of the "GW" cards in Vlask's section here https://www.vgamuseum.info/index.php/cpu/item … ologies-f82c451

It scaled with bus speed, so could be got to reasonable in DOS, windows it was very bare minimum though. If I had that particular card here now, I'd guess it was around same as the 9000s.

after making a small comparision chart, i've come to believe that these are the overall slowest vga cards tested at vgamuseum.info for being slow in all tests:
realtek3102
oak037
cirrus51020
the chips451 can be equally slow or even a bit slower in quake, but it performs better in diag and pcplayer, and so are the ati18800, et3000 and trident8800. that places them a bit higher than the slowest cards.
however, there are still some untested early vga cards: ibm vga, cirrus41020, intel 82706 and sx094, and i wonder if they can be even slower.

I think I've seen even the slowest cards claiming things like "1.7x faster than IBM VGA" so expectations for that one are super low.

BitWrangler wrote on 2024-11-01, 13:39:

I think there are ppl who have tested 8900CL in 16 bit mode with zero wait states and FIFO enabled, and people who haven't.

necro this post up for searching info...
hi BitWrangler, do you still keep the testing platform? can you retest the trident8900cl with 0wait and fifo off, to find out how much impact they have on performance? i still hesitate to believe whether they make such a big difference because in some test results the 8900cl is equal to 8900c, and 8900c is less than half of the 8900d(on fast machines).
i also have a small bunch of isa video cards now:
stb cirrus5434 2mb
gainward cirrus5429 2mb(no 0wait)
everex et4000ax vram 1mb(no 0wait)
generic et4000ax 1mb(no 0wait)
generic et3000 512kb
8bit isa et3000 with tvout 512kb
trident8900d 1mb
trident8900c 1mb
ati mach64 dram 2mb
ati28800 wonder xl 1mb
umc85c408 1mb
oak037 256kb
ibm vga 256kb
and i am going to test them on my umc8881+amd5x86-133 platform in a few weeks, just waiting to decide which tests to run.
the fastest isa platform i have is 440bx+pentium3-1.1ghz, which is a lot faster, but i am too lazy to set it up.

It is still together but will be "a while" I just got a load of other stuff out and buried the bench when several annoying real life situations came up, which I am still dealing with, so will be however long those take to deal with plus a day to dig out the bench again.

Typically the wait state setting is for older, slower machines, to allow for a wait state, so cards by 92-ish weren't bothering with it, so are default zero ISA wait states.

i did an et3000 vs oak037 test. they are both very slow cards, but in different ways: oak has 8bit isa bus and 32bit ram width just like the ibm vga, while the et3000, according to ctcm and xvesa results, seems to have true 16bit isa bus and 16bit ram width.
as a result, et3000 is 40-80% faster than oak in 3dbench, pcpbench, chris and quake. but in doom, its ~15% slower than the oak. this seems to be in agreement with the rumor that doom writes to video card in single bytes.
i have yet another 8bit isa version of et3000 with tvout to test, so wait and see how slow it can get.