Timeline

In about 1985/1986 I cracked a Commodore 64 game.

In 2015 I mentioned it in my blog Someone from csdb contacted me and asked to upload the crack to their database.
The crack was corrupted, but I managed to restore it, but found it to be so shamefully bad, that I didn’t want to upload it, without ofsetting it by doing something better. Which lead to my ‘rehacking the past’ series.

A better hack would need a better intro and I created a generic method where you could change the border color of a Commodore in such a way that you effectively had a fullscreen multicolor sprite. This I thought would make a unique kind of intro.

I realised that such a generic method could also be used to create games (although they had to be in sprite resolution).
This got me sidetracked for several years and resulted in the game Kung Fu Pixel ( https://csdb.dk/release/?id=165154 ), published in 2018.

After making the game I set out to finally finish the hack.
But still other things were more interesting to do, like create a 4K game in 2018 or a Ludum Dare C64 game in 2019.
Then in 2019 I realised that my intro-to-be method with a full screen sprite would not work on a NTSC version of the Commodore. That was a no-no. Although a lot of things for the C64 nowadays are PAL-only it would nonsense to have an intro limit the usability of a game.

So I had to think of something different.

Furbee-bop, the software Furby Organ.

I recently had become aware of the furby organ created by Look Mum No Computer.
I really liked it and and thought it would be possible to create something like that in software form on the C64.
I wrote a a design document to formulate my goal:

Furby organ
64 sprites of furbies each responsible for a single (or 2 notes)
notes and animation triggered by a tracker player
intended as an intro

stretch goal
add a scroller outside the bottom border
maybe add lame flashing border as beat accent?
music should be made in a way so there is enough variation in furbies animating
to make it visually pleasing as well (tricky!)
so probably walking bass
two note chords, like old C64 arcade classics?, upbeat melody
maybe some  ripoff of old song? https://www.youtube.com/watch?v=68AnYzIceb0
Frantic freddie
maybe arpeggios
fast vibrato because furbies talk like that

By complete coincidence I noticed CSDB ran an intro competition. It gave me the extra drive to finish my intro in 2019.
Amazingly the result is pretty much what I wanted it to be.
Here’s a little gif that shows some furbies animating

The furbies have an intro phase where they seem to be waking up (which also happens in the Furby organ video), with yawning and sleepily opening eyes. After that phase they will start to sing in sync with the music.

The design of the furbies took some time, here’s the first sketch I did on my phone:

But I couldn’t transform the design to a real C64 sprite:

I needed more than two colors for one furby, I could use the black for the background but I would still need more colors. You can use multicolor sprites, but you would lose some horizontal resolution.

There are 5 or 7 sprites in a row (to mimic the white or black keys), which means that you can’t have sprites on top of each other (the C64 had max 8 sprites in a row). That’s why I had the character overlay.

As far as I know there isn’t a tool to design sprites with an character overlay. But you can design multicolor sprites with a single color sprite overlay with SpritePad.

I wrote a conversion script that when building would automatically change the overlay sprites to character definitions (9) and also optimize memory usage by reusing identical characters. KickAssembler has some nice options for that.

I put 48 furbies on one screen (not 64 as was my first plan, which resulted in a ‘wall of furbies’).
Because of the char overlay and bad lines, the furbies are practically speaking 24 pixels high so you can’t have more than 8 rows (8×24 = 192, screen height = 200).

Music

If you use one furby per note, that would mean you would have four octaves. That should be enough for a tune.
As you could see in the design document I also had a style of music in my head and I could start with some simple walking bass line.

After that I started improvising a bit on my guitar trying to come up with a two-note progression to go over the bass.

I used a simple looper program on my phone to create some layers to see how they worked together. I’m really bad at it, but it works to plant ‘idea-seeds’ in my head.

I entered the notes into the C64 tracker Sid Wizard. I planned to use Sid Wizard to play the music in my intro, but I also wanted the music to be fully synchronized with the animation. The code of Sid Wizard is freely available so in theory I could alter the code to make notes trigger animation.
In practice it was too difficult. Not only did I need to fully understand the workings of Sid Wizard, but also I had to be able to split the excecution of the code in three parts. Because the screen was split in 8 parts (9 if you include the scroller) which all need code to be executed at that exact time, there wasn’t much continuous runtime left in between. So not not enough continuous run time to run all of Sid Wizard.

In the end I decided to write my own music tracker. The sound I was going for didn’t really need much fancy coding. But it was spread all across the other code which made someone trying to rip the music from my intro to remark:

Took me a good hour to rip, rebuild the init (didn’t restart) and compact the tune to a 6kb file, damn spaghetti code!

I did use Sid Wizard to write the music. I had learned enough about the workings of it to write an import script which would convert the data to my own (very memory hungry) format. I had a pretty smooth workflow, for once!

Logo

The rules of the competition stated that a logo was needed as well. I designed something in CharPad. I made the letters of ‘GOERP’ in square shapes, but with the ‘O’ round. I liked the result. Because the ‘O’ was round I thought it would be nice to have a moon circle the ‘O’. I had a spare sprite left, so that would be simple.
I used a simple ‘attractor’ type of algorithm to calculate the orbit and a simple algorithm to decide if the sprite had to be drawn in front or behind the ‘O’.  
The letters in itself looked a bit sparse so I decided to add a tagline. I liked ‘orbiting excellence’ because it was kind of ambiguous. It could be taken as a (inexplicable) boast, but could also mean ‘I’m orbiting excellence’ (like how I feel if I’m surfing CSDB pages). 

 

Scroller

A scroller was also a prerequisite of the competition.
There was enough space on screen to add a one character high scroller, but I liked the idea of a border scroller more. Nowadays that’s nothing special, but it gives you more room on screen.

It’s a screen-wide row of sprites (expanded horizontally) on which characters are drawn.

The blue part is the background color, the black wavy part is the so called ‘ghost byte’ which I change every screen line to create a 8 bit wide ‘wave’. I shift the ghost byte values every frame so the wave seems to be moving. This gave me the idea of making the letters kind of appear from beneath the waves.
The color of the sprite letters cycles from the background color (blue) to white and back again. During the cycle I change the priority of sprites from beneath characters ( in this case the ghost byte wave) to in front of the chars to enhance the feeling of rising up.

This wave part will be probably removed from the version I intend to use for my hack. It is timing sensitive so will not work on NTSC (the competition only demanded working on PAL).

Synchronisation

The most important part for me was the synchronisation of music and animation. I wanted the animation and music to be perfectly synchronised without being hard coded (and since the upper limit for the competition was 16K it was inevitable).
I also really wanted people to notice the synchronisation, which also put some demands on the music. There should be distinguishable parts so people would notice the synchronisation even when three notes were playing at the same time. And I wanted the ADSR sync to be visible so there should be slow crescendos (and that’s why the music end the way it does).

ADSR

Old computers don’t use digitized sounds because of memory limitations, but for syncing that is an advantage. The SID chip works by generating wave forms. The volume envelope of a sound is defined by the ADSR values. Attack defines the time used until it reaches max volume, the decay time is the time before the sustain volume level is reached. The release is the time to reach zero volume when notes are set to off.
In my program I ignore the release, I only use zero (immediate) release values. Attack, Decay and Sustain each have 16 possible values.

I use tables to determine how Attack and Decay values correspond to a number of frames. In the Attack phase a Furby will go from being quiet to singing aloud. In the decay time it goes from max volume to the sustain volume. To complicate matters not too much, I only use four volume levels for animation.

This gives 4 possibilities for the decay animation frames.

decayLoudnessTable:
//sustain 3 (max)
.byte SUSTAIN_LEVEL_3, SUSTAIN_LEVEL_3, SUSTAIN_LEVEL_3, SUSTAIN_LEVEL_3
//sustain 2
.byte SUSTAIN_LEVEL_3, SUSTAIN_LEVEL_3, SUSTAIN_LEVEL_2, SUSTAIN_LEVEL_2
//sustain 1 
.byte SUSTAIN_LEVEL_3, SUSTAIN_LEVEL_2, SUSTAIN_LEVEL_2, SUSTAIN_LEVEL_1
//sustain 0
.byte SUSTAIN_LEVEL_3, SUSTAIN_LEVEL_2, SUSTAIN_LEVEL_1, SUSTAIN_LEVEL_0 

For every note the furby goes through 10 animation frames, 4 for the attack phase (always volume 1 to 4), 4 for the decay phase (volumes calculated from the table above), 1 for the sustain phase (volume value from instrument) and one for the off phase.
I determine the instrument for the note and the corresponding ADSR values and take the length of the note. From this I calculate how long each animation frame should be shown (which can be zero, meaning not shown).

Vibrato

I wanted the furbies to sing with a nice vibrato. I couldn’t get my own vibrato routine to sound like it did in Sid Wizard, so I copied that part of the code. Each instrument defines if there is vibrato and the delay before the vibrato kicks in.
The vibrato is also synchronised. In the ‘going -up’ phase of the vibrato code I add one to the current volume frame (the frames are ordered in ascending volume). In the going down phase it just shows the frame of the current volume. That means I need one more volume level totalling 5.

I made a video of the result, but someone else beat me to it in posting it on Youtube and also did a better job in digitizing so I’m showing that one here:

If anyone wants to untangle my spaghetti code, they can! The code is online: git repo

Finally

This is part of series that has been going on way too long. I do intend to finish it in 2020, but as can be read in the timeline section: there are loads of possible distractions.