Tap Dancer Project

Bubble Ghost

This is a game that Melody used to play, and one which she introduced me to while we were converting games for testing using tapdancer.  It is wonderfully fast-paced and addictive game.  Trying to navigate the bubble from the start of the screen to the exit can be both frustrating and very rewarding.  Overall the game has a wonderful difficulty curve though, with enough progress initially to give you a sense of achievement before it gets harder.



I created a new build of tapdancer on a windows machine, and it is available on sourceforge. Tapdancer at this stage is just a small set of command line utilities, with the main binary “tapdancer” able to convert c64 TAP files into audio files suitable for mastering onto real cassettes or feeding to the machine through a car cassette adaptor.

Read the instructions posted previously for Mac users to get an idea about this (ignoring the DMG file related stuff).

Obviously it is very very alpha… but if anyone is game then I do welcome the feedback.


I have setup some make rules for automagically creating DMG (mountable disk images) for the associated tapdancer binaries.

They are available for download at http://sourceforge.net/projects/tapdancer.

Remember this is pre-alpha, or at least that is what I’m calling it right now.

It will however convert a c64 TAP file (.tap extension) into a Sun AU audio file that can be either recorded to a blank tape, or burnt to a CD. (We generally use a car cassette CD adaptor to feed it from CD into the real datasette, although I have started to experiment with recording the audio out to tape.)

I will post some instructions on how to do this at a later stage, but for simple usage of tapdancer: –

1. Download the dmg, and copy the files to a location that is executable in the path (for example /usr/bin or /usr/local/bin).

2. Find a suitable TAP file (the are plenty of places you can obtain them from).

3. In terminal, type: tapdancer mygame.tap

This will produce an audio file, called “mygame.au”, which is the audio as the datasette would read it. Playing it back loudly in your ears is not advisable hehe, but it sounds a lot like a 300 baud modem… which interestingly enough is a pretty good analogy for how the datasette worked. If you plan to load the software onto a real commodore, I’d advise using a program that will play back audio without special effects or EQ settings (avoid Quicktime and iTunes like the plague).

The best option is to use a CD burning program and burn them onto a CD, and use a cassette adaptor to feed the audio into the datasette.

You could try using an mp3 player, but in practice I have found depending on the player and the encoder you will likely experience a lot of trouble.

Either way, it will take some fiddling with volume to find the optimal level for this to work. You also need to ensure the heads on your datasette are properly aligned as well.

Windows binaries will follow, when I get time to fire up my Windows machine and perform the necessary builds.


Today I migrated the posts from my old blogger account.

WordPress will now host this blog.



Well, I finally got up my nerve to put the current source onto sourceforge. It needs some cleanup, but basic TAP -> Audio functionality is there, as well as a tool to create blank TAP files suitable for use in VICE.

It is available at: sourceforge For those who don’t know, VICE can save programs to TAP files, which then can be passed through tapdancer and converted for use on a real system.

The skeleton of ZX Spectrum TZX support is in there as well… But getting that to convert TZX to raw audio is going to be a larger milestone than TAP support.


Well, I now have an official sourceforge project for Tap Dancer.

But I haven’t yet have the chance to place any kind of useful page at the address: –


On the weekend I might work on putting some content up there.


I transferred the code onto to our PowerPC based Mac Mini last night and it compiled first time… it was however a shame that it didn’t actually work.

Welcome to the world of endianess… where depending on whether or not you are putting some intel employees kids though college or not, or IBM kids, your lovely Pascal code might compile, but totally fail to do what it was supposed to.

The problem was, that I developed this on a PC, and moved the code to PowerPC based mac. Pascal is a wonderfully optimized language, down to the point where it uses the byte ordering of the CPU to represent words, integers and longwords. This is fine, except when you write code that is intended to be cross-platform. In that case, you need to ensure that when it compiles, it reads and writes the data to and from files in the correct way…

A LongWord is 4 bytes. On a Big Endian system, the most significant byte (MSB) is first in memory, and on a little endian system (ie. Intel based), the LSB (least significant byte) is written first. Now, if I ask the system to read a longword from a file stream, you see that this might present problems.

The solution, at least on FreePascal are some handy defines the compiler gives you…

Either ENDIAN_LITTLE, or ENDIAN_BIG will be defined, depending on the target architecture you are compiling for. My solution was to create some functions that would compile differently based on what the target system was. I created a unit called "Endian" which provides four functions…

function endianLittleLong( l: longword ): longword;
function endianLittleWord( w: word ): word;
function endianBigLong( l: longword ): longword;
function endianBigWord( w: word ): word;

So, if a value we read from a file is supposed to be a Little Endian LongWord value, we would wrap the access in endianLittleLong(). On a little endian system, this does nothing except return the value as is, but thanks to the wonders of conditional compilation, this same function will reverse the byte ordering of the LongWord on a BigEndian system.

After doing this, everything worked on PowerPC. Theoretically now, the same code should compile on Windows as well, and act correctly there as well.

Long story short (no pun intended), I have tested and run tapdancer on a PowerPC Mac and it runs fine. A little quicker than my Windows 2000 machine (but that is a Pentium II).