Feedback Atari version (GTIAdigitizer)

[c0pperdragon]

Please let us know here about your experiences with the device. Pictures of installation and visual results are appreciated.

[scorpio-ny]

Hi,

I want to let you that I have received the GTIA digitizer and it works perfectly so far. I am using with your RGBtoHDMI Mono & LumaCode device with the latest posted Alpha software.

[c0pperdragon]

That looks very good. Just to make sure: Both machines (Atari and C128) are NTSC with 60 Hz?

[scorpio-ny]

Yes, both are working. The only thing I noticed on both machines is that the aspect ratio looks slightly stretched vertically. Additionally, it looks like color saturation is slightly off from I am used to.

[c0pperdragon]

The details of geometry and scaling can be fine-tuned on the RGBtoHDMI. There is a seemingly infinite number of different settings to tweak. Also the palette can basically be modified to anything you like. But for that you need to patch the palette files. I am not sure how the format works for that, please refer to the RGBtoHDMI documentation.

There is also the latest firmware available on Ian's clone of the repo: https://github.com/IanSB/RGBtoHDMI/releases which has slighly different colors for the Atari. Maybe this is already more to your taste.

[scorpio-ny]

No problem! I will review the documentation. There is an important tidbit that I just gleaned from glancing at the documentation. If one decides to use a PI Zero, it does not support 4K natively. So if one is using it with a 4K display (as I have) it will either display it in 1080P which will produce a softer image or a special mode where it supports the display at 4K vertically only. I think that is what I am seeing with my current set up. Could I connect your hat variant to it to a different Raspberry Pi (i.e 3 or 4) to test this theory?

[c0pperdragon]

The hat should work with other Pi variants as well. It is mainly the software that needs to all the necessary adjustments.

[scorpio-ny]

Ok. I have a Raspberry PI 4 but I need to order a HDMI cable for it to test that out. When I get it, I will report back to see if it makes a difference.

[scorpio-ny]

Oh one more thing. I have other solutions for connecting to the Atari to a 4K display and I I checked the settings for it. They were set to 960x540. So I went in the menu for the HDMItoRGB menu and set that screen resolution manually. And now it looks exactly how I am used to on my particular display. I will still do some testing with the Pi 4, but this setup so far works perfectly. Thank you for your efforts!

[dantaipan]

Mine is en route. Do I use the C64 LumaCode profile or is there an Atari-specific profile?

[scorpio-ny]

Hi @dantaipan ,

You will need to download the latest version of RGBtoHDMI firmware that has the Atari specific profiles. I downloaded it from this repo link

When I first launched it with my Atari 800XL, the screen dimensions were distorted because it defaulted to a screen mode that stretched it in only dimension . You will need to go in the RGBtoHDMI menu and set your preferred dimensions. I set mine to 960x540. And my system was NTSC.

Hope this helps!

[dantaipan]

@scorpio-ny got it thanks. Hopefully it will be here before the weekend but starting to look like next week.

[r3mowilliams]

I've now tried the GTIAdigitizer in two different 800XLs and overall I am so far impressed with it at this point : )

It is not getting along well with the first XL I installed it in. This XL has a U1MB installed and is otherwise without issue.

https://youtu.be/_Nl4-rC22iE

The second has a UAV mod and nothing else, it is working well in this unit.

I have noticed an issue where GTIA shading is not being correctly represented.

GTIAdigitizer:

What it should look like:

[c0pperdragon]

You could try to fix the first issue by adjusting the settings in the RGBtoHDMI. Do this by opening the menu (menu button on the RGBtoHDMI), navigate to Sampling and adjust the "Phase" setting.

I will look into the second issue with the GTIA colors and see if I can reproduce the issue.

[c0pperdragon]

