Unless you've been living under a rock for the past couple of years (or have zero interest) you have probably heard of the VIC-II Kawari, the brainchild of Randy Rossi, and, as the name implies, a modern replacement for the venerable VIC-II chip found in Commodore 64 computers.
 |
| The VIC-II Kawari Mini (Rev 1.4) |
A few years have passed since the project got off the ground, and the global chip shortage delayed things by another year. But in late 2022, the design finally went public and on 23rd November '22 I was able to bag one myself. 42 days later (yes, 42!) after spending the whole of December sitting in Royal Mail's Heathrow Worldwide Distribution Centre (thanks for the wait guys, really appreciate it) I finally took delivery on the 4th January '23.
 |
| Kawari Mini (top) |
 |
| Kawari Mini (base) |
Randy has a bunch of YouTube videos outlining why he wanted to build the Kawari, and the curious should definitely check those out. It's a remarkable piece of work.
There are presently 2 versions of the Kawari available to purchase, the Large, and the Mini. As you can tell I bought the Mini version and that's what I'll be concentrating this article on. I bought this from VGP. The total cost to me was €98.34 (about £85.62 or $107.32) including shipping.
So, at its most basic, what we have here is a straightforward replacement for the VIC-II. Theoretically, I can simply remove the 6569R5 in my SixtyClone board, slot the Kawari in its place and the latter will pick up where the former left off. Theoretically.
Without putting it anywhere near my beloved SixtyClone I can already tell you it isn't going to be as simple as that. If this comes as a surprise then you clearly haven't read any of my other posts. We'll return to the complications in a moment. So much for the basics. What else does the Kawari offer?
Let's copy a little list from Randy's Github page, for ease and brevity:
- No 'VSP' [Variable Screen Placement] bug
- Configurable color palette (262144 RGB color space, 262144 HSV color space)
- No need for a working clock circuit
- Can software switch between NTSC and PAL-B
- Optional NTSC/PAL-B hardware switch
- Four chip models supported (6567R56A, 6567R8, 6569R1, 6569R3)
- An 80 column mode and new graphics modes
- An 80 column Novaterm driver
- Some fun 'extras' to play around with
- It's not an almost 40 year old device that may fail at any time
 |
| Jumpers and Headers on the Kawari Mini Rev 1.4 |
 |
| Jumpers and Headers on the Kawari Mini Rev 1.5 |
Of most interest to me, beyond the quest of having a Commodore 64 with all new parts, is the ability to software switch between NTSC and PAL and I really want to learn to play with the fun 'extras'.
But let's return to the complications.
You may recall, in this post, I installed a SaRuMan SRAM, which replaced the two original DRAM chips. You may also recall, that this only worked when I used a 6569R5 VIC-II chip. I had serious problems using my 6569R3 chip. Now, cast your eyes back across Randi's list of features above and see if you can spot a problem? Did you spot this:
- Four chip models supported (6567R56A, 6567R8, 6569R1, 6569R3)
That's right, the 6569R5 isn't amongst this list and consequently, we can be pretty damn certain if I was to insert the Kawari into my SixtyClone, with the SaRuMan, it isn't going to work and sure enough, a quick first test proved this to be true (frozen screen, no cursor, random characters scattered across the screen).
Luckily, I am so late to this particular party, that this issue has cropped up before and Randy has written an alternative firmware to address this issue. So yeah, I'm going to have to install that, before I can do anything else.
So how do we install new firmware?
Easy. First we need to remove a jumper from the board. This is a safety feature - we don't want to make it easy for any nefarious rapscallions creating software which may deliberately (or inadvertently) brick our board. These jumpers are extremely small by-the-way - 3mm tall. Not much bigger than a grain of rice (replacements here).
 |
| Jumpers on the left are for determining whether NTSC and PAL use the onboard oscillator or the oscillator on the C64. Jumpers on the right are for locking/unlocking Functions and Preferences. |
Next, download the firmware d64 files (there are 5), pre-mount them all in my pi1541 and run. And obviously we'll remove the SaRuMan and put in original DRAM chips to get all this to work. Clearly.
The firmware installed on the Kawari on arrival was version 1.5. The fixed firmware was 1.6 (and I have since upgraded again to 1.14). The process took about 10 minutes and went without issue. I replaced the jumper after completion.
 |
