The FPGA that we are using is a Gowin one. So far we have had a decent relationship with them, and have received quick tech support (although sometimes of a bit of a junior nature that we've observed, or something lost in translation) and also free samples readily available just by asking. Their boards have been decent, although not perfect - in early development we took a few months to find errata and reverse engineer some of their RAM behavior.

The snafu we now have had with them is due to a certain order/production mixup. They have given a friendly reply to us so far, even though we are tiny hobbyists.

I've expressed interest in the crt terminator in using old 386,486 PCs.

I'm hoping to get good results hooking up a Gigabyte Auros F04U (48" OLED), is this the type of monitor something you guys had in consideration?

I would be using cirrus logic CL5434 & S3 868 type of cards.

When you state that 256 color mode is the initial target, is this device upgradable by firmware to improve support if required for higher resolution and color modes (i.e 800x600/1024x768 16 bit)?

It would be nice to play around with windows 95/98 at mid 90s targeted resolution and color depth.

dirkmirk wrote on 2024-01-03, 08:08:

I'm hoping to get good results hooking up a Gigabyte Auros F04U (48" OLED), is this the type of monitor something you guys had in consideration?

Gaming monitors are unfortunately not something that we've tested. So far testing has focused on older flat panels and some 1920x1200 displays (that we consider appealing for the 1600x1200 pixel perfect upscaling possibility). In my lab I have the following:

Fujitsu-Siemens P19-1 YEGA519530
Dell 2007WFP
Dell 2007FPB
ASUS ProArt PA248QV
Sony SDM-X73
BenQ BL3201PT
BenQ ET-0029-B
HP EliteDisplay E241i
Philips Brilliance 252B9/00

(of which Philips Brilliance 252B9/00 and ASUS ProArt PA248QV work the best, and they are 1920x1200)

dirkmirk wrote on 2024-01-03, 08:08:

I would be using cirrus logic CL5434 & S3 868 type of cards.

I have a Diamond Speedstar 64 1 MB PCI CL-GD5434 in my lab, which works nicely with CRT Terminator; except that there is a unique quirk in that card specifically that it forgets PCI bus palette snoop settings on every video mode change.

I wrote a TSR to fix that, which seems to work decently.

I don't seem to have a S3 868 card in my lab, the closest that I do is a S3 864:

Although I don't have a recollection of having put this card through much testing, so I'm not 100% sure how it fares. _Some_ S3 cards (might be just in the Trio line?) have a vendor/firmware-specific behavior that in order to get output from the Feature Connector, a S3-specific register must be enabled. SNOOP.EXE does that, and so can be placed in autoexec.bat, but it unfortunately means that on those cards there won't be any image during boot until that executes.

Iirc this is due to a hacky limitation of S3 (Trio?) they have that Feature Connector lines are shared with VRAM, or something like that.. so enabling the Feature Connector requires disabling half of the VRAM. (4MB -> 2MB maybe? I'm a bit hazy on the details when writing this right now)

dirkmirk wrote on 2024-01-03, 08:08:

When you state that 256 color mode is the initial target, is this device upgradable by firmware to improve support if required for higher resolution and color modes (i.e 800x600/1024x768 16 bit)?

It would be nice to play around with windows 95/98 at mid 90s targeted resolution and color depth.

I am afraid that this will likely not be possible.

CRT Terminator does have the option to upgrade the firmware after release, so we can mitigate problems after shipping.

However, the underlying reason here is that the Feature Connector is only a 8-bit data bus.

We observe that few rare VGA cards do output 16-bit and 24-bit color modes over the 8-bit bus by double and triple-clocking the video, which means the clock speed of the bus doubles or triples.

Some cards don't output 16-bit and 24-bit color modes via the 8-bit Feature Connector at all, but they just output the lowest 8 bits of the 16-bit video signal, and the highest 8 bits are discarded, making the hi/true-color output completely unusable. (yeah, spent some two and half weeks double and triple checking that to believe) I hunted for a possible VGA/RAMDAC register that might be able to change this behavior, but never was able to get any to work.

Some reverse-engineered notes about RAMDAC chips hint to the possibility of DDR signaling 16-bit modes over a 8-bit bus, but despite searching, we haven't been able to find and activate a single card/RAMDAC to do this. So there may be some future mysteries unsolved or to be debunked.

VESA standardized their later "VAFC" connector to run at max 37.5 MHz clock speed, which is essentially the same for this 8-bit Feature Connector bus. That speed is good for 800x600 @ 256 colors max.

In testing, some cards run a bit better, e.g. at 40-50MHz, but sadly not nearly as much better to be able to cope with the 2x or 3x pixel clock speed that would be required for 16-bit and 24-bit video modes.

So I recommend assuming that it won't be possible to get CRT Terminator to output new video modes after shipping, we want to be very cautious to avoid building up any disappointments in expectation.

Back in the days, there were a number of TV tuner and MPEG-1/2 cards that could be connected to the VGA Feature connector using a ribbon cable. I assumed that the VGA Feature connector was an input only connector where you could feed video signals that are genlocked over the computer VGA output. But I guess it is both input and output (IO). Did you test the CRT Terminator with the signals coming from the Hauppauge WinTV, Sigma Hollywood Plus, Sigma X-Card or others? This would be an interesting experiment to try out. Sigma calls this a PDI = Parallel Digital Interface ribbon cable. The PDI cable could also be connected to deinterlacer/scaler cards like the PDI Sweetspot or Immersive Holo3DGraph. I am interested in your feedback on this? Christian

That is an interesting idea.

The Feature Connector does go both ways on a lot of ISA and PCI VGA cards. On AGP cards, we oddly see it only working as an input (or are missing some configuration in AGP space to turn it to go around).

We haven't tested any of these other accelerator cards. If their signal is compatible with Feature Connector (hsync, vsync, display enable and 8 bits of pixel data), then it is possible that those could be compatible.

clb wrote on 2024-01-03, 13:01:

Some reverse-engineered notes about RAMDAC chips hint to the possibility of DDR signaling 16-bit modes over a 8-bit bus, but despite searching, we haven't been able to find and activate a single card/RAMDAC to do this. So there may be some future mysteries unsolved or to be debunked.

This mode is not just in RAMDAC.TXT, but can also be found in original DAC data sheets. That mode is also known as "Sierra mode", because Sierra RAMDACs likely were the first successful DACs that supported this mode. You can find it in the SC15025/SC25026 data sheet as "Pixel repack mode 1a" (2 DDR 8-bit transfers, i.e. 1 clock period, per pixel for 16bpp) and "Pixel repack mode 3a" (4 DDR 8-bit transfers, i.e. 2 clock periods, per pixel for 24 bpp; 8 bits ignored). I also associate that mode with Tseng graphics chips, but failed to find it in the ET4000W32 data sheets scans I have. I did find it in the ET4000AX datasheet, though! Figure "2.3.2-1 CRTC Output Timing" shows SDR transfers as well as DDR transfers on the 8-bit pixel port. The DDR transfer is labelled "high color mode", and the SDR transfer is labelled "excluding high color mode". High color mode is enabled by setting both bits 4 and 5 in attribute controller register 16h. This combination is labelled "reserved" in the W32 data sheet, but there is a note "to support ET4000 Rev. G's high color mode, configure CRTC and ATC to 8-bit per pixel (256 color mode) and clock AP<0:7> with double clocking". As my scans of the W32 data sheet contain no OCR, I didn't extensively search how to "clock AP<0:7> with double clocking", so maybe the W32 chips require external help.

I recently had a ET4000AX ISA card at hand in which the POST screen explicitly mentioned "Rev. G" which seems to be the required revision to get the DDR mode. At the moment, I don't have the system at hand to take a photo of that card, or look at VGA museum to find any scans over there, but I might be able to get there next weeks. I expect that card to use DDR high-color modes, if it has a high-color DAC at all.

EDIT: The Diamond Speedstar 24 is likely a good starting point to hunt for that DDR mode.

Since writing that previous note, I have been able to find two adapters where the DDR signaling is readily observable: WDC WD90C31A-LR (my card has that Sierra SC11487CV-80 RAMDAC) and Trident TGUI9440 (Integrated RAMDAC). This DDR signaling does come through the Feature Connector as well.

Oddly though, both of these adapters stop using DDR signaling in any higher resolutions, and they turn off the output signal lines going to the Feature Connector altogether. So the usefulness of this mode may be limited. (Are there great VESA based games that use 320x200@15/16bpp, 320x240@15/16bpp or similar?)

Higher resolutions like what, 640x480? Because it would be nice to get 640x480 high color in Windows.

clb wrote on 2024-02-09, 10:34:

Oddly though, both of these adapters stop using DDR signaling in any higher resolutions, and they turn off the output signal lines going to the Feature Connector altogether. So the usefulness of this mode may be limited. (Are there great VESA based games that use 320x200@15/16bpp, 320x240@15/16bpp or similar?)

For the WD90C31-based card, that seems strange. Typically, the pixel data lines on the feature connector are physically connected to the 8-bit DAC pixel input port, so there should be no way for the pixel data to "disappear" from the feature connector. The clock might be controlled separately, and it is not completely unimaginable that the clock signal is shut off in modes that are deemed to be "feature-connector incompatible" for whatever reason. On the TGUI with its integrated RAMDAC, the chip designers obviously have the freedom to internally connect the RAMDAC using different signals than the feature connector, so it's not as strange on that card as on the WD card.

It was the Hsync, Vsync and Display Enable signal lines that went down, although the pixel clock signal was still present. Not sure what was the state of the pixel color data lines (though even if they were still signaling, reconstructing the visible picture without hsync,vsync and DE would be quite tough)

keenmaster486 wrote on 2024-02-09, 16:34:

Higher resolutions like what, 640x480? Because it would be nice to get 640x480 high color in Windows.

Sadly this adapter was only giving 320x200 and 320x240 in 15bpp.

Although I have been able to get 640x480@16bpp working on some other adapters (that utilize SDR signaling). But, I don't want to get your hopes too high here, since be it SDR or DDR, both frequencies are out of spec of the connector. We cannot really guarantee that it works.. which is why we are recognizing the < 37.5 MHz spec that VESA advertised.

clb wrote on 2024-02-09, 19:42:

Although I have been able to get 640x480@16bpp working on some other adapters (that utilize SDR signaling). But, I don't want to get your hopes too high here, since be it SDR or DDR, both frequencies are out of spec of the connector. We cannot really guarantee that it works.. which is why we are recognizing the < 37.5 MHz spec that VESA advertised.

640x480 at 60 Hz uses a dot clock of 25.175 MHz. If you use DDR transfers for the pixels, the clock signal is still 25.175 MHz, even though you need to transfer 16 bits per cycle. I would consider that "in spec" if the clock is supposed to stay below 37.5 MHz. There is a quad tri-state line driver next to the DAC on the WDC 90C31 board I can find on the VGA museum. That chip could be used to conditionally enable or disable signals on the feature connector.

The VESA specification never standardized a DDR mode, so it is basically out of spec by omission.

Looking at the required setup and hold times for SDR signaling on that 37.5 MHz, they say that for a clock period of 26.6ns, the minimum setup time is 10ns and required hold time is 2ns. Theoretically 2*(10+2) = 24 < 26.6, so one could argue that a DDR signal should fit within the timing frame.

But still, these are several decades old hardware, so every case will be a bit of a ymmv thing.