Thoughts on a different way to connect a C64

[c0pperdragon]

@IanSB

While my C64 component video mod is actually working nicely with the RGBtoHDMI, the new Kawari project that implements a complete VIC-II replacement got me thinking. I envison a slimmed-down version of the Kawari that would directly fit into the VIC-II socket and just works as a normal VIC-II generating the luma/chroma signals without any additional interfacing options and relying on the original C64 circuitry to get the video signal out through the A/V port. While this seems disappointing at first (still nothing better than s-video), it would allow for a very interesting possibility:

Support an output mode where the luma signal changes at double the pixel clock and sets the output to 1 of 4 different luma levels (chroma is completely silent to not introduce disturbances). Combining two values gives 16 different color possibilities. This can then be fed into an external RGBtoHDMI which does it usual magic to again get pixel-perfect HDMI.

The one question on the RGBtoHDMI side of things is how to receive 4 different luma levels. I am not totally sure I understand the analog board schematics, but it seems that there are three comparators on the green input that could do this. To also the the sync tip, I would probably have to connect the ASYNC input to the green input line in the cable. If my assumptions are correct, the RGBtoHDMI could be easily made to accept the proposed signal, but I guess it would require some progamming on your side. I also could rather easily modify my component video mod to generate this signal to test this approach.

If this works out, I would propose the whole scheme to the developer of the Kawari board.

[IanSB]

@c0pperdragon

This should be possible. As you noticed, there are 3 comparators on the green input already so no need to fit U7 on the other side of the board. One of the comparators can be configured either to do sync separation or increase the number of levels of green/luma that can be discriminated to four, however once in this mode it can't do sync separation.

The workaround as you suggest is to connect both the green input and the sync input to the source and then you will have four level discrimination with sync separation as well. One potential problem with this is that you might get reflections on the cable with such an arrangement so you would have to keep it short. Alternatively the green/Y cable could be looped back into the 6 way IDC in place of the sync cable.

If you prototype this in your existing adapter you could see what it looks like using the attached profile: C64_LumaCode_50Hz.txt This should have everything setup correctly for double rate 4 level capture but I haven't been able to test it. You will need to set the DAC levels correctly for Sync, Ylo, Ymid, Yhi (note Yhi>Ymid>Ylo) and once you have the levels set and run the calibration you can check for noise (calibration should show 0 errors if the signal is clean)

If you screencap the result you should be able to view it zoomed in on a PC to manually decode the pixel pairs to see if it is working. The palette is the Y test palette which has the following colours: 0=Black 1=Green 2=Yellow 3=White

It would require a new capture mode similar to the Atari one to decode this profile.

[c0pperdragon]

Thank you for this profile. I have set up everything as you specified, and it is working flawlessly. The simple color sequence produces just the expected half-pixel colors:

There was no need to change my RGBtoHDMI hardware setup, as I had already hard-wired the analog board to a TRRS jack with the Y input going to both the G and SYNC lines. So this a very nice proof of concept. Of course my signal source is now extremely clean. I can not really guess what would happen with a regular Kawari install that feeds the luma through the original C64 amplifier.

With me having a bit too much time in lockdown here in Vienna (yes, one lockdown yet again) I really consider designing a VIC-II replacement myself. As I specified above, I want to use a form factor identical to the VIC. This is a really hard squeeze and I am not sure if I will be able to actually build this, using BGA packages and all... Just in case, it would be better to not use the name "Kawari" for this C64 profile in the future (given that you want to eventually include it in the official release). Something more generic like "C64 Semi-digital or C64 single-wire" could work.

[IanSB]

@c0pperdragon Yes that looks clean, but as you say it really depends on what it looks like when it's passed through the original C64 luma video path as that is double the bandwidth it's expecting.

I called the profile C64_LumaCode_50Hz for now.

[IanSB]

@c0pperdragon If you have an unmodified C64 you could route the signal from your board (on another C64) through it's video path to see if you get a noise free result.

[IanSB]

@c0pperdragon Do you intend to pursue this any further?

If this works out, I would propose the whole scheme to the developer of the Kawari board.

Have you suggested this to the Kawari developer?

[c0pperdragon]

not yet. but feel free to contact him yourself.

[c0pperdragon]

I have given the whole topic more consideration. What I now intend to build is a downsized variant of my C64 component video mod. This should combine all necessary parts into a board that goes under an existing VIC-II (which is still necessary to drive the system, just like before). But it would then generate the discussed luma-only signal exclusively. The original signal paths of the VIC-II (digital as well as analog) would be completely unaffected by this and work as before. The newly generated luma signal would be brought out of the C64 through the re-purposed RF output jack. This could even be possible without soldering, by just cutting the RF output wire and attaching the new signal with a clip.

By the way: I did not find an official way to do feature-requests on the Kawari, also there is no e-mail address of the developer easily available.

[c0pperdragon]

Of course all these plans are purely theoretical by now, and I don't expect the necessary semiconductor parts to become available soon...

[c0pperdragon]

I have worked a bit on this topic and I could design a board of the same form factor as the pickup-board for my original component video mod. It will support the luma-coded signal exclusively and I dropped even the video amplifier. As it turns out, the FPGA can quite comfortably drive the video line directly using only a few resistors. I also built a simple cable to bring the signal from the RCA jack to the 6-pin analog board.

