The hardware chiptune project
Download:
Normally, when you create a chiptune, you start with an
existing chip (such as the SID chip or
the YM2149) and write a tune for it. We decided to start from scratch, and
create a chip and a tune.
It all started at St. Lars
Meeting III, an oldschool demo party held in Lund. Yarrick,
flex and I were there. I had gotten the idea for the project on the day
before the party, so things were a bit spontaneous, and we had to make do with
whatever components I had laying around.
In the beginning, we used a homebrewn AVR programmer, which I had built as
part of a course
in mechatronics. flex valiantly supplied the USB-to-serial adapter.
However, at one point we started experimenting with the so called fuse bits of
the AVR, basically trying to make the processor run at 8 MHz instead of the default 1 MHz.
When we did this, the AVR programmer stopped working.
Luckily, I had brought some spare microcontrollers, but we knew that we'd
eventually need those 8 MHz anyway. So we called Laban on the
telephone, and asked him to bring his STK500 (a commercial AVR programmer). In
order to use it, we realized that we needed some software, so Yarrick
downloaded avrdude, using his
mobile phone as an internet gateway. (Did I mention it was an oldschool
party?)
We wrote all the sound-reproducing software at the St. Lars meeting.
One particularly interesting bug that kept us wondering was the fact that when
we tried to multiply two integers on a particular source code line in the
interrupt routine, all sorts of weird things would occur. If we commented out
the multiplication, things would work. However, there were other
multiplications in the interrupt routine that did work. The "weird things" were
that, for instance, we wrote a constant to an output port at startup, and never
wrote to that port anywhere else in the program; but when we un-commented the
multiplication in the interrupt routine, that output port emitted a quite
different signal.
This confused us to no end, until we looked at the generated machine code
and started counting the clock cycles. Apparently, the multiplication was the
final straw that caused the interrupt routine to run for too long. Before the
interrupt routine would finish, another interrupt would occur, causing a new
frame to be pushed onto the stack. The stack would fill up and the new stack
frames would overwrite RAM and eventually the I/O registers.
This meant that we would have to rewrite the interrupt routine in assembly
language.
Once we had the software up and running, we had to compose a chiptune. I had
been experimenting with chip trackers before, so I re-used some code, and
hooked it up to the sound routine, which was quickly ported from the AVR.
Unfortunately the party was very noisy, and we were sitting just below a
loudspeaker, so it was quite impossible to compose anything. Since I lived
nearby, and had recently had a cold, I was sleeping at home. So, this night I
went home, got some sleep, and wrote the chiptune in the morning.
Sadly, when I got back, the party was already over. There were several
people left, but the lights were on. I asked the crew if we could stay for an
hour or so, and see if we could get it to work (which would have been nice,
because then we would have completed the whole project in just one weekend). We were
allowed to stay, but alas, the chiptune that I had written was too large to fit
into the 8 KB of flash ROM together with all the code. This was such a
setback that we had to give up.
I brought it all home, and ordered a few new components (in particular, a
resistor ladder, so that we wouldn't have to use discrete resistors for the D/A
conversion). flex and I also discussed various ways of compressing the song
data.
Eventually, we managed to cram it all into 8 KB. We couldn't use any
standard compression algorithms, since we were so low on RAM (i.e. there was no
room for the unpacked data). Instead, we devised a solution involving variable
bit-length data structures and lots of bit shifting. We also removed one of the
command tracks; as you can see in the tracker screenshot, every note can be
followed by two effect commands. To save space, we removed support for the
second command, and edited the tune to cope with this new limitation.
At this point we had decided to bring the project to Birdie 17, and participate in the wild
compo.
The time had come to move the project from the solderless protoboard. The
technique of using schematics printed on paper, glued to a veroboard, is part
of the rapid prototyping method taught in the mechatronics
course. I wrote the schematics in PostScript, using a set of functions that
I had designed during that course.
We ended up with a 5th place in the Birdie wild compo. That's actually good,
given that it was a non-technical audience. The winning entries featured humour
and/or singing girls, of course. =)
Here's the Pouët
page for the chiptune project.