Lumacode sampling for Atari 2600

[c0pperdragon]

Hi!

As earlier discussed, I would need an implementation of the 8-bit per pixel sampling as is needed for my new Atari 2600 Lumacode board. The specification is straight-forward: 4 samples together make one pixel. Most significant bits are first. I can provide profiles and palettes to then integrate into the official release.

[IanSB]

I hope to look at this soon

[IanSB]

@c0pperdragon

Try this kernel: kernelrpi.zip

To modify your existing Atari 2600 test profile, select "Atari 2600 lumacode" in the palette menu and change the clock frequency and line length to 4x actual rather than 3x actual with the Atari GTIA

The order is 4 bits hue, 4 bits luma

This is completely untested so might not work

[c0pperdragon]

This works nicely and after quite some fiddling around with the geometry settings, I do get a perfect picture on my screen. Because I do not really know what I am doing here, this is probably not suitable for general release.

There is also one problem: The RGBtoHDMI's menu overlay now displays the text with so wide pixels, that it does not fit on the screen. It extends beyond the right edge and wraps over to the left, clashing with the text there. So it is pretty difficult to use now. I am quite sure I messed up the whole geometry thing, so maybe have a look at my configuration files and tell me what to do better. Profiles_and_palettes.zip

I have built palette files from the information on wikipedia. To directly use the proper palette for each game, there are profiles for the various number of lines, but not for the horizontal clock speed. I set the profiles to tolerate quite a large clock speed difference to make them work for both PAL and NTSC consoles. The color palette to use is then only depending on the game cartridge.

[IanSB]

@c0pperdragon

There is also one problem: The RGBtoHDMI's menu overlay now displays the text with so wide pixels, that it does not fit on the screen.

Change the FB size to double height + width. That will double the screen area for the menu. With such a low horizontal resolution it might even be better to write two pixels in normal mode and four pixels in double width mode instead so I might look at doing that but selecting double width should improve things for now.

Do you have any idea how many cartridges produce non-standard lines per frame? (i.e. not 262 or 312)

[c0pperdragon]

Setting the FB size to double does not work correctly. When I do that, the colors all get wrong (in a vertical striped matter) and I can not fix it with changing the horizontal offset.

I do not know how many or which cartridges create a non-262 lines display. I just stumbled over two so far: Space Invaders (260) and Combat (263). Also the only PAL cartridge I have is Atlantis, which creates 312 lines. If you have any specific requests, I could download game roms for my home-made flash cartidge, as long as they are just basic 4K dumps and do not do anything funky with paging.

[IanSB]

@c0pperdragon

Setting the FB size to double does not work correctly. When I do that, the colors all get wrong (in a vertical striped matter) and I can not fix it with changing the horizontal offset.

I found a bug in the double width capture loop, try setting double size with this version: kernelrpi.zip

Also you should set the palette count to 128, not 256 (i.e. file2.write(bytes([128,0,0,0])) in your converter). This will enable variable intensity scanlines as they will use the other 128 palette entries for the scanlines. When scanlines are disabled, all 256 palette entries will be used, when scanlines are enabled the least significant luma bit will be forced to 0 and palette entries 128-255 are reprogrammed with scanline levels. Setting the palette count to 256 disables this behaviour and forces all 256 entries to always be used for the image with black scanlines only (This is used by the Atari 800 profile which does use all 256 entries)

[c0pperdragon]

This works nicely now. I set the doubling to horizontal so the onscreen menu looks good now. With a bit more tweaking of the geometry and using integer maximum scaling (will this be 5x on my 1680x1050 display ?) I have a very good picture.

Also the palettes now have this different value at the end (128 instead of 256) for proper scanline effect (which I personally never use). profiles and palettes.zip

I will contact a few people to get beta-testers to see if this works on NTSC machines as well as on my own PAL. I have good reason to think that this will work out of the box, but just to make sure.

[IanSB]

@c0pperdragon

This works nicely now. I set the doubling to horizontal so the onscreen menu looks good now. With a bit more tweaking of the geometry and using integer maximum scaling (will this be 5x on my 1680x1050 display ?) I have a very good picture.

I will probably need to tweak the profiles once I have a test system set up so that they produce good results for all resolutions, not just one. Also it might be better to use separate profiles for each of the four possibilities rather than all four in an auto switch folder. The reason for this is that when you use individual profiles you will always get a stable image even if the number of lines per frame doesn't match. Using an auto switch set will result in flashing screen if the number of lines doesn't match +-1

BTW Where did you get these palettes from?

I found some palette tables in this emulator: https://github.com/stella-emu/stella/blob/85f23044437a5da35d68f96045d363d0e339f872/src/common/PaletteHandler.cxx#L600

[c0pperdragon]

I would actually prefer to have exactly two profiles: One for 50Hz cartridges and one for 60Hz cartridges. When auto-switching, the color palette would directly match the intended look of the game developers. Is there a possibility to configure a larger tolerance for the line number (like 300 - 330 = PAL, 250 - 270 = NTSC)? Just like for the pixel clock?

[c0pperdragon]

The palettes were taken from this wikipedia page: https://en.wikipedia.org/wiki/List_of_8-bit_computer_hardware_graphics

[IanSB]

@c0pperdragon

Is there a possibility to configure a larger tolerance for the line number (like 300 - 330 = PAL, 250 - 270 = NTSC)? Just like for the pixel clock?

I am going to look at applying the existing clock tolerance value to the line number as well so e.g. 25000ppm tolerance would equal about +-7 lines on a PAL source and +-6 lines on an NTSC source but I need to make sure this doesn't break something else.

The palettes were taken from this wikipedia page: https://en.wikipedia.org/wiki/List_of_8-bit_computer_hardware_graphics

I couldn't see any 2600 TIA palettes on that page, only one palette each for CTIA and GTIA for the Atari 400/800

BTW I checked my Atari 2600 and it still works.

[c0pperdragon]

Sorry, I mixes this up. That page was where I take the colors for the upcomming TMS9918digitizer from. For game consoles therer is a similar page available: https://en.wikipedia.org/wiki/List_of_video_game_console_palettes

[tlindner]

Has this been added to a distribution yet?