I could reproduce the effect with the wrong colors in the Ballblazer intro. It seems it is somehow caused by the scanline effect added by the RGBtoHDMI. If you turn scanlines off, everything looks correct (but without scanlines of course). Please raise an issue at the RGBtoHDMI project for this, so Ian may have a look at it: https://github.com/hoglet67/RGBtoHDMI/issues

[scorpio-ny]

I went and just posted the issue with the RGBtoHDMI project so it can be looked into.

[TheRetroChannel]

Just tested this out with the 130XE. Note I have it hooked up directly to the RGBtoHDMI with LumaCode board as the XE doesn't provide an easy way to reuse the RF socket.

I'm seeing some odd graphical corruption in certain places. For example the Atari Control Program shows a number of issues (colours missing, random junk where there should be nothing) with the LumaCode output that isn't present with the same machine using s-video

The drunk chessboard demo also shows some odd junk on the far right of the screen that isn't normally present

I've played with all the settings in the RGBtoHDMI sampling menu but nothing has worked to solve this.

[c0pperdragon]

As far as I understand, this junk at the far right is actually generated in s-video as well, but normally it is so far out that it is always cropped. The RGBtoHDMI should provide options for this in the geometry menu.

The issues with the control picture must be genuine incompatibilities. I can easily see what is going on at the left and right border of the big color box. But I have no idea yet on what is this garbage pattern on the right part. Could you point to to the download for this test program, or maybe directly post this here?

[TheRetroChannel]

Ah yes, it is normally cropped out. I adjusted the horizontal position on svideo and it is still there. So nevermind that one. The ACP program is here: https://forums.atariage.com/applications/core/interface/file/attachment.php?id=527461

[c0pperdragon]

I actually found both problems. The GITA colors appearing a bit too early on the left side was fixed by adding a delay before GITA mode takes effect (this also fixed the grey stripe on the right side of the colors).

The garbage on the right part was caused by the fact that using the GTIA mode turns off the highres mode for the rest of the scan line. So even after turning the GTIA modes off after the color box, everything is shown in low-res mode. I did not know that, so the GTIAdigitizer happily shows high-res pixel instead.

I very much guess that this quirk of the GTIA caused many coders to tear out their hair in frustration. As far as I can see how this specific program works, the developer had to do do quite substantial workarounds (including using player graphics and whatnot) to account for this.

The fixed firmware (1.1) will be used for all future sales of the GTIAdigizier, but I don't quite know what to do with the units already sold. Shipping stuff around the globe is such an effort.

[IanSB]

@TheRetroChannel

You can crop the garbage off the image using the crop border(zoom) option in the preferences menu or adjust the capture size in the geometry menu. Would it be better to have the default profile with more cropping or not?

[TheRetroChannel]

@c0pperdragon

Yeah not sure what to do about the units already out there. I've played around with it a little more and haven't spotted any issues with anything else. I guess it depends how many units are affected and whether it causes issues with other programs. If it's just that ACP program then it probably doesn't matter.

@IanSB

I did find a few programs that seem to use the entire visible horizontal area, they don't place any critical information out there (just the borders extend close to the "screen" edge). I'd say leave it as is and people can choose if they want to crop anything

[dantaipan]

I had not been comparing with s-video and had to spend a lot of time to find something "off" which I guess is good news. I focused on homebrew as it tends to push the limits. Only things I could find after an hour or so of testing were that the sword(?) in Final Assault is missing detail and the colour on the Arcadia background seems off. So in practice, the scale of the issue seems minor. Testing note: NTSC 800xl.

[c0pperdragon]

The slightly wrong color is a matter of how the palette is set up by the RGBtoHDMI. The GTIAdigitizer only sends color numbers.

This falsely colored weapon is probably implemented using multiple players/sprites layered on top of each other with some extremely unusal priority usage. The priority flags and resulting color merging effects are such an arcane topic that it makes my head spin every time I try to actually understand it. I am very hesitant to change anything here in fear of breaking something else.

[dantaipan]

