Support for "LumaCode"?

[c0pperdragon]

Earlier this year, I came up with the idea of creating a proprietary video format to get digital video data from certain retro computers for further upscaling: https://github.com/c0pperdragon/LumaCode/wiki/Overview User feedback is pretty good but I guess for users already owning a OSSC, the mandatory RGBtoHDMI seems a bit overkill. So maybe you are interested in adding support for lumacode into the OSSC, as I guess this should be possible with the existing hardware.

[marqs85]

The idea is definitely interesting and could be supported on OSSC, but robust decoding of multi-sample codes would require horizontal sampling rate and phase to be adjusted accurately to avoid wrong colors / artifacts.

[c0pperdragon]

Yes, this will most likely require individual fine tuning, at least for the Atari 8-bit machines what need the highest data rate of all the supported computers. The C64 and and machines with lower data rate normally work out of the box without any re-adjustments. Just by telling the RGBtoHDMI that the source is in fact such a lumacode signal. Of course, I have no idea how to integrate such a feature into your user interface.

[Cod3N3rd]

Hi, Did you move forward with this? I just bought the ossc and took for granted that lumacode was supported.. (obviously wrong). Looks like lumacode got some traction, at least with atari 8-bit community, and it would be great to see it supported by ossc.

[marqs85]

This is not yet moved forward, unfortunately. I could create a test version for a configuration that already operates at 2x oversampling, but due to lack of suitable HW and time my debugging capabilities are currently limited.

[c0pperdragon]

@marqs85 If this helps, I could extend the firmware on my signal generator to support all lumacode patterns and just send it to you. So you would not have to get all those 1980ties machines and also Lumacode-enable them.

[marqs85]

Let me first create a test firmwared for you to try. If that doesn't work out, then test hardware with pattern generation could be useful.

[marqs85]

A test firmware can be now downloaded here. It is configured for C64 so the following settings should be applied:

Input: AV2_RGsB (RCA from C64 connected to green Y jack) 240p/288p proc: Line2x Line2x mode: 384x240 optim. H. samplerate: 504 for PAL C64, 512/520 for NTSC depending on VIC-II model Sampling phase: adjusted manually until colors correct and stable

[c0pperdragon]

This is totally awesome, that you start to integrate lumacode support into the OSSC. I very much think there is a huge number of existing OSSC users that would love to get this option. Unluckily I do not have an OSSC of my own (went straight to the RGBotHDMI option instead).

But I know of a few prominent users with a github account that have both an OSSC and a VICIIdizer. So maybe someone here can give this a try: @TheRetroChannel @JanBeta

I don't know if @randyrossi , who works on the Kawari (a VIC-II replacment for the C64) with possible support for Lumacode output does have an OSSC, but his input would also be very valuable.

[TheRetroChannel]

I don't have an OSSC, only the tink 5x. But I may be able borrow one to do some testing

[marqs85]

I don't have an OSSC, only the tink 5x. But I may be able borrow one to do some testing

That would be great. Let me know if the test firmware works as expected.

[TheRetroChannel]

@marqs85 Got my hands on an OSSC, but it looks like the above link is dead. Happy to test it out if you repost it

[marqs85]

The link works for me now, perhaps there was temporary downtime on the server.

[TheRetroChannel]

Alright, the download worked and I got the OSSC updated. It took me a little while as I didn't realise the new firmwares do not work with the older hardware versions - I think this one was 1.16. Anyway, did the hardware mod and got it all working. But the lumacode output is not working as expected. I can get it to sync and look almost right, but after messing around with the sampling phase and playing with the offset and gain settings I could never get a perfect image.

Here's an example https://youtu.be/UREFcGgG_vU

[marqs85]

Ok, so aside from sampling jitter the functionality seems to work. I'll need to see if multiplying the sample rate further could improve stability as the video ADC does not perform very well at low frequencies.

[marqs85]

I've updated the linked test firmware with some improvements, hope that helps.

[TheRetroChannel]

Thanks marqs85. The new firmware does seem to help with sampling. I can set the phase to 213deg and get a stable image, but the colours are wrong. Playing with the G/Y offset does affect the colours but they never end up correct. I don't know if that's a matter of swapping some palette settings of if that's another issue. Here's another quick video https://youtu.be/EMAyqLI3B1A

Cheers, Mark

[marqs85]

The file has been updated again, hopefully this time everything works. I also added an option under Video in proc where Lumacode now has to be explicitly enabled (C64 and Spectrum palettes are currently supported).

[TheRetroChannel]

Getting close!

Just the colours are slightly off, especially with red/brown/orange. Here's an example with the same machine, OSSC on the left, s-video on the right:

Note these were all done on a PAL C64 6569R3 (8 luma level) VIC-II with the following settings: Video in proc: Lumacode C64 Line2x mode: 384x240 optim. H. samplerate: 504 Sampling phase: 22deg

I'm not sure if there's a way to adjust the OSSC to output a 4:3 ratio in this mode, or if I just need to set my capture device to squeeze it back down - again I'm still learning my way around the OSSC.

I don't have Lumacode for the Spectrum so can't test that. I do however have both the older 5 luma level VIC-IIs for PAL and NTSC which I can test, the only major one I don't have is the 8 luma level NTSC VIC-II.

[marqs85]

I used color codes listed here but it seems order of orange and brown there are swapped. I fixed and uploaded the firmware again. You can try e.g. Line5x with 384x240 mode and 1920x1200/1600x1200 Line5x format to see if that results to more accurate aspect.

[TheRetroChannel]

Yep, using 5x with 1920x1200 looks about right. And orange and brown are now correct.

I think the overall colour palette could still use some tweaking. This one here is the most accurate I've found https://jamontoads.net/p/lumachroma.html (the hex values are towards the end of the page).

[marqs85]

The palette is now updated with those values.

[TheRetroChannel]

Finally got a chance to test out the latest update. It looks soo much better - thanks Markus!

For a comparison, svideo on the left, new palette centre, old palette right.

Of course they don't totally match the s-video output but that's likely more down to my settings with the tink 5x and subtle VIC-II differences. I think the new palette is a pretty damn accurate.

I'll do a few tests with other C64/128 and VIC-II combinations and report back shortly

[TheRetroChannel]

Alright, this probably won't come as a surprise to those familar with the C64 lumacode. It works with all PAL revisions - long and shortboard, and also works with PAL 128s. I cannot test NTSC as I only have the 6567R56A which does not work correctly with lumacode without a custom firmware from @c0pperdragon at least I assume this is still the case?

As for the rest of the NTSC stuff, I'm unable to test. I guess if we stick with the current palette then it may look a bit weird to NTSC users as the NTSC palette is a bit different. But all the best C64 stuff is coded for PAL so who cares ;-P

[marqs85]

The core functionality is now integrated in e49106b6358d86cf2e298a3943666a66909e67d1. Closing the issue for now. Support for other systems (like NES) may be added once color encoding details are published.