The hardware chiptune project

by kryo

Download:

• kryo-hardware_chiptune (Original zipped release, DivX, 18.5 MB)
• Linus Akesson - The hardware chiptune project song (Recorded MP3, 1.5 MB)
• hardwarechiptune-cad (Schematic, EPS source code, 8.6 kB)
• hardwarechiptune-cad (Schematic, PDF, 31.9 kB)
• hardwarechiptune-tracker (Tracker with source code, docs and song data, 26.0 kB)
• hardwarechiptune-src (AVR source code, 10.5 kB)

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.