| Updating the Kawari Mini Firmware |
One restart later and checking the configuration proved the install was successful. I then put the SaRuMan back in my machine. It worked, and running a few demos went without issue. Phew. So far so good.
The next thing to address was the colours. Out of the box the colours looked ok, but not quite right. In a recent YouTube Video, TheRetroChannel (Mark Sawicki) went into this in some detail and the long and short of this is our Kawari video output signals aren't quite right. Now that is something that may be addressed in a future firmware update which we can perhaps expect later this year (2023). However, in this video Mark also gave some suggestions as to the Composite Video settings changes he made to improve things somewhat (based on the output of the 6569R3). This operation is done in one of the utility programs (Composite Settings Editor) Randy has produced and available here.
I initially copied Mark's settings exactly and the result was definitely an improvement over the stock settings. However, and this is very much a matter of taste, to my eye some of the settings didn't please me. I spent a good long time playing with these till I got something I was happy with. I very much doubt there is a standard setting everyone will like though; this is too subjective and comes down to each individual's unique taste, hardware, etc. For example, I intensly dislike the standard light blue colour generated by the 6569, it's got too much red in it so it pleases me greatly to "fix" this.
Something else I noticed, which is very interesting: jailbars are very much reduced - not, I stress, eliminated, but very much reduced. As I played around with the settings I noticed I could minimise their appearance a little more, usually by increasing luminosity. I also saw what I can only describe as swimming static noise in some areas of solid colour, especially when the colour was heavily saturated - in Blue, Green and Purple for example, it was particularly noticeable. By obsessively playing with the values I was able to minimise this too.
After quite some time (and a lot of trying this and trying that), what I've ended up with is a unique colour palette that doesn't align with either my old 6569R5 or Vice or anything else really - it's a palette which I'm happy with and which works exceptionally well with my setup, while still feeling authentic.
For what it's worth (and serving as an aide-mémoire), my settings are as follows (I will update this table as I refine my settings):
NB - According to the GitHub page, these colour settings are based on an 18-bit HSV (Hue, Saturation, Value) color space so the headings above translate to:
Lu = Luminosity = Value (i.e. brightness)
PH = Phase = Hue (i.e. colour type)
Amp = Amplitude = Saturation (i.e. vibrancy of colour)
Additionally, it's worth stating that although you can reset the chip values to original settings by pressing "J" for some reason this doesn't reset the Black Level or Color Burst values (update: seems fixed in latest firmware), hence why I have noted original values for reference. I wish I knew enough about this stuff to understand exactly what changing these values actually does to the video signal.
Of course, I had to try some of the special graphic modes. Mostly these work exactly as they should. The graphics in the 320×200 (16 colour) and 640×200 (4 colour) modes were perfect but the spinning Amiga Ball colour cycling demo, which is meant to be a bright red and white, looked way too dark to me - I figured out why this was however, and changed it to my satisfaction (see Fixing the Ball, below). Split screen works and once I figured out how to run it, the Racer80 demo works, as does 80 column mode (and is perfectly readable in s-video). In fact, so far every issue I've encountered to date (except the Amiga Ball thing which wasn't even a "fix" - it was behaving exactly as it had been programmed) I've tracked back to user error. All games and demos I've tried (from pi1541, d64 files) have worked perfectly. However, it's very early days and plenty of time to discover something more serious.
 |
