clb wrote on 2024-11-27, 21:26:

One way that I thought to mitigate this problem might be for the PALTSR interrupt to use a heuristic : when the update interrupt it reads the currently active palette write index from 3C8h, it would compare it to what the active palette write index at the start of the previous interrupt run would be. If the previously active palette write index is different than the current one, the idea is to think "maybe we're right in the middle of an update", and the interrupt would skip mirroring the palette to CRTT. I.e. only when the palette index is seen to be identical twice in a row, the palette is mirrored to CRTT.

I was thinking of something slightly different for the beginning of the TSR's update loop:
- read 0x3C8
- write a dummy value to 0x3C9
- read 0x3C8 again, if the index has incremented we know the app was about to write a "B" value. At the end of the update loop we need to restore the write index and write the previous red and green values.
- else write another dummy value to 0x3C9, again check if 0x3C8 has changed. If so then the app was about to write a "G" value, do the same as above but only write the red value.

Obviously this depends on the hardware only updating palette entries when all 3 values have been written / discarding the dummy values, otherwise it would modify existing palette data.

Another option would be skipping the TSR's update loop if vsync is active, since most games will only do palette updates during that time. So the CRTT might see updates a little bit later but the risk of corruption would be less.

That's very clever. Could work as well for sure. Makes for interesting testing this weekend, I think 😀

Actually, gave that scheme a go at https://github.com/juj/crt_terminator/commit/ … 4e5d63bff8365b7

It totally works as well, and based on the PC speaker "sound(); nosound();" debugging, the workaround tends to trigger less often than the previous workaround code I linked.

I gave PALTSR a bit more testing based on different test games and programs I have, and it looks like both the previous "skip update if palette index changed" and the "detect if updating a sub-component" scheme seem to work. Here are some of the more interesting test cases I found:

Wiering's Mario: Both methods work, the workarounds both trigger there
Jazz Jackrabbit: workarounds trigger all the time, creates different artifacts in the background sky with the two methods.
Cyril Cyberpunk: works ok, triggers repeatedly
Copper demo: works ok in both, except for the copper bars which never show up

Though PALTSR does have its limitations. The following tested games/demos don't work at all with it: Prehistorik 2, Yo, Luminati, Kukoo 2, Ambience, Pinball Fantasies, Psycho Pinball, Pinball Illusions, X14, Crystal Caves, Cannon Fodder.

I think this is because these games replace the default timer interrupt without chaining. So the interrupt that PALTSR register doesn't have a chance to fire at all. It's hard to say if there might be another interrupt that could work better.

Taking a step back though to gain perspective - I don't know of any ISA or PCI scenarios that would need PALTSR, so this hopefully will be bit of a niche requirement. I wonder how many ISA VLB users will need to use PALTSR, and how many would be able to enable palette snooping in hardware (either on the VGA card or on the motherboard BIOS). I'm still a bit puzzled why enabling snooping didn't work for Keenmaster's Cirrus Logic card - the registers did seem to check out.

I think it would be a good idea if there was a version of the CRT Terminator that outputted SDI for use with capture cards

Xpl0itR wrote on 2024-12-02, 19:53:

I think it would be a good idea if there was a version of the CRT Terminator that outputted SDI for use with capture cards

What do you gain from SDI over HDMI at these resolutions and refresh rates?

Shitty chroma subsampling?

yeah, SDI doesn't give RGB or YUV444, only 420 and maybe 422, except perhaps the later flavors which require several cables.

Shows how little you two know, dunno where you get 4:2:0 from because all SDI standards support 4:2:2, with dual-link hd or single link 3g and above supporting 4:4:4 YCbCr or RGB, and that's at 1080p60, at lower res there's even more available bandwidth.

The HDMI capture card recommended in the user manual only captures 4:2:0, other HDMI capture cards don't support the DVI-D signal the terminator outputs on its HDMI connector.

keenmaster486 wrote on 2024-12-02, 20:55:

Xpl0itR wrote on 2024-12-02, 19:53:

I think it would be a good idea if there was a version of the CRT Terminator that outputted SDI for use with capture cards

What do you gain from SDI over HDMI at these resolutions and refresh rates?

For one I already own a couple SDI capture cards. It's also nice that they can take multiple inputs so you can capture from multiple computers simultaneously, or just simply plug your computers in once and switch between inputs without having to replug any cables.