Lacking actual hardware, I modified one of my component video boards which can now only output this specific signal, so it is of not much other use currently. @IanSB , maybe you could look into implementing the necessary sampling code in some time? I would be very grateful. The encoding I use is specified in this table: lumacode.ods I specified an encoding for all the colors in a way to make the average luma of both half-pixels to roughly match the brightnes of the corresponding C64 color. So you can directly plug this signal into a TV and get a kind of grayscale image.

Using the current RGBtoHDMI firmware with your provided profile gives a super-stable image showing the half-pixels.

[IanSB]

@c0pperdragon

Try this:

LumaCode-Alpha1.zip

Install the latest stable release then overwrite kernel.img with the one in the zip and add the C64_LumaCode folder to /profiles/6-12_BIT_YUV_Analog

Use the YUV CPLD and select the C64_LumaCode profile. You will probably need to adjust the voltage levels and also the Pixel H Offset in the sampling menu (to get the lo/hi bit order correct).

This is mostly untested as I don't have a way of producing the required signals.

[c0pperdragon]

Wow! That was fast! It worked immediately after calibrating just the voltage levels without touching the Pixel H Offset:

For my purposes I then increased the minimum vertical size to get more overscan for use in demos. Specifically the "Edge of Disgrace" demo - which could be considered the gold standard - is perfectly aligned now. C64LC_50Hz.txt

Many thank for the quick implementation.

[IanSB]

@c0pperdragon

C64LC_50Hz.txt

Are you sure you posted the right file as that one is the same as the original.

[c0pperdragon]

Silly me. The saved profiles of course go to the folder "Saved_Profiles". So now, this should be the correct one: C64LC_50Hz.txt

[c0pperdragon]

@IanSB

Hi Ian! As I currently can only do theoretical work on the matter, I came up with yet another possible thing concering the C64. I guess it would be also a nice option to allow an internal installation of the Pi, similar to what we did on the Amiga. As this would cause more current draw on the PSU and also some extra way to route the HDMI cable out of the case, I consider this as the advanced option. But not as advanced as de-soldering the RF modulator as for my original component mod. As this would not require any specific hardware on the Pi side of things, it would also be cheaper, I guess.

For this to work, my FPGA board (which goes under the VIC) provides a pin header for a 6-wire ribbon cable that carries: pixel clock, csync, lum0, lum1, GND and connection to a 3.3K resistor.
I imagined that it would be possible to connect this cable to pins 11 - 16 of the Pi where most of the relevant inputs are already located in one spot. Power to the Pi should come through the USB power plug. I am not sure about pin 13 (genlock?) and pin 15 (analog?) which I did not use on the Amiga adapter. Maybe they can indeed be used as pixel data input when configured correctly? If yes, there would surely be some coding necessary on your part.

One other open question here is how this ribbon cable should best be attached to the Pi. Normal plugs can not be put on a longer header because they mechanically interfer with the pins on the side. One option is of course cutting way these pins on the Pi (would also prevent later miss-alignments of the plug), but I would not recommend such a destructive treatment. Maybe you have some better idea here?

[c0pperdragon]

I have released a new firmware (2.11) for the C64 Component Video Mod. This now exclusively creates the LumaCode output when switched to its RGBtoHDMI mode: https://github.com/c0pperdragon/C64-Video-Enhancement/releases/tag/2.11

Your recent RGBtoHDMO beta release already contains the decoding logic for the LumaCode and it works fine after again adjusting the voltrage levels. Instead of my previous confiiguration file which was adjusted to my experimental hardware, this now has different levels on my original hardware. I will try to also use these levels for future developments, so minimal adjustments should later be necessary. C64LC_50Hz.txt

It would be great if you could include this in future stable relases.

[c0pperdragon]

I can not currenty proceed with my intended C64 luma-code solution, so there is no hurry to integrate the luma-code profile to the stable official release. But I guess, I will be able to come up with a cheap - and more importantly - easy install that repurposes the RF-out jack of the C64 to produce this signal at least at some time in the future.

To not confuse the matter unnecessarily, I have withdrawn my 2.11 firmware, for the C64 Component Video Mod, so the latest 2.10 will just generate the well-established high-contrast YPbPr signal to be fed into the RGBtoHDMI.

[c0pperdragon]

I found an easier way to build the cable from the RCA plug to the 6-pin analog board input. Using a standard 6-wire ribbon cable, I made wire 2 a bit longer and wire 4 a bit shorter than the rest and bent over wire 2 before clamping everything together. I guess the picture should expain this a bit better.

In this way there should not be too much reflection on the sync input. Works really nicely.

[IanSB]

@c0pperdragon Yes I have made up cables the same way and it is better than using separate wires for the same signal

Will you be looking at the C64 luma-code again sometime?

[c0pperdragon]

Yes, I am designing a new board for the C64 to generate the luma-code signal from the digital VIC pins. It will be just as big as the pick-up board of my original component video mod. The FPGA will directly fit on this. Maybe I can just run a single wire from the FPGA to the RF output jack, but probably I need to also have a shielding ground on this as well. Installation will be solderless by inserting the board between VIC and its socket and attaching the output wire to the RF jack using a clip. The only destructive thing would be to cut the original wire to the RF output.

Unluckily FPGAs are still not available. I decided to go with one specific FPGA that is small enough but still has enough pins and logic cells to do the job. When I first looked, this had a delivery date from mouser for April. But when I was finally sure that this would be the right part, everything from this batch was already preordered and now I placed my order for a July batch.

This whole contraption will deliver luma-code only besides the original analog signals. So the RGBtoHDMI + analog board (or something with equal capability) will be mandatory to use it.