| VIC-II Kawari 80 column mode |
Something I found when software switched to NTSC mode, which is simply a case of changing the selected VIC-II to one of the two NTSC versions (I chose the 6567R8): this initially seemed to work fine but I very quickly found that my pi1541 didn't work properly in this mode. I could use the browser (I'm using CBM Filebrowser V1.6 11x Turbo Pi1541 Edition) to find files, but they absolutely would not open and instead the machine crashed requiring a restart. However, if I instead mounted the file in the pi1541 (using the onboard buttons and NOT using the browser) and then used the standard, load and run commands this did work and I was able to rerun the config tool and change back to PAL mode. When I changed back to the standard CBM FileBrowser in NTSC mode, that actually worked perfectly so there must be a timing issue with the Turbo Browser and Kawari. Not really an issue, just a heads up. To date, that's as far, as my foray into NTSC land has gone - testing some games is on the to-do list.
I do know other people have had more significant problems - some GAL PLAs, specifically Lattice 25ns GALs, seem to be problematic, but so far I've not encountered any show-stoppers so I'll be keeping the Kawari in my SixtyClone and I won't be rushing to upgrade to the Kawari Mini's bigger (and HDMI equipped) brother anytime soon either.
Considering I am now running a C64 with all new mainboard components, CPU and CIA chips aside, and an RF Modulator replacement I designed and built myself, the fact these disparate parts are getting along together at all is impressive.
Having used the Kawari Rev 1.4 extensively (in PAL mode), there is only one significant flaw I've encountered, which IMHO prevents it from being perfect. On the Kawari Rev 1.4 there is no sensible way to get the onboard dot clock out (there is a hack available - see below - but it's really untidy). See, the problem here is that the dot clock on the motherboard, and the dot clock on the Kawari aren't mutually compatible. So, with this revision, if I don't set the Kawari jumpers to use the motherboard clock, I wouldn't be able to use any cartridges which expect to find the dot clock on pin 6 of the cartridge port: these would expect the VIC-II's (or in this case, the Kawari's) dot clock to be identical which it definitely wouldn't be if I used the Kawari's onboard clock - they would be out of sync in my native PAL and completely different in NTSC mode.
Revision 1.5 of the board resolves this issue by providing a dedicated header for the dot clock - please see labelled graphic above. This can be used in conjunction with a dedicated firmware which will output the dot clock to this pad and which can then be routed to the C64 mainboard.
My main concern here, incidentally, was that I wouldn't be able to use my Ultimate II+ L (UII+L) cartridge if I set the Kawari to use its onboard clock, as I assumed the UII+L would use the motherboard clock for some functions. However, according to Gideon Zweijtzer (the developer of the UII+L) in direct reference to this:
"At this point no features use it [pin 6]. And if it is ever used, it should be 8x the PHI2 frequency and be in phase, regardless of the actual pixel clock used."
So my initial concerns are allayed but I did have to invest in the new version 1.5 board to be fully satisfied.
This aside, I admit to becoming quite the Kawari fanboy. Together with the ARMSID I now have Commodore 64 with impressive configuration credentials. Though it must be said, another green board in my beautiful ebony SixtyClone does make me want to spew. How about some black PCBs Randy FFS! 😁
I saw someone posit the question, in relation to FPGA populated clones like mine, "Is it still a C64?" and it's an interesting point. I see exactly where the question is coming from. But. These FPGAs are programmed to communicate in exactly the same way as the original chips. The voltages flying in and out of the pins have to be the same and the timings have to be exact or it all falls on its ass. So whilst they are feature rich, that comes second to replicating the real thing. What we have here then is a C64 + Other Stuff, or simply: a "C64 Neo".
Fixing the Ball
During my testing I was puzzled to see that the Amiga ball demo looked very dark. I say puzzled because while watching Randy's YouTube video's his demonstrations always looked nice and colourful - the expected red and white spinning ball. But this is roughly what I was getting (looking closely the ball is actually dark brown and white):
After some extensive tests I was 99% sure that the Kawari was working perfectly and that the dark colours I was seeing was because of the code. So I dug into Randy's github page and found the assembly language (asm) file for the ball demo. Scanning through this I found these lines:
And on seeing these I realised exactly what was going on:
- Line 261 contains the 16 Luminosity Settings (Lu) in decimal.
- Line 262 contains the 16 Hue Settings (PH) in decimal.
- Line 263 contains the 16 Saturation Settings (Amp) in decimal.
The first values from each line 12,0,0 = Black
The final seven values from each line, 63,0,0 = White
Which leaves the remaining 8 values 24,80,5 = Red
I know it's Red I have a problem with so lets convert the Decimal numbers to Hex and then compare those values with the values for Red in my table above
Lu 24 = 18 Hex... Original Value 2a which I changed to 30 Hex (= 48 Decimal)
PH 80 = 50 Hex... Original Value 50 which I changed to 45 (= 69 Decimal)
Amp 5 = 5 Hex... Original Value 0d which I changed to 0e (= 14 Decimal)
Just looking at these numbers I can tell the Ball demo Red is indeed very dark Brown, with a luminosity of only 24 (vs my 48) and a saturation of only 5 (vs my 14) which would give exactly what I see.
So, if I change these 3 lines of code and on line 261 change every 24 to 48; on line 262 change every 80 to 69, and on line 263 change every 5 to 14, recompile the program and run it, I should see the Amiga ball with some nice bright reds. So, that's exactly what I did...
This now works exactly as I want it. Randy has confirmed these findings in the Kawari Discord channel and may update the downloadable demo. However, should you desire a copy of the version I prepared, you may download here.
A Note About Colours
As noted above, the colours from the Kawari mini are based on an 18-bit HSV (Hue, Saturation, Value) colour space. Theoretically this translates to 262,144 colours from which you can select (64 Luminosity Values (Hex 00 to Hex 3F), 256 PH Values (Hex 00 to Hex FF) and 16 Amp values (Hex 00 to Hex 0F). 64 × 256 × 16 = 262,144. However, in practise the actual number of colours you can select from is significantly lower than this. To explain why, we need to look at the Luminosity (LU) values in more depth:
Luminosity settings can be any Hex Value from 00 to 3F, that's decimal 0 to 63. Theoretically then, 0 should be pure black, 3F should be pure white and the remaining 62 values should be shades of grey. To test this I've taken a screen shot of all 64 luminosity values from my Kawari mini and charted them here:
- Everything from Hex 00 to Hex 1E gave a lightness value of 0. This means that of all 64 shades, the first 31 are pure black. In the chart above I omitted most of these.
- Hex 1F and Hex 21 both had a Lightness of 1.
- Hex 20 was back to having a Lightness of 0
- Hex 21 through to Hex 3B were shades of grey with a lightness gradient roughly as expected
- Hex 3C to Hex 3F all had a luminosity of 100 so are pure white. I only charted Hex 3C.
Some of this is no surprise. My overall Black Level, which can be adjusted via the Comped tool mentioned above, is set at Hex 19. This needs to be set here otherwise the Kawari video output voltages are too low - see the TheRetroChannel's YouTube video linked above. As such everything from Hex 00 to Hex 19 (the first 26 shades) should be black. What is a surprise however is that Hex 1A to Hex 1E and Hex 20 are also just pure black. This means that of the 64 available values, 32 of them, exactly half, are pure black. Additionally Hex 3C to Hex 3F are all pure white and again, I expected only Hex 3F to be white.
In reality then, with my black to white gradient starting at Hex 20 and ending at Hex 3C, I only have 29 luminosity values from which I can select, not 64. This means that in practise there are 118,320 available colours (29 × 255 × 16) and not 262,144. Once again, this is not a complaint, just a statement of facts as I find them. And lets be honest, 118,320 is still a lot more than the C64's native 16.
Like what you've read so far? In my next post I write about the remarkable Ultimate II+L cartridge.
Total Cost Update
I decided not to include the total cost of designing my RF Modulator replacement, or the many pounds I spent resurrecting my damaged SixtyClone board as these definitely weren't a normal outlay. It could certainly be argued that neither is a WiC64 or a Kawari to be fair! However as my goal is to eventually have an all new Commodore 64, and given the necessity to test parts and accessories old and new against each other, it seems legitimate to add these costs. Someone else building a new C64 now, needn't incur the costs of buying both a regular VIC-II chip AND a Kawari for example, but I did.
So, as stated above, the total cost, including tax and shipping for the Kawari was £85.62 (or $107.32 or €98.34). This brings my grand total expenditure to:
£993.91, or $1,318.57 or €1,175.27 approx.
