This purpose of this page is to describe my attempts to get a good HDMI Picture from Randy Rossi's Kawari Mini, a modern replacement for the VIC-II chip in the Commodore 64. Please note, I am NOT talking about the large variant of the Kawari which can output an HDMI (well, DVI) signal natively. I am specifically talking about the Mini variant, which until recently could only output Luma and Chroma.
Now before you begin ploughing through this please be aware: everything here is experimental. Nothing has yet been proved to be repeatable so regardless of the process, values and settings outlined here, it is unlikely you will be able to replicate precisely.
Right. Here goes. In order to accomplish this, we need 6 things:
- The Kawari Mini (obviously)
- An RGBtoHDMI decoder
- A Raspberry Pi Zero to make the RGBtoHDMI work
- Some sort of hardware with a voltage divider (more on this below)
- A micro SD card for the RGBtoHDMI software
- The Experimental firmware for the Kawari Mini
You would be well advised to do a lot of research on all of this before doing anything else. There are different types of RGBtoHDMI and the online documentation is extensive and by no means simple or crystal clear.
For starters then, you need to get reading:
- Kawari Mini LumaCode (Experimental) documentation on GitHub. The page proves that it is possible to get an HDMI signal via the Kawari Mini and provides the principle of what I'm attempting to achieve. Here you will see how Randy incorporates the necessary voltage divider, however, I am trying to do this in a much neater way. No hacked up sockets here. More info below.
- RGBtoHDMI full documentation on GitHub. Best of luck.
For absolute clarity, as far as the RGBtoHDMI is concerned I bought:
- RGBtoHDMI Mono & LumaCode board by Reinhard "c0pperdragon" Grafl. This does not need the additional Analogue board to work for my purpose. Another variant of the RGBtoHDMI might. You have been warned. If you have no idea what I'm talking about then you haven't read or understood the RGBtoHDMI documentation.
- Case for RGBtoHDMI also by c0pperdragon. A 3D Printed case to protect the electronics.
Note: if like me you are based in the UK, c0pperdragon no longer ships here from his Tindie store. It's not stated why. I assume this is because of post Brexit import/export issues but that is my supposition based on my own grim experience trying to ship to the EU and I'm not running a business. c0pperdragon's Tindie page links to a list of alternative vendors. That page, in turn, links to this SellMyRetro page. At time of writing (28th July 2024), the RGBtoHDMI mono and lumacode board, the case, and the VIC-II-dizer ARE NOT AVAILABLE on that site. This may simply be because they are out-of-stock. However, if you are struggling to obtain these, and c0pperdragon's Tindie store DOES have stock, you could use a third party freight forwarding company (I've successfully used myGermany before), buy direct from c0pperdragon on his Tindie store, and simply swallow the massive financial hit freight forwarding will incur. If you are UK based you do have options, for a price.
Ok. Let's assume you have all the hardware, and you've read up on everything. Assuming you have, nothing from here on will be a mystery. We are creating a chain of components:
Kawari Mini (producing LumaCode)
|
Voltage Divider
|
RGBtoHDMI (converts LumaCode to HDMI)
|
HDMI Socket on TV/Monitor
As explained in Randy's Kawari Mini LumaCode GitHub page, the LumaCode coming straight out the Kawari isn't quite up to snuff. Before the signal can be fed into the RGBtoHDMI the signal must first be fed through a Voltage Divider (just a pair of resistors connected to a source of 5v and GND (Ground)). Randy achieves this by hacking together a Frankenstein's monster of socket, wires and resistors. On the other hand, I have done this by incorporating the two resistors into my RF Modulator replacement board, called the "JaF Sandwich" and just using the existing circuitry on my 250466 mainboard to get the LumaCode signal to the JaF Sandwich. Both methods do exactly the same thing; my method is just way neater, though to be frank, neither method will suit everyone (* see note in bold below). Randy advises one of these voltage divider resistors should be 120 Ω (but I had to change this - keep reading). The other should be 75 Ω.
*Let me be absolutely clear here. Nothing here will be possible unless you are prepared to put in a lot of work finding a way to incorporate that voltage divider. I am in the fortunate position of having designed and had manufactured my own PCB (an RF Modulator replacement) which can easily accommodate this. I fully appreciate that it is highly likely that you don't, and it's equally likely that you don't want to implement my design, and very probable that you don't want to hack up sockets and solder in wires and resistors either. However, the plain and sad truth is that without something to undertake this function, you will never get off the ground. This simple fact alone will almost certainly prevent mass take up of this method, if not kill it stone dead. Harsh, but I'm sorry to say, fair.
Regardless of how you get there, once the hardware chain above is complete, you must then install the necessary experimental firmware into the Kawari Mini, and load the correct software for the RGBtoHDMI onto a micro SD card. You will then be ready to start attempting to get a good HDMI signal from the Kawari Mini.
To achieve this, you will need to adjust LumaCode settings in both the Kawari Mini AND the RGBtoHDMI. This is the gruelling part.
The Kawari Mini settings are adjusted in the Composite Settings Editor (called COMPED). The RGBtoHDMI settings are adjusted in the Sampling menu. If you don't know how to access either of these then you haven't done your research and honestly, you've no business attempting this.
In the Kawari Composite Settings Editor (COMPED), initial setup defines Luminosity (Lu) with the following four values:
- 00
- 1c
- 30
- 3f
These four hexadecimal values control the voltage levels for the LumaCode encoding. These are the default and our starting point. NB: these values are repeated another 3 times in the Lu column in COMPED. You can ignore these additional entries. Only the 1st four are used.
The next step is setting up the RGBtoHDMI. In his LumaCode GitHub page, Randy specifies the Sampling Settings he successfully used:
Setup Mode: NormalSampling Phase: 3 (180 Degrees)Half Pixel shift: OffClock Multiplier: x6Calibration Range: AutoPixel H Offset: 6Sync Edge: TrailingSync on G/V: OffSample Mode: 6 Bits (4 levels)75R Termination: Off <- NOTE this is different than Vic-II-dizerDAC-A: G Hi : 138 (1.79v)DAC-B: G Lo : 119 (1.54v)DAC-C: RB Hi : DisabledDAC-D: RB Lo : DisabledDAC-E: Sync : 067 (0.87v)DAC-F: G Mid : 129 (1.67v)DAC-G: R Mid : DisabledDAC-H: B Mid : Disabled
This is all well and good, but I happen to have a different version of the RGBtoHDMI, and by default mine is set to a YUV color model whilst Randy's is set to RGB. I could change mine to RGB but I figured I didn't actually need to: looking carefully at Randy's settings he has specifically set:
- G Hi: 138 (1.79v)
- G Mid: 129 (1.67v)
- G Lo: 119 (1.54v)
- Sync: 067 (0.87v)
- Everything else is disabled.
I know from reading a conversation here, that it's the Green channel (abbreviated to "G" in the RGBtoHDMI menus) that the RGBtoHDMI variant Randy is using requires for the LumaCode. Now let's look at how my Sampling Settings look (values shown are my initial adjusted values):
Setup Mode: NormalSampling Phase: 3 (180 Degrees) <-- NOTE I copied Randy's valueCalibration Range: AutoPixel H Offset: 15 <-- NOTE I changed this from 6 to suit my TVFilter Y: OnSubsample UV: OffPAL Switch: OffSync Edge: TrailingLevel Type: 4 Lvl Y, 3 Lvl UVSync on Y/V: OffSample Mode: 6 Bits (4 levels)75R Termination: OffDAC-A: Y Hi : 139 (1.80v)DAC-B: Y Mid : 130 (1.68v)DAC-C: UV Hi : DisabledDAC-D: UV Lo : DisabledDAC-E: Sync : 067 (0.87v)DAC-F: Y Lo : 119 (1.54v)
The menu items are obviously not the same. I don't have a Green channel. In my variant of the RGBtoHDMI, LumaCode is on the Y channel. But in this instance, G (for Green) and Y (for Luminosity) are carrying the exact same LumaCode signal and the RGBtoHDMI is doing the exact same thing (i.e. decoding) with them, so:
- Y Hi in my menu is the equivalent of G Hi in Randy's
- Y Mid in my menu is the equivalent of G Mid in Randy's
- Y Lo in my menu is the equivalent of G Lo in Randy's
- Sync is the same
- Everything else is disabled.
So, I ran with this and used Randy's values as my starting point. As you can see from the screen grab below, these settings did result in a picture with accurate color (which isn't nothing!), but that picture was filled with noise, so I simply experimented from there until eventually - many weeks later (I cannot stress just how long this took in sporadic sessions between, you know, having a life), I had values which kinda worked. However, nothing I could do would eliminate all the noise in the video signal completely.
On first use, with Randy's settings duplicated, yellow was one of the colors demonstrating particularly bad noise. Here's a screen capture to illustrate:
Now, a blind man could see that there is an obvious regularity to some of this noise. What's this all about then? Well, in his Discord channel, when discussing this Randy has provided some illumination:
"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 100ohm resistor instead of the 120 and adjust the levels up slightly."
So I want to see if the noise I'm seeing is as Randy describes: from the transceivers in the Kawari - whatever the hell they are - it's not necessary for me to know so I don't care to put time into the research.
In order to work this through, the first thing I did was overlay some vertical bars on the screen grab above, which I could then paste over other screen grabs just to see if the position of the noise I'm seeing there corresponds to these same vertical lines. My simple logic being that any noise corresponding to these lines can reasonably be ascribed to the same cause.
First off, that's pretty damn convincing - observe how the worst of the noise is definitely in perfect columns to the left edge of the characters. There is however some other noise, scattered randomly that is not so clearly defined.
As stated above, with my revised settings in COMPED and in the RGBtoHDMI, I managed to remove most of that noise, and it should be noted that the most significant change I made to accomplish this was to adjust the Luminosity values in COMPED to:
- 01
- 18
- 2c
- 3f
With my revised settings, yellow is cleared up almost completely but I still had noise associated with other colors and I want to confirm that the noise is aligned to the same columns:
As you can plainly see, with my revised settings the noise is much diminished but there are scattered dark dots with this green background and it's not so obvious that this is associated with the same columns. I can now easily check, by overlaying my vertical lines:
That's an almost perfect correlation. Let's try another color with noise. Scattered across this purple background are some blue dots:
And again, if I overlay the lines:
It's clear that once again, we have near perfect correlation. So with this, I managed to convince myself that the vast majority of the errors I'm seeing are indeed due to the switching noise of the transceivers in the Kawari and so the next obvious step is to replace the 120Ω resistor in my voltage divider with a 100Ω resistor, as Randy suggested, which will allow me to raise the voltages a little more, potentially enough to eliminate these artefacts. The major downside of doing this is it essentially takes me back to scratch and I will have to spend an inordinate amount of time adjusting settings in both COMPED and in the Sampling menu in the RGBtoHDMI. And honestly, it's a fucking chore.
CHANGING TO A 100 Ω RESISTOR
However painful, if I want to see this through then there is no other choice but to try this with a 100 Ω resistor instead of 120 Ω. This time though I'm going to be a lot more evidence based about the reasons I have set every value.
With the 100 Ω resistor in place, switching on returns us to a rolling, unsynchronised screen. This is to be expected.
In the RGBtoHDMI Sampling Menu I firstly raised the Sync. A steady picture was achieved at 070 (0.90v). Higher makes no difference, lower loses sync.
Still in the Sampling Menu I then concentrated on the Y-Hi, Y-Mid and Y-Lo settings and after two hours of trial and error found the settings with accurate color rendition. There was still a lot of noise though. At this point I played with the Sampling Phase which I had simply left at the same settings Randy recommended, i.e. 3 (180 degrees) and not given it much thought. Only now did it dawn on me what this actually is - it's the settings for an 8 bit Analogue to Digital Converter (ADC). I know what that is but I have NO clue how it works. However I noticed as I scrolled through the 8 settings that 4 (180 degrees) gave a much better picture than 3 (180 degrees) and figured the revised voltages must have something to do with the correct setting required here. Incidentally, I found the auto calibration of the Sampling Phase in the RGBtoHDMI completely ineffective.
I then used COMPED to fine tune the settings a little more. This gave me the cleanest picture yet achieved, but some color channels still have noise and this is the point where i must get specific. If I do not record reasons for specific adjustments then I simply get lost on the path.
So far then:
In the RGBtoHDMI Sampling Menu:
Sampling Phase: 4 (180 degrees)
Y-Hi: 153
Y-Mid: 145
Y-Lo: 134
Sync: 070 (0.90v)
And in COMPED:
- 02
- 1c
- 2b
- 3f
Using COMPED, I scrolled through all 16 background and border colors and gave each of these a letter, A through P, and within that, all text colors, numbered 1 to 16 and took a note of any problems from every combination. Thus A1 = black border and background with black text. A2 = black border and background with white text, C6 = red border and background with green text. This makes dealing with a large dataset easier. If this sounds laborious that's because it was.
I ended up with 16 tables and all problematic combinations annotated. For example, here's one table (a check mark means no problems):
H (Yellow border and background) - no noise in border and background.
- H1 - bad shimmer
- H2 - ✓
- H3 - slight shimmer
- H4 - ✓
- H5 - ✓
- H6 - ✓
- H7 - bad shimmer
- H8 - X (yellow text not visible on yellow background)
- H9 - ✓
- H10 - bad shimmer
- H11 - ✓
- H12 - bad shimmer
- H13 - slight shimmer
- H14 - ✓
- H15 - ✓
- H16 - ✓
Once I had all 16 tables, I then went back to the tables which had the most problems. And took a note of what I had to do to fix it. As I did this I started to notice a pattern. A lot of the shimmering I was seeing was mitigated by reducing Y-Mid from 145 to 144.
So, I reduced Y-Mid from 145 to 144 and went through every combination again, and made another table, noting the results:
- A - all text stable
- B - B1 still shimmers
- C- all text stable
- D - NEW: scrolling noise in border and background
- E - all text stable
- F - no change: F1, F3, F7, F10, F12 and F13 still shimmer
- G - All bad shimmering fixed. G6, G8, G11, G14 and G16 still slight shimmer
- H - all text stable
- I - I1 and I10 still shimmer
- J - J9 still shimmers
- K - no change: K1, K3, K7, K10_still shimmer
- L - NEW: Noise in border and background
- M - NEW: Noise in border and background
- N - no change: N1, N3, N7 and N13 still shimmer
- O - O10 still shimmers
- P - All text stable
Doing this I can see categorically that reducing Y-Mid introduced Noise into Cyan (D), Dark Gray (L) and Gray (M) but, it reduced a lot of the shimmer in text throughout. I can also see a very distinct pattern in noise that remains.
If I raise Y-Mid again, I will get rid of noise I've introduced but I will be back to square one with shimmering text. First however, I wanted to see if I could reduce the shimmering still present - so went back to the combinations with the worst issues and took note of what I did to fix it and again I noticed a pattern. Reducing Y-Hi to 152 from 153 had an immediate effect.
So I did this and, once again went through every combination and noted the results:
- A - perfect
- B - noise in B8 - can be fixed by raising Y-Hi back to 153.
- C - perfect
- D - scrolling noise in border and background. Can be fixed by lowering COMPED 1c to 19.
- E - perfect
- F - perfect
- G - perfect
- H - some noise in border and background - can be fixed by raising Y-Hi back to 153 or lowering COMPED 2b to 2a.
- I - I1 and I10 still shimmer. Can be fixed by raising COMPED 2b to 2c
- J - perfect
- K - perfect
- L - noise in border and background. Can be fixed by raising Y-Mid back to 145 or lowering COMPED 1c to 19.
- M - same as L
- N - perfect
- O - I10 still shimmers. Can be fixed by lowering COMPED 1c to 1b.
- P - P2 still shimmers. Only fix is to raise Y-Hi back to 153.
Now after working through all this I noted that lowering COMPED 1c to 19 could fix some more issues, but yet again needed to note what effect this would have on everything else, so yet again, I made the change then went through every combination and noted the results:
- A - perfect
- B - noise in B8 - Only fix is to raise Y-Hi back to 153.
- C - perfect
- D - perfect
- E - perfect
- F - perfect
- G - perfect
- H - noise in border and background - Only fix is to raise Y-Hi back to 153 or lowering COMPED 2b to 2a.
- I - I1 and I10 still shimmer. Can be fixed by raising COMPED 2b to 2c but that creates problems with H.
- J - noise in background and border and with J1. Can be fixed by raising COMPED 19 to 1a, but that reintroduces scrolling noise to in D.
- K - perfect
- L - perfect
- M - perfect
- N - perfect
- O - perfect
- P - P2 still shimmers. Only fix is to raise Y-Hi back to 153.
Now we're getting somewhere. There really are only a small number of specific combinations still exhibiting noise. Of the 5 remaining issues:
- For 3 of them the only solution is to raise Y-Hi back to 153 but doing that re-introduces all the text shimmer I got rid of above so that's a no go. Nothing in COMPED fixes it.
- For one of the remaining 2 issues, fixing Brown (J) by raising COMPED from 19 to 1a re-introduces scrolling noise to Cyan (D). So that's a no go.
- And finally if I raise COMPED 2b to 2c I make the noise in Yellow (H) worse. If I lower 2b to 2a I remove the noise in H but make the shimmer in Orange (I) worse. The only compromise is to leave it alone where neither are awful. It's the least worse option.
And there we have it. It's not perfect, but there is not one damn thing left that I can do which will improve it from here. Unless the program I'm running has a lot of yellow I barely notice the worst of the persistent issues. In watching demo's and games I can also spot the odd pixel flicker especially when black and brown are in close proximity. In general however, and these established issues aside, picture quality is outstanding. I have NO clue how these problems can be resolved. It's clearly something to do with the voltages coming from the Kawari Mini but that's way beyond me.
Relevant RGBtoHDMI Settings now at:
- Sampling Phase: 4 (180 degrees)
- Y-Hi: 152
- Y-Mid: 144
- Y-Lo: 134
- Sync: 070 (0.90v)
COMPED settings now at:
- 02
- 19
- 2b
- 3f
DEMONSTRATION
Here is a simple video demonstrating the output from the Kawari Mini (using the above settings) in comparison to the VIC-II-dizer (with settings out-of-the-box). Every 20 seconds the video alternates between the two sources. Demo used is Wonderland XII by Censor Design. Captured via OBS. Editing done in DaVinci Resolve (only cutting the video together - no adjustments to resolution or color have been made).
OTHER ISSUES
In addition to everything above, I experimented by removing the 75 ohm resistor from the resistor divider, and instead turned on the 75R setting in the RGBtoHDMI Sampling Menu which emulates the same thing. The effect of this was that every setting would require re-adjusting. Sync was re-acquired by raising it from 70 to 72. Noise in every color indicated I would have to go through the entire process above again which I was not prepared to do so the actual resistor went back. However, it does lead me to suspect that even slight variations in resistor tolerances will throw everything out and so by using the Kawari Mini, not only do you have to create your own hardware, you will have to divine your own, unique settings.
CONCLUSION
Do I call this a success? Well, it sure as hell ain't a failure, but it's heavily caveated and I cannot, hand-on-heart, recommend it unless you love experimenting with this stuff. I found it all pretty brutal and soul destroying most of the time, after the initial enthusiasm waned and it was only sheer bloody-minded determination that got me to this stage.
I stand by what I said above: I can't see very many people at all going through all that, and as Randy has advised me he won't be making any changes to the Kawari Mini design going forward (e.g. by adding a dedicated header for LumaCode with the voltage divider resistors incorporated) then the need to bodge the necessary hardware together yourself is a step too far. Further, the fact that the firmware to enable this is likely to remain an experimental fork, and the LumaCode function not incorporated as an option in the normal firmware will just add more complications down the line. It won't get updates and there is no trivial way to just return to normal usage without re-installing a different firmware and resetting the whole device. All in, getting LumaCode from the Kawari Mini is a mighty pain in the ass.
I have heard gossip, and I stress it's all second hand with nothing confirmed by the developer, that there might be a new Kawari which just produces LumaCode. If that is indeed the case, that is the obvious long term and most satisfactory solution and we can dispense with all this nonsense.
