Here's my result for a PCI TNT2 M64:

badmojo wrote on 2023-08-09, 06:24:

Here's my result for a PCI TNT2 M64:

untitled.jpg

Thanks for the screenshot. I was almost going to complain about a bug, because 640x400 256c mode was missing in the author's screenshot and I thought that can't be.
800x600 16c (6Ah) and 640x400 256c (100h) are among the most interesting, because they are available with ISA VGAs with 256 KB of video RAM.

Cool, thanks for testing!

Nice to see that the tool works from within Windows 9x. I have not tested that, I only have DOS and Windows 3.11 currently in my testbench.

The -32768KB memory print was a bug, fixed that and pushed a new version.

At first I thought that the resolution matrix printing [d] everywhere would also have been a bug. But apparently the dblscan cap means "Double Scan variant of the mode available", instead of "Mode is always doublescanned" (?).
Although I am scratching my head to understand why on earth any of the > 320x240 modes would ever have doublescan. That does look odd to me. Oh well, maybe that mystery will uncover in a later version - I am planning to do modescanning where I test each mode to see what kind of video signal each actually spits out.

Jo22 wrote on 2023-08-09, 06:57:

badmojo wrote on 2023-08-09, 06:24:

Here's my result for a PCI TNT2 M64:

untitled.jpg

Thanks for the screenshot. I was almost going to complain about a bug, because 640x400 256c mode was missing in the author's screenshot and I thought that can't be.
800x600 16c (6Ah) and 640x400 256c (100h) are among the most interesting, because they are available with ISA VGAs with 256 KB of video RAM.

The video mode matrix currently only prints out VESA advertised modes and not the IBM (S)VGA modes. So it would not see 800x600 16c (6Ah) mode even if card supports it. That will change once I implement modescanning.

It definitely looks like that Cirrus Logic card does not implement a VESA 640x400 256c (100h) mode though. It would have enough RAM to do so, but it just does not seem to advertise that mode via its VBE BIOS. I'm sure the card could be programmed to output such a mode via direct register access.. maybe UNIVBE did implement that.

I'm super keen to start testing my PCI cards. As luck would have it I'm gearing up for a house move and most of my retro has gone to storage! But I think I can get away with setting up a test bench soon and retrieving my box of cards.

clb wrote on 2023-08-09, 17:05:

Nice to see that the tool works from within Windows 9x.

Yes that was Win98 SE to be specific - I did run it in pure DOS too and got the same result.

The new version corrected the memory size bug, and I tried it after running UniVBE this time just out of interest. More modes were available, still all 'd' across the board though.

Pierre32 wrote on 2023-08-09, 20:37:

I'm super keen to start testing my PCI cards. As luck would have it I'm gearing up for a house move and most of my retro has gone to storage! But I think I can get away with setting up a test bench soon and retrieving my box of cards.

Congrats on the new house!

Pushed a new update to SNOOP to add detection for Hidden RAMDAC register ( https://pdos.csail.mit.edu/6.828/2008/reading … adoc/RAMDAC.TXT ).

Testing on a Cirrus Logic 5446 made me smile a bit.. these cards must have been selling like hot cakes that they did not have time to update the vendor/product fields from placeholder "Vendor Name", "Product Name", "Revision Number" values. 😁

Also I wonder what that Jaton Corp. was.. never heard of them.

clb wrote on 2023-08-10, 22:06:

Also I wonder what that Jaton Corp. was.. never heard of them.

A long time dead US company. I have an Jaton's S3 Virge/GX ("made in USA").

clb wrote on 2023-08-10, 22:06:

Also I wonder what that Jaton Corp. was.. never heard of them.

I've seen the name "Jaton Corp" on a lot of different OEM graphics cards that seem to be based on the chip manufacturers design recommendation. So likely they sold those card imported from Asia for a competitive price in the USA. The empty vendor strings in your card support the impression of a "low price OEM card".

Another curious card in my test lab is the Jazz Multimedia G-Force 128, which is a Tseng ET6000 in disguise.

It supports tons of resolutions and runs really well with CRT Terminator. The only scary bit about this card is that the Feature Connector is located on the PCB in a "reversed" orientation from what seems to be the common convention. Most cards managed to set the connector in a common orientation where the ground pins are away from the PCB edge on PCI cards (and towards the edge on ISA cards), but there are few percentage of cards that seemingly for no reason decided to rotate the connector 180 degrees around. (as result you see the CRT Terminator Feature Connector cable making an odd twist)

And since the connector is unkeyed, it is possible to make a big mistake when slotting in to the Feature Connector, connecting high speed pixel data signals directly to the ground pins. That would quite possibly trip the PSU, or heat something up more than it could take.

You can see there in the picture I've taken a sharpie and marked the 3+4 ground pins on the Feature Connector on the card, and on the cable (an insurance measure I have done on all my cards to make sure I won't do any mistakes).

That quirk aside, this Jazz Multimedia card is forming to be one of my favorite cards. Although unfortunately, like Vogons has already observed before, Tsengs have trouble with Keen 5 and Jazz Jackrabbit at least. In Keen 5 there is a persistent flicker appearing every second frame (shown below), but fortunately the issue can be remedied by turning on Keen's SVGA Compatibility in Options.

In Jazz Jackrabbit, there is permanent ghosting that appears from the game sprites on screen.

