jmarsh wrote on 2025-03-05, 10:30:

I guess if it's 96% used, you definitely don't have room for a 65536 (256x256) byte LUT to avoid multiplying...

Yeah, unfortunately no. Cheeky idea 😀

jmarsh wrote on 2025-03-05, 05:51:

That was added when support for opengl shaders was implemented, unsurprisingly I named the shader "sharp" because I couldn't think of anything more fitting. It uses no blending except for the rows and columns of output pixels that straddle input pixel boundaries, where it uses bilinear. In cases where the input size is an exact integer multiple of the output size the output should be identical to nearest-neighbour.
Even though it's implemented using a shader in DOSBox it's not too difficult to implement in software with no more cost than a regular bilinear transform.

Nice, didn't expect the author of that code to chime in. Thanks for the info.

clb wrote on 2025-03-05, 10:14:

This is definitely not a matter of "I don't want to do it", believe me, I would love to implement this in the FPGA, and would do it in a split second to accommodate this request if I could, but it requires a more powerful and larger FPGA to make it all fit.

Originally when we designed CRT Terminator with its Multimode feature as a way to achieve this desirable "surface area sampling" image quality, we thought that since the 1-2 second video resync effect that it brings is fundamentally unavoidable anyways, (since each VGA video mode has different refresh rate that necessitates a resync anyways to get the "no frameskipping or stuttering" result, which we thought would be a non-starter for users if frameskip/stuttering occurred) that adjusting the resolution for the MultiMode strategy is an ok way to achieve the best image quality, as it can happen "for free" at that resync.

Unfortunately we just did not anticipate this other ordering of preferences, where giving up no-frameskip/stuttering would be more preferable to get immediate video mode changes, while (naturally) not wanting to sacrifice any image quality when making that tradeoff. 🙁 In hindsight I understand this request - it is just that the development of CRT Terminator was very much led by the aim to solve the pixel-perfect no-stuttering 320x200 -> 1600x1200 upscaling "utopia" that so many threads in Vogons had repeatedly called out to be impossible.

Yeah, makes sense.

And you have indeed solved that problem. That is the ideal case for 320x200, and the CRTT really shines at that resolution. And I do spend most of my time in DOS in text mode or 320x200. But if I want to run Windows, or other DOS programs that use different resolutions, it'll be "fine" but not perfect - however, still better than any other VGA to HDMI solution that has previously existed, to make that clear.

So here's an idea. Have you thought about pairing the FPGA with something like a Raspberry Pi Zero running bare metal code, similar to how the RGBtoHDMI adapter works, to handle manipulation and buffering of the image and the generation of the HDMI signal? That would allow higher resolutions and let you run the FPGA in "passthrough" mode all the time, freeing up resources, maybe you could use a cheaper FPGA that was as well? Maybe you've considered this already, but the RGBtoHDMI is not a particularly well known product, I've found.

RGBtoHDMI uses the same integer scaling in its default mode of operation that CRT Terminator uses. RGBtoHDMI does have an interpolated mode, but a Raspberry does not have enough performance either to run a bilinear upscale loop on the CPU, so it does the interpolation filtering by uploading the whole framebuffer to the GPU to upscale, before scanning out. It is great that the GPU works fast enough for that, though that definitely does add extra frames of input latency to round-trip full video frames via the GPU.

A Pi-based approach would be a different project altogether, for different people.

Okay, I've had an epiphany.

I looked through some of my old captures from RGBtoHDMI.

What I realized is that it gets away with using integer scaling because it *doesn't try to stretch the image to the full vertical height of the screen*.

I can't remember if it does this by default or if I configured it this way.

So when it's outputting 1920x1080...

320x200 becomes a 1280x1000 box centered on the screen
640x200 also fits into the same 1280x1000 box
(320x240 would fit into a 1280x960 box centered on the screen, if CGA/EGA had that mode)
(640x480... etc. etc.)

This leaves room for the overscan border as well!

The tradeoff is that you get a 1.28:1 aspect ratio for 320x200 and 640x200, instead of true 4:3 (1.33:1). It took me a while to realize that though, as they looked so similar I was fooled this whole time.

