c0pperdragon / LumaCode

Definition of the "LumaCode" signal standard with reference implementation
67 stars 2 forks source link

Feedback Atari version (GTIAdigitizer) #2

Open c0pperdragon opened 1 year ago

c0pperdragon commented 1 year ago

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

IanSB commented 10 months ago

@dantaipan @scorpio-ny @c0pperdragon beta 61 now available: https://github.com/IanSB/RGBtoHDMI/releases

Imperious685 commented 10 months ago

Just fitted my Rev 2 board to my NTSC Atari 65XE. It has some bad noise issues. I previously had a home made S-video mod so the normal video output is disconnected as I had removed the resistors for Luma and chroma. I am using a rev 3 analog board with my RGB2HDMI and am using the same cable as my vic-20 as It's using the same pins. 5 is lumacode. 3 is Audio. 2 is GND. The other 2 pins are not connected. Also I have just soldered a wire from the Lumacode output directly to pin 5. The GND output on the lumacode board is not being used. The Vic-20 works perfectly with the same cable. I have attached photos but please let me know if You have any ideas. I tried a different power supply for the RGB2HDMI and will try and make up a cable for a different power supply for the Atari but was ok previously with s-video. I don't know if connecting the GND pin should make a difference as I'm not using the RCA connector. Also it gets quite a bit better after warming up but doesn't go away completely. I should also mention that I tried every adjustment possible in rgb2hdmi including the level adjustment as suggested by theretrochannel. nearly forgot to mention moving the joystick (Genuine Atari 2600) seems to minimise the noise momentarily when I push in any direction. The noise is still there with no sd drive connected.

noise turned on from cold noise after warmed up some noise in game warmed up

Imperious685 commented 10 months ago

On a separate note in the latest Beta 61 Lumacode 800 doesn't work whereas 5200 does work. Beta 60 Lumacode 800 worked ok. this was from the first time I tried 61, not after any messing with configs.

c0pperdragon commented 10 months ago

The Atari 8-bit solution really pushes the limit of what lumacode can do. This noise may well be introduced by your wiring and especially be leaving away the GND return path. Try to wire up a dedicated GND from the GTIAdigitizer to your output connector. Twist this GND wire together with the LUM wire to get best possible noise protection. It may also be a problem when your connector carries composite or chroma so you may have cross-talk. To avoid all this, I recommend using a dedicated output RCA jack,. Either a re-purposed RF output or a new one.

IanSB commented 10 months ago

@Imperious685

Just fitted my Rev 2 board to my NTSC Atari 65XE. It has some bad noise issues

That looks like some sort of ground loop or crosstalk issue and I agree with c0pperdragon's suggestion of a direct ground to his board. This is almost certainly some sort of hardware issue but if that doesn't help here are a few other things to try:

Go into the sampling menu Adjust the Y Hi, Y Mid and Y lo DAC settings (only a small amount either way). Note that final values must be Y Hi > Y Mid > Y Lo

Also try running an auto calibrate sampling phase.

Finally try selecting the RGB version instead of the YUV version of the Atari lumacode profile as these use slightly different settings. (Revert back to YUV if no difference)

On a separate note in the latest Beta 61 Lumacode 800 doesn't work whereas 5200 does work

In what way doesn't it work? I've just tested Beta 61 again with my 800 and it works OK. Are you using a PAL or NTSC system? (The Lumacode 800 & Lumacode 5200 profiles are identical)

dabonetn commented 10 months ago

Replacement unit arrived today, and after a quick install the new unit works perfectly. Thanks!

Imperious685 commented 10 months ago

Thanks for the replies. 1st of all the beta61 config is all good. I overwrote beta60 and that must have messed the 800 Lumacode config. All good with a clean installation. For the noise issues I have replaced the capacitor on the main board and the ones in the Atari power supply, which cleaned up power supply noise but made no difference to the noise in the video output. I tried attaching the ground wire to the Lumacode board which made no difference. I also resoldered the logic ic's on the Lumacode board as there was the odd bit of solder here and there. That made no difference. There is no crosstalk as there is no signals other than Audio, Lumacode, and Gnd connected to the 5 pin Din.

