Shadow Lord wrote on 2024-10-28, 23:36:

Thanks but not exactly what I had in mind. I have done that myself as well but the formatting is not the greatest. I was looking more for something that was properly formatted with matching size pages. That way, if a user wanted to, it could be printed out as a booklet or easily viewed on a tablet without scrolling (I have an old tablet that I use only to read manuals off of. All the PDFs are on my local server and I can pull up a manual whenever/where ever when working on a system). I know the HW is the important bit and is taking all of your time but when/if you get the time you may want to consider a download section on your site where FW updates, any NECESSARY utilities, and the the manual can be easily downloaded. Having github is great but github doesn't help less technical users and not all the info there is needed to just be a user. Just a thought. Thanks and I am looking forward to getting my unit!

That's a great point. I took time today to work with CSS media queries to adjust the page layout specifically for print. That cleaned up the layout for printed PDF to look quite a bit nicer. Hopefully that helps a bit here.

Thanks for your support, we are now working on calculating actual shipping costs for everyone for the first shipping batch, and will soon post the PayPal checkout links. The nearest UPS drop-off point is some 100km away, so we will batch shipments, aiming to get the first batch out to UPS by next Monday.

janih wrote on 2024-10-29, 08:15:

What happens if you input high/true color SVGA to CRT Terminator? Does it display anything?

Ahh, that is a great question.. The short answer is "maybe, try it out and tell us what happens".

As an example, here is one of my favorite ISA VGA adapters, Cirrus Logic CL-GD5422:

In SEA image viewer, I was able to get a 640x480 @ 16bpp image out from it with CRT Terminator:

The video timings coming out from the card are shown in the upper right. Note though that the Developer HUD right will look a bit different in the release version.

So 16-bit does work with that Cirrus Logic card at least. But then I have another newer Cirrus Logic CL-GD5430 card:

which one might expect to be a "newer and better" version of that CL-GD5422 card, but for some reason, on that card the signal quality is worse than on the CL-GD5422, resulting in unstable high and true color video modes. (maybe recapping the CL-GD5430 might have some effect, idk)

So the long answer is that in testing, we see a large amount of variance on how the SVGA adapters decided to treat these video modes.

See, the VESA Feature Connector specification only ever talks about 8-bit video data. There is no official support for 15-bit, 16-bit or 24-bit video in the standard. The pixel bus is fixed 8 bits wide.

In the case of > 8bpp video modes, we see that some adapters simply turn off the FC bus output altogether.

Then we see that some adapters have been hardwired to only send lower 8 bits of the 16-bit/24-bit video signal out from Feature Connector (basically as a byproduct of how hardware wiring is done), discarding the >8 bits lanes (there are no physical outputs from the graphics chips for those bits to the Feature Connector), making it useless for high/true color.

Then we see that some adapters (like the CL cards above) start to double or triple clock the 16-bit/24-bit video modes over the 8-bit FC bus. This will carry all the pixel data at least, but greatly exceeding the maximum rated bandwidth capability of the FC bus, so the output can be unstable (like with CL-GD5430 card above).

And then in some rare cases, we see that the adapters will turn into DDR signaling to clock out the 15-bit and 16-bit video modes. This behavior was highly entertaining to observe the first time we stumbled across it. Trident TGUI9440, WDC WD90C31A-LR at least do this, possibly S3 Vision 864 as well but haven't been able to conclusively verify.

As more or less as a hidden easter egg feature, I did implement support for these different double-/triple-clocked and DDR addressing modes (that was some months of work, I really wanted it to work out!). But it is a wild west, which is why we eventually decided to exclude it from the advertised CRT Terminator feature set altogether. (there are a couple of hidden "easter egg" extra features like this)

So ultimately it is a for-tinkerers "maybe, give it a go and see" kind of a thing.

All the 8-bit palettized color modes, i.e. CGA, EGA and VGA are known to work on all compatible hardware.

clb wrote on 2024-10-29, 09:19:

That's a great point. I took time today to work with CSS media queries to adjust the page layout specifically for print. That cleaned up the layout for printed PDF to look quite a bit nicer. Hopefully that helps a bit here.

Yes. That is much better! Thank you.

This is a really cool project but I wish that the ISA card would have been an external box instead with a simple internal bracket and ribbon cable to expose the feature connector to the back of the machine. The card is quite expensive and for those with multiple machines on which this would be a great addition, it becomes unaffordable quite quickly.

pan069 wrote on 2024-10-29, 19:51:

