Feedback Atari 2600 version (TIAdigitizer)

[c0pperdragon]

This thread is intended for feedback and discussions on the TIAdigitizer. Please post problems or pictures and also information about successfully use.

@IanSB @TheRetroChannel @dantaipan One question from Ian regards the compatibility of the current RGBtoHDMI software with games that use an off-spec number of scan lines. Most games for NTSC create 262 lines and for PAL 312. The software should handle some deviation, but it would be nice to test.

[c0pperdragon]

You can check the number of lines created in RGBtoHDMI's "Info Menu / Source Summary". I already found "Gorf" with 260 lines and "Combat" with 314 lines. Both work without issue.

[dantaipan]

I have been through the first 50 of AtariAge top 100 list. 45 games had no issues noticed. 5 with issues outlined below. NTSC palette could use some finessing IMO though I know this may be subjective. Comparing via UAV s-video through Retrotink and Commodore monitor (and my old memories). I am impressed that it handles the Harmony cart menu no problem.

Findings:

• Pitfall II - Activision logo missing part of the colour band. No other Activision games exhibited this so far.
• Solaris - vertical artifact/line appears where it shouldn't
• Tapper - Shakey/interlaced screen - This goes stable when RGBTOHDMI menu is on
• Battlezone - Part of the tank turret is missing
• Starmaster - part of the crosshair is missing

Screens comparing issue with s-video output. Retrotink does not like Battlezone so I switched over to CRT. Note, my IPS display does not like that 30hz flicker from Harmony menu and gets temporary "burn in" seen in a couple shots below. Nothing to do with TIAdigitizer or RGBTOHDMI.

[c0pperdragon]

Thank you for going through all these games. I will try to reproduce the issues. My guess is that these all have one common cause.

[dantaipan]

Thank you for going through all these games. I will try to reproduce the issues. My guess is that these all have one common cause.

That would be nice if it was common. For good measure I went through games 50-100. I put all photos into a gallery here so as to not clog up this thread. I will try some homebrews tomorrow.

https://photos.app.goo.gl/qUnJMFZ8v4ti8GWp9

Testing notes:

• Breakout - missing left wall
• Tron - missing part of "O" on title screen
• Subterranea - Extra artifacts on left side of screen
• Chopper Command - Very minor, stray red pixel on left side of screen
• Dragster - Multiple sprite pixels off on left side of screen
• Star Raiders - flickering on title screen and colours off
• Smurf Rescue - left edge of house appearing on right side of screen
• Plaque Attack - Flashing white pixel left side of screen
• Track and Field - Lines running horizontally through stands/crowd
• Space Master X-7 missing some pixels on angled lines
• Snoopy - lots of artifacts and things off on clouds and mountains

[c0pperdragon]

Thank you for this very comprehensvie list. I will dig right into it.

[c0pperdragon]

I went through your list and using the Stella emulator tried to figure out what the game is doing in each case and how the TIAdigitizer misinterprets what is happening. Known bugs in firmware 1_0.txt

Some thing are pretty obvious and easy to fix, others are so strange that I am not even sure I can find a fix. Anyway that is quite some work for me now to straighten this all out.

[dantaipan]

I will hold off on testing any more since it is likely similar issues at this point. If there is something else specific I can check let me know.

[c0pperdragon]

I found and fixed some of the issues, but there are quite some extremely weird things that happen when the programs change registers at just the wrong moment. I have no idea how to properly reverse engineer every last bit of strange behaviour here.

There exists a scan of the hand-drawn schematics of the TIA which shows how obfuscated the whole things actually is: https://www.atariage.com/2600/archives/schematics_tia/index.html Maybe I will try to directly translate this circuitry into VHDL in some way, which would be challenge all in itself because of the extremely unusual way all the registers are designed here. Anyway I really need a bit of a break from this mind-bending stuff and will just work on re-stocking my other boards.

[c0pperdragon]