Understood. My point above was really just to say that the vast majority of titles that I have tested seem to work just fine even on 1.0. I really had to dig for something that looked off other than that ACP program. I agree that changing something to satisfy that one unusual implementation is not worth the risk.

[dantaipan]

Just want to report that v2 is working without any observed issues on the Atari 5200. This shouldn’t really a surprise as it is essentially a 400/800 machine but I thought maybe others would like to know that it is compatible.

[scorpio-ny]

Speaking of versions, is there any way one can check which version of the firmware is run? If not, would be possible to include some code to allow the end user identify what they are running.

Also, I was thinking: Wouldn’t it be possible to upgrade from the Atari itself by making extra connections to the CPU lines to run a patch? I run a FPGA recreation of the Pokey sound chip and the creator of that project has made so it can be updated from an Atari executable using updates that he posted.

[c0pperdragon]

Sorry, there is no direct way to know which firmware version is on the FPGA. But since I normally only have to make new firmware versions when something does not work, I could write up how to expose the problems and which firmware version fixes that.

About updates: This would only be possible with a dedicated programmer hardware (which indeed could somehow be integrated into the Atari). Also it would mean to give away the firmware binaries, which I don't want to do. The firmware for the various boards took the most effort to make and right now it is nicely protected inside the non-readable FPGA flash. Reverse-engineering the hardware is probably not so difficult and I actually plan to stay in business a bit longer.

Because of this update situation I am willing to give out replacements very cheaply or even for free if the user makes a good case in demonstrating why he absoluteley cannot live with the faulty firmware. ;-)

[scorpio-ny]

About updates: This would only be possible with a dedicated programmer hardware (which indeed could somehow be integrated into the Atari). Also it would mean to give away the firmware binaries, which I don't want to do. The firmware for the various boards took the most effort to make and right now it is nicely protected inside the non-readable FPGA flash. Reverse-engineering the hardware is probably not so difficult and I actually plan to stay in business a bit longer.

It is understandable that you want to protect your IP. I was under the impression that you would be able to make the changes with a small patch, not with the entire code base. Thus making the fixes available while still be able to offer some protection to your IP.

Because of this update situation I am willing to give out replacements very cheaply or even for free if the user makes a good case in demonstrating why he absoluteley cannot live with the faulty firmware. ;-)

So far, I have not seen any show stopping issues that affect the ones I have already acquired and I have been happy with what they can do. It is nice to see that there are options available in case something comes up that severely impacts its usability.

[dantaipan]

@IanSB I noticed in alpha61E you added an Atari 5200 Lumacode profile. Was this just a straight duplicate of Atari 800 Lumacode project or is there something unique about it?

[IanSB]

@dantaipan

It's a straight duplicate of Atari 800 Lumacode

I added a separate profile to indicate that it works with that as well and also so you can have different preference settings to the 800 if required.

[scorpio-ny]

Just tested this out with the 130XE. Note I have it hooked up directly to the RGBtoHDMI with LumaCode board as the XE doesn't provide an easy way to reuse the RF socket.

I was just looking at this with my XE Remake. You may be able to route some cabling outside by going under the ECI connector and use slightly thinner cabling. You will probably need to remove the motherboard to do this.

[TheRetroChannel]

I was just looking at this with my XE Remake. You may be able to route some cabling outside by going under the ECI connector and use slightly thinner cabling. You will probably need to remove the motherboard to do this.

I worked out a few options. The cables will just fit past the RF jack if you're going for a solderless solution, alternatively you can disable the composite output and reuse that without needing to solder anything. Otherwise desoldering the centre pin of the RF jack is possible without removing the entire modulator.

[dabonetn]

I just got my unit, and I've not been able to get a good picture out of it. I've tried on a atari 130ex with a rambo upgrade, and a stock 800xl, and get the same results on both. I'm a NTSC user located in the USA.

Here's a short video... https://www.youtube.com/shorts/E0mfNoPuuQo

And some stills.

