Atari 8 bit

[c0pperdragon]

Atari 8 bit

[c0pperdragon]

The Altirra emulator has a very sophisticated way to set up the palette by parameters:

But I have no idea, what this all means...

[IanSB]

If you want to try creating your own palette file for RGBtoHDMI the format is as follows:
The file is a 1K binary and is 256 32 bit values with bit order as follows:
0xMMBBGGRR
RR GG BB are the rgb values from 0x00 to 0xff
MM is the value used in mono mode from 0x00 to 0xff

For the Atari only, the order of the words in the 1K file is slightly re-arranged due to a problem with the menu system which normally uses the top bit of the palette:

Normally Atari palette is indexed like this:
C3,C2,C1,C0,Y3,Y2,Y1,Y0
but the palette file words are indexed so that the lsb of luma is in the msb:
Y0,C3,C2,C1,C0,Y3,Y2,Y1

Y0 is forced to 0 when the menu is on screen but as it is 0 in most cases already doing it this way means the least disruption to the screen when the menu is enabled.

The above means that:
word 0 is chroma = 0, luma = 0
word 1 is chroma = 0 , luma = 2
..
word 128 is chroma = 0 luma = 1
word 129 is chroma = 0 luma = 3
etc.

Put any file you create in the palettes folder and select it from the palette menu after rebooting the Pi.

[IanSB]

Here is an updated test version:
AtariTestV0.02.zip
This has the 6 bits per pixel modes also running at 14Mhz so it can work in YUV mode as well which makes it easier to switch between C64 and Atari.

In RGB mode there are 4 profiles to test:
Atari 800XL 1 - uses 3bpp mode with double width frame buffer (equivalent to the old 14Mhz test profile)
Atari 800XL 2 - uses 3bpp mode with normal width frame buffer
Atari 800XL 3 - uses 6bpp mode with double width frame buffer
Atari 800XL 4 - uses 6bpp mode with normal width frame buffer

In YUV mode there are two profiles:
Atari 800XL 3 - uses 6bpp mode with double width frame buffer
Atari 800XL 4 - uses 6bpp mode with normal width frame buffer

All six should work identically but exercise all possible combinations of capture loops so can you check them all.
You might have to adjust the delay value in the 6bpp modes

[c0pperdragon]

I have tried all these possibilities and after tweaking the delay and setting the palette, all these look identical and perfect. Here are all my saved profiles for this:

Saved_Profiles.zip

[c0pperdragon]

I also extracted the default PAL and NTSC palettes from Altirra (easy with export function) and converted them to RGBtoHDMI format. You can get everything at: https://github.com/c0pperdragon/A-VideoBoard/tree/master/atarimod/palette

[c0pperdragon]

Just in case you have not yet found the bill of materials for the GTIA adapter board: https://github.com/c0pperdragon/A-VideoBoard/tree/master/atarimod/doc

[IanSB]

I've ordered the parts for the Atari and Amiga boards which hopefully should be here tomorrow

Here is a finalised version of Atari support to test:
AtariTestv0.03.zip

This generates palettes based on your Altirra ones and there is now only one profile which is in YUV mode (You can copy it to the RGB folder if needed)

Can you confirm that it is OK and I'll commit the changes.
Maybe post some screencaps?

[c0pperdragon]

This version seems to have the same palette as the Altirra, which looks pretty good and very similar to what my CRT displayes.
I have made a few captures of various games and demos. I is quite astounding how small these .PNG files are...

Bad thing is, I have found another issue with the GTIA emulation. This time it appears at the weird graphics mode, the "Reharden" demo uses...

[IanSB]

Looks good, but the image isn't centred as I had to just guess the H and V offsets so can you try centreing and post your saved profile. (Go into the geometry menu and adjust the H and V offset values using that text page above as the source)

I is quite astounding how small these .PNG files are...

There is zero noise in the images so they compress very well.

(BTW did you see my post in the Amiga thread about using an SD card extender to get screencaps without having to disassemble the machine - I will make short button presses with no menu do a screencap in simple mode so that would be useful)

[c0pperdragon]

I just set H Offset = 68 and V Offfset = 60. This looks pretty centered now..

[c0pperdragon]

About the SD extender: Yes, this would be an optional extra, like the single button. I will stay with my simple solution and not have screencaps.

I have found and fix the bug that messed up the "Reharden" demo. So I did the screenshots again and they look correct this time. The difference is not so easy to spot, but people who know would see it. Additionally they are properly centered now.