Continued to fix the firmware. As I only have my homemade FLASH Cartridge that can not handle any back switching or other fancy stuff, I am a bit limited on which games I can actually test directly. Nevertheless I found the problems behind all reported bugs and very likely fixed all of them.

@dantaipan If you want to give this a new try, I would send you a new part with latest firmware.

[dantaipan]

Wow, I thought you were going to take a break ;-) That is really exciting. I would be happy to put the updated firmware to the test.

[c0pperdragon]

Yes, I just could not leave it alone. Ian agreed to give the firmware a test first before sending hardware around the workd. If this works out initially, I send you a board for a torough testing.

[dantaipan]

Yes, I just could not leave it alone. Ian agreed to give the firmware a test first before sending hardware around the workd. If this works out initially, I send you a board for a torough testing.

Sounds good.

[IanSB]

@c0pperdragon @dantaipan

I've been testing the latest firmware and the graphical glitches seem to be fixed on all the examples above e.g.:

However there is another problem which seems to have been present in some of the tests above but seems to be much worse now. Some games seem to have sync glitches that are causing various problems. e.g. tapper as mentioned above appears to look a little interlaced which I think means that one hsync is being omitted on one frame as the image is moving up and down one line on alternate frames.

Similarly some games such as Star Raiders, Space Master X-7 and several others I looked appear to work for the first few seconds then start mis-sampling:

In order to determine if this was a problem with RGBtoHDMI or the tiadigitizer I connected a digital RGBtoHDMI to the three luma and sync pins out of the TIA to give an 8 level mono image and the results from that were stable, with no vertical jitter on tapper and no mis-sampling on star raiders

I think the initial working followed by mis-sampling can be explained as follows: When first running a profile, RGBtoHDMI measures the H sync timing averaged over 100 lines before capturing and then it continuously updates that measurement while capturing to generate the sampling clock so it is measuring a different number of lines in those two circumstances and maybe if one or two hsync pulses are missing in an area that is only monitored during capture then that would mess up the clock timing.

So it seems that both of the above problems are related and likely caused by one or more hsync pulses being dropped or jittering in some way.

[IanSB]

@c0pperdragon

I found the cause for the mis-sampling: The vsync pulses on some games are much longer than on others e.g. on Star Raiders it is 6 lines so that is why they appear to be missing. (This is on both the direct TIA and lumacode outputs).

The maximum capture size is set to 240 lines which is actually too high with 6 lines used for vsync so the fix is to reduce the max capture so it never tries to look at the missing lines. (e.g to around 230) so I have updated the profile for that.

This doesn't affect tapper so I am now comparing the direct and lumacode sync pulses to see if there is any difference

[IanSB]

@c0pperdragon

Tapper is actually generating an interlaced video output but the lumacode board isn't tracking that with it's vsync position Here are two consecutive vsync pulses on both the TIA and lumacode output: Yellow is TIA, Cyan is lumacode

You can see that the first vsync is normal on both but the second one starts half way through a line on the TIA output but the lumacode output doesn't follow that.

[c0pperdragon]

My lumacode output currently aways tries to generate sync pulses for progressive scan. I was not aware that some games actually do produce interlaced video. When it is better for the RGBtoHDMI to handle that, I can easily change it to produce exactly the same sync signals as the original hardware. It may look a bit strange when the game toggles vsync on some arbitrary position in the scan line, but I will happily let you handle this issue.

[IanSB]

@c0pperdragon

I think it will have to be handled by RGBtoHDMI to fix Tapper and any other similar games.

RGBtoHDMI detects interlaced sync by counting the number of lines in two fields. If the value is odd then it assumes interlaced, if the value is even then it assumes progressive.

Tapper does this correctly and generates 523 lines in two fields but I found some 2600 interlaced sync & video demos which are buggy because they produce interlaced video with the second field one line shorter than the first so they get detected as progressive. There might be some other games that fell into the same trap as the demo authors and missed the extra line on the second field which might cause a problem but at least that could probably be fixed with a new RGBtoHDMI software release..

