C64 PAL to RGB Adaptor
This is a circuit I built to decode the PAL video output from a
Commodore 64 for display on an RGB monitor. It's based on some parts I
salvaged from and old TV set, in particular a TDA2525 PAL demodulator
chip, the luma and chroma delay lines, and a couple of inductors.
Click photos to enlarge.
SchematicClick to enlarge.
How it Works
The following assumes some familiarity with the PAL colour video encoding system. If you're interested, I've written a brief summary here based on what I've learned from my googling and experiments.
Inputs from the C64
I chose to use the separate luminance and chrominance signals provided
by the C64 rather than the composite video output, since I need them
The first thing I had to do was separate the sync pulses from the video
signal and generate a burst gating signal. Sync separation is done by
comparator U1. The sync part of the luminance signal from the C64
ranges from about 0V to 0.3V, so the comparator needs to switch at a
threshold of about 0.15V. R1 and R2 raise this a little so that it is
within the input range of the LM319.
Monostable U2 is triggered by the trailing edge of the sync pulse and
generates a burst gate pulse lasting about 2µs. Q3 is a level shifter
that produces the 0-12V pulse needed by the TDA2525.
The separated sync signal is also taken to Q8 for driving the monitor's
I wasn't able to find a datasheet for that exact chip, but I found one
for the TDA2522, which appears to
be very similar. The datasheet is a
bit light on usage details, but I found schematics for a couple of TV
receivers that used it, and between those and the datasheet I was able
to figure it out.
The TDA2525 has separate inputs for the B-Y and R-Y demodulators at
pins 5 and 6. How these are used depends on whether you're using a PAL
delay line or not. I decided to try doing without one at first, in the
interests of simplicity, to see what would happen. When used this way,
pins 5 and 6 need to be fed with the same chrominance signal but in
opposite phases. So the first version I built used a phase splitter,
C4, C5, C6 and R19 form a filter network for the phase-locked loop. I
don't know any details of how it works, I just copied it directly from
the TV circuit. C7 and C8 and pin 13 are concerned with automatic
colour control. In a TV receiver, pin 13 would be used to control the
gain of the chrominance amplifier, but I don't need this, so I left it
Crystal X1 provides an 8.86MHz clock which is divided down inside the
chip to the 4.43MHz PAL subcarrier frequency. Trimmer VC1 can be used
to fine-tune the frequency, but I found it would lock on quite happily
in almost any position, so a fixed capacitor of 10pF or so could
probably have been used just as well.
Pin 16 is designed to have a capacitor connected to control the time
constant of the colour killer. In a TV receiver, this disables the
colour outputs when no colour information is present, so that
monochrome signals are decoded without random colour artifacts. But I
don't need a colour killer because the C64 will always be providing a
chrominance signal, so as per the datasheet I connected pin 16 to
ground through a 2.7k resistor, which disables the colour killer.
Decoded R-Y, G-Y and B-Y colour signals come out at pins 1-3. Luminance
(Y) is added to these by resistor network R21-R26 to give R, G and B,
which are buffered by Q5-Q7 and sent to the monitor. Diodes D1-D3 are
included because, due to the DC offsets of the various inputs to the resistor
network, the black level comes out a little too high
Chrominance delay line
I was hoping that a chrominance delay line wouldn't be needed, but that
turned out not to be the case. The problem can be seen here, where
there is a noticeable difference in brightness between consecutive
Looking at the signals with a scope, there didn't seem to be any
difference in the amplitude of the chrominance from one line to the
next, which meant there must have been a slight phase shift on
alternate lines. From what I've read, it seems that this is a known
problem with the PAL version of the C64.
Since phase errors are what the PAL system is designed to address, next
I tried the full PAL decoding arrangement incorporating a chrominance
delay line. The phase splitter was replaced by a chrominance amplifier
(Q1, Q2) to compensate for losses in the delay line (DL2). (You can see
vestiges of the phase splitter in the fact that the collector resistor
of Q1 is actually two resistors. The points labelled PSR and PSB are
the old phase splitter outputs; I left them in place and installed
headers H1 and H2 so that I could switch the delay line in and out with
jumpers for comparison purposes.)
from the delay line is combined with the output from the chrominance
amplifier coming via VR1, C3, R13 and R14. The two ends of the delay
line output have opposite phases, so the chrominance from the previous
line is added to the current line at the B-Y input and subtracted from
it at the R-Y input. This achieves the extra flip along the R-Y axis
needed to cancel phase errors.
VR2 needs to be adjusted so that the amplitudes of the direct and
delayed chrominance at the B-Y and R-Y inputs are equal. One way to do
this is to look at a screen full of solid colour and adjust it until
all the lines look the same. During my initial attempts at this, I was
able to get the blue of the C64's default colour scheme looking fairly
However, I wasn't able to get it right for all colours at the same
time. When blue was balanced correctly, red wasn't, and vice versa.
While playing around with it, I also thought of another way to perform
the adjustment. The default background colour seems to be pure blue, so
the R-Y component is zero and the chrominance consists entirely of B-Y.
Since B-Y is unchanged by the phase reversal of R-Y on alternate lines,
the direct and delayed chrominance at the R-Y input should have
opposite phases and cancel completely. So I should be able to put the
scope on the R-Y input and adjust VR2 for minimum amplitude.
When I tried this, I found that I could get it down nearly to zero on
odd lines, but then it would be significantly non-zero on even lines.
Or, I could compromise and get the amplitude roughly equal on all
lines. Visually, this corresponded to either having odd lines pure blue
and even lines somewhat purple, or having all lines the same shade of
slightly purplish blue. While the latter wasn't really noticeable, it
was still a compromise and had worse effects on most of the other
Thinking about what might be going wrong, it occurred to me that proper
cancellation relies on the chrominance being delayed for a whole number
of subcarrier cycles to a fairly high accuracy, and I began to doubt
whether the delay line was made that accurately. Some careful scope
measurements seemed to show that there was a significant phase
discrepancy between the input and the output of the delay line. It
didn't seem like it could ever work properly unless there were some way
of fine-tuning the delay.
Then I turned my attention to L1 and L2. Until then, I hadn't really
known what their purpose was. I had tried including or excluding them,
and it didn't seem to make much difference either way, except for a
slight change in the amplitude of the delay line output. Later I found
that without them I couldn't get the VR2 adjustment anywhere near
right, so they did seem to be necessary, even if I didn't know exactly
why. But I had only been thinking about their effect on the amplitude,
not the phase.
Now, I began to wonder whether their true purpose included adjusting
the phase of the delayed signal to compensate for inaccuracies in the
delay. Up to then I hadn't tried adjusting them, reasoning that they
had already been adjusted for the circuit they came out of, so it would
be best to leave them alone. But perhaps that reasoning was flawed,
since my version of the circuit has a different layout with different
stray capacitances and inductances, etc. So I scoped the delay line
output and tried moving the slugs. I found that I could indeed shift
the phase somewhat, particularly with L2. By fiddling with both L2 and
VR2 I was able to get it so that all the colours looked reasonably
Luminance delay line
I wasn't quite out of the woods, though. The following was supposed to
be purple lines against a cyan background. Instead it came out as
adjacent grey and purple lines in the vertical direction.
This one was easier to fix, though. I knew immediately what was causing
the problem -- I hadn't included a luminance delay line. This provides
a small delay to compensate for the fact that the chrominance goes
through more processing than the luminance.
On the schematic it's DL1. R5 and R6 provide impedance matching to
prevent reflections (I tried it without them, and it was terrible). Q4
buffers the output for driving the luminance addition resistor network.
The result was a big improvement:
I had some spare space on the board and room in the box, so I added an
audio amplifier (Q9-Q12) and a small loudspeaker. That part was much
easier to get working!
Here are some more screenshots - click to enlarge.
It's not perfect. Some colour combinations still look a bit raggedy,
particularly with narrow vertical lines.
I suspect it's possible to do better, but I'm not sure. I haven't seen
a real C64 running with a TV or monitor with composite video input, and
I don't have one around to try it with. I've seen screenshots of C64s
that look quite a lot better, but they're probably NTSC, so I'm not
sure how good a PAL C64 is capable of looking. In any case, I'm out of
ideas for the moment, and I feel I've spent enough time on something
that I'll only be using occasionally. If I get a brainstorm I may come
back to it later.
If anyone out there with experience of things like this, and who
actually knows what they're doing, has any ideas, free free to let me