Roadmap

[c0pperdragon]

@IanSB
I wanted to outline here my intention on further development concerning Lumacode upgrades. As the RGBtoHDMI project is basically the thing that holds this all together, I wanted also to mention the challenges for this project in the future. Please feel free to join the discussion.

1. Next Lumacode boards?
   I am currently working on a board for the Nintendo NES to output Lumacode through its fairly obsolete RF output jack. Installation will be a bit more involved than on the C64 and will require soldering. But it will not be as difficult as the NES-RGB which requires desoldering of the PPU.

After that I consider the setup to be actually complete. There are some computers that are possible candidates, but I decided againts them for the following reasons:
Atari 7800: The MARIA chip has a higher color depth as is feasible to support with Lumacode. Also it is very rare and very badly documented/reversed engineered.
Commodore C16, Plus/4 with their TED chip: Basically the exact same reasons as for the above.
Sega Master System: It has a straight-forward 6-bit RGB-palette and each channel has just 4 different voltage levels that are directly available at the video output port. So I guess an RGBtoHDMI with fully populated Analog board should very well be able to handle this.
Intellivision: The graphics chip of this machine already exposes the color & sync as a set of 5 digital lines. So it is fairly easy to tap into this and drive a digital RGBtoHDMI. Also, without socketed chips any mod would require some soldering anyway, so you can as well use the method already proposed at https://github.com/hoglet67/RGBtoHDMI/wiki/Cables#intellivision-4-bit-ttl .

2. HDMItoSCART
   Due to request from users who want to get RGB-quality analog signals from various computers to show on high-end CRTs, I decided to provide an adapter for that converts HDMI to SCART-RGB. Besides its original purpose to allow the RGBtoHDMI to drive 15kHz CRTs this can also used to have emulators on Windows or Linux to do the same thing. I am not sure yet about the possible problems to get various emulators to generate the necessary output resolution, but I did manage to get it to work with WinUAE. Other emulator's developers may need some encouragement to support this hardware ;-).

3. RGBtoHDMI
   Due to future discontinuation of the CPLD, some RGBtoHDMI boards will need redesign. From my perspective of course, the Mono & Lumacode board is of special importance. I really count on Ian here ;-)
   Maybe this is a good opportunity to implement audio support as well. I still consider an "RGBtoHDMI Pro" variant (6-pin analog & 16-pin-digital & audio in) as a convenient option for many users.

[stanstrup]

Would genesis/mega drive be possible?

[c0pperdragon]

The resolution and color depth of the genesis is a bit too much for lumacode. Also this machine already produces RGB natively which an be upscaled with standard devices pretty well.

[stanstrup]

Thanks for the answer. I run my mega drive through retrotink and even if it is good, it is of course not pixel perfect without blurring like my c64 is now "outputting" a clean 4K signal :)

[tocksin]

Is there any plan for expanding Lumacode to include metadata in the video stream? I was thinking you could send a packet of data right after releasing the sync signal in the blanking area. This could be palette information, or resolution, or maybe include audio data. Even if you have 8-bit color, you could send the data over multiple lines, and it would only take 1 frame to transmit the whole palette. You could then have automatic configuration of the receiver or even switch video modes on the fly. Perhaps periodically refresh the data in case the receiver gets reset or misses a transmission.

With RS-170 composite, you have a 4.7us back porch which even at very slow 200 pixels per line would be 68 bits which should be plenty. For example, you could have a short data identifier right after the sync which describes the data type. Then a variable packet after that. And maybe a short CRC at the end for verification.

I have to image at some point the RGBtoHDMI or other receivers will include audio out support, so it would be very convenient to embed it in the Lumacode video stream. Even if the transmitters don't support it now, they might at some point. One or two bytes of audio per line (63.5us) would max out the audio at 15.7kHz, but that would be fine.

[c0pperdragon]

This is way to complex for my taste. Basically like how HDMI was super-imposed on DVI.
My main intention is to make the minimum viable solution to get digital video from vintage machines. So most of the heavy lifting is actually done by the RGBtoHDMI. I will never do anything about audio in the lumacode standard. Upscalers may or may not be able to integrate this in the HDMI stream, but this is a topic entirely independent of lumacode.

I could imagine that there is a need for auto-detecing the lumacode signal type when having multiple machines that use the same upscaler. Specifically when these machines are connected through a YPbPr-switchbox maybe with auto-switching functionality. Maybe the sync signal patterns are already different enough to at least in theory allow this autodetection. I need to check for that.

[tocksin]

I would think the metadata would be optional for transmitters and receivers. You could have no metadata and it would work just fine. Or just the transmitter could have it and it would still work fine. You wouldn't have to implement any of it yourself - you are just defining the standard. You wouldn't even need to define the metadata types - you'd just define what the format is and let other people fill in the types of data they want. If other people come up with useful features, then they can be pulled into the standard. I see Lumacode as having a lot of untapped potential.