Posted by (twitter: @Sosowski)
April 29th, 2013 4:44 pm

Sooo… I decided to make a game on a C64… And how did it go? Pretty awesome!


Making a game for a C64 and on PC is super simple and tons of fun! But Making a game on a real C64 is something else! One false move and BAH! your game is gone! There are no drives inside C64, everything that you are working on will die once you flip the power button. Moreover, there is no memory protection, so you can accidentally wipe out your code while it’s executing~!

The Setup


I have been swapping around 3 C64s, because all of them have quirks.
– Top one is a C64 C with old motherboard and it had troubles with VIC IRQs
– The middle one I used the most, it seems to work fine, but old memory chips catch interference easily, so somehimes it swapped random bits in memory.
– The bottom one is a new 1993 C64C. It is super stable, but the video signal quality was too bad for streaming.



I never had a C64 disk drive so I’m super used to tapes. Fortunately I had this.


This is Black Box v8 a.k.a Quick Box, it has many cool features.

– Turbo Tape (25min vs 3min)
– Head Fit (a tool to visualise tape reads to help you setup head angle properly)
– Monitor (think of it as a C64 system debugger)
– Speech synthesis (polish only, but still!)
– Reset button (dev is impossible without this thing)

And to go with that I have my super cyborg Datassete.


Inside it, you can see a MP3<->JACK adapter. Basically, it’s a tape with a head inside connected to jack. This way you can easily Transfer games from T64 and PRG files onto a C64. Unfortunately, it only works one way.

I have also found an old blank tape! It is really neat! Back in the days, you could buy a tape specifically engineered for data storage, but I didn’t have that! But a blank tape works fine at all times! If it has music, it is good to wipe it beforehand.


As I said, C64 can be a pain when it comes to crashes. It can glitch out wiping itself randomly because you screwed something up. Fortunately, with this, saving was super neat, and since tapes are sequential I have so many old versions on it! You can easily do merges with old revisions with that!


Previously, I had trouble with good C64 recording quality. But I made an S-Video cable and it all works fine.

Here is how it looked on my old cable.

This was hooked to a simple USB video grabber.


I used AMCap to work fullscreen and XSplit to stream that.

Here’s a quality sample of my environment.



This one is a screenshot of a game I abandoned to make PONK.

Tools that didn’t exist when I started.

I had to find a way to transfer stuff from C64 to PC since the tape adapter thing worked only one way. I had to make a transfer cable.


I used these to create XE1541 extended cable that only works with DOS and Linux. Setting up DOS on an SD was taking too much time so I had to find another way anyways.
I also had this neato helper to hold things for me.


The Citizen

The Citizen may have ruined buttons, but it can do HEX<->DEC conversions pretty well. This helped me out a big deal.


Also, it has the first known occurrence of the word ‘Sosowski’ on the back!

The Pro-cess

I got back from A-MAZE Indie connect in Berlin on Saturday morning after a long night drive and I woke up on Saturday evening. I started working on something but in the edn I decided to scrape it and start something smaller. I’m glad I chose to do that since I ended up with a 1kb large game and you’ll see how this was important later.


I was using the cartridge’s Turbo Tape functions to save often and monitor to write my code and do graphics.


Writing code on C64 is not like writing in a text editor or even like BASIC line numbers. You type your code directly into RAM and instructions are being assembled as you type. This way it is super simple to accidentally wipe out your entire game with a bug.

I wanted to make a platformer where you play as the platform first, but then I ended up with making a lunar buggy kind of racing game. When I woke up on Sunday I started making an XE1541 transfer cable.

When I finished, it was too late to finish my game so I started a new one. This time, I wanted to make PONG, because it’s super simple. The results were nice and fast!


I was finished and had time to polish, so I made a code snippet to wipe the screen contents before the game and quickly tested it. However, video memory was super close to where the game resided (like, 32 bytes apart) and I accidentally corrupted my game. The last save was from super long ago and I had to go through all the code and make it work again.

memory corruption

This is how it looked like. Random bytes swapped in random places. Moreover, I later realised that the Commodore has Alzheimer’s disease and forgets stuff if you work for too long. It was a lot of work but I managed to fix the code and had a working playable version, wooo!