So I did a bit of poking around. This is a C070025 Rev C NTSC board. When I poke around where U21 isn't and especially when touching W2 which is connected between pins 28 and 16 of the GTIA the noise gets a lot worse. I can't find any problems with the board but will keep looking. this is interesting as according to the GTIA pinout for NTSC models pin 16 is N/C. I can't find anywhere what W2 is, perhaps a coil? but that should be L something?

scorpio-ny commented 10 months ago

There is no crosstalk as there is no signals other than Audio, Lumacode, and Gnd connected to the 5 pin Din

You may still be picking up cross talk noise from DIN connector. I recommend wiring up from the GTIAdigitizer directly to RGBtoHDMI to see if that makes a difference.

IanSB commented 10 months ago

@Imperious685

Thanks for the replies. 1st of all the beta61 config is all good. I overwrote beta60 and that must have messed the 800 Lumacode config. All good with a clean installation.

Thanks for confirming beta61 is OK. These updates are always meant to be clean installed on a blank SD card. Sometimes palette and profile names change and if you overwrite you end up with a hybrid install with some files left over from the old version that won't work with the new version.

Looking a bit closer at your noise, it seems to be somewhat similar to dabonetn's noise but more severe as his was only triggered by sound activity.

dabonetn commented 10 months ago

I spent more time with my defective unit, and I've reflowed every chip and all the legs on the 40 pin socket/pins. There has been no changes in the symptoms, but it is much much worse on a cold boot vs leaving it on for a long while.

Cooling off (Freezing) the gtia-digitizer makes the symptoms much worse, but they get less over time, so maybe there were some marginal components in a batch?

Imperious685 commented 10 months ago

I have found the solution to the noise problem. I tried directly connecting the Lumacode output to the RGB2HDMI Analog board. That made no difference, nor did removing W2. As I mentioned before W2 is a Jumper but there is no need for it in NTSC machines as Pin 16 on the GTIA is not connected. Actually there is no need for it at all as it says to remove it for Pal machines. The Noise did improve as the computer warmed up, but I noticed that if I pressed my finger where L37 and C206 are connected together, or on one side of W2 the noise got a lot worse. Those points are the Oscillator signal to pin 28 of the GTIA. In the Schematics it mentions that L37 can be swapped for a 470 ohm resistor. I desoldered one side of L37 and test soldered a 470 ohm resistor, and that has completely solved the problem. No more noise at all. No need to remove the capacitor either. I just spent half the night playing various games and all good, I can now enjoy the fantastic image quality that the Lumacode board offers.

resistor installed coil removed test resistor noise fix

c0pperdragon commented 10 months ago

Congratulation that you could solve that! So the root issue was that the oscillator input to the GTIA was somehow off. Could either have been a non-50% duty cycle or some other fluctuations. It is good to have this now reported here in this issue thread for future reference.

dabonetn commented 10 months ago

I did this fix on my 130xe with my unit that wasn't working and it fixed it also, so now both units work.

Imperious685 commented 10 months ago

According to information that i could find L37 is a ferrite bead. It could be introducing some ringing noise, or maybe the resistor dampens the oscillator signal just enough to solve the problem with the Lumacode board. I'm not an electronics engineer but am a technician. I guess I should have put an oscilloscope on this before and after for some extra documentation. The ribbon on my keyboard already has a rip in it so I don't want to keep taking it apart. For C0pperdragon's reference My board is CO70025 NTSC with the 4 pin oscillator fitted.

c0pperdragon commented 10 months ago

As dabonetn also could fix his issue in the same way, this is probably something too look out for on the XE series machines.

dabonetn commented 9 months ago

FYI, if you want a PAL 800xl in the states with color, this worked for me.

Replacing the Antic/GTIA and crystal while using the GTIAdigitizer gives great video, without needing to add the pal color burst crystal and other components.

CO21698 (PAL XL / XE ANTIC) CO21698 (PAL GTIA)
CO16112 (3.546894 MHz XTAL)

Brentarian commented 9 months ago

Hi, I cannot get a good picture with the GTIAdigitizer that I received this week. I have attached captures for you to see. I tried it in three different Atari 8-bit computers with three different GTIA chips. The Atari 800 profile was selected and I tried every option I could find. Any help is appreciated.

The VIC-II-dizer worked perfectly in a C64 on both of the Lumacode RGBTOHDMI units I purchased.

Thanks, Brent

A8-capture1 A8-capture2 C64-capture0

c0pperdragon commented 9 months ago