This is a really cool project but I wish that the ISA card would have been an external box instead with a simple internal bracket and ribbon cable to expose the feature connector to the back of the machine. The card is quite expensive and for those with multiple machines on which this would be a great addition, it becomes unaffordable quite quickly.

I respectfully disagree. Yes, the card is expensive so buying more then one is burdensome but if these homebrew/hobby projects are not properly supported then we won't see them happen. As far as I know nobody is making a living off of one of these types of projects (I am not counting guys like TexElec who mostly mass produce other's designs for those of us who can't make our own). Switching from machine to machine would be a pain but this is such a nicer and neater solution then the box hanging off that we usually see. I would love to see someone incorporate one of the flux readers with a full fledged FDC that supports 8 drives and has connectors for everything form 8" to 3.5" drives. An all in one that lets you do everything without having bare PCB hanging off of your system.

pan069 wrote on 2024-10-29, 19:51:

This is a really cool project but I wish that the ISA card would have been an external box instead with a simple internal bracket and ribbon cable to expose the feature connector to the back of the machine. The card is quite expensive and for those with multiple machines on which this would be a great addition, it becomes unaffordable quite quickly.

Thanks, that is a really interesting idea. One of the challenges with an external box is that the video signal quality starts to degrade the longer the Feature Connector signal becomes, and the 30cm long cable is getting to the limits of the signal stability. VESA standardized the upper limit of the FC bus at 37.5 MHz, but in practice we see the desire to go higher (e.g. the 640x480 @ 16bpp is 43.6 MHz, above the VESA rated specification). An external box would have to balance the cable length with signal quality. Not sure, maybe it would be feasible to have a 40cm or 50cm long cable that would be good enough for the signal and for an external box to lie flat behind a tower case (instead of having it dangle off the back end). The IDE40 and IDE80 pin cables with ATA33, ATA66 etc. standards can maybe serve as a reference, iirc 33 MHz ATA33 still managed with IDE40, but 66 MHz required the isolated grounds with IDE80 pin cables, so the quality drop-off exists somewhere in between.

One of the things in the "future ideas" category has been to ponder whether doing an external CGA/EGA -> DVI-D converter in this manner would be possible. That would be an external USB-C powered converter box exactly like you mention. Of course, CGA/EGA conversion has been done already by hoglet's RGBtoHDMI, so it would be a question of "could we provide any additional features for it to make any sense". But if we did, then maybe such an external converter box could then also have a pin ribbon header input for the Feature Connector to also enable converting VGA in the same box.

Pixel clock is the hard part, since it isn't present. Although you can regenerate it since all the CGA/EGA cards should have same pixel timings, unlike VGA/SVGA things where things tend to be all over the place...

Signal integritywise, it will help to use an intermediate dongle to buffer the signals to a known impedance and then use a fitting cable+connectors to transfer it to final location.

That's true, converting external CGA and EGA will require doing clock reconstruction in order to interpret what the pixel clock will be. The fact that there were only few different possible pixels/scanline values for CGA and EGA will definitely help there.

I dropped the first batch of boxed up CRT Terminators off to UPS today, and the second batch of parcels will go out next Monday. We've got plenty of antistatic padding inserts to defend against UPS people if they decide to play football with the parcels.

Placing the first Terminators in their boxes, oh man, what a crazy feeling.

We are tremendously thankful for everyone's support. On the way to the UPS office, we were recalling back about three years in time to when the project got its spark in a rainy drizzle in midst of a "hey, do you recall what that Feature Connector was all about?" vintage PC chat outside a friend's garage.

If you placed an order and haven't yet received a payment link to complete the checkout, hold on a bit longer - it will probably take me a bit more than a week to get the order queue completely rolling. (I'm verifying with customs how to declare exports to all the different world areas so I don't make any mistake, so that will take a bit)

It is kind of a crazy anxious feeling to wish that the card will work well in everyone's vintage PCs. Though I don't doubt that there will be plenty of "oh why is it doing that?" moments as well with fresh pairs of eyes using it. When you do get your copy, please do have a low barrier to report any issues at https://github.com/juj/crt_terminator/issues , even if they might be "just" documentation issues or similar. I've been staring at the manual text for so long that I'm starting to zone out into that "forest from the trees" state of mind.

Really excited to get this card! I know VLB support is YMMW, but I've got a half-dozen VLB motherboards and VLB cards I want to test out just to see how it works.

Can't wait for this one. 😁

Congrats guys. I've been frothing for this since the first post, but currently find myself in a slightly different financial position than I was a year ago. I'm staying subbed to the thread, and looking forward to all the user reports. Could twist my arm...

