JaF Sandwich - The Penultimate (possibly) Part

AI generated image of a man holding the JaF Sandwich

Some things really try my patience. And patience isn't something I have an infinite reservoir of in the first place. This here is one of those things. So let's recap. In part one I set out my reasons for wanting to add an RCA Jack to my JaF64 RF Modulator replacement. In part two I got a prototype of my new build, now renamed the "JaF Sandwich", to elegantly pass a LumaCode signal from the VIC-II-dizer out of this new RCA Jack. In Part three I got a second prototype JaF Sandwich to pass a Kawari Mini generated LumaCode signal out the newly added RCA Jack (with caveats - more below). And now, in part four, I will outline what needs to be done to get the JaF Sandwich to properly fit my C64C Case.

But first, my expired patience. And let's not beat about the bush - it's that damned Kawari Mini LumaCode that has me beating my head off the desk.

How much time is reasonable to expend on trying to get this to work? My answer to this question is always, "until it stops being fun". Now, my issue is NOT with how the JaF Sandwich deals with this - that actually seems to work perfectly - my issue is with hours and hours and hours fucking about with voltage settings in the Kawari Mini and in the RGBtoHDMI to get a good picture on my TV and basically getting nowhere.

I can get good Sync, I can get accurate color, but I absolutely cannot get rid of both the shimmer (i.e. the picture literally wobbling in areas of high contrast with certain - not all - color combinations) and the noise. I can get rid of the shimmer but that adds more noise to certain colors. I can get rid of the noise in those colors but that either brings back the shimmer or adds noise to different colors and believe me, I've tried. In the last entry I prepared a video which adequately demonstrated the noise issues as they stand, both with recommended settings, and with my own adjustments). As nothing I've yet tried has improved on this, the same video is presented again in the event you want to see (warning, there is no audio and it's just a capture of me scrolling through different background, border and text colors to demo the noise. 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):



In his Discord channel, Randy has said:

"Are the errors always on the left edge of a character?   Where jail bars would be?  If so, it's the switching noise from the transceivers [in the Kawari].  Maybe try fiddling with the sync level?  You could try a 100hm resistor instead of the 120 and adjust the levels up slightly."

Looking at the noise I'm getting, it does indeed seem to be where jailbars would be. Changing my voltage divider to use a 100 ohm resistor would give me scope to raise the voltage even more, which might be enough to remove the noise completely. It's definately worth a try, but in all honesty, I'm exhausted with this for now.

It is definitely no longer fun. So, with a very heavy heart I need to put this aside. Let's look at the facts:
  • The generation of LumaCode in the Kawari Mini is experimental and, to all intents and purposes, unsupported. For good or ill, Randy (the developer of the Kawari) has no interest in making this an official feature by, for example, adding dedicated headers to a future board revision and when asked replied "I don't have plans on modifying the PCB anyway". Its use also cripples some of the additional features of Kawari Mini that offer higher than standard resolutions.
  • It is too laborious to force a good picture from the RGBtoHDMI and the Kawari Mini voltage settings. There is way too much messing about with voltage settings to make this a viable proposition for the masses.
  • There only appear to be three people on the entire planet (as far as I can tell from Randy's Discord) who have even attempted this and there is little in the way of help/support.
  • Even if I could have gotten it working perfectly, who's to say my settings would work for anyone else? When a 0.01v change can make a visible difference to picture quality, I worry (because I fundamentally do not understand Ohms Law)  that voltage settings are so sensitive even different resistors of the same brand I'm using, with slightly varying tolerances will affect the outcome.
So that's it for me. I'm done with Kawari Mini LumaCode for now. Like I said, my JaF Sandwich seems to work just fine so I'll leave the voltage divider resistors and the isolation jumpers as part of the JaF Sandwich design for future experimentation, but anyone following along should note: until further notice, that part is caveated to hell and back until someone much smarter than me can figure out some standard settings that will just work without all that fucking around (don't hold your breath). This is very disappointing. Randy has advised that using a 100 ohm resistor (in place of the 120 ohm resistor I'm currently using) in the voltage divider on the JaF Sandwich might help, but this is a job for later. Much, much later.

Anyway, with that out of the way, I can finally talk about fitting the JaF Sandwich into my C64C case.

Probably worth stating now that I neither know, nor care, if the JaF Sandwich will fit in a breadbin case. I won't be attempting to use one, so for me it's moot. I also need to state emphatically that I have no idea if the JaF Sandwich will work on any other C64 board except the 250466 SixtyClone. I have two of these boards, one for testing and one as my daily driver. That's all I need or want so this has never been tested on anything else. So. If you're looking for an answer to whether this may work for you, the answer is a comprehensive "no idea".

Eagle eyed readers may have noticed a liitle something in part three of this series. If not, here's the picture again:

JaF Sandwich Prototype #2 properly mounted

That is a photo of my Revision #2 Prototype board actually mounted on the 250466 and my reproduction C64C case (ignore the black and red wire, that's the case LED cable). In order to get this to mount correctly, I had to design a notch in the top right corner of the board. This accommodates a protruding case clip. As you can plainly see, that issue is now solved. There is now an aesthetic issue with the protruding pin header at the bottom left of the board. This is where the VIC-II-dizer can connect with a custom built cable. Obviously it's not meant to protrude like that so I'll push it back a few mm in the next (and hopefully final) version of the board. What remains is the positioning of the RCA Jack. Here's how it looks now:

Available dimensions around the RCA Jack


RCA Plug from RGBtoHDMI fits through case hole, just.

As you can see, the Jack is right at the top of the hole in the case. Horizontal positioning is perfect so that's something at least, and in this position I am in fact able to connect the RCA cable that came with the RGBtoHDMI so it all works. But it's too close for comfort, it looks silly and a different cable may not fit at all. So, here's what is going to happen:
  • The RCA Jack will be removed from the top board
  • A third, small daughter-board will be created, 1.2mm thick.
  • The RCA Jack will be attached to that daughter-board
  • The daughter-board will be soldered directly to the underside of the top-board.
  • This will position the RCA Jack 1.2mm lower than at present.
The daughter board will look like this:

3D image of daughter-board

Notice the 4 castellated holes (aka Plated half-holes). These castellations serve two purposes: 
  1. I will use them to solder the daughter-board to the top board.
  2. Carry LumaCode and GND signals from top-board to daughter-board.
The top-board will then be redesigned, removing the RCA Jack and replacing this with 4 pads, on which the daughter-board will be soldered. Oh, and it'll need a hole to accommodate the solder tangs of the RCA Jack protruding through the daughter-board or it won't fit:

Solder pads on base of top-board

3D mock-up of top-board and daughter-board in position

Now, I didn't want to go down this whole daughter-board route because it's a bit of a bastard. It's awkward and adds considerably to the overall cost. But, because I see no other choice, this is a practical solution. Though whether 4 large castellated holes is better or more secure than lots of smaller ones I have no clue coz I'm no engineer (if that wasn't completely obvious). I'm going with 4. I can think of no other sensible way to lower the RCA Jack.

So, with those changes implemented, it's back to waiting for a delivery from China again.

The castellated holes for the daughter-board increase production costs somewhat. At a minimum order of 5 PCBs you're looking at approximately $5.20 per board.

The redesigned top-board with matt black solder mask and ENIG gold also has a unit cost of approximately $13. Costs can be reduced to just $1 per board with standard options. The bottom board is similarly priced, but I haven't ordered these in matt black and ENIG gold yet until we see if this design works.

All in, and including parts, I'm looking at a unit cost of approximately $40 per sandwich, which even I can admit is a ludicrous price.

Moving swiftly on. In the next instalment (due early 2024) we'll see if these changes work as planned and whether the JaF Sandwich becomes my new permanent RF MOD replacement.


Popular Posts