I looks like your RGBtoHDMI uses a wrong profile. You need the "Atari 800 Lumacode" profile from the latest beta release. You can get this release from https://github.com/IanSB/RGBtoHDMI/releases

wthorch42 commented 8 months ago

If you're installing this on an OG Atari 800, you'll need to remove the GTIA socket and solder the LumaCode digitizer directly to the CPU card. There isn't space in the cast aluminum shell to fit the digitizer into the existing socket and then the GTIA into the digitizer. Other than that, it's working well.

aleksander-martin commented 8 months ago

@c0pperdragon - Does your extension actually emulate GTIA or converts it's real output to LumaCode? Reading the discussion above gave me a feeling that it may do some emulation for this specific output.

c0pperdragon commented 8 months ago

All my lumacode boards work in a similar way. By monitoring the digital data communication it figures out what the video chip is currently up to and which color it will produce. So this is kind of emulation, but it heavily relies on the video chip being present and doing all the memory addressing and other auxilary stuff.

c0pperdragon commented 8 months ago

Using the output video signals just does not work for machines that natively create composite video or even s-video in the chip. I simply never managed to reliably re-quantize this to stable digital data. The GTIA2DVI project tries the same, but as far as I have seen they also can not get rid of flickering pixels.

sideburn commented 1 month ago

I have the same issue as Brentarian. My firmware is current. Using Atari 800 lumacode (unterm) profile, and Atari 800 PAL palette.

The board is a 65XE PAL. Tried the 470 ohm resistor mod and no luck. Tried auto calibrations, changing resolutions, adjusting the sampling params. Everything I could think of.

Verified composite video is working properly. Tries two different displays.

Video: http://sideburn.com/vid/lunacode.MOV

IMG_9252 IMG_9253 IMG_9258 IMG_9255

c0pperdragon commented 1 month ago

I did some experiments with the settings and the only way to get a faulty picture similar to your is when miss-adjusting the sampling phase. When tweaking the phase does not help, maybe you could try to adjust the clock multiplier (everything is in the Sampling Menu). While my RGBtoHDMI still runs fine even with a multiplier of 8, this could be too fast for your specific device. Reducing the multiplier even down to 4 also works for me, so maybe you give this a try.

sideburn commented 1 month ago

I’ll give it another go but I tried that already. I’ve now tried my 130xe and two GTIAs and same results. Can you tell me specifically what params to adjust?Photos of both boards attached On Aug 19, 2024, at 12:38 AM, c0pperdragon @.***> wrote: I did some experiments with the settings and the only way to get a faulty picture similar to your is when miss-adjusting the sampling phase. When tweaking the phase does not help, maybe you could try to adjust the clock multiplier (everything is in the Sampling Menu). While my RGBtoHDMI still runs fine even with a multiplier of 8, this could be too fast for your specific device. Reducing the multiplier even down to 4 also works for me, so maybe you give this a try.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

sideburn commented 1 month ago

I just went back in and tried every sampling phase and clock multiplier (and all of the other adjustments) and just cannot get it to work on either board. 🤷‍♂️ On Aug 19, 2024, at 12:38 AM, c0pperdragon @.***> wrote: I did some experiments with the settings and the only way to get a faulty picture similar to your is when miss-adjusting the sampling phase. When tweaking the phase does not help, maybe you could try to adjust the clock multiplier (everything is in the Sampling Menu). While my RGBtoHDMI still runs fine even with a multiplier of 8, this could be too fast for your specific device. Reducing the multiplier even down to 4 also works for me, so maybe you give this a try.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you commented.Message ID: @.***>

IanSB commented 1 month ago

@sideburn

If you have a multimeter, try measuring the input resistance of the mono/luma board (when powered up) both with the YUV and RGB (unterm) profiles.

sideburn commented 1 month ago

You mean the resistance between the red and yellow luma and gnd wires?On Aug 19, 2024, at 2:12 PM, IanSB @.***> wrote: @sideburn If you have a multimeter, try measuring the input resistance of the mono/luma board (when powered up) both with the YUV and RGB (unterm) profiles.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

IanSB commented 1 month ago

@sideburn Yes the red and yellow luma wires (when not plugged into the Atari board)

sideburn commented 1 month ago

.978kOn Aug 19, 2024, at 3:42 PM, IanSB @.***> wrote: @sideburn Yes the red and yellow luma wires (when not plugged into the Atari board)

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