Shponglefan wrote on 2024-10-31, 00:09:

Really excited to get this card! I know VLB support is YMMW, but I've got a half-dozen VLB motherboards and VLB cards I want to test out just to see how it works.

Can't wait for this one. 😁

That's fantastic!

The story with our VLB testing is that I had one VLB mobo from old days but couldn't find a VLB graphics card.. got one from eBay, only to realize that the mobo I had was apparently faulty and wouldn't boot. Then decided to get another VLB capable motherboard from eBay.. that one did boot, but oddly, only with ISA graphics cards, and if I put that VLB graphics card in, the system wouldn't post. Then got another VLB graphics card from eBay, which then did boot.. but then to find out that I couldn't get that motherboard to detect any IDE devices, either via a IDE card or using XT-IDE. Argh.

At that point being so much in the red already from hunting all that VLB gear from eBay, we decided to put a lid on the VLB investigation.. there were so many other things to work on in the project (most notably to research how to get PCI SVGA adapters to work), and we had superficially been able to confirm that one VLB card would provide a picture out to get to BIOS screen at least.

Interested to hear how different VLB adapters do in practice.

Pierre32 wrote on 2024-10-31, 08:25:

Congrats guys. I've been frothing for this since the first post, but currently find myself in a slightly different financial position than I was a year ago. I'm staying subbed to the thread, and looking forward to all the user reports. Could twist my arm...

Thanks! Definitely voting to keep all arms (and other body parts) intact. Let's stay on the lookout for the reviews together, it'll be interesting content to read for sure.

The first production run was all bought up and the orders in the first batch have now all been shipped. There were more orders that we had stock for, so for those whose order was left in the queue, we have ordered more components for a second production run. This will take some weeks, but fortunately there should be stock on Mouser for all the needed components, so the lead time shouldn't take too long.

In the meanwhile, I am working on adding more sections to the manual to help some missing gaps of information. Please don't hesitate to contact out if you have any questions.

Congrats on getting this product out the door, it must be an amazing feeling (and a huge relief 😅)

Thanks, it is indeed really good to get the project out there. Although not yet a relief exactly, as we are holding our breath here to see what the feedback will be like 😁

Preliminary results from testing this in my 486 machine with a CL-GD5426 based VLB card.

The output is crisp and sharp. I can tell there is some fudging going on to try to make up for in-between pixels, but it does a good job of this and it still looks sharp and uniform. An extreme improvement over the so-called "scaling" all LCD monitors do with their VGA inputs, and all VGA scalers for that matter.

Issues I've noticed so far:

1. No way to get the palette correct with this VLB card. The PCI TSR obviously doesn't work since this isn't a PCI system. I'm not seeing a VGA Palette Snoop option in the BIOS, so that's a dead end. Is it possible to write a TSR for VLB systems? Is there a way to program the card to pass palette writes to the ISA bus, as in this post? Re: CRT Terminator Digital VGA Feature Card ISA DV1000
2. In the Keen menu screenshot, note that there is one vertical column of pixels left over from the overscan border on the left hand side - and since I'm monitoring this on my CRT as well, I can tell you that there is another vertical column of actual pixels on the right hand side that is cut off.
3. Also in the Keen screenshot, if you look at the grid you can see that the individual pixels look a little uneven. Every other row is larger. Maybe some more "fudging" could be done to alleviate this - but if that comes too much at the expense of sharpness, maybe it could be an optional feature?
4. I tried to use SNOOP to configure the VGA border, but the interactive menu seems to be broken. The menu gets written over the top of the diagnostic output on the right hand side of the screen, and pressing enter to select an option does nothing.

Heya, thank you so much for the review! Really good points overall.

keenmaster486 wrote on 2024-11-21, 04:50:

Preliminary results from testing this in my 486 machine with a CL-GD5426 based VLB card.

The output is crisp and sharp. I can tell there is some fudging going on to try to make up for in-between pixels, but it does a good job of this and it still looks sharp and uniform. An extreme improvement over the so-called "scaling" all LCD monitors do with their VGA inputs, and all VGA scalers for that matter.

This is very relieving to hear. Let me go over the different points below.

keenmaster486 wrote on 2024-11-21, 04:50:

Issues I've noticed so far:

1. No way to get the palette correct with this VLB card. The PCI TSR obviously doesn't work since this isn't a PCI system. I'm not seeing a VGA Palette Snoop option in the BIOS, so that's a dead end. Is it possible to write a TSR for VLB systems? Is there a way to program the card to pass palette writes to the ISA bus, as in this post? Re: CRT Terminator Digital VGA Feature Card ISA DV1000