It it possible for the CRTT to do this? It sounds kind of like the "letterboxing" you were talking about earlier. Almost like it's a "Multimode, but on a fixed resolution canvas" type of thing.

Yeah, looks like that is the case.. taking a look at their screenshot gallery, they have the following examples:

In the Keen example, EGA 320x200 upscales to 1280x1000 pixels of content, fit inside a 1440x1080 bordered frame (they actually output a 1408x1080 box, not sure what's up with that), fit inside a 1920x1080 screen.

In the second text mode example, an EGA 640x350 text mode is shown, upscaled to 1280x1050, and then padded to 1920x1080. That looks quite ok.

In VGA, the situation is a bit different however. A VGA 320x200 Keen image will be 320x400 due to double-scan. That would integer upscale only to 1280x800, and not 1280x1000.

However CRT Terminator does have a scanhalver circuitry, which detects double-scanned video modes and strips these down to the halved size. Maybe that could be combined to to strip down every second scanline, to recover the 1280x1000 upscale. That might look something like this:

However, the VGA text mode is 720x400, which is not double-scanned in VGA. So that video mode could only be upscaled to 1440x800. This would look a bit disappointing, something like this:

or highlighting the border area a bit better:

so for VGA, the upscaling of 720x400 to 1440x800 is not as pleasing end result with integer upscaling, like EGA 640x350 text mode is.

I am not sure how well such an upscaling mode would fit. It might be doable, although I would need to find free space to fit one hardware 11-bit adder and two comparators into the high-speed pixel clock domain. Not sure yet how well that'd work out.

I'll try to find time to do some investigations in this area, though it might take some time. Before that, I'll work on getting a new firmware that will have the video mode change resync glitch with interlacing resolved.

Ah yes, I forgot about double scanning. Nice that it can detect those modes though.

If it helps, I personally would be fine with either a squished text mode like the screenshot you posted above, and/or some kind of hybrid mode whereby it uses full stretching on text, and letterboxing on graphics modes.

Maybe it could even be further optimized by letting the user choose the mode to use for each resolution.

Hey all, a new firmware DV1000-2025.3.16 is now ready for download!

Changelog: (I notice I didn't post a ChangeLog from the previous firmware fix, so here's both of them)

DV1000-2025.3.16
----------------
- Removed the ISA bus timing information from the Developer HUD, that was added in the previous firmware version to help troubleshoot reported palette upload problems. (5da3b7c6)
- Fixed an issue reported by Keenmaster486 where video mode sync would incorrectly be re-established when switching video modes with both MultiMode and StutterStop disabled. This was caused by video mode change being intermittently detected to be entering an interlaced mode. (f1439e09)
- Improved FPGA timing closure performance in the ISA bus clock domain. (a7474ead, 43e5e1dd)
- Improved FPGA timing closure performance in the HDMI clock domain. (e2b016f9, d506e200, fd12ab5b, 7f5476d2, db2c046e)

DV1000-2025.2.9
---------------
- Temporarily added ISA timing analysis information in the Developer HUD to enable troubleshooting a customer ISA bus read issue. (09a04426)
- Fixed a bug in ISA bus I/O read timing, where the read request might get ignored due to a badly timed interaction with the DMA_AEN signal. Fixes observed ISA read stability on MikroMikko 386 PC, and hopefully fixes the issues reported by Vogons user CircuitRewind. (14407a9e, 1c192411)
- Implemented a new self diagnostic circuitry to allow CRT Terminator DOS unit test software to detect if a ISA bus I/O conflict might occur. (d70c4b0e)
- Implemented new troubleshooting switch STATE_DISABLE_ISA_BUS_WRITES to force-disable CRT Terminator from performing any writes to the ISA bus, to enable troubleshooting ISA bus problems. (09307229)
- Implemented new troubleshooting switch STATE_DISABLE_8BPP_PALETTE_SUPPORT to force-disable CRT Terminator 8bpp palette RAMDAC subsystem, to enable troubleshooting ISA bus palette problems. (09307229)
- ISA I/O: Restored logic to specify JP_CONFIG[1] to select between 120h-12Fh and 160h-16Fh as the CRT Terminator ISA I/O address range. Note that this functionality may be temporary. CRT Terminator is recommended to be always used in the ISA I/O address space 120h-12Fh. (61adf861)
- Added sanity check to the ISA bus write logic to ensure that CRT Terminator will not write to the bus in unexpected scenarios when the ISA_RESET line is active. (dab008d5, 5dac28e3)
- Improved FPGA timing closure performance in the HDMI clock domain. (9a586945)
- Improved output refresh rate video timing synchronization to input video refresh rate (StutterStop Level 3 mode) by expanding the video refresh rate HBP field search window from 6 to 8 bits. (2a53a3c4)
- Implemented a mechanism for benchmarking video processing input-to-output latency, to be used in the future. (e5a01310)

Download latest firmware from the GitHub releases folder.

ChangeLog history of all firmware releases can be found in the manual.

Heya - I have gotten a couple of inquiries about what the horizon of CRT Terminator looks like, so it is a good time for a status update.

The current availability is exactly one unit in stock, though not to worry, we have a queued order for components and PCBs to be able to manufacture some more as needed. (CRT Terminators are baked in a 100% Finnish pizza oven) After having satisfied the initial production run queue, we are looking to sustain a "built-to-order" availability probably at least for this calendar year.

For the latest orders, we have not done any changes to the PCB revision, and there are no pending revisions/fixes that we would be looking at - that is how well things stand (having done four trial runs of pre-production really helped). There have been two changes we have had to make into the production board, which both have just been due to Mouser announcing end-of-life of a voltage shifter and a buffer component (iirc), so we had to adapt the positions of a couple of pads on the PCB to accommodate for two different components. But functionally no revisions have been necessary - all sold boards are behaviorally the same.

There have been some questions about if there is going to be a "DV2000". At the moment we don't see there being a new hardware model of the board, and we are not working on one. (we are still in the red for this current endeavour, though that is really on us due to our own applied R&D perfectionism 😅)

Originally I had been thinking of keeping the more "advanced" 15/16/24-bit video mode support, interlaced mode support and >800x600 resolution video mode support as extra features for such a DV2000, as a "maybe we'll get around to figuring those out later" kind of a thing. But given that we had an unanticipated 6 months pause in 2023 until getting to that first production run (caused by yours truly accidentally ordering the wrong FPGAs), I had plenty of time to complete investigating how those SVGA video modes worked. And we found it was possible to optimize the implementation enough, so that there was really no technical limitation why those couldn't be included on the DV1000. It felt silly to artificially "hold back" just for the sake of being able to later differentiate such a DV2000, so we gave the DV1000 everything we got.

There were some features that I prototyped, but had to drop from DV1000 due to the FPGA floorplan not having enough space. We currently use about 95% of all the FPGA resources. At this level of utilization (and our ridiculously high pushed clock timing requirements), it takes about 350 compute hours of combinatorial optimization search to route a passing placement layout for a new firmware version. I leave an Intel 14900KS running 100% hot all cores overnight to compute every new firmware update, hoping to wake up to a Christmas the next morning. Every time I do this, I get the feeling if we are Icarus flying too close to the sun. Though so far, the combinatorial optimizer we've developed has not failed us.

There were features that had to be dropped though, because they just wouldn't fit on the board. Here are two such examples of features that didn't make it:

Burger Time with regular CGA:

Burger Time with CGA+Composite colors emulated by CRT Terminator prototype (didn't make it):

EGA Castlevania no scanlines:

EGA Castlevania with scanlines emulated by CRT Terminator prototype (didn't make it):

The scanlines implementation was very rudimentary, it just applied a weighting multiplier mask matrix to every pixel, i.e. no fancy color bleeding or other advanced filtering. I do say that the photo actually just cheats.. it makes the scanlines look way way better that it really was. The camera gives a forgiving blur there - in reality it looked quite harsh.

Maybe these might be things that a DV2000 could include, if we ever got to it. Although likely not enough to call it a DV2000. Then there are also the whole value analysis and cost vs demand analysis to be made to warrant the whole thing.

So DV1000 is where it is at. We are currently focused on finding places to reduce resource utilization to help maneuverability in floorplan optimization, with the end goal of being able to have room to prototype the feasibility of integer or area scaling as per the conversation with Keenmaster486 earlier. It is going to be a journey though. There are also a couple of other smaller features, and one exciting secret feature that I have been prototyping, but it is currently too early to say if it will be just a silly idea, or something actually worthwhile, so I'll leave blabbering about that for a later date, if that ever realizes 😀

If there is a next product, we have been pondering that maybe it might be an external CGA/EGA video converter box, or that maybe we might do a variant for Amiga (my Amiga owning cousin has been bugging me about this for years now).. though given that RGBtoHDMI exists for both, it is unclear if there is any practical added value we could offer there, besides than satisfying the "it won't be a Pi" checkbox (for those that might feel that to be a thing). Nevertheless, these have been rather far ideas at this point.

Overall the focus for CRT Terminator is in maintenance and support. This is a great thing, since it means that the project has matured well. The bug reports that you have provided have been super valuable and satisfying to squash, and fortunately we have been able to stay on top of them. There will be occassional firmware updates to come likely at least throughout 2025.

I maintain a "conformance test suite" of adapters at https://oummg.com/manual/adapters.html, and there's still a small pile of SVGA adapters in my lab that have not yet been put through the full testing. I am hoping to expand the test suite with a "conformance analysis" on different displays and PC video capture devices as well. The test suite is also something that I hope to polish up and publish on GitHub at some point.

Hopefully that gives an idea for the direction of the project!

Sounds great. I'd be interested in the CGA/EGA converter.

I have finally managed to update to the latest firmware. The card is now very reliable and compatible. Some screenmodes such as music trackers now also run on my monitor. 😉

I use the DIP setting 0011 (1440 x 1080). This gives me nice sharp pixels. The other modes sometimes have significantly blurred pixels. My use case is 95% 320x200px for DOS games and demos. I have a nice picture on my 3:2 monitor.

Is it possible to change the DIP switches during operation? Or will this destroy the card?

Sometimes the monitor ‘shakes’ horizontally. Then the values at H: -> FPO: and BPO: change, especially with Monkey Island in the code query. I generally have the impression that this only happens when there is very little content on the screen.

The image is also slightly shifted to the left under DOS. I haven't noticed this at 320x200 yet.

Nelson68k wrote on 2025-03-24, 18:31:

I have finally managed to update to the latest firmware. The card is now very reliable and compatible. Some screenmodes such as music trackers now also run on my monitor. 😉

Fantastic to hear 😀

Nelson68k wrote on 2025-03-24, 18:31:

I use the DIP setting 0011 (1440 x 1080). This gives me nice sharp pixels. The other modes sometimes have significantly blurred pixels. My use case is 95% 320x200px for DOS games and demos. I have a nice picture on my 3:2 monitor.

Great - I see that StutterStop level 3 is also working well, locking the input and output refresh rates. You might be interested in running some test cases in 70HZ.EXE, or crowdsourcing info on "how does your LCD display treat 70Hz video modes?" to check out how the display handles this 70hz output.

Nelson68k wrote on 2025-03-24, 18:31:

Is it possible to change the DIP switches during operation? Or will this destroy the card?

It is perfectly safe to flip any and all the switches and jumpers during operation, and the change will take immediate effect. Just make sure that the card is firmly screwed in to the chassis, so it won't accidentally be able to unseat from the ISA slot while being prodded.

Nelson68k wrote on 2025-03-24, 18:31:

Sometimes the monitor ‘shakes’ horizontally. Then the values at H: -> FPO: and BPO: change, especially with Monkey Island in the […]
Show full quote

Sometimes the monitor ‘shakes’ horizontally. Then the values at H: -> FPO: and BPO: change, especially with Monkey Island in the code query. I generally have the impression that this only happens when there is very little content on the screen.

The attachment IMG_9657.jpg is no longer available

The image is also slightly shifted to the left under DOS. I haven't noticed this at 320x200 yet.

The attachment IMG_9659.jpg is no longer available

When this happens, take a close look at the row of four +/- characters in the Developer HUD. These correspond to the Hsync, Vsync, Display Enable and Pixel Data sampling phase detection (rising/falling).

If you see any of them flipping between +/-, then this issue is caused by the card's automatic sampling phase (rising/falling) detection misbehaving, i.e. the video signal coming to the card is unable to automatically decide if the particular signal line should be sampled on the rising or falling edge of the pixel clock.

In such case, you can try disabling the automatic sampling phase detection (set J2 to state 2-3: https://oummg.com/manual/#jumper_settings), and then change the state of the J3-J6 jumpers to find the most stable configuration. For most cards in my lab, the expected setting is to use rising edge for all signals (++++ in Developer HUD, i.e. each of J3-J6 set to 1-2), though different cards have different conventions.

The horizontally shifted image will be a result of mismatched Hsync, Display Enable or the Data line. In most cases, Display Enable and Data lines should have the same sampling phase setting.

Clb, did you ever consider producing a version of the CRTT that is essentially an external converter box that connects to an inexpensive breakout card? That way people could purchase one CRTT and multiple breakout cards for different machines.

This has not been something that we've given much attention to. I'm not quite sure how feasible that will be in general, because CRT Terminator needs to communicate on the ISA bus to snoop the VGA palette, so such a breakout setup would have to have parallel cables from both the ISA bus, and also the Feature Connector outside the PC chassis.

In January this year I did a test of how different Feature Connector cable lengths affect the signal integrity, and the realization was that there are cable length limits: https://oummg.com/manual/cable_length_test.html . With longer cables there will be tradeoffs to max resolution, and analog VGA output signal quality. So it could get a bit tricky to develop such a setup, without walking a fine line of limitations.

How about zero external cables, a box that connects directly to a connector on a breakout card?

I’m not sure how common my particular use case is (KVM switch to one retro PC at a time from my main modern PC). So maybe I’m the only one who would be interested in this form factor because I’m too lazy to open up the computer and swap out the CRTT lol.

In other news, yesterday I tried to install the CRTT in my 286 with a WD90C00-JK VGA card. It turned out to be impossible because this card does not have a notch in the “feature connector”… which makes me wonder whether this is even a VGA standard feature connector, or something else.

Here you can see the WD card’s feature connector alongside that of my Tseng ET3000AX, along with some full front and back pictures of the card.

I ended up using the Tseng card instead, which presented a different problem: the image was shifted up one scanline and to the left one pixel. I was able to fix the left shift by switching to manual phase detection, but no jumper combination would fix the vertical shift with a single overscan scanline visible on the bottom.

Also, I somehow forgot to mention earlier that I was able to update to the latest firmware version using the methods previous posted here for Linux, and it had the following effects:

1. Fixed the signal dropouts on mode change with fixed resolution, no Multimode, no Stutterstop... *most of the time*. Sometimes it still happens. It seems kind of inconsistent. I can try to get some footage of it happening at some point. But for the most part it's a nice experience now.
2. Made the sync issues in VGA games a little better. I'm still getting some issues with certain games... the Jazz Jackrabbit menu screen in particular seems to be difficult to sync to. Probably has something to do with that weird plasma effect in the background.

There's another issue I forgot to mention. I need to capture it so you can see it, but maybe you've observed the same thing... In certain VGA games, most noticeably Doom, I'm seeing the bottom edge of certain pixels turning pink. Like this random pink noise that spreads itself throughout the image.

keenmaster486 wrote on 2025-03-26, 15:30:

How about zero external cables, a box that connects directly to a connector on a breakout card?

Hmm, a box that would clip directly at the end of the PC? That does sound quite novel.. would have to be something that is designed to clear other connectors on neighboring ISA slots.

keenmaster486 wrote on 2025-03-26, 15:30:

In other news, yesterday I tried to install the CRTT in my 286 with a WD90C00-JK VGA card. It turned out to be impossible because this card does not have a notch in the “feature connector”… which makes me wonder whether this is even a VGA standard feature connector, or something else.

Well that's definitely something new I haven't seen before. Notice that the backside of the card has two separate groups of three and four lines that are connected together.. that is a good signal that the connector would definitely be a Feature Connector. These correspond to pins 1,3,5 and pins 15,17,19,21 in the pinout in our manual: https://oummg.com/manual/#appendix_b_vesa_sta … rough_connector

It is good to double check though with a multimeter in continuity mode to find the grounds, and to be extra certain, if your multimeter has a frequency (hz) mode, to double check the frequency of PIXCLK, DISPEN, HSYNC and VSYNC lines.

WD90C00-JK is the oldest VGA card from Paradise, so maybe they just goofed up in their first card's implementation.

The key (i.e. the blocking pin) on the IBM Feature Connector cable we provide is a plastic insert that is glued in between pins 2-3 inside the female connector end. So if you are careful, it should be possible to pull it out, and then the connector should fit that card. Of course, be extra careful when doing this to verify with a multimeter that the connector checks out.

keenmaster486 wrote on 2025-03-26, 15:30:

I ended up using the Tseng card instead, which presented a different problem: the image was shifted up one scanline and to the left one pixel. I was able to fix the left shift by switching to manual phase detection, but no jumper combination would fix the vertical shift with a single overscan scanline visible on the bottom.

The horizontal shift sounds like typical sampling phase problem: Tseng cards are of that rare breed to need to be sampled at falling edge of the signals, rather than on the rising edge as most cards. A 1px vertical shift suggests that the card might have a bit nonstandard porch timings. A suitable TSR would be able to fix that, but might be a bit of work to develop.

keenmaster486 wrote on 2025-03-26, 15:30:

Also, I somehow forgot to mention earlier that I was able to update to the latest firmware version using the methods previous posted here for Linux, and it had the following effects:

1. Fixed the signal dropouts on mode change with fixed resolution, no Multimode, no Stutterstop... *most of the time*. Sometimes it still happens. It seems kind of inconsistent. I can try to get some footage of it happening at some point. But for the most part it's a nice experience now.

This is nice to hear. If you find example setups about the sync loss, I can try to repro if I can get similar conditions to happen.

keenmaster486 wrote on 2025-03-26, 15:30:

2. Made the sync issues in VGA games a little better. I'm still getting some issues with certain games... the Jazz Jackrabbit menu screen in particular seems to be difficult to sync to. Probably has something to do with that weird plasma effect in the background.

Jazz menu screen is part of my test routine, so it is regularly exercised. Try to see if there might be any differences between different DIP/jumper settings on this sync problem (e.g. resolution or config modes). Jazz menu screen is still a regular Mode 13h 320x200, so I would expect it to be quite stable.

keenmaster486 wrote on 2025-03-26, 15:30:

There's another issue I forgot to mention. I need to capture it so you can see it, but maybe you've observed the same thing... In certain VGA games, most noticeably Doom, I'm seeing the bottom edge of certain pixels turning pink. Like this random pink noise that spreads itself throughout the image.

This does not sound familiar. It would be interesting to see on video how this effect looks like. Also interested in hearing whether this issue occurs in all resolution/config modes, or just some.

Random noise, i.e. hot or flickering pixels, most commonly is due to the pixel data sampling phase not being correct, so what can happen is that the pixel data bus is sampled in the middle of the signal changing, resulting in individual pixels flickering temporally. Although such an artifact typically manifests in the whole DOS pixel changing color, but here you are mentioning only a part of the DOS pixel changing color, and not the whole pixel.. that suggests a problem in the output HDMI clock domain instead. If that is the case, here it would be interesting to try out if all the firmware versions have the same issue, or if it appeared only after firmware update.

I removed the plastic divider on the CRTT feature connector cable, and confirmed that the WD card's connector is indeed a VGA feature connector, and works fine with the CRTT.

I will get back to you on the pink noise after I put the card back in my 486 so I can get some captures.

Great work!