It was all cool until I tried to copy the game onto PC!

The Copyright

First of all, I tried using the tape adapter to get the game on the PC! It was super simple and I had a high quality tape audio data dump soon after that. But it failed to work with any sound<->data applications since they require an audio record of the tape, not a data transfer record.


So I moved to using the cable I made!


But the cable required DOS or Linux installation to operate and no VM could do that for me. Setting this up took too much time, so I had another idea.

First, I rewound the tape and wanted to load the game and suddenly…


It couldn’t load! It seemed like the magnetic interference from my hardware wiped the tape! But in the end I realised that the cable I soldered is producing the interference and it all worked fine.

So I came up with another idea. I wanted to use one of my old ghetto-blasters to record audio from the tape so that it can be used with the conversion app.


But it appeared that neither of these had a working tape player. I had only 3 hours left so I decided to take screenshots of memory dumps on C64, and use OCR to read them! I used OneNote’s OCR feature (paste image, right click and copy test) but it was awful and in the end I had to proofread all 1024 bytes.


Then I wrote a simple C app that assembled a .PRG binary from the text and it magically worked!


I was really glad that the game is only 1kb. Also, it’s this small because it takes a lot of work to fill up memory on a C64, it was kind of not intended.

The End

I really like how PONK plays and it’s a very simple game. It also has a ball slow-motion mode wherer you can slow down the balkl by holding fire button. But two joysticks are XORed so if both players hold the button, it goes fast! This creates a really cool mechanic that makes you want to kill your opponent IRL.

In the end I took the code dumps from C64 and commented them to show you how simple C64 development is! You should totally try it out one day!


Making this was tons of fun!

Play and rate PONK

25 Responses to “PONKMORTEM”

  1. Shigor says:

    This is fucking awesome I might start worshiping you in my spare time (although I still consider myself a speccy guy and gerenally frown down on those commodorists)

  2. goerp says:

    I can imagine doing something on a C64 but in 48 hours?
    (ooh, maybe I should check out the game before worship? NAAAAH);

    (haha, look at that, I automatically ended that sentence with a semicolon). Time to quit!

  3. Someone get this man some professional help.

  4. FuzzYspo0N says:

    2 stars, I have played this game before


  5. gamaral says:

    I’ma gonna go start an Indie GoGo to get SOS a girlfriend. :)

  6. Michcioperz says:

    yyy… korektor czego? πŸ˜€

  7. Markusn says:

    This is easily the best thing I read all day. All weekend. Make it: This year!! :) Awesome work!

  8. w0wbagger says:

    I used to love developing on the C64. If you want to continue developing in assembler, can I suggest you use PAL? Just Google “Pal Assembler C64”. Makes it so much easier, and what I used to develop on the C64 25 years ago [gah!].

  9. DST says:

    Just. Amazing.

  10. Gornova says:

    amazing, I can’t say anything else, amazing!

  11. Jiggawatt says:

    Aww yeah. Gotta love that diagram at the end.

  12. SamoojaMies says:

    Fascinating stuff to read!!

  13. BNeutral says:

    You make your own cables? You should tell us more about that.

  14. johanp says:

    I like how you made the game first, and saved the super critical tech things for last! πŸ˜€ good job all around!

  15. rdytmire says:

    Back in the stone age (1983 or so) I learned to code on the Sinclair Z80 in just this manner….except we didn’t have all that fancy pants “color” and “stable display” that a C64 had.

    We also had all of 2K memory to work with. (For you kids that’s 2000 bytes of memory or far less than an iPhone icon).

    Writing everything done was a common thing….I always coded on paper first, then on the computer.

    Of course you need to mention how a stretched tape can destroy your save file, copying your tapes was a must!

    My centipede game was killer though!

  16. robbotron says:

    This is a great post, thanks for sharing! Back in the C64 days, I used to make text-based adventure games that loaded each new “room” from the dataset as you entered it. The lag while waiting for the next room to load from tape built up the suspense and actually made the game more fun to play! I recommend givin that a try if you feel like doing some more C64 stuff!

Leave a Reply

You must be logged in to post a comment.

[cache: storing page]