At Revision 2025, we released “Signal Carnival” (csdb, YouTube). This demo asks you to
switch the audio and video cable of your C64:

(Diagram by Felidae)

Technically, “misplugging” those cables is not a completely new idea. In the
90s, it was a common thing to connect audio to both speaker and video,
to get screen flickering timed with the music beats.

However, “Signal Carnival” is the first production to switch both these
cables, while still being able to play meaningful audio and video.

How to drive audio using a video signal

The C64’s VIC chip operates at a frequency of 7.9Mhz, and new values can be
written to it by the 6502 at a rate of up to 246kHz. Since even high
quality audio rarely exceeds 44kHz, this is easily a high enough frequency
to generate music.

Inspired by the music routine from freespin, we combined two timers to
get an interesting waveform, which is adjusted once per frame. This is
the code that drives audio:

lda $dc06
ora $dd06
eor $02
sta $d020

Here, $dc06 and $dd06 are the lower bytes of the B timers of CIA #1 and #2,
respectively. They’re in turn increased every time their A timers
overflow. And those are set to a new value for every new note.

Eor-ing with the value at zeropage $02 allows to slightly tweak the waveform (and volume!),
and then the result is written to $d020, which is the screen color.
Only the brightness of said color matters (chrominance is encoded at the
PAL color carrier frequency, which is outside of the human hearing
range). There’s no obvious relationship between the brightness of the C64 color
and its number, but that’s fine – it actually makes the
waveforms more interesting.

Of course, the above uses up all four timers the C64 CIAs have, which means there
are no timers left for e.g. video stabilization, which is instead done
through the lightpen circuitry. (Finally! A use case for $d013. :))

Music is just one voice, but the song switches between voices (and
waveforms) often enough to sound mildly polyphonic.

How to drive video using an audio signal

The SID chip of the C64 internally operates (for PAL) at 9.85Mhz, and,
like the VIC, can be fed with new values at a rate of up to 246kHz.

The SID has a number of audio features. It can generate three voices
using multiple waveforms, it has an ADSR envelope generator, can sync
between voices, and apply filters.
Unfortunately, all this circuitry works at a (for video)
glacial pace: The highest frequency the chip can output is 3906Hz, which
is the equivalent of changing the video output every four rasterlines.
Similar with ADSR, for which the smallest possible configurable attack
time is 2 ms, so about 32 rasterlines.

But thankfully, there’s also circuitry that is wired more directly and
and gives instant output: the volume register ($d418)!
This has been used in the past to generate samples at high frequencies
(16+ khz), and is a good choice for generating video, as well.

However, the C64 mainboard also, vexingly, passes the SID signal through
a analogue bandpass filter. And this always happens, regardless of
whether filtering is on or not.

This means that the pixels we work with are very wide, and also horizontally
blurred. Here’s one “pixel”, displayed on my 1084 monitor:

This blurryness poses an interesting constraint on effects. While technically,
you do have some degree of horizontal resolution, the blurriness makes it
unenticing to use it for scrollers. Here are a few letters, for illustration:

Signal Carnival makes heavy use of both axis,
but to cope with the bluriyness, the x axis is used for graphics elements that
are fine to blur, like e.g. textures.

Other than that, driving the video is just your normal vanilla video
bitbanging. Due to the bandpass filter, horizontal syncs (i.e., pulling
the signal line to ground) need to be precisely timed, so they get
recognized, but not mistaken for vertical syncs. (which differ from
horizontal syncs only in that the signal is pulled to ground a
little bit longer)

Video sync generation is happening at the same refresh frequency that
the VIC would have produced (so we can use raster interrupts and query
the lightpen), but we use a different horizontal frequency (64 cycles
per line instead of 63), since having that extra cycle proved useful
in a lot of effects. And besides, if you’re generating your own
video signal, you might as well make your own rules!

Loading

I’ve written a new loader for probably every demo I’ve ever released on the C64,
and this one is no exception. Since a lot of the effects are quite
memory-hungry (we even play a sample at the end), loading breaks are
long enough that we can’t just
pause audio while they happen.

Hence, we have to bitbang audio the entire time. Also while transferring
data from the drive to the C64. Also during decrunching. (The
decruncher actually unrolls all copy loops, also for that reason)

The loader has a few gimmicks, like doing on-the-fly GCR decoding that
allows to write to any page (not just stack), and it buffers (stashes) a
full kilobyte. But it’s also a one-off, so it’s missing tons of
features seen in fully-fledged C64 loaders. It doesn’t even support
loading from tracks 18 and above yet (the demo uses 1-10.)
Also no checksumming. (So remember, kids, dust off your 1541 drives, or
Signal Carnival might not work!)

Talking about GCR decoding, I found it tedious to handcode the decoding
tables, so we instead wrote a solver that generates them given the code
that uses the tables, and the desired input/output. Very useful tool,
hopefully to be released soon.