Mucking around on the....C64/MCL64/Kawari combo

[mrbombermillzy]

As anyone may have recalled if they were following @rubber_jonnie s 'box of delights' thread:

viewtopic.php?p=132294#p132294

I am now - other than gratefully indebted to him - in possession of a C64 which has had some 'mad scientist' style upgrades to the HW as well as a repaired DTV... amongst other things.

I have been keeping a low profile, as I have had some personal problems going on (which have affected me mentally for sure), but I decided to take my mind off things by carrying on with some projects.

Originally, I resumed my tinkering on the DTV and was slowly coming up to scratch with achieving code parity between the code in VICE emulation and the real DTV (as there were -and still are - a few niggling differences). Here is one of the earlier tests from my 'Mucking around on the DTV' thread on a 'real' DTV:

P1050192.JPG (313.54 KiB) Viewed 138 times

However, that didnt last long before some wires decided yet again to part ways with the board.

In this instance, im guessing the micro movements made when holding the power switch firm to turn the thing on and off after a while caused four (yes 4!) wires on the inner side of the switch unit to become unattached:

BEFORE:

P1050194.JPG (291.18 KiB) Viewed 138 times

AFTER:

P1050195.JPG (276.07 KiB) Viewed 138 times

So anyway, not currently having the flat surface area to attempt a repair (and clearing the desk being a low priority at the time, with all else that was happening) I decided to have a bit of a more in depth look at the other C64 machine, with its onboard goodies, which I will now describe in more detail, although do bear in mind that I am still learning about them both, so some of the details may actually be inaccurate or plain wrong - apologies in advance.

Specifically then, this old breadbin of mine has been modded with a CPU booster;

mcl64.png (544.42 KiB) Viewed 138 times

the MCL-64-mini, that on full acceleration is claimed to be twice as fast as the CMD Super CPU unit.

The CPU has 3 modes of operation:

Mode 1: Is 'regular' mode and should behave as a standard 6510 should. From the impression I got from @rubber_jonnie s experiences with running software, I was in the mindset that the unit would be - especially when paired to the other 'non standard' VICII - pretty flaky and crash often.

However, testing it in mode 1 at least, I found it to be pretty much like a regular C64. The only thing that would cause trouble is some demoscene custom loaders, wouldnt work. I am pinning this problem on the Pi1541 device Im using with it rather than the CPU, but for a definitive answer, I really need to break out the real 1541 to test for sure.

With that said, plenty of hardcore demos worked, some didnt. Anyway, its a good start in my opinion.

Mode2: From what I gather, the CPU has onboard RAM that it can obviously access far faster than system RAM, so it uses that instead, only writing through to the slower C64 RAM for better compatibility with the VIC chip, as that cant see the onboard fast RAM. (ST folks think, about the blitter and cache problems as a similar issue).

Mode3: This is the full acceleration mode and will only write though to the current bank of video RAM. It is also assumed the VICII will keep the same (currently active) bank.

So there we have it... plenty of tinkering options to be had with the CPU booster here.

Whilst modes 2 and 3 could do with testing games/demos on, I will be focusing on what *I* can do with these modes, so its not so critical, as I wont be using it to boost legacy game speeds.

Moving on...



This upgrade has also been paired with the replacement VICII project created by Randy Rossi called the VICII Kawari:

kawari-large-side.png (213.93 KiB) Viewed 138 times

This VICII replacement has several enhancements over the original chips, including PAL or NTSC output (so at last the Americans can finally play all the PAL games and demos). It also has an 80 column text mode and of course, there is a DMA copy engine as well as a BLT unit present. All these can be accessed by exrta registers that appear in the memory map once a 'magic phrase' is poked into the relevant register enable location.

Several screen modes are available, including 320x200x4bpp and 640x200x2bpp bitmap modes.

The palette colours - whilst being limited to a maximum of 16 in the lower resolution modes - can also be changed to any colour from an apparent choice of 262,000 (18bpp) in RGB and theoretically* HSV (composite video) colour modes.

There is also a choice of composite, analog RGB and HDMI (well actually HDMI compatible DVI) modes available, so plenty of scope for nice crisp displays, or chroma noise inducing CRTs - whatever you wish to use.

* Theoretically, as in practical terms, a luma value below a certain threshold will cause display problems (i.e. blanking) on the display device. (See the further posts below for more details).