I found a similar issue with some homebrew interlaced demo modes on the Commodore 128.

If you update the firmware I can give it a try.

[IanSB]

@c0pperdragon The new 1.2 firmware fixes Tapper

It may look a bit strange when the game toggles vsync on some arbitrary position in the scan line, but I will happily let you handle this issue.

Are you aware of any games that do this?

The variable field sync pulse is going to be a problem so I think the length of it will have to be measured during profile loading so the necessary adjustments can be made automatically.

Canyon Bomber has a 14 line field sync pulse!

[IanSB]

@c0pperdragon @dantaipan

There is a new alpha61E release here which detects the length of the field sync pulse and compensates automatically plus an updated profile for the 2600: https://github.com/IanSB/RGBtoHDMI/issues/21#issuecomment-1781599238

This release also adds automatic detection of the HDMI mode so if connected to a DVI monitor it will configure for DVI signals and if connected to a HDMI monitor it will configure for HDMI signals. The HDMI mode menu option has been moved to the settings menu and can be used for manual override.

Note it's possible that some games may still give a flashing screen on the 2600 due to a timing problem but hopefully those can be fixed with a further profile update.

[dantaipan]

Thanks @IanSB I will test tonight.

[IanSB]

@dantaipan

I've tested all the games you mentioned with the latest firmware and this RGBtoHDMI release and they all appear to work correctly.

Can you also try it with your HDMI audio embedder as it should put the pi into HDMI mode. (My audio embedder wouldn't work with the default DVI setting as that doesn't support audio)

Note the auto detection is only on reset or power up, not when HDMI hot plugging.

[dantaipan]

@IanSB will do

[dantaipan]

@IanSB HDMI audio working as expected running through the audio embedder. https://photos.app.goo.gl/LrJ1APgbG3rXABPy5

[c0pperdragon]

@dantaipan I have just sent off a TIAdigitizer with the latest firmware. I used a reasonable quick method, but cheaped out on the tracking. So I hope it will reach you in a week or so.

[dantaipan]

@c0pperdragon Appreciated. Will let you know when it arrives.

[dantaipan]

@c0pperdragon until arrived yesterday thanks. Today has been a busy one will be testing tomorrow.

[IanSB]

@dantaipan If you get any games with a flashing screen please post the name so I can check it and update the profile if possible

[dantaipan]

@dantaipan If you get any games with a flashing screen please post the name so I can check it and update the profile if possible

Give Buck Rogers a try. It can't seem to lock on to the title screen. Tested most of the other usual suspects like Pleiades, Robot tank, Moon Patrol, etc. and other than temporary drop outs they seem to play as expected.

[IanSB]

@dantaipan

Thanks for that, I found a bug and fixed it so hopefully you won't see any further flashing screens.

Please try Alpha 61F here: https://github.com/IanSB/RGBtoHDMI/issues/21#issuecomment-1793938279

[dantaipan]

Hey @IanSB that fixed the flashing title screen, there is a significant amount of delay before sync is stable after proceeding into gameplay. I have noticed those delays in some other games. Is that a limitation in how fast the device can catch up when modes are switched in game?

[IanSB]

@dantaipan

Is that a limitation in how fast the device can catch up when modes are switched in game?

Yes, the number of lines changes which means the refresh rate changes and the Pi changes its HDMI clock to match and the monitor sees that as a mode change and so blanks the screen while it caches up with the Pi. Sometimes changing the Genlock speed to slow in the settings menu can help as that makes the Pi change its HDMI clock more slowly.

[IanSB]

