Well, “quest” is a little bit of an exaggeration. In reality, I had decided to stop thinking “I wish I had a PAL C64” as I had been for many years, and just get one.
For those who may not know, there are significant differences between the video standards of North America (NTSC) and Europe (PAL). These differences translate into incompatibilities between NTSC and PAL Commodore 64s with respect to what software they can correctly run, as each region had its own hardware designed with timings specific to the required video standards. Sometimes the difference is not important, but often it is. When developing my demo last year, I was keenly aware of this, and it can be a real challenge to write timing-sensitive code that works properly on both systems. You can read here for some technical details. But the bottom line is this: If you are using NTSC hardware, like I always have, you have limited support for modern software.
This isn’t a big deal at all if you are running C64 software in an emulator like VICE, but if you are like me, and have a penchant for CRT displays with old hardware, it really is a limiting factor. Why?
Most of the activity in “the scene” is going on in Europe, where they take advantage of the slower frame-rate and extra CPU cycles PAL-timing gives them.
And frankly, when it comes to retro computer and gaming hardware, there really is no substitute for a genuine cathode ray tube display. Which means: if you want to be able to run a variety of software, especially new software, you need to get a Commodore 64 that was sold in Europe.
I found a seller in Italy who was willing to part with a nice-condition C64C. He took the time to properly pack the unit in an amply over-sized box. I paid for express shipping, and he sent it promptly. About a week later, this arrived at my door.
The box had obviously been set in water and soaked up a lot of it. The USPS claimed it arrived to them in that condition. I was surprised it even made it to me — the shipping label practically fell off when I took the paper masche, I mean box.
It had also taken a bit of a beating. The seller sent me several pictures and video before shipping the box, so I know it was intact when it left, but at some point, in addition to getting soaked, it also got slammed hard enough to knock a key off despite all of the packing.
However, the key re-attached without any trouble, and the bubble wrap had been sealed well enough to keep the moisture from getting into the unit. Just to be safe, I opened it up, and let it air out for several days before doing any electrical testing.
In the meantime, a question is begged: how do you use a PAL computer in North America? In addition to the video standard difference, there is a voltage one. But that is not much of a problem. A PAL computer can be powered with a North American C64 power supply. It presents virtually no problem, unless you want to use the real-time clock, which will be running at the wrong speed because of the difference in the AC frequency. Other than that, everything runs as it should.
But there is that biggie: the video signal. You cannot use a typical CRT monitor from North America with a PAL C64. It just won’t work properly. All you’ll get is a black and white flickery mess. The Commodore 1902A monitor I use for my C64 and C128 would not do, and I was not about to pay shipping for a CRT monitor from Europe.
The solution is a multi-sync monitor. I’ve got a Sony PVM-14L1. It will accept an NTSC or a PAL signal. On top of that versatility, it is a supremely excellent monitor — a Trinitron display designed at the technical height of CRT technology, decades after the 1902A monitor I usually use.
None worse for the wear
After a few days, it was time to test the unit that barely made it to me.
All is well! But I wasn’t quite done. Although the quality of the display is excellent, and connected in the best possible way (using an Commodore to S-Video cable), there is still room for improvement.
The C64 video processor has a well-known “jailbar effect” where even with the best connection and monitor, vertical “striping” occurs. The effect is more pronounced on certain units — On my older breadbox C64 it is quite heavy, but just barely noticeable on my newer C64C. Regardless, it is noticeable, and it is due to the output of the VIC-II processor itself.
But an interesting fix for this exists: the LumaFix64. (I got mine from a seller on eBay.)
I won’t go into many details on how this works, but basically, you put this between the VIC-II and the mainboard, and you make manual adjustments to three settings until you have a perfect picture. And a perfect picture indeed (this photo from my phone doesn’t do it justice):
(If you see any weird patterns in that image, it is probably due to it being re-sized on your device.)
Incidentally, the LumaFix can also limit the chroma signal, which is a bit higher coming out of the C64 than the S-Video spec allows. On many displays this creates an aweful picture that the Lumafix can correct. My Sony PVM didn’t care one way or the other — it took any level chroma signal and produced a good picture. YMMV.
Finally, I could watch my own demo the way it works best, with PAL timing (on NTSC the music gets out of sync with the display).
I must say, I sure do like rasterbars on a CRT… They just don’t look like that on an LCD or in an emulator.
I haven’t yet spent much time with my PAL C64, but it’s an important part of my retro Commodore hardware collection and I am glad to have the option of running any C64 software on real hardware.
Honestly though, I still prefer NTSC. Probably because it is what I grew up with and what I remember. PAL displays are decidedly “fatter” than NTSC ones, and everything looks just a little “off” to me when I am looking at a PAL display instead of an NTSC one. Also, I don’t know how common this is, but I can notice a slight flicker from a PAL display due to its lower framerate (50hz) compared to NSTC (60hz). It’s just barely enough to be slightly annoying to me, but I expect it is something one just gets used to.