My SDI knowledge comes from reading some of the (leaked) broadcast specs and service manuals of variety of broadcast equipment, which only list YUV420 at up to 1080i, so I suppose it is a bit outdated on at least some regards. Also some datasheets of SDI receivers and transmitters, although those were positively ancient and near the beginning of high speed serial links developments.

But as far as supporting SDI goes, it seems to be totally impossible to buy any off the shelf parts that can do it, and because of the very high speed serial link, you're gonna need relatively capable FPGA to actually output it if one were to "bitbang" it.

Well, my EVGA XR1 Lite is doing 4:2:2 at 1080p60 without any issues so far. That at least is good enough for me.

Xpl0itR wrote on 2024-12-02, 19:53:

I think it would be a good idea if there was a version of the CRT Terminator that outputted SDI for use with capture cards

Thank you for this idea, it is greatly appreciated. At this point, we're focusing on "maturing" all the documentation and software and are not planning new hardware iterations. My weekends are well booked on improving the software and docs side of things to fill up gaps in the manual.

Maybe in the future if there is a growing need for SDI, it might become a thing to consider.

Xpl0itR wrote on 2024-12-03, 18:49:

The HDMI capture card recommended in the user manual only captures 4:2:0, other HDMI capture cards don't support the DVI-D signal the terminator outputs on its HDMI connector.

As for the 4:4:4 vs 4:2:2 vs 4:2:0 conversation, this is one of the things that fortunately doesn't matter with CRT Terminator. This is because e.g. to capture 320x200, CRT Terminator's Passthrough mode will output 640x400 anyways with 2x pixel upscaling, so the decimated Chroma channels will be invisible there. By setting the maximum resolution in DIP1.1 - DIP1.4 boxes, one can also get e.g. 4x pixel upsampling for more lossy Chroma modes, so effectively a lossy Chroma channel can be mitigated that way.

In the current manual I point that limitation out, but it turns out that the problem was OBS UI all along. I confused that for a hardware limitation, all the while thinking "lossy chroma shouldn't be a problem but for some reason it is", and only recently realized that it was a UI fluke with OBS. I commented in Re: Lossless and pixel perfect video capture of DOS 70 Hz 320x200? in more detail about that. Could be a USB3HDCAP + OBS specific interaction thing. I'm in the process of rewriting those sections in the manual and doing the screen captures again without the lossy chroma, now with the correct OBS settings applied that can be avoided.

I purchased a USB3HDCAP the other day, only to discover that it doesn't work on Linux 🤣.

My complaint about the EVGA is that it won't do 1600x1200. It scans it as 800x600.

keenmaster486 wrote on 2024-12-04, 17:06:

I purchased a USB3HDCAP the other day, only to discover that it doesn't work on Linux 🤣.

🤣, I made the exact same mistake a while back 😅

Really baffling how a USB device for video capturing doesn't work in Linux in this day and age. You'd think that it would support one of those standard USB device classes or something. But nope, not this one.

It reminds me to put it back up for sale at some point. That, or donate it to a Linux developer who would genuinely be willing to develop a driver for it.

I think I got the EVGA XR1 capture box when doing R&D on how CRT Terminator behaves on different capture devices, but now I can't quite locate it anywhere. Too much hardware lying around everywhere I guess. 😒

As the latest update, I re-did the OBS video captures with correct OBS settings to avoid a "doubled Chroma loss" artifact that was present in the screen grabs, and finished up the CRT Terminator config utility "CRTT.EXE", which can be downloaded from https://github.com/juj/crt_terminator/tree/main/DOS/bin. It can currently be used to control the card in four different ways:
- Enable/disable reading VGA palette updates (this is different from the snoop setting. This setting makes CRT Terminator actively ignore VGA palette updates even if it was seeing them)
- Enable/disable the PCI VGA palette snoop setting for PCI graphics cards.
- Enable/disable VGA border crop. By default CRT Terminator crops away the VGA border. This might not work for all VGA adapters/peculiar video modes/sampling phase settings. This allows disabling the border crop altogether, to enable viewing the VGA border along with the image.
- Enable/disable vsync. By default CRT Terminator displays video vsync-locked (triplebuffered). Disabling this makes CRT Terminator upscale single-buffered without vsync. Not sure if this will be interesting/useful, but it's there to enable testing effects of video latency.