https://imgur.com/a/64euYRA

The rgb2hdmi works on a c128 with lumacode, and I've also tried my standard analog rgb2hdmi board and it does the exact same symptoms. Firmwares I've tried are the latest standard release, and betas 59 and 60.

[c0pperdragon]

@dabonet Could you also plug the lumacode signal directly into a composite input on a screen and take pictues/videos of the result. I already have some feedback with simillar symptoms and need to narrow down the possible cause.

[dabonetn]

https://imgur.com/a/4htvMjI

Looks about the same with the large blocks of garbage and lines, etc..

[dabonetn]

On just a standard menu screen, the colors (White and Black) are inverted, and when I load something off my sdrive MAX, it really goes nuts.

HDMI out...

https://www.youtube.com/shorts/ElVoqMSyBHg

Monochrome Composite Monitor.

https://www.youtube.com/watch?v=TBi55fdlpkc

Are you testing each unit before shipping?

[c0pperdragon]

@dabonetn I do test all units in my dedicated test rig, but as I recently learned, there are some faults that pass unnoticed. Specifically when there is a bad/missing connection of the GND pin of one of the ICs this may slip through. In a really machine this then causes mayhem. Could you check with a multimeter if there is continuity between the GND (from the lumacode output header) to each of the 4 logic ICs? (no need to check the central FPGA). The GND pin of these is always located at the bottom right (when looking on the IC so that the numbers can be read).

[dabonetn]

No GND on the IC near C4.

[c0pperdragon]

So, there is the problem. This pin needs to be soldered down properly. Since I know that my test rig does not show this specific problem, I always do manual test for that.

The question is: Do you have the equippement to repair this yourself? If you want to give this a try and mess up the board, I will send you a new one in any case. But if you succeed this would solve the problem immediately.

[dabonetn]

Ok, I gave it try and now I have a gnd and a slightly melted socket, and better, but still some random noise that corresponds to audio or maybe bus activity..

https://www.youtube.com/watch?v=LVq9qXIyAEE

So it's still not working 100%.

[c0pperdragon]

Lumacode on the Atari 8-bit is pushing the limits of what is possible with the transmission circuitry. But you are very close to a stable solution here. Try to tweak the following things: When using my cable with the crocodile clips, twist the Lum and GND wires together for best noise immunity and clip he GND wire as closely as possible to the output jack to the ground metal. When you use my RGBtoHDMI with the built-in cable, there is nothing to change. Use the sampling menu of the RGBtoHDMI and try to fine-tune the phase, but also the comparator voltages.

[dabonetn]

I'm running a new coax cable from the board to the rf jack output on the rf modulator, I've removed the surface mount components from the board and isolated the jack for the output, I've also cleaned the port fully. Using your cable makes no visible difference.