Ahh right. I do indeed have just the TSR for the "last resort" case when the VGA adapter cannot be configured to enable palette snoop, and the motherboard does not provide an option either. I now notice that I had not uploaded that TSR to GitHub. Added the PALTSR.EXE program there now (download zip here), and added links to the TSR in the manual as well.

Although, the comment you linked indeed discovers that CL-GD542X adapters should have a Shadow DAC option in the adapter itself. I don't have a ISA VLB setup that works, so I'm writing a bit blind here, but I created a test program to enable that bit:
- CLGD_DAC.CPP
- CLGD_DAC.ZIP

That test program is not a TSR yet though. My hope is that it wouldn't have to be. Give it a test and see if it works. A test scheme could be as follows:

1. Run CLGD_DAC.EXE and verify it prints that Shadow DAC was originally DISABLED, but are now ENABLED.
2. Run CLGD_DAC.EXE again to verify that it prints that Shadow DACs were enabled.
3. Run some VGA game and see if palette colors work correctly there.
4. Quit the game and rerun CLGD_DAC.EXE.
5. See whether it prints that Shadow DAC was originally DISABLED or ENABLED.

-> if palette colors work correctly in step 3, then everything is set, and the tool won't need to be a TSR.
-> if palette colors do not work correctly in step 3, but step 5 prints that Shadow DAC was DISABLED, then re-doing it as a polled latching TSR would help.
-> if palette colors do not work correctly in step 3, and step 5 prints that Shadow DAC was ENABLED, then something was wrong with the program, or the CL-GD542x register bit doesn't quite work like expected.

The PALTSR.EXE should work as a fallback for all VGA adapters, although compatibility issues with different games may occur.

keenmaster486 wrote on 2024-11-21, 04:50:

2. In the Keen menu screenshot, note that there is one vertical column of pixels left over from the overscan border on the left hand side - and since I'm monitoring this on my CRT as well, I can tell you that there is another vertical column of actual pixels on the right hand side that is cut off.

This suggests an incorrectly detected phase sampling of Display Enable signal by the automated jumper setting J2. If you disable automatic phase sampling (set J2 to 2-3: Disabled), and try both states of J4 (Display Enable phase sampling), does that fix the off-by-one error?

It is possible that flipping the J2 jumper might cause other signal failures, so you may need to then toggle the J3, J5 and J6 jumpers to accommodate.

keenmaster486 wrote on 2024-11-21, 04:50:

3. Also in the Keen screenshot, if you look at the grid you can see that the individual pixels look a little uneven. Every other row is larger. Maybe some more "fudging" could be done to alleviate this - but if that comes too much at the expense of sharpness, maybe it could be an optional feature?

Can you double-check that you have Multimode enabled? (DIP 2.1) Enabling Multimode, and forcing LCD display to output 4:3 should address this type of effect that occurs when Multimode is disabled.

keenmaster486 wrote on 2024-11-21, 04:50:

4. I tried to use SNOOP to configure the VGA border, but the interactive menu seems to be broken. The menu gets written over the top of the diagnostic output on the right hand side of the screen, and pressing enter to select an option does nothing.

Thanks for reminding.. that part of SNOOP is a bit work-in-progress. I initially started writing an interactive menu there to configure CRT Terminator, but then later decided to pivot the purpose of the tool to be that kind of a "one-pager" diagnostic report utility, and a VGA quirks scanning utility. There is a separate CRTT.exe config tool program that I started writing recently to just configure the different settings of CRT Terminator. I'll try to upload a version of that this coming weekend.

Thank you so much for all the feedback, really nice to hear about ISA VLB compatibility for CRT Terminator.

Thanks for the quick reply. I tried your new DAC register tool, and it told me that it was already ENABLED. Running the tool had no effect on the palette.

The PALTSR tool worked, though. I have correct colors now.

Still testing and will post updates as I have them.

Another "issue", although this may simply be a limitation of the chip you're using: it takes a bit to switch resolutions. Maybe 2-3 seconds.

I also enabled Multimode and it fixed the uneven pixels. I was a little confused as to what "Multimode" meant - I guess it doesn't change the output resolution?

keenmaster486 wrote on 2024-11-21, 18:30:

Thanks for the quick reply. I tried your new DAC register tool, and it told me that it was already ENABLED. Running the tool had no effect on the palette.

Hmm, that's unfortunate. Re-reading the spec sheet, not quite sure where the issue would be, or if the Shadow DAC feature works somehow different than what I assume.

