ramapcsx2
commented
7 months ago Hey ho, I don't think the chip has the exact right capabilities to clamp / extend the analog input to the required custom ranges. That's asking a lot, and at best some random (mis)configuration of the various units might even do something as intended.. Not a good outlook there.
But instead, I would look more into modifying your first stage board. To start with, give it different power options, definitely try not using the same supply as the GBS, as that power is now "contaminated" with video related noise. Next, your output RGB seems to be high voltage DC, right? It might be better to have an AC coupled output (ideally 0.7Vpp standard, too), as the GBS board and ASIC seem to be optimized for that (especially the board layout). Small tweaks like that might be able to reduce or even just shift the noise levels to be out of band of the intended levels.
[This is GBS-C cloned just this afternoon, compiled via the version of Arduino IDE available through Debian's repository ("Bookworm"). The GBS8200 board is a version 4, it and the companion ESP8266 are brand new as of a day ago, and I have replaced the pots with wire links as directed]
First a big thanks! GBS-C really improved the display from my Commodore 128 compared to the stock 8200 firmware. It's almost stupidly-crisp now 🙂, better than the 1902 I used to have (and that was considered THE definitive monitor to use with this machine). Finally there's no more of that ugly nearest-neighbor-looking scaling the 8200 had going on before.
I have a feature request for GBS-C, as it pertains to the input/sampling side (this would apply to many vintage machines actually, not limited to the C128).
Like a lot of folks doing the retro-computer-to-VGA thing, the video source is 15kHz, 240p/60 Hz digital RGBI, which is connected through an RGBIHV-to-analog adapter to the 8200. The C128's video is very similar to IBM CGA, so much so that one could often directly use a once-common CGA monitor if desired. Don't have any of those though, so I've got it all connected to a common Dell LCD screen instead. 🙂
The thing is, the sort of digital-to-analog-to-digital-to-analog conversion that's necessary to make this kind of video suitable to drive a VGA monitor is sensitive to color distortions and noise, particularly in that first digital-to-analog stage.
That being the case, would it be possible to add a sort of "low color resolution" mode to GBS-C that takes advantage of the limited-depth, digital nature of the video?
Rationale/use case:
I lived in another locale when I first had this sort of C128-to-8200-to-LCD setup, and it worked fine back then, but something about my setup or my environment since moving here is introducing some ghosting on full-bright-to-less-bright transitions on the input side of the chain (the output side is clean). There's also a subtle haze of analog noise that's mainly only visible if you set the whole screen to white, but this may just be a normal quirk of the computer's design.
I thought the ghosting problem was either a firmware bug in the v4 board, because of how oddly-precise it seems. That or a hardware fault in my existing board. The one I had when it was all working properly was a v3, and I figured a downgrade wouldn't be such a great idea, so I got another v4 with the intent of installing GBS-C should the problem persist. Unfortunately, while GBS-C was a big improvement, it didn't solve the problem. Oh well, blaming the firmware was a long shot, and I suppose now I have a spare 8200 if I should need it.
Here you can see the offending ghosting most easily in the dark purple, brown, and light gray bars (the right half is the correct shade). Some bars being a bit dim in the middle is just a camera artifact, you can ignore that.
I have tried literally everything I could think of[1] and nothing so far has had any effect. Since I can't find the underlying problem, let alone fix it (and indeed it may not BE fixable - I suspect bad mains), I had hoped GBS-C could work around this noise-prone environment.
I figured if it could quantize the analog signals to the low color depth they actually start out as -- essentially have the firmware "downgrade" the color depth by rounding the analog values to their nearest CGA colors -- it would eliminate both the ghosting and the overall "haze" I mentioned, regardless of the underlying cause. It would most likely also eliminate those regular vertical stripes that you can see in the image (especially in green and light red), which are due to a quirk in the machine's design.
I thought maybe the "peaking" or "step response" settings would do this, but alas no.
Once RGBI is turned into an analog signal, whatever is sampling it would simply see the resulting (scaled) fluctuations from noise as variations in color. So when RGBI is converted and fed to an analog input, that input needs to be able to convert it back to its low-depth form rather than assuming it started as analog.
I suppose such a feature would need range settings or thresholds to clearly mark what's considered entirely-off, vs. low-intensity, vs. high-intensity.
The RGBI board is one of my own design, by the way -- the very one that's sold by Shareware Plus and by Protovision. This board is known to work flawlessly -- I made certain of that. In case there's a concern that it has gone bad, nope, I recently replaced it in hopes of addressing this issue[1]. Here's the schematic for it, so you can see how stupidly-direct the signal conversion is: [2]
(note: I removed the regulator; it's getting 5v directly, from the same supply as the 8200 and ESP boards).
[1] I have an "Display of Theseus"/"Abe Lincoln's video chain" situation going on here -- the ghosting is nearly identical across three computers, two RGBI boards (both commercial-grade, they're not prototypes), two 8200's, two VGA cables, three RGBI cables, two monitors, two or three ways of plugging everything into mains... Literally everything swapped but the house mains power. It's been like this since I moved to this home, and the issue just screams "bad grounding", but I'll be damned if I can find the cause (though the electrical system here is mediocre).
[2] Yes, I know the 24kΩ and 51kΩ resistors in my circuit seem wrong, but I used a circuit sim to arrive at those values, and they worked perfectly on at least a few screens and setups, so that's what I went with, and as far as I know, the retail product uses those values also.
Loosely-related: #111