JaF Sandwich - Part the Third

It strikes me now, and I'm pretty far down the line, that this particular project will only be of use to a very small number of (discerning) readers. Specifically, those with an interest in the Commodore 64, that also have a Kawari Mini VIC-II replacement, that also have an interest in getting LumaCode from that Kawari Mini, that also have a 250466 motherboard in a reproduction C64C case, that are also willing to remove or replace their existing RF Modulator/Replacement and who can also wield a soldering iron. I'd hazard that number is so vanishingly small in fact that it won't reach double digits. However, as always, this project isn't really for anybody else. I just want to see if I can do it. As ever, I'm merely explaining things as I understand them - that may be a very different thing from being correct or accurate. And remember: you undertake these things at your own risk. If I mess this up, it's only me that's responsible. Same goes for you.

So, this is the third in an ongoing series of articles dedicated to redesigning my JaF64 RF Modulator replacement, now renamed the JaF Sandwich, to accommodate an RCA (phono) Jack and getting maximum use from that. To recap, in Parts One and Two I detailed my plans and outlined all the problems I've encountered so far. We ended part Two with perfectly functioning prototype, producing a clean, noise free HDMI image generated from C0pperdragon's VIC-II-dizer board. However, that first prototype didn't fit in the C64C case, and it hadn't been attached to the Kawari Mini. Now two out of four ain't bad, but all we've done is crossed off the easy parts from the to-do list. The tricky parts are still to come.

Here in Part Three, I'm going to try and tackle getting LumaCode from the Kawari Mini and I have lots of question marks as to how this is going to pan out.

Let's get specific.

I'm pretty confident I understand my hardware requirements (remember much of this is unique to me - nobody else in the world has a JaF Sandwich):

1. With a new firmware, the Kawari Mini will generate LumaCode and output this on its Luma pin (pin 15).
2. This LumaCode will travel from that Luma pin, down the existing copper on my 250466 board to my JaF Sandwich.
3. There I will use both the 5V and GND signals which are already on the JaF Sandwich, together with two newly added resistors which act as a voltage divider, to adjust the LumaCode signal to better meet the required specifications.
4. That adjusted LumaCode signal will then travel on to the RCA (phono) Jack on the JaF Sandwich, and out of the case to be processed into an HDMI signal by the RGBtoHDMI converter.

I'm 75% certain all of that will work. My one doubt is about point 2 being effective. The Commodore 64 mainboard is notoriously noisy, by which I mean circuits aren't necessarily properly isolated and can literally interfere with each other. I'll need to find a way to test for that. However, at least I can test for that (NB: anything I describe here will only be relevant to my 250466 board. Other board revisions may have differing circuitry so I offer no guarantees about anything working for anybody else, ever). What I'm less certain about is the software adjustments that will have to be made to allow a picture to appear. It is entirely probable, dare I say certain, that on first setup, any picture I get will be noisy and corrupt. Why? Well everything I've learned about this comes from Randy Rossi's experimentation outlined here. And whilst it's not explicitly stated, I'm surmising that the voltages being generated by this version of LumaCode, despite being adjusted by the voltage divider, still aren't quite right and will require further "tweaking".

There are two places this tweaking will need to be done. And this is what is going to make this part of the process arduous, if not downright painful.

In the first instance, we will need to use the Sampling Menu in the RGBtoHDMI to adjust some settings in there. And if that doesn't properly work, we will need to edit the LumaCode configuration in the Kawari Mini itself. So, to be crystal clear, there are 3 things that may cause an issue with the picture: noise in the 250466 luma line, unadjusted settings in the RGBtoHDMI, and unadjusted settings in the Kawari Mini.

Everything I'm doing here is 100% experimental. It's absolutely not fit for general release and with my extremely limited knowledge, I am categorically not the best peson to be beta testing this. But given that I'm in the position to be able to when very, very few others will be, and I kinda/sorta understand what's going on I might as well give it a go and see what happens. It might be of use to someone at some point.

First things first - I need to install the trial LumaCode firmware on the Kawari Mini. This can be found here. If or when I need to return to a normal firmware, I will probably have to revert to shorting the reset jumpers to get a normal s-video signal back. I already have a record of all my settings from the config utility so returning them back is a non-issue. Oh, and because I've made no mention of it until now - this mod will prevent the use of some of the Kawari Mini's extended features (80 column mode etc) as their resolution is not supported by this mod). One really does have to weigh up the pros and cons of all this. And remember - we've not even thought about the lack of audio that will result. This is a real irritation and if nothing else, resolving that means yet more expenditure and additional cables to add to the considerable rat's nest already going on around my machine. I don't know how I feel about that yet. Will improved picture quality really justify all this?