keenmaster486 wrote on 2024-11-21, 18:30:

The PALTSR tool worked, though. I have correct colors now.

That's great to know. It should work as a compatibility fallback for most adapters. Although some timing related issues could cause visual glitches or incompatibility on some DOS games.. more experience will be needed here.

keenmaster486 wrote on 2024-11-21, 18:30:

Another "issue", although this may simply be a limitation of the chip you're using: it takes a bit to switch resolutions. Maybe 2-3 seconds.

Currently I suspect that the slow syncs are a behavior on the LCD display end. From CRT Terminator perspective, it should take about two to three video frames (< 50 msecs) for CRT Terminator to change a video mode.

I've observed that when I feed CRT Terminator into my StarTech HDMI capture USB box, the video mode changes are practically instantaneous. But on the same video input (via a HDMI splitter), my ASUS PA248QV LCD display will blank the screen for more than a second before showing the new video mode. I'm not quite sure why some displays want to take a few seconds to display a new mode, but that is something that the StarTech HDMI capture device at least is pretty immune to.

I did actually send an email to ASUS's display department to list out improvements to how they could evolve their ASUS PA248QV display to be the "ultimate" vintage PC retro monitor. Fast video mode switch sync was one of the items I mentioned there. They never replied back 😁

keenmaster486 wrote on 2024-11-21, 18:30:

I also enabled Multimode and it fixed the uneven pixels. I was a little confused as to what "Multimode" meant - I guess it doesn't change the output resolution?

That's great. The way MultiMode works is it first crops the video geometry visible area, then possibly inserts black borders if it deems necessary, then upscales the video by an integer multiple in width and height directions, and lets the LCD display resample the rest to fit in the 4:3 mode. The idea here is to constrain the display from applying soft bilinear filtering on the video content.

This does mean that whenever the DOS input resolution changes, MultiMode will search a new output video mode, based on a large video mode table that has heuristic entries for about ~250 {(S)VGA adapter} x {custom DOS video mode} combinations, to recognize video modes used by e.g. the Pinball games, The Incredible Machines, Jazz Jackrabbit, Jurassic Park, Mode-X games etc that are known to use custom video modes. Then if StutterStop is enabled, the output video refresh rate is matched using a video geometry timing search algorithm to lock the output video refresh rate to the input. Generally MultiMode and StutterStop are recommended to be on, except if the output display/HDMI capture device doesn't support it.

(For example, my StarTech doesn't like to get 70Hz video as input, so StutterStop needs to be disabled there)

Hmm. All this is why I disabled Multimode and Stutterstop in the first place, hoping to get a single fixed output resolution and refresh rate that never changes, thus mitigating dropouts due to mode changes - but I still have dropouts.

I guess I should enable Stutterstop too as long as I'm going to have dropouts anyway.

The dropouts occur with both my capture device and my monitor, fwiw.

One more thing I forgot to mention: the PALTSR tool takes up 7K of RAM. Couldn't this be much less? Seems like what it's doing isn't that complex.

keenmaster486 wrote on 2024-11-21, 20:32:

Hmm. All this is why I disabled Multimode and Stutterstop in the first place, hoping to get a single fixed output resolution and refresh rate that never changes, thus mitigating dropouts due to mode changes - but I still have dropouts.

I guess I should enable Stutterstop too as long as I'm going to have dropouts anyway.

Yeah, agree that enabling StutterStop makes sense to do while having MultiMode enabled, if the HDMI capture device and LCD display support it. The video mode change is done "simultaneously" for resolution and refresh rate.

Disabling both will give that single fixed output resolution that does not change, even if the input video mode changes.. That should not produce video dropouts. But that does have competing interests vs the upscaling challenges to match the video resolution and refresh rate with the input.

If you're interested in "perfectly" upsampled video quality for 320x200 without enabling MultiMode, then one way to achieve that might be to run on a 1600x1200 display, which is an integer multiple of 320x200. I finished adding a new section in the manual about pixel-perfect upscaling: https://oummg.com/manual/#pixel_perfect_upscaling .

keenmaster486 wrote on 2024-11-21, 20:32:

One more thing I forgot to mention: the PALTSR tool takes up 7K of RAM. Couldn't this be much less? Seems like what it's doing isn't that complex.

I agree, and believe it could, if I only knew how. I get an impression that Borland Turbo C++ 3.0 that I used to create that is possibly not the best tool. Maybe handwriting the TSR fully in assembly would be the way to go for these types of things. I might try disassembling what Borland Turbo C++ 3.0 generated for that, and writing an assembler version of the same.