@dantaipan You can also eliminate the screen blanking by disabling the genlock (in the settings menu) but then the HDMI output is no longer locked to the Atari output and this will give strange effects like uneven flicker on multiplexed sprites and possible tearing on smooth scrolling. (You will probably need to save any changes and restore defaults to undo them as all the mode changes might trigger a reload of the profile thus losing your temporary settings.

The blanking does depend on the monitor and some monitors will lock faster than others. I will see if any further improvements can be made to the genlock code to help with this but ultimately it's down to how the monitor behaves when it gets a change of frequency.

[dantaipan]

Thanks for the background @IanSB. It does seem very pronounced with the TIA Lumacode vs GTIA or Vic2. I know this is a different beast. Any improvements would be appreciated. In some cases like Pleiades, between the title screen and gameplay, by the time the monitor locks on in my setup I have already lost a life. Everything else seems to be working so well now. This is likely to be the main remaining complaint from people at this point.

[dantaipan]

Slightly off-topic here: do you think 2A is enough juice to power the pi+RGBTOHDMI+Audio embedder+2600 (Vader)? I am trying to decide what to replace the 7805 regulator with in order to have everything in the case. Was thinking this https://www.digikey.ca/en/products/detail/traco-power/TSR-2-2450/9383726

[IanSB]

@dantaipan

Slightly off-topic here: do you think 2A is enough juice to power the pi+RGBTOHDMI+Audio embedder+2600 (Vader)?

2A sounds reasonable, the Pi only takes about 150mA but it depends on how much the audio embedder takes.

In some cases like Pleiades, between the title screen and gameplay, by the time the monitor locks on in my setup I have already lost a life. Everything else seems to be working so well now. This is likely to be the main remaining complaint from people at this point.

A lot of the lockup time depends on the monitor and you may find that different monitors will lock up faster. I do intend to look at this so that the pi slowly follows the changes in the atari output in the hope that the monitor will slowly follow that without losing lock and blanking the screen.

The reason this is more of a problem with the 2600 than other computers is that the sync timing is under software control so it is very easy for it to output non standard signals. The C64 / Atari / Vic etc are more stable at producing sync signals.

[dantaipan]

Thanks @IanSB. Caught a nasty human bug this week. Going to try to test a bunch of recent homebrew this weekend just to get a feel for things. Will also try a couple different displays.

[dantaipan]

Hey @IanSB , I tested this morning with Beta 61. Screen blanking was about the same as before on previously tested monitor. I also tried my 4k LG OLED TV and on that display there is very little issue. So as you said it is going to depend on the display. Still probably something people should be aware of before purchasing so that they know what to expect and avoid returns.

[IanSB]

@dantaipan

Screen blanking was about the same as before on previously tested monitor

I've made some experimental changes to the genlock so can you give Alpha62A a try: https://github.com/IanSB/RGBtoHDMI/issues/25

These changes disable the genlock if the vertical frequency (which depends on the number of lines) varies by more than a fixed percentage.

There are three test profiles to try: Atari_2600_Test_1 allows genlock to vary by 1% Atari_2600_Test_2 allows genlock to vary by 2% Atari_2600_Test_5 allows genlock to vary by 5%

This stops the monitor trying to lock to video outside of those thresholds so might eliminate some of the screen blanking with the more extreme timings. Note that the V sync indicator is set to on with these profiles so you will see a bar moving up or down on the screen which can be used to judge what is happening with the genlock. (when it stops moving the video is locked).

Give each one a try to see if they make any difference for you Note that some games with only a small change in the number of lines will still genlock so you might still get blanking with those but maybe for a shorter period.

There is a more comprehensive list of scan line totals here: https://www.ataricompendium.com/faq/vcs_scanlines.html

It is difficult for me to test this as all my monitors lock quite quickly

[dantaipan]

@IanSB here is a couple videos of the 5% profile. Others look more or less the same and not noticeably different from the last alpha profile. I tried both with and without the audio embedder and it didn't make a noticeable difference. Keep in mind I am loading from the Harmony cart. I have not for example tested HERO from the stock cart which I could try later.

Pleiades https://photos.app.goo.gl/jnMwPwkuqeNSrpxc8

HERO https://photos.app.goo.gl/TnMnjDRUWygUGyDg6

[dantaipan]

FYI: I completed the internal build with the audio embedder and it is working nicely. Need to do some clean up and direct solder the luma code cable still. Old, analog hookups from a mod I did over 20 years ago. Forgive the mess.

[IanSB]

@dantaipan

here is a couple videos of the 5% profile

The 1% or 2% settings are the ones most likely to have an effect.

[dantaipan]

@dantaipan

here is a couple videos of the 5% profile

The 1% or 2% settings are the ones most likely to have an effect.

Here are videos of Warlords running from the actual cart. Observe what happens when reset is hit to start the game.

Test profile 1 https://photos.app.goo.gl/9mbUA1FTzV1cY1fGA

Test profile 2 https://photos.app.goo.gl/WFstp5sFrsrqPskn8

Google photos is giving me buffering issues. If you have the same problem try downloading them.

[dantaipan]

@IanSB I honestly don't know if this is an significant enough issue to worry about. I tested many games tonight from the top 100 and a bunch of homebrew. Outside of the known offenders the percentage of titles it has a real impact on is small. As long as @c0pperdragon notes this possibility on some displays in the details of the Tindie page so people don't gripe about it I think it is a very small issue. I am quite happy with the setup of having the audio embedder right in the machine. The audio quality is better than expected. I guess if there is a downside of the pi being powered by the machine is that there is an 8-10 second delay before you get a picture. This doesn't bother me though.

[IanSB]

@dantaipan

I honestly don't know if this is an significant enough issue to worry about.

There isn't really much more I could do about it, that monitor really doesn't like the clock of it's HDMI source being changed at all. I was hoping that reducing the speed and amount of change would help but it looks like the only way to get a completely non blanking screen is to turn the genlock off completely.

You can try this by using the normal profile, going into the settings menu and changing "Genlock Mode" from On to Off followed by save configuration. Note you will need to do this twice, once with an NTSC game and once with a PAL game.

This isn't really a problem with most computers because their video output is stable so you only get a blank screen at power up but the 2600 timing varies from game to game and sometimes even withing a game.

Maybe I will include a second Atari 2600 profile with genlock disabled.

[dantaipan]

@IanSB I do have a second, similar but more expensive LG IPS monitor here I have tested on as well and it does the same thing. Like I said the LG TV has very minimal delay. I personally think the TIAdigitizer is now ready for production.

[c0pperdragon]

@IanSB @dantaipan Thank you for all this testing and tweaking efforts.

I will initially build 10 TIAdigitizers to be included in my next batch of items that will go on sale. Depending on feedback from those users I will plan further production.

[c0pperdragon]

Alles was ich dazu habe ist sowieso öffentlich hier zu finden: https://github.com/hoglet67/RGBtoHDMI/tree/master/kicad_AmigaAdapter/V2 Teileliste habe ich keine, aber das Schematic sollte alles enthalten. ICs sind durchwegs TSSOP und die anderen Teile in Größe 0805 (imp.) .

[c0pperdragon]

oops. wrong thread...

[dantaipan]

@c0pperdragon had a thought last night for consideration for a future revision of the PCB. A lot of people would likely want to run this alongside the UAV so they have the option of analog or RGBTOHDMI output. If the PCB had a spot for 5 pin headers with leads to TIA pins 2, 5, 7, 8 and 9 (NTSC) or 2, 5, 6, 7 and 9 (PAL) it would make the UAV install that much easier. Since the PCB is already tapping TIA it would seem possible. Just an idea for consideration.

[c0pperdragon]

All my lumacode boards are designed to fit under the graphics chip and are as small as I can possibly make them. There is just no space for extra features. But I do consider creating a device for direct conversion of lumacode to analog RGB. This should cover the use case for an otherweise analog video setup.