How to connect Commodore c16

[bisvu]

dear experts, what would be the recommended way to connect c16 video signals to rgbtohdmi/analog and which profile/settings to use ?

video

modulator

[IanSB]

@bisvu

The commodore 16 generates PAL or NTSC chroma within the TED chip similar to the VIC chips on the c64 and VIC20 and that is too noisy to do pixel perfect sampling so it would require a lumacode board similar to the ones for those machines.

Unfortunately it doesn't look like that would be possible at the moment, see: https://github.com/c0pperdragon/LumaCode/issues/8

[bisvu]

Thank you Ian for the hint, I was afraid that this would be a long shot for the C16. Still, there are at least separate chroma and luma signals available - how to connect these to the analog board, with the understanding that pixel perfect sampling cannot be achieved ?

[c0pperdragon]

I have revisited the possibility for a C16 lumacode adapter (the "TEDdigitizer"). Work is progressing nicely, but the one main issue is how to squeeze the necessary data through the single cable following the lumacode standard. For the most straight-forward solution, every pixel (7 bits color depth) would need 4 samples which would require 28.6 Msamples/sec. By packing the data tighter (7 samples for every pixel pair), we could get down to 25.03 Msamples/sec. This is also too much for my taste because the Atari solution is already at the very limit with its 21.4 Msamples/sec.

So my latest idea is to stretch the data transmission over a larger part of each video line. With some buffering I could directly use the Atari sample rates (the C16 has the exact same pixel rates both for NTSC and PAL). Then I would have to use the time that is normally consumed by the back porch (including the color burst) as well as slimming down the front porch. After some tinkering, I have these horizontal timings: Total samples/line: 1368 Sync: 100 samples = 4.66us Black level: 50 samples = 2.33us Active: 1204 samples = 56.06us Black level: 14 samples = 0.65us PAL timings are a tiny bit longer.

@IanSB Do you see any reasons why the RGBtoHDMI could not handle such a signal? Is there some required delay after the sync before pixel data can be processed?

[IanSB]

@c0pperdragon

I think it should be able to cope with that. There does need to be a small delay between the end of sync and the first readable pixel but it is the order of a few samples so 50 samples should not be a problem.

[c0pperdragon]

@IanSB As I am now pretty much done with the TEDdigitzer but can only display 64 colors for now, I would ask if you could implement the aforementioned 7 samples / 2 pixel decoding. I would imagine to encode the two pixels (a6-a0) and (b6-b0) in the following manner:

1. Sample = a6 & b6 (a6 being the more significant part)
2. Sample = a5 & a4
3. Sample = a3 & a2
4. Sample = a1 & a0
5. Sample = b5 & b4
6. Sample = b3 & b2
7. Sample = b1 & b0

And if you could also fix the decoding of "palette_control=10", as there all bits are reversed which is quite a hassle when creating/checking the palette (for NES and for the Master System). No need to implement the color emphasis bits for the NES for now. With "reversed" I mean the bit order is reversed, not the individual bits.

[IanSB]

@c0pperdragon

OK I am working on that now