These two artifacts seem to be very distinct, that made me wonder if they are caused by the same root hardware bug, or if they might actually be different hardware bugs. It would be interesting to know if detection of those glitches could be done programmatically and reduced into a small standalone test program. I wonder if any programmers might ever have done a writeup on what exactly is happening with these bugs? The Keen issue seemed to be something to do with hardware scrolling registers, though not sure if that would be programmatically observable. The Jazz bug seems to be something with u32/u16/u8 wide writes to graphics RAM, or some kind of write plane masking? Any other notable DOS games that the Tsengs could not cope with due to these issues?

clb wrote on 2023-08-12, 15:04:

It would be interesting to know if detection of those glitches could be done programmatically and reduced into a small standalone test program.

The Keen issue seemed to be something to do with hardware scrolling registers, though not sure if that would be programmatically observable.

Looks like indeed the Keen issue is easily reproduced by adjusting the Start Address Low Register (Index 0Dh) and Start Address High Register (Index 0Ch) values, they work differently beyond the 256KB address mark on Tseng and other cards.

clb wrote on 2023-08-12, 17:17:

Looks like indeed the Keen issue is easily reproduced by adjusting the Start Address Low Register (Index 0Dh) and Start Address High Register (Index 0Ch) values, they work differently beyond the 256KB address mark on Tseng and other cards.

You can easily program the Start Address Low and Start Address High registers in a way you can observe the "Keen issue" on the screen. The reason is that the original VGA card wrapped around to display data at address 0 when the Current Address exceeds 256KB. As the registers only contain the Start Address, but can't be used to read the current address, I don't see a way to find out whether this wrapping occurs or not without asking the user what's visible on the screen.

clb wrote on 2023-08-10, 13:30:

Congrats on the new house!

Coming soon™ but cheers!

So today I decided to fetch my box of cards from storage, since I still have a socket 7 system sitting around loose. Unfortunately on that same run I put my VGA monitors into storage and didn't put 2 and 2 together until I got home... I am not a smart man 😆 Regardless, I thought I would dive into the box and check out the candidates - and their feature connector orientations.

The S3 & Trident cards have pin 1 towards the rear (plate end) of the card:

The ET6000 is reversed, and my Cirrus GD5446 is also reversed unlike yours!

In the release version of the hardware, will your ribbon cable have a red core for pin 1? That might prevent some drama...

clb, this "CTR Terminator" project seems interesting, but why you're planning only ISA version of the add-in card? For example I have no ISA videocards (currently I own one VC512TM Trident TVGA9000i-1 and one OAK OTI-067) with so called "feature connector", but I found this 26pin connector on my already mentioned Jaton S3 ViRGE/GX (PCI card), on a QDI Legend Rendition Verite 2200 (AGP card) and even on some unknown to me (maybe Palit) nVidia GeForce2 MX400. Is it possible to adapt the project for PCI variant?

mkarcher wrote on 2023-08-13, 01:35:

clb wrote on 2023-08-12, 17:17:

Looks like indeed the Keen issue is easily reproduced by adjusting the Start Address Low Register (Index 0Dh) and Start Address High Register (Index 0Ch) values, they work differently beyond the 256KB address mark on Tseng and other cards.

You can easily program the Start Address Low and Start Address High registers in a way you can observe the "Keen issue" on the screen. The reason is that the original VGA card wrapped around to display data at address 0 when the Current Address exceeds 256KB. As the registers only contain the Start Address, but can't be used to read the current address, I don't see a way to find out whether this wrapping occurs or not without asking the user what's visible on the screen.

CRT Terminator is able to observe this, and route necessary information to the user. I wrote an unit test for this Tseng scrolling and DWORD address decoding behavior, something like below.

Pierre32 wrote on 2023-08-13, 10:29:

In the release version of the hardware, will your ribbon cable have a red core for pin 1? That might prevent some drama...

We are not planning on marking pin 1, but instead, the idea is to mark all the ground pins. This is because not all boards have pin 1 marked, so it is safer to locate via the ground pins. A multimeter in resistance mode can easily find the ground pins.

analog_programmer wrote on 2023-08-13, 11:04:

clb, this "CTR Terminator" project seems interesting, but why you're planning only ISA version of the add-in card? For example I have no ISA videocards (currently I own one VC512TM Trident TVGA9000i-1 and one OAK OTI-067) with so called "feature connector", but I found this 26pin connector on my already mentioned Jaton S3 ViRGE/GX (PCI card), on a QDI Legend Rendition Verite 2200 (AGP card) and even on some unknown to me (maybe Palit) nVidia GeForce2 MX400. Is it possible to adapt the project for PCI variant?

CRT Terminator is an ISA card to keep the project scope reasonable for now. However, even when CRT Terminator is an ISA card, it does support PCI graphics adapters. The motherboard will just need an available ISA slot to work.

It may be possible that in a distant future a PCI version of the card might be done, but that depends on user interest, and the success of the ISA variant.

clb wrote on 2023-08-13, 16:30:

CRT Terminator is an ISA card to keep the project scope reasonable for now. However, even when CRT Terminator is an ISA card, it does support PCI graphics adapters. The motherboard will just need an available ISA slot to work.

It may be possible that in a distant future a PCI version of the card might be done, but that depends on user interest, and the success of the ISA variant.

I mean, the ISA slots on PII/III boards with AGP slot are usually on the "bottom" of the motherboard, so it will be more convenient to use PCI card next to AGP slot. But anyway I got your point.