sideburn commented 1 month ago

Forgot to measure the others here they are:YUV Atari 800 lumacode: 76.4 ohmAtari 800 YUV LC: 76.5 ohmsAtari 800 lumacode (unterm): .980kOn Aug 19, 2024, at 2:12 PM, IanSB @.***> wrote: @sideburn If you have a multimeter, try measuring the input resistance of the mono/luma board (when powered up) both with the YUV and RGB (unterm) profiles.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

sideburn commented 1 month ago

I solved it by switching to the YUB attin800 lumacode profile and adjusting the DAC settings. On Aug 19, 2024, at 3:42 PM, IanSB @.***> wrote: @sideburn Yes the red and yellow luma wires (when not plugged into the Atari board)

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

IanSB commented 1 month ago

@sideburn Those resistance readings are in the expected range, glad you got it working.

sideburn commented 1 month ago

It’s all good now except for a tiny bit of noise. Not sure if that is normal or not. Auto calibrate is working now so I think the core issue was using the unterm profile. I need to be using the YUV profile. On Aug 20, 2024, at 4:31 AM, IanSB @.***> wrote: @sideburn Those resistance readings are in the expected range, glad you got it working.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

IanSB commented 1 month ago

@sideburn Try switching back to the RGB (unterm) profile and adjusting the DACs although the adjustment amounts will have to be a bit larger. (The unterm profile normally has better noise immunity)

sideburn commented 1 month ago

I will try again but I hadn’t had any luck before. The auto calibrate definately did not work and then I tried adjusting every param I could. The key is the DAC-F Y Lo setting and DAC-E Sync and I think we don’t have those in the unterm profile.

sideburn commented 1 month ago

Ok so now that I know what I’m doing a little more, I was able to get it pretty good with the unterm profile. After getting it pretty close I then tried the auto calibrate and I can get auto calibrate to work pretty well when I have the Atari Control Picture utility on the screen. Still has a little bit of noise but maybe slightly better.

IanSB commented 1 month ago

@sideburn Noise problems can sometimes be caused by the Pi zero PSU or even the monitor PSU if that uses a similar plugin style PSU rather than an integrated PSU so it is always worth trying different makes of PSU for those. If your monitor has a built in USB hub, another option is to try powering the Pi zero from that hub using a USB to micro USB cable.

sideburn commented 1 month ago

Ah right. Good idea.  This is going to end up as a custom laptop running on battery power, maybe that will help clean it up. It’s very good now after more tweaking. The little noise there is is darker and more subtle with the unterm profile. I guess auto calibrate doesn’t change all of the params because at first it would not work at all but once I got it pretty good manually then auto calibrate works and got down to zero errors. On Aug 20, 2024, at 7:28 AM, IanSB @.***> wrote: @sideburn Noise problems can sometimes be caused by the Pi zero PSU or even the monitor PSU if that uses a similar plugin style PSU rather than an integrated PSU so it is always worth trying different makes of PSU for those. If your monitor has a built in USB hub, another option is to try powering the Pi zero from that hub using a USB to micro USB cable.

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.***>

Brentarian commented 1 month ago

Oh wow! I haven’t messed with mine since earlier this year, as I have not had a lot of free time. I’ll have to do this and see if it works for mine. Thank you!

From: Sideburn Studios @.> Sent: Tuesday, August 20, 2024 2:17 AM To: c0pperdragon/LumaCode @.> Cc: Brent Carroll @.>; Comment @.> Subject: Re: [c0pperdragon/LumaCode] Feedback Atari version (GTIAdigitizer) (Issue #2)

I solved it by switching to the YUB attin800 lumacode profile and adjusting the DAC settings. On Aug 19, 2024, at 3:42 PM, IanSB @.<mailto:@.>> wrote: @sideburn Yes the red and yellow luma wires (when not plugged into the Atari board)

—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you were mentioned.Message ID: @.<mailto:@.>>

— Reply to this email directly, view it on GitHubhttps://github.com/c0pperdragon/LumaCode/issues/2#issuecomment-2298050076, or unsubscribehttps://github.com/notifications/unsubscribe-auth/APQGAK7L4NPXSB64HFON6DDZSLNM7AVCNFSM6AAAAAA2NE6HYOVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJYGA2TAMBXGY. You are receiving this because you commented.Message ID: @.**@.>>