An because I already have the SDcard out, here is my saved profile:
Atari_800_(625).txt

[IanSB]

I've built up my board but it's not working properly so far:
After inserting the extender board, the analog output still works so I don't think any GTIA signals are getting messed up and each buffered output from the board has a valid looking signal on it but when I connect it to the A-board I had from you I get a picture with messed up sync:

The above is currently using the normal 288p output as I was also testing with a retrotink, it's not configured for the special Atari output yet.

Any ideas what the problem is?

EDIT: Using the latest atarimod_1_2.pof

[c0pperdragon]

This looks really pretty bad.

First thing to check is the clock signal - this must surely be somehow strange. Otherwise you would at least have output lines that match up. Particularly check if the edges are well defined with not too much ringing. This could be a specific problem when the wires are too long. Normally my ribbon cable is just long enough to get from the adapter board to the FPGA board.
To improve the clock signal you could try to use a different resistor value for R10. Those 100 Ohm are really only a ball-park figure. Maybe you can tweak this a bit...
The frequency needs also to be correct, and stable of course.

Second thing is the voltage 3.3V rail on the the adapter board. I have not used this particular voltage regulator before (I took a replacement you could get from digikey). If this is now missbehaving in conjunction with the 1uF capacitor this could also cause any bad behaviour.

[c0pperdragon]

Oh, just to make sure: The FPGA board needs to be connected to the same GND as the adapter. There is no GND connection via the connector cable.

[IanSB]

I used the same 3.3v regulator that I used on the analog board as there was no stock of the specified part.

I also did the following tests:
I programmed the C64 fpga code into the A-Board and that worked OK with the C64 so the A-Board is OK
I programmed the Atari fpga code into the C64 board and got the same glitchy display so the issue is definitely with the new buffer board.

There is a huge amount of ringing on all signals and I notice that this design uses LVC parts compared to HC parts on the original board so that might be the problem as LVC is much faster and those fast edges are going to produce a lot more ringing.

Any suggestions for values to try for R10?

It looks like it is generating hsyncs but vsyncs are missing or random so does that point to any particular signals to check?

I configured it properly for RGBtoHDMI mode and it is at least producing the right colours:

If I can't find any obvious faults I think I will build another board with HC parts to see if that improves things.

EDIT: tried a very short 5cm cable and got the same results so it's either a build problem with the board or the lvc parts

[c0pperdragon]

Yes, the main difference between my own build and yours are indeed the LVC parts. I changed this to get proper level conversion without pulling down the inputs and/or raising the supply voltage through the input clamping diodes. As this worked so nicely on the C64 I thought this should be the right choice here also.

Before changing everything to HC, please try first to get the clock signal right, because this must be the main issue.
There a two points to tweak: A different resistor (use a 440 Ohm to see if it changes the signal at the end of the cable). Maybe send me an oscilloscope capture of the 100 ohm and the 440 ohm results. Second possibility is a small capacitor from the resistor (right before the signals reaches the cable) to ground.

But maybe the atari clock itself is the problem. On my machine it has a very regular edge on one side but the other edge is very jittery - so I just use the "good" one. Could be different on your machine. I really need an oscilloscope capture here.

[c0pperdragon]

If you are already using the oscilloscope please do check the 3.3V rail. I actually cheaped out on the capacitors and used 1uF instead of 10uF as I did for the C64 board. Maybe this worsens the matter.

[c0pperdragon]

Part of the ringing could be created by not tighly tying the GND lines together. If you for example ground your oscilloscope probe to some distant point this shows much more ringing than would actually be there. In any case the ringing of the data signals should not cause the trouble. The clock (pin 19 on the cable) is the relevant factor here

[c0pperdragon]

Of course, I meant 470 Ohm the previous comment, not 440.

[IanSB]

I changed the resistor to 470R and also changed C1 and C2 to 10uF and I now have a locked picture but there are still glitching pixels.

Any other suggestions?

[c0pperdragon]

I still would like to see the clock signal as it is generated by the atari (GTIA pin 29), and how it looks when arriving at the FPGA board while everything is plugged together (an open cable could distort the measurement). This would be GPIO1 pin 19, or FPGA pin 105.
It would be best to send me an oscilloscope capture of both signals in one view.
Maybe I can spot something suspicious.

[c0pperdragon]