Thats the blurb covered. Testing/tinkering to follow soon...

[rubber_jonnie]

Good to see you getting on with your projects

The damn wires are a pain hence why I put hot glue on the main pcb but the power socket could do with beefing up.

Any time you need anything re-doing just shout, happy to help.

[mrbombermillzy]

Thanks Jon.

My plan is to leave well alone until I have a case to house it in. Only then will I repair the wires, so there will be no further movement, as the unit is securely housed with absolutely no movement to the wires.

If it all somehow continues to go horribly wrong, I may request your services again.

[rubber_jonnie]

If it all somehow continues to go horribly wrong, I may request your services again.

And I'll be happy to help

[mrbombermillzy]

Composite video and the Kawari

I thought I would elaborate a bit more on the asterisk (*) in the first post to explain what I meant by not having a full 64 value luma range.

From the KAWARI POV, dealing with the composite video Luma/chroma/amplitude levels seems quite limiting. e.g. setting the luma level below a certain threshold (<12/$0c) causes the screen display to become quite unstable:

Here the luma value of 12/$0c for colour 14 is as low as we can go:

P1050209.JPG (281.05 KiB) Viewed 98 times

...before things start to crumble....

P1050210.JPG (316.5 KiB) Viewed 98 times

...and by the time that we reach luma value 0, its a real mess. (Nice distortion effect on the colour bar though. Perhaps a future demo? :

P1050211.JPG (345.05 KiB) Viewed 98 times

Therefore, although 64 luma levels can be set, in practice - on my LCD Sony Bravia 24" TV anyway; (Im unsure if a Sony BVM would fare any better) - only around four fifths of that (51 out of 64 luma levels) is usable. At this stage, Im sure its just an issue with composite video signals in general that cause this, rather than any fault of the Kawari, but Im open to any arguments to the contrary.

So with the above limitations in mind, why bother with composite video mode at all?

Well, to back track slightly, I was full steam ahead working hard on the 256 colour DTV version of my game engine until that suddenly fell apart (literally). So having made the exodus over to the Kawari, I have found the 16 colour palette to be a tad limiting in trying to recreate a similar graphical experience.

Spurred on by Randi Rossi's picture display demo where he changes the 16 colour palette every scanline, I am therefore experimenting with the Kawari to see if anything can be done about this. Im sure I can come up with something... you just have to keep reading this blog to find out for sure!

Anyway, back to the subject in hand...why bother with composite video?

From the perspective of fast colour changes, it seems that the HSV/composite colour system is perhaps more versatile than the RGB colour system, in so far that the actual colour can be changed to any desired colour - albeit at the same luminance level - by changing the colour phase. This value is a single byte and the 360 degrees are interpolated into the 255 available values. This equates to 256 different colours; but at the same luminance and amplitude level.

The equivalent colour change on the RGB colour system takes three byte writes to effectively change the colour. Although this allows full control then over the 18bit/262,000 colour palette range, its 3 times slower to change. Hence I will investigate what can be done with the phase, luminance and possibly amplitude values first.

More to follow soon.

[mrbombermillzy]

As a quick demonstration (before I get into anything serious again), heres a simple copper bar style effect demo with 256 colours on the C64 (with the borked TFT screen; apologies) and a seasonal message to boot:

P1050213.JPG (254.99 KiB) Viewed 65 times

As the demo says, a Merry Xmas to all on Exxosforum! I hope you all have a great Christmas time.

(Hope its not too early? )

[exxos]

Cool ! Pretty sure thats 8 colours though

[mrbombermillzy]

Cool ! Pretty sure thats 8 colours though

Actually, its a very reduced set from an estimated 204,000 possible colours, with the same brightness/luma and intensity/amplitude from a comp vid signal.

The colours are incrementing phase on a horizontal axis (rather than per scanline or more), so the colour graduation is a bit more compact and repeats more often.

[exxos]

Actually, its a very reduced set from an estimated 204,000 possible colours, with the same brightness/luma and intensity/amplitude from a comp vid signal.

Impressive stuff anyway !

Maybe we need a xmas tree smack now instead of the chair one Wonder if AI can do it

[mrbombermillzy]

Maybe we need a xmas tree smack now instead of the chair one Wonder if AI can do it

Sounds appropriate.