(The coax I used is RG174, and I use it to make cables for the Commodore boards I make and sell, it works very well, but it's not the easiest thing to work with.)

I'll try to find time to try to tweak and fine tune tomorrow. But I'm confused as why you say the interference that's appearing that's synced with the audio is a video issue, There is no video movement on the screen when it's happening.

The C128 version was so easy, this one has been a nightmare. So many hours wasted on defective hardware.

[IanSB]

@scorpio-ny

If one decides to use a PI Zero, it does not support 4K natively. So if one is using it with a 4K display (as I have) it will either display it in 1080P which will produce a softer image or a special mode where it supports the display at 4K vertically only. I think that is what I am seeing with my current set up. Could I connect your hat variant to it to a different Raspberry Pi (i.e 3 or 4) to test this theory?

Up until now full 4K was not supported on the Pi 4 but I have now added that. There will be a new beta soon but in the meantime here is an Alpha release with 4K support on the Pi 4: Alpha61F here:

https://github.com/IanSB/RGBtoHDMI/issues/21#issuecomment-1793938279

[scorpio-ny]

@scorpio-ny

If one decides to use a PI Zero, it does not support 4K natively. So if one is using it with a 4K display (as I have) it will either display it in 1080P which will produce a softer image or a special mode where it supports the display at 4K vertically only. I think that is what I am seeing with my current set up. Could I connect your hat variant to it to a different Raspberry Pi (i.e 3 or 4) to test this theory?

Up until now full 4K was not supported on the Pi 4 but I have now added that. There will be a new beta soon but in the meantime here is an Alpha release with 4K support on the Pi 4: Alpha61F here:

IanSB/RGBtoHDMI#21 (comment)

That is very cool! Are there any performance penalties using 4K output?

[c0pperdragon]

@dabonetn I am really sorry about this faulty board. When building larger quantities, something always seems to slip through undetected.

It is pretty obvious that there is something that carries over from the audio signal into the lumacode signal to cause interference. I guess the lumacode is already extremely marginal in your case, so the slightest disturbance may just push it over the edge.

According to the datasheet the RG174 as 50 Ohm, which is not ideal for signal as everything is designed around 75 ohm cables. But for short distances this should not be such an issue.

Another thing: Which RGBtoHDMI board are you using? The one from my store with the coax cable permanently attached? Or some other variant. I know there are specific analog boards that have a slightly worse performance any may cause such an issue. @IanSB knows more about this.

[IanSB]

@dabonetn

One possible cause of noise like that is the PSU used to power the Pi zero. Some noisy PSUs can interact with the ground paths of the computer in strange ways so try another PSU of a different make if you have one.

Alternatively if your monitor has a USB hub on it, try powering the Pi from the monitor using a USB to micro USB cable although note some hubs on monitors won't power up unless actually connected to a USB host like a PC.

[IanSB]

@scorpio-ny

That is very cool! Are there any performance penalties using 4K output?

The core clock has to run a little faster at 550Mhz rather than 500Mhz so it will run a little hotter than normal but the Pi 4 will run quite a bit hotter than a zero and take a lot more power anyway. The Pi 4 hasn't had that much testing as there was no real reason to use one instead of a zero until now but I'm not aware of any issues at the moment.

The main issue is physically fitting the board onto a Pi 4 which will depend on which type of board you are using. The special lumacode board with captive cable should fit but a standard CPLD board plus analog addon board won't and you will have to use a 40 way stacking extender to clear the connectors on the end of the Pi 4 board. e.g. https://www.adafruit.com/product/2223 https://www.adafruit.com/product/1979 https://www.ebay.co.uk/itm/193060049594

[dabonetn]

@dabonetn I am really sorry about this faulty board. When building larger quantities, something always seems to slip through undetected.

It is pretty obvious that there is something that carries over from the audio signal into the lumacode signal to cause interference. I guess the lumacode is already extremely marginal in your case, so the slightest disturbance may just push it over the edge.

According to the datasheet the RG174 as 50 Ohm, which is not ideal for signal as everything is designed around 75 ohm cables. But for short distances this should not be such an issue.

Another thing: Which RGBtoHDMI board are you using? The one from my store with the coax cable permanently attached? Or some other variant. I know there are specific analog boards that have a slightly worse performance any may cause such an issue. @IanSB knows more about this.

The analog boards I've been trying are the one I got from you and one I purchased from retro hack shack a while ago. I tried 2 other power supplies tonight, one is a motorola charger for my moto phone, another was from a Intel compute stick, both still had the same problems, and actually today it's worse. I really think I did get a lemon unit, and maybe the solder fix you had me try is not the only issue or there is another cold joint somewhere.

Both RGB2HDMI and analog boards give a perfect picture using the C128 board.

[c0pperdragon]

As you have pretty much tried everything we can think of, I will need to just send you a replacement. Can you tell me your Tindie order number so I get the address from there?

[dabonetn]

Order Number: 424267

On a side note, I hooked up the TS1000 (zx81) to the analog board last night, and that thing has never looked better!