Swedish Commodore 64 No Colour Repair

I don't normally do Commodore 64 repairs these days, and even when I do, I don't bother writing them up as they are usually the same old faults, bad RAM or bad PLA etc.

Unless of course they are a bit unusual, like the 4064 / PET 64 I repaired last time.

• http://blog.tynemouthsoftware.co.uk/2026/04/commodore-4064-repair-c64-in-pet-style-case.html

This one was also a little unusual.

This is one of the Kalex boards, made in Hong Kong under license.

It is a 250425 board, I think the last of the large C64 boards with 8 RAM chips before the briefly moved to two RAM chips, on the way to the C64C.

Normally the later boards like this don't have the tin box around the VIC II and associated parts, like the early boards do.

This one does, but it is not the usual type of tin box with a removable lid, it is "n" shaped with no sides and is soldered in place.

Let's hope I don't need to access the bits inside there .... #foreshadowing

Like many of the later boards, all the chips are soldered in, other than the VIC II and the SID.

All seem to be early 1985.

What is unusual on this board is the KERNAL and character ROMs are not the standard PAL variants.

These are Swedish, C2G007 is the character ROM, C2D007 is the KERNAL. 901226-01 is the usual BASIC that is in every C64.

There is telltale flux residue on the back of the board, so it looks like those two ROMs have been replaced. Maybe this was a standard PAL board that had the ROMs removed and replaced with the Swedish versions to go with the modified keyboard (I don't have a picture, but I think they stuck stickers on some of the keys to get the extra accented characters in the character ROM)

So What's Wrong With It?

Well, there is no colour, but more than that, there is a weird pattern on the screen that changes with the colour.

Sort of a chequer board alternating with each pixel.

It seems to be working fine, other than that.

Different patterns on Dead Test, but still not right, and it confirms the colour RAM is testing OK.

I am going to desolder the tin lid, aren't I?

Bit of a job to desolder a large lump of metal from a ground plane, but I got there.

There is not much under there on these later boards.

All the video signal processing happens in the modulator.

All the timing is handled by a custom clock chip, the 8701 (the PAL version, NTSC is 8801).

I tried adjusting the trimmer, but it didn't make any difference.

Both of the chips are socketed, so I swapped them with a working board.

No difference.

The good chips gave no colour in the bad board, and the suspect chips worked fine in my test board.

Which is more than I can say for my camera, I can't get it to like the C64 colour scheme, it just goes all blue. But take my word for it, it was the normal READY screen.

This is why my development C64 has a custom KERNAL ROM with the SX-64 / VIC 20 colour scheme.

That is also the colours used on Dead Test, so I tried that.

The output again was nice and visible, and the camera liked it.

So both chips are fine.

Hmm, there's not much left.

Is it the modulator?

These is not much you can get to on the modulator, unless you desolder it.

I had the test board on the bench already as I had used that to test the chips. I wonder if I can "borrow" it's modulator without the use of a soldering iron?

Two Commodore 64 boards, is that how you make a Commodore 128?

Here I have the faulty board on the bottom powered up as normal.

I have tapped the power from the 9V DC unregulated supply, and the chroma and luma out of the VIC II.

Those power just the matching 9V unregulated rail on the test board, and the chroma and luma plug into the VIC II socket. The monitor now connects to the test board. The rest of the board is not powered.

No change.

Hmm, so it's not the VIC II. It's not the clock chip. It's not the modulator.

What's left?

I tried adjusting the trimmer again, I did get a brief flash of colour, but nothing stable, it could be flaky?

Before I turn on the desoldering station, let's just try something.

I have left the power as before, as that also feeds the regulator that generates the separate 5V supply for the VIC II and clock chip.

I have a clock chip on the test board and have tapped the two clock outputs. All the rest are supplies or fixed high or low options.

Those plug into the socket on the faulty board.

And it worked!

(I would insert a picture of a normal C64 READY screen if I was capable of taking one)

So that narrows it down.

Could it be a bad trimmer?

No, I replaced that and still couldn't get the colour back.

OK, so it's the crystal then?

I didn't have any new ones, so I borrowed one from a parts board.

And that fixed it!

(you know by now that I can't show the working READY screen, but it did work)

Testing the Fix

Everything seems to be working now, even the special characters.

Let's see if I can find something a bit more colourful.

That was the colour RAM test from DesTest.

Time to load some programs, out comes the SD2IEC Fastload Combo.

It's the easiest option when I just want to load things quickly and with minimal fuss.

I loaded the file browser and then scrolled down.

Ah, now don't panic.

That is a known problem with the early C64 KERNAL ROM, normally 901227-02. It was fixed in 901227-03.

I presume the Swedish variant must be based on the -02 with the colour scrolling bug.

It might be possible to patch the ROM with the fixes from the -03 KERNAL, but since it's soldered in, I will leave well alone.

I tried a few games, and all seemed to play fine.

Yes, we definitely have colour, thank you Toxic Frenzy.

Ghosts and Goblins was a lot more colourful than I saw recently on the 4064 (although it doesn't make me any better of a player).

That all seems good.

Wave goodbye to the inside of the tin.

That's getting entombed again (and about 2 days after soldering the lid back on, I found the bag of new 17.37MHz crystals)

I left it running the memory test I wrote for the 4064.

Ah, hang on, a couple of POKEs later and you can actually see the results...

I have run that through a couple of times as I have been writing this up (in blue on blue so I could see if the colour was stable).

That's all done and ready to go back.

---

Adverts

The recent Tindie debacle seems to be on it's way to being resolved, so orders are now shipping again.

My store contains all sort of kits, test gear and upgrades for the ZX80, ZX81, Jupiter ACE, and Commodore PET.

• https://www.tindie.com/stores/tynemouth/

If you do want anything from the store and you don't fancy using Tindie, contact me directly using the link at the top of the page and let me know what you want and which country you are in, and I will get you a price if you want to order direct.

---

SD2IEC Combo

The SD2IEC Fastload Hybrid is available from TFW8b.com

• https://www.tfw8b.com/product/sd2iec_fastload_hybrid/

---

Patreon

If you enjoy posts like these, you can support me via Patreon, and get access to advance previews of blog posts, Patreon exclusive posts and progress updates on new projects and other behind the scenes updates. There is also access to my Patreon only Discord server for even more regular updates, and to discuss your own projects.

There is now a free trial on the Patreon, if you want to find out what goes on in there, and I hope you will want to stick around.

• https://www.patreon.com/tynemouthsoftware

Commodore 4064 Repair - Part 2 - Reverse Engineering the Video Conversion Board

The PET 64 or 4064 is a modified Commodore 64 board inside a PET style case with a PET 12" monitor.

In the previous post, I fixed a few issues with the board and got it working again.

• http://blog.tynemouthsoftware.co.uk/2026/04/commodore-4064-repair-c64-in-pet-style-case.html

But How Does it Work?

The Commodore 64 produces a composite video output. The board has been modified so it will only produce a monochrome composite video output.

The PET monitor needs a 3 part signal input, horizontal sync, vertical sync and video.

To convert the single input to three outputs, Commodore used a small converter board, part number 2833981. (N.B. the owner asked me not to clean any of the boards to preserve the patina)

I have not found any schematics online, and I wanted to know how this worked, so I reverse engineered it.

One moment please.....

I tried both ways, but found it easier with the front photo flipped.

There are various wire links, so I start off by marking off the 0V and 5V rail connections.

I then went through and traced out the circuit, marking each of the pads I had drawn in blue as I went.

I drew the schematic sort of how the board was laid out, with the input in the middle at the bottom, and the output at the top.

Once that was completed, I rearrange it to make more logical sense.

I then removed the various wire link jumpers and not-fitted parts to clean things up a bit.

There is a lot going on, so I will explain it in sections.

Video

I will start with the simplest circuit, the video output. This should be TTL level digital pulses, with low being black and high being white / green.

The composite video signal comes in containing both sync and video data.

This is taken from the "luma + sync" pin on the VIC II chip, via a ferrite bead FB15. You can see the blob of solder at the end where the wire is soldered on the back of the board.

The diode shifts the level down by approximately 0.6V, which blocks most of the sync signals and just leaves the video.

This is amplified by the transistor as a non-inverting emitter follower and finally the AND gate converts that to a TTL level digital signal.

Zooming in, you can see the analogue video signals before and after the emitter follower (which has unity gain, so they are the same levels) and the clean digital out of the AND gate.

The resultant signal is nice and clean, and I could work out that it was the bottom row of the word "FASTLOAD".

The AND gate is gated by the vertical sync signal (generated elsewhere in the circuit), so that no video is generated during the vertical sync pulse (which would be visible as the electron beam flies back to the top left of the tube.

(the spikes are part of the C64 video output, at the far left of the frame, so not normally visisble)

Sync Separator

Both the horizontal and vertical sync generators share a common part, the sync separator.

This uses the two back to back diodes to clamp the input to cut off the video parts of the signal.

An inverting common-emitter transistor amplifier generates a positive version of the negative going sync pulses on the input.

The top trace shows the video input at the point where the vertical sync is, the last lines at the bottom of the screen are on the left, the first lines at the top are on the right. The C64 outputs a pulse at the start of each line, I think where the chroma burst would be in colour video. It is not visible, but it is useful to see what is going on there.

Composite video has the complicated pattern of half length lines with no video signal. These invert part way through, then return to normal. This is the PAL pattern, the NTSC version is slightly different.

The middle trace shows the clamped version which only contains the sync elements,

The lower trace is the cleaned up, inverted and amplified version used by the the two following circuits.

Vertical Sync

Next, the vertical sync.

The previously generated positive sync signal is buffered by the AND gate and passes though an RC low-pass filter.

Time for the first bit of maths.

The cutoff frequency of the low-pass filter is 1 / 2π R C

With 820Ω and 33nF, that works out as 5882Hz, so anything below about 6KHz will be passed through and anything above that will be filtered out.

This filters out the 15KHz horizontal sync pulses and leave just the 60Hz vertical sync.

The top trace is the sync signal from the AND gate, the middle shows the output of the RC filter which has turned that into a single pulse.

The final trace is the output of the monostable which extended that to create the vertical sync.

The cleaned positive pulse is used to trigger a 74LS221 monostable circuit. This has Schmitt trigger inputs, so the output of the RC circuit can be connected directly to the B input, which triggers on the rising edge.

This generates a clean negative going pulse on it's /Q output, the duration of which is set by the Rext and Cext on the chip.

The formula for the 74LS221 is 0.7 * Rext * Cext

(Actually, I think it is actually the natural log of 2, rather than 0.7, so ln(2) is 0.693147, but most of the datasheets just say 0.7 as you don't need to be that accurate given the tolerance of the parts used.)

The units are seconds, ohms and farads, so there are some pretty small numbers there.

I find it more manageable to keep Rext in ohms, and use a convenient value for the capacitance. Then you use the same multiplier for the time. With Cext in nanofarads, the result will be in nanoseconds, with the input in microfarads, the output will be in microseconds.

In this case, Cext is 0.1µF, and Rext is 10KΩ.

0.7 * 0.1µF * 10,000Ω = 700 µs

700 µs is about the duration you need for the VSync on a PET monitor.

I measured that as 731 µs, which is fair enough as the tolerance of the parts are probably 5% - 10% at best.

That pulse is repeated once every frame of video. You can see all the horizontal sync pulses, one per line, on the top trace. Below is the filtered trigger pulse and finally the VSync output.

Horizontal Sync

I was expecting the horizontal sync circuit would be the same as the vertical sync, just without the RC filter.

Working backwards from the output, it uses the same combination of an AND gate feeding a monostable.

Here, the time is 0.7 * 0.0033 * 8200 = 18.94 µs, the length of the horizontal sync pulse.

If you are paying attention (and if not, why not?) you may have spotted that there were three ICs on the board, and so far we have only used 3 AND gates and 2 halves of the 74LS221. What about the third chip, the 74LS123?

You had to ask, didn't you?

It took me a while to think this one through.

What is happening is the sync pulse is triggering the lower left monostable, with a period of 8 µs, slightly extending the incoming 4.7 µs and then this is ANDed with a mask signal.

The mask initially starts high, so the slightly extended sync pulse is passed through the AND gate and triggers the right hand monostable to generate the HSync pulse.

That also triggers the top left monostable, which sets the mask output low for 35 µs. That effectively masks off the incoming sync pulses and prevents them triggering the output monostable.

At the end of the 35 µs, the output goes high, and the next sync pulses will be passed through.

But why?

The top trace shows the sync input, next is the extended pulse, then the mask, and finally the output HSync pulse.

In normal operation, the mask is not doing anything, the sync pulses from the input only appear every 64 µs, so always get through.

It is only important when it comes to the VSync section. Remember those half lines that make up the VSync pulse? Well that is what this masking circuit is blanking out. You can see the transition in the above screenshot, the last normal line on the left and then the start of the half lines.

This continues until the normal lines start again, so you get a nice clear train of HSync pulses without the extra ones. Neat.

Conclusion

There is a lot going on there to take a composite video input and generate video, HSync and VSync signals for the PET monitor.

But it does a good job of the conversion and the PET monitor picture is clear and stable.

Lots of thought must have gone into that, so as I said in the previous post, I don't think these are the "spare cases and warranty returened boards" they are often dismissed as.

Side note 1

I thought you only had a two channel scope Dave, didn't I see some screenshots with 4 traces on?

Yes, I do, I cheated the third trace using the reference trace (previously saved version of trace 2 when the probe was connected to a different point), and I cheated the forth channel using the external trigger input (which is digital only which is why it looks cleaner than the others - it would be a nice option to be able to enable that on the other signals).

I did capture the same thing with the logic analyser.

But I decided to stick with the 'scope screenshots instead.

Side note 2

I skipped over the calculations for the two pulses from the the 74LS123, as that chip calculates the pulse period differently from the 74LS221, the formula is now:

Why didn't they use another 74LS221? Pass. The 74LS123 is pin retriggerable, so will restart the pulse if it received a second trigger before it finishes. I am not sure that is necessary here, but if it is, why didn't they use two 74LS123s instead?

---

Adverts

Good news, everyone, Tindie appears to be back. There are still some issues, hopefully those will be resolved soon and I can get back to normal. Three weeks with no income has not been fun.

• https://www.tindie.com/stores/tynemouth/items/

My store contains all sort of kits, test gear and upgrades for the ZX80, ZX81, Jupiter ACE, and Commodore PET.

If you do want anything from the store and you don't fancy using Tindie, contact me directly using the link at the top of the page and let me know what you want and which country you are in, and I will get you a price if you want to order direct.

---

Patreon

If you enjoy posts like these, you can support me via Patreon, and get access to advance previews of blog posts (e.g. the next unusual Commodore 64 repair), and exclusive posts (e.g. part 1.5 of this series with the look at using the debugger to dump the ROMs).

You also get progress updates on new projects and other behind the scenes updates, as well as access to my Patreon only Discord server for even more regular updates, and to discuss your own projects.

There is now a free trial on the Patreon, if you want to find out what goes on in there, and I hope you will want to stick around.

• https://www.patreon.com/tynemouthsoftware