Anyway, with the new firmware installed, and LumaCode activated, on the screen I now see the expected greyscale picture (if you don't know why that's expected, you didn't click the link to Randy's experimentation above.)

Now I switch off the C64, unplug the S-Video cables, set all the jumpers in my newly configured (and cost reduced!) JaF Sandwich Prototype No. 2. Then plug in the RGBtoHDMI via the RCA Jack. Setting those 3 jumpers isolates the Kawari Mini's LumaCode from everything else on the board, preventing the original electronics interfering with the LumaCode voltages. It also directs the LumaCode through the voltage divider resistors and towards the RCA Jack. When I'm finished with this test I will need to reset all these jumpers back to the standard position. Whilst far from ideal, jumpers are quick to design and implement and very effective. What it's not, is particularly easy to just switch between one output and another but then I'm sure we can all agree everything about the Kawari Mini LumaCode process is, if not quite half assed, definitely not easy.

JaF Sandwich Lower Board incorporating Kawari Mini LumaCode circuit

JaF Sandwich Upper Board showing Kawari Mini LumaCode circuit to RCA.

Completed JaF Sandwhich installed on 250466 SixtyClone board

From this point, switching on will just display whatever the Kawari Mini LumaCode is generating via the RGBtoHDMI. Let's see what happens when we flick the switch.

The answer, as one might expect, was an unsynchronised rolling mess.

What followed was two days - and I'm absolutely not kidding here - I must have spent 10 hours over two days tinkering with voltage settings in both the RGBtoHDMI and the COMPED utility in the Kawari Mini trying hundreds and hundreds of different settings until eventually, and to my great amusement I actually got something approaching a colorful picture.

Now before we start popping champagne corks and setting off fireworks, I've not yet found the sweet spot. I still have a lot of noise in some (not all) colors, and anything with high contrast and certain color combinations (again, not all) is a shimmering mess. When I say shimmering, I mean the picture literally wobbles. This is not useable. But it's close. Tantalisingly close. And it's close enough that I can say some things with confidence:

• There doesn't seem to be electrical interference coming from the 250466 Luma line - I assume that would be something obvious and persistent across all combinations. There's plenty of noise, but not of that type.
• My revised JaF Sandwich appears to work perfectly in all planned functions - as a normal RF Mod replacement for S-Video; as a throughput for the VIC-II-dizer LumaCode; and to level up and output the Kawari Mini LumaCode. The fact that there's an issue getting a good picture via Kawari Mini LumaCode does not seem to be because of the JaF Sandwich in any obvious way.
• Using the RGBtoHDMI in YUV mode clearly works.

Below is a video (warning - there is no audio) which is by far the best way of demonstrating all the video noise issues. The first half of the video shows the noise issues with Randy's initial recommended settings, and the last half shows the noise issues remaining after I've implemented my own settings. If you're going to go to the trouble of watching this, best to do it in full screen and make sure quality is set to max or else the noise I'm trying to demo is disguised by compression artefacts.

I am absolutely not going to get into the rabbit hole of how the RGBtoHDMI Sampling Menu works, other than to say that these settings directly affect the voltages generating the LumaCode and they are extremely sensitive. For example, if I move DAC-A from 139 to 140 (so going from 1.80v to 1.81v - a 0.01v change), the screen fills with noise. There isn't much latitude between a steady picture with accurate colors and one which is filled with noise and rolling. Using different combinations of the Lu settings in the Kawari Mini and the DAC settings in the RGBtoHDMI one can fine tune, however by solving problems with one color, you can inadvertently introduce problems in another. It's a laborious and frustrating experience exactly as predicted. As my picture still isn't correct, as stated, there's still a lot of fucking around with these settings to do. Oh joy.

However, for the purposes of this article, I'm calling it a triumphant success. The JaF Sandwich was designed to pass the Kawari Mini LumaCode out of the machine without any messy hacks. It does this perfectly and so, of my four criteria, three are now met:

1. Accept the existing video input signals and output normal composite and S-Video signals as it currently does.

2. Support a Lumacode signal from a VIC-II-dizer and output this through an RCA (phono) Jack. This will categorically be a different approach from point 3.

3. Support a Lumacode signal from the Kawari Mini and output this through an RCA (phono) Jack. This will categorically be a different approach from point 2.

4. Fit on the 250466 mainboard and C64C case without any modification.

In the next article in this series, we'll look to see how well the JaF Sandwich fits on the 250466 board, and my C64C case and what, if anything needs to be done to make it 100% fit for purpose.