The PCI snoop setting persists until PC reboot. Other settings persist until physical PC power down.

digger wrote on 2024-12-05, 11:54:

LOL, I made the exact same mistake a while back :sweat_smile: […]
Show full quote

keenmaster486 wrote on 2024-12-04, 17:06:

I purchased a USB3HDCAP the other day, only to discover that it doesn't work on Linux 🤣.

🤣, I made the exact same mistake a while back 😅

Really baffling how a USB device for video capturing doesn't work in Linux in this day and age. You'd think that it would support one of those standard USB device classes or something. But nope, not this one.

It reminds me to put it back up for sale at some point. That, or donate it to a Linux developer who would genuinely be willing to develop a driver for it.

Developing one isn't really the problem. Maintaining it, and keeping it working whilst the rest of the code the driver relies on gets changed 'for the better', that is a lifetime commitment.

sorry for the offtopic. please go on.

clb wrote on 2024-12-05, 20:33:

I think I got the EVGA XR1 capture box when doing R&D on how CRT Terminator behaves on different capture devices, but now I can' […]
Show full quote

I think I got the EVGA XR1 capture box when doing R&D on how CRT Terminator behaves on different capture devices, but now I can't quite locate it anywhere. Too much hardware lying around everywhere I guess. 😒

As the latest update, I re-did the OBS video captures with correct OBS settings to avoid a "doubled Chroma loss" artifact that was present in the screen grabs, and finished up the CRT Terminator config utility "CRTT.EXE", which can be downloaded from https://github.com/juj/crt_terminator/tree/main/DOS/bin. It can currently be used to control the card in four different ways:
- Enable/disable reading VGA palette updates (this is different from the snoop setting. This setting makes CRT Terminator actively ignore VGA palette updates even if it was seeing them)
- Enable/disable the PCI VGA palette snoop setting for PCI graphics cards.
- Enable/disable VGA border crop. By default CRT Terminator crops away the VGA border. This might not work for all VGA adapters/peculiar video modes/sampling phase settings. This allows disabling the border crop altogether, to enable viewing the VGA border along with the image.
- Enable/disable vsync. By default CRT Terminator displays video vsync-locked (triplebuffered). Disabling this makes CRT Terminator upscale single-buffered without vsync. Not sure if this will be interesting/useful, but it's there to enable testing effects of video latency.

The PCI snoop setting persists until PC reboot. Other settings persist until physical PC power down.

Tested the border crop feature. Works.

keenmaster486 wrote on 2024-12-05, 22:59:

Tested the border crop feature. Works.

Cool - while implementing that it did make me wonder if there were ever any games that would do something with the border, e.g. animate/flash it red or some other color when player was hit. But can't recall any game doing anything like that. The only game I know is Commander Keen that paints the border cyan.

clb wrote on 2024-12-06, 10:22:

keenmaster486 wrote on 2024-12-05, 22:59:

Tested the border crop feature. Works.

Cool - while implementing that it did make me wonder if there were ever any games that would do something with the border, e.g. animate/flash it red or some other color when player was hit. But can't recall any game doing anything like that. The only game I know is Commander Keen that paints the border cyan.

Take a look at Alley Cat, especially the fish bowl level. If I remember correctly, on my first VGA card, that game changed the border color to show how much air the cat has left before drowning. With CGA register-level compatibility enabled, the color of the cat changes as well or instead of the border.

@clb @jmarsh, any plans to release a binary for the assembly version of PALTSR?

mkarcher wrote on 2024-12-06, 15:49:

Take a look at Alley Cat, especially the fish bowl level. If I remember correctly, on my first VGA card, that game changed the border color to show how much air the cat has left before drowning. With CGA register-level compatibility enabled, the color of the cat changes as well or instead of the border.

Oh right. Indeed!

keenmaster486 wrote on 2024-12-06, 19:36:

@clb @jmarsh, any plans to release a binary for the assembly version of PALTSR?

Thanks for reminding. That slipped my mind to put it to GitHub. Uploaded it now. GitHub commit, GitHub directory and Download ZIP. That is the original code from jmarsh assembled to a .COM file. It does not yet have the "fail-safe" heuristic that we pondered about a couple of comments above. The .EXE version does have that first attempt of the fail-safe. Curious to hear if you find any difference between the two. I tried out a few different versions of the heuristic to try to benchmark which would be the best, but did not come to a conclusion.