Another thing would be to look at the video output using the retrotink X2. To see if the mod board gets wrong data and produces the glitches, or if only the pixels are so unregular that the RGBtoHDMI can not decode them properly (this would be similar to what caused the sparkly pixels with the C64 and the old clock generator circuit).

[IanSB]

Here's the clock:

[c0pperdragon]

Which clock is this? The original ATARI (GTIA pin 29), or what comes to the mod board. In any case I would need the second to directly compare signal and phase.

This one actually looks pretty noisy.

[IanSB]

That is pin 19 on the A-board header

Here are both signals:

Yellow is pin 29 of GTIA, cyan is pin 19 on A-board.

I tried with a retrotink and I am still seeing glitches on characters like the above screencap.

I also tried using the short 5cm cable and the picture was a lot worse.

[c0pperdragon]

This signal is really terrible. The GTIO clock is so much cleaner. I don't know what causes this. It is no ringing but some kind of high-frequency noise.
Because of the resistor there is a very visible RC curve which may or may not cause some extra problems.

The fact that shorter cables make the issue even worse suggests that the noise is not picked up by the cable or is a result of signal reflection or something like that.
It really seems that either the level shifters do some very bad thing or the voltage regulator creates this noise. In fact there are some voltage regulators that need some very specific filter caps to work properly.
Please do check the 3.3V rail.
If this is indeed looks reasonable your only option may indeed be to go for the HC parts.

The Atari signals are nominally 5V, which would cause a whole load of troubles for HC being powered at 3.3V. But in fact the voltages are much lower and probably below the input clamping threashold. If you can verify that all the relevant GTIA pins are indeed newer exceeding 4V, the HC logic parts can very well be used for level shifting to 3.3V.
Maybe I should have designed your adapter board in this way from the very beginning. I just wanted to make sure not to break anything.

[c0pperdragon]

Somehow I still can not believe that a properly working LVC part could produce such noise when it is not actually switching.
To try a very wild guess, maybe some input pins do not make contact and are now floating wildly and oscillate in some feedback loop. This could very well induce all this noise.

Or the part is just faulty.

[IanSB]

It really seems that either the level shifters do some very bad thing or the voltage regulator creates this noise. In fact there are some voltage regulators that need some very specific filter caps to work properly.

The regulator is MCP1754S-3302 which has a minimum of 1uF load capacitor and max of 1000 μF so 10uF should be OK

This is the 3.3v regulator output which is showing 250-300mV of noise:
(measured across the output capacitor so a good ground).

To try a very wild guess, maybe some input pins do not make contact and are now floating wildly and oscillate in some feedback loop.

If the LVC inputs were floating the video output wouldn't work at all would it?
(I checked the unused inputs were grounded)

The Atari signals are nominally 5V, which would cause a whole load of troubles for HC being powered at 3.3V.

What regulator did you use on your HC based prototype?

[c0pperdragon]

Because I could not remember what part I used, I just took a look and was quite surprised to find this brutal hack I did years ago:

I can dimmly remember that I somehow shortend and burned the last of the regulators that would fit the board, so I took another one I found in my spares box and somehow made it "fit". Works a treat, actually :-)

Bad thing is, I have not the slightest idea, what this is.

[c0pperdragon]

But it could very well be the same part as I now use in the C64 adapter board. It seems to be the same package at least.
https://www.mouser.at/ProductDetail/Microchip-Technology-Micrel/MIC5504-33YM5-TR?qs=U6T8BxXiZAUmVQ5Zs217qQ==
And it never gave me any trouble.

[c0pperdragon]

Reading the datasheet of this part, I really guess it is it, because it just fits in this diagonal way.
This will teach me to not give out designs that were only based on guesswork. Especially power supplies and regulators are always ready to surprise you.

[c0pperdragon]

Still the hypothesis of an open input contact is not 100% impossible. There are some inputs that are not used and are only tied to ground normally.

[IanSB]

There are some inputs that are not used and are only tied to ground normally

I already checked the grounded inputs were connected to 0v and the other pins on the 20 way connector have what looks like valid signals so I guess that regulator might be the problem with those LVC parts.

Reading the datasheet of this part, I really guess it is it, because it just fits in this diagonal way.

I'm not so sure as it looks like pins 2 & 3 are connected together (enable & ground) on your photo but the enable is active high according to the data sheet

[c0pperdragon]

It is impossible to see on the photo, but the enable pin is completely broken off and the GND is bent over to reach the pad. A truly ugly hack.
..

[c0pperdragon]

Just for comparision, I probed the signals from the C64 board. This also uses LVC components and the MIC5504 regulator.
There everything looks pretty OK. At least on my scope. Maybe it is filtering out the highest frequencies and I can not see them...

Normal data pin with some ringing, but nothing to worry about:

Both edges of the clock pin with the 100 Ohm resistor completely removing the ringing (second picture is without single shot):

[IanSB]

I'm going to order an MIC5504-3.3YM5-TR to try in the board first and if that doesn't help I'll build a second board with HC parts.

[IanSB]

I tried the above regulator and it didn't make a great deal of difference. I also tried a second board with HC parts and that had the same problems. Finally I put a 1K trimmer in place of the 100R resistor and managed to get a reasonably clean image at about 680R but not totally stable.
Any ideas what to try next?

[c0pperdragon]

First thing is to probe the clock signal now with the new regulator. I am specifically interested how the signal looks with LVC parts and only a 100 Ohm resistance.

With 680 Ohm, this is probably a bit slugish. The fact that it works a bit better, probably means that the other signals are in a different phase relation than on my machine.

Still I really want to see a screenshot when running with LVC, 100 Ohm. The picture should not have jittering edges, even if the pixel content fluctuates. Then at least the clock would be running OK.
To fix the pixel content I would have to modify the firmware to use different sample points for the data.
Another test would be to check sprites. Just use some game for that.
A third test woud be to see if register writes to the GTIA work reliably. This can be tested by running the COLORBAR.BAS program from https://github.com/c0pperdragon/A-VideoBoard/tree/master/atarimod/doc. This shows all 256 colors by permanently re-writing one of the color registers.

[IanSB]

OK Here are some waveforms with the new regulator and 100R series resistor (Yellow is GTIA clock, Cyan is buffered clock at the FPGA board.

1. Repeated capture at full bandwidth
   
2. Single shot capture at full bandwidth
   
3. Repeated capture at 20Mhz limited bandwidth
   
4. Single shot capture at 20Mhz limited bandwidth
   

The waveform is quite asymmetric is that expected?

The chips on my board are dated from around the middle of 1984
The GTIA has the following numbers:
AMI 8443GZ
C014889-01
C04085

Still I really want to see a screenshot when running with LVC, 100 Ohm. The picture should not have jittering edges, even if the pixel content fluctuates. Then at least the clock would be running OK.

The picture is jittering sideways by a couple of pixels and when cold it can't even get a vertical lock (see earlier captures)

It's difficult to do any further software tests at the moment as I'm just running the bare board on my bench with no keyboard.

I do have an SD card disk interface so can you point me to some disk images to try when things are a little more stable.

[c0pperdragon]

OK, so the clock looks reasonably stable now to create a rectangular background. Jittering of the pixels (and garbage pixels) inside this background is very probably be caused by bad sampling point for the data inputs in relation to the clock. This will also cause the vsync to fail, because this is normally triggered by a specific data pattern comming at the data inputs to the GTIA.
I will try to adjust the data sampling to be a bit later to correctyl catch it.

[c0pperdragon]

I have shifted the sample point for the incomming bitmap data about 70ns back. So the signals from the ANTIC should be stable at this point. I am not sure if this may cause other problems with the sprite DMA which may have become off by one clock instead. But one thing at a time.

This experimental firmware is on: https://github.com/c0pperdragon/A-VideoBoard/tree/master/atarimod/firmware

If the BASIC start screen looks good, you may try some more challenging stuff. My favourite thing for testing is the well known "Joyride" demo, which you can conveniently find at my other repo: https://github.com/c0pperdragon/SIO2SD/tree/master/ATARI
Part 1 of the demo runs quite far (up to the plot tunnel) without needing keyboard interaction.
For comparision see the video https://www.youtube.com/watch?v=p69z3zytU6I

[IanSB]

I have shifted the sample point for the incomming bitmap data about 70ns back

That gives a stable locked picture at cold startup but after about 30 seconds warm up it starts to lose sync which is the opposite of what was happening with the previous version.
The rise time on the GTIA clock is really slow, is that the same on your Atari and are you using that edge for timing or the other one?

Cold startup:

After ~30 secs

EDIT:

That firmware is stable with the 74HC14 build of the board (so far)

[IanSB]

As mentioned above, the LVC version is not stable enough to do any tests but the HC one is so I tried a few demos including the joyride one and they all have messed up graphics. Here is an example:

[c0pperdragon]

From all this screenshots, I deduce that at least the clock is in fact running stable now.
By the way, I use the falling edge of the original clock to synchronize the rest of the logic to. As everything goes through inverters (I need them to have schmitt-trigger inputs), this of course means rising edge of the signals that come to the FPGA.

I guess, the messed up graphics is really due to miss-aligned sprite DMA, which is now happening because I shifted the sample point right to the other side of the signal changing point.

Anyway I will try to change the sample point 70ns to the other direction. Maybe this gives stable bitmap data then on both the HC and the LVC versions. If this is finally working, we can look to the get the sprites ok as well...

[c0pperdragon]

Just uploaded a new version.

[IanSB]

That seems to be a lot better, it works with both LVC and HC boards and the above demo is not messed up:

I'm back running the LVC board
I tried running the Reharden demo and compared with youtube and noticed that there are a couple of columns of wrong pixels on the right hand edge:

[c0pperdragon]

This column of garbage at the right is actually also present on the composite video signal. All the captures on youtube just crop away this noise. I don't know what overscan area should generally be considered "important" to show - this may well depend on the actual grame/demo.

[c0pperdragon]

I guess I should reduce the overscan area in the component video signal. I need to find a compromise between showing as much as possible, but leaving away such artefacts. I did the same for the C64 mod and nobody complained about missing overscan area.

[c0pperdragon]

After checking the docs, I see that the Atari can actually produce a 48 column display (384 pixels) without any tricks. So this area at least I will not crop away. If this is not enough for the Reharden Artefact to become invisible, I can not help it.

[c0pperdragon]

Hmm - maybe 360 pixels are in fact enough - this would match up with the DVD resolution (720 width) and is what we are doing now for the Amiga and it looks just right there.

[c0pperdragon]

After doing some calculations, it turns out 360 pixels would take about 50.8us on a PAL machine, which is very close to what I am showing on the C64 (400 pixels). This value is also pretty close to the PAL video timings itself which would specify 52us of visible screen area.
The current firmware only shows 344 pixels - probably some earlier tweak. I will extend this to 360, but need to make the horizontal shift more sensible. There is something weird going on in the way the first two columns in the basic screen are intentionally left blank (I have once heard to avoid the overscan area). Maybe I should center the remaining 38 columns into the middle of the visible area and adjust the sync accordingly. I will need to experiment with this a bit.

Anyway, this will surely not eliminate the artefact in the Reharden demo. But you can always crop this on the RGBtoHMDI.

[IanSB]

Anyway, this will surely not eliminate the artefact in the Reharden demo. But you can always crop this on the RGBtoHMDI.

As long as it's on the composite output as well then it's faithfully reproducing the output of the Atari so that's OK.

[c0pperdragon]

I finally realized that the ANTIC actually tells the GTIA chip exactly which area or the scren are to be blanked. So I just also use this information now. The visual screen size is quite wide now, and many bugs in demos become quite apparent. But this is faithful to the composite video output, so I keep this for 288p mode. Upscalers (including the RGBtoHDMI) can easily crop away the border garbage.
In the integrated 576p line doubler mode on the other hand, I am cropping the output because this mode is intended to be directly used on TVs without the ability to do more post-processing. I have fine-tuned this to match the scroller of the "Reharden" demo, With 340 pixels width I can get rid of the garbage at the right as well make the left edge perfectly straight. This setting also is perfectly sufficient for all other demos I have tested.

[c0pperdragon]

The change alos shifted the relative positions of the sync signal, and this seems to confuses the RGBtoHDMI, and the colors are all wrong now. I will fix this. Release 1_3 was a bit premature, it seems...

[c0pperdragon]

Sorry, I just realized that with the new way to handle sync and image generation, it would be pretty awfull to change the behavior on my side. Maybe you can fix this in the RGBtoHMDI? The relative positions of the sync and the pixel data has changed by one pixel.

[c0pperdragon]

No, I was mistaken The sync shifted by two pixels, so everything should work as before. Will investigate...

[c0pperdragon]

LOL! I just switched the Pb and Pr cables, therefore the colors were off!
So everything is perfect, actually.

[IanSB]

Maybe you can fix this in the RGBtoHMDI? The relative positions of the sync and the pixel data has changed by one pixel

You can adjust the delay value in the sampling menu to fix that

[IanSB]

I've tried the new firmware with the increased visible area and it works OK.
As you mentioned, more artifacts are visible and while tweaking the geometry settings I found a bug in the Atari capture code that calculated the H-offset incorrectly. I have fixed this and made some other updates so you can use preference menu settings to crop the screen area rather than adjusting geometry settings.
Here is the updated version (full SD card file set):
AtariTest_v0.04.zip

Here are some examples of the settings:

Normal full capture showing edge artifacts (at least I assume that's the case, I don't have a composite output wired up yet):

This has "Crop Overscan" set to 40% in the preferences menu

(In this case, Overscan is the area between the minimum and maximum sizes in the geometry menu. Crop 0% = use max area, Crop 100% = use min area with other values being in between.

The capture below has the "V Adjust 625<>525" setting turned on.
This allows PAL sources to be displayed with NTSC aspect ratio and NTSC sources to be displayed with PAL ratio:

[c0pperdragon]

Using this options I have set the minimum width to 320 and the maximum to 360. By cropping 60%, this gives just the correct size to work with the mentioned demos.
But somehow this cropping percentage gives weird results. The vertical cropping changes in a very unpredictable way.
Maybe it would be better to have seperate options for vertical and horizontal cropping? The requirements may be very different in different circumstances. Often it is just the horizontal overscan that contains broken stuff.

[IanSB]

The vertical cropping changes in a very unpredictable way.

It's trying to maintain the same aspect ratio while also rounding vertical sizes to the nearest 2 and horizontal to the nearest 8 pixels.

When using interpolated scaling, the maximum h/v size is used as the source area and that is then scaled to fill the 4:3 area of the screen so the max area should have the right number of pixels for a 4:3 image. When you use the overscan in this mode it crops off the border but then the cropped image is scaled to the full 4:3 screen so it is effectively a zoom option.

The aspect ratio of the min area usually differs from the aspect ratio of the max area so it has to scale the cropping to cope with that and maintain the aspect ratio of the max area.

[IanSB]

I put the original 3 pin 3.3v regulator MCP1754ST-3302E/CB I was using back on the board and that works fine so it looks like the problem was entirely the FPGA sampling point.

[c0pperdragon]

That is good to know, even if this proofs that that we were chasing the wrong problem
Anyway, I have already changed the design files to use the same regulator as for the C64 board, as this is working so flawlessly.

[IanSB]

That is good to know, even if this proofs that that we were chasing the wrong problem
Anyway, I have already changed the design files to use the same regulator as for the C64 board, as this is working so flawlessly.

When I tested with that regulator, it had less noise than the MCP1754ST-3302E/CB so probably a good idea.

[bwmott]

@c0pperdragon

I've been reading through this thread on Atari 8-bit support for RGBtoHDMI. I was wondering if instead of using the YUV converter board, if it might be possible to build an adapter board that takes the 4-bits of LUMA from GTIA (PINS LUM0, LUM1, LUM2, LUM3) along with a circuit to reconstruct the 4-bits of CHROMA by looking at the delay between the GTIA COLOR and OSC PINS. Looking through some of the technical details on the GTIA makes it seem like this might be possible:

http://ftp.pigwa.net/stuff/collections/atari_forever/www/www.atari-history.com/archives/gtia.pdf

Given the 4-bits of LUMA and the reconstructed 4-bits of CHROMA the pixel color could be determined using a palette lookup. I'm not sure how hard it would be to reconstruct the 16 CHROMA values by looking at the delay between the signals. In the table above each increase in the CHROMA values results in 35ns of additional delay. Any thoughts on if decoding the CHROMA from the delay would be possible with a "simple" circuit?

[c0pperdragon]

This decoding of the chroma information was actually my first approach to the matter. After many, many attempts I still could find no reliable way to do this. The signal produced by the GTIA is just to wonky and there are always some miss-detected pixels. This forced me to use the digital information exclusively and reconstruct the color from that.

But maybe there is a more light-weight approach to that in conjunction with the Pi: Using a cheaper CPLD that is also 5V-tolerant to implement just enough logic to reconstruct the chroma signals and then use the luma signals from the GTIA.
Maybe this could fit on and adapter board that goes between the GTIA and its socket and this also provides a 40-bin female socket to plug the Pi in.

I have no experience with the CPLD in question and don't know if the required amount of logic will actually fit. Also the physical size of the CPLD may be a problem. I need to do more checks on the feasibility of that.