Subscribe via RSS

GAME OVER? Amsterdam – Retro Games Store

GAME OVER? has existed for over 14 years, tucked away in a side-street in central Amsterdam. I was very happy to hear this when asking the owner about the history of the shop.



This shop is bursting at the seams! Wall to wall of amazing retro goodness. You'll find everything here from VIC20/C64/Atari through to XBOX/Gameboy/PlayStation. The window is full of relics and will get anyone interested inside. Don't be fooled into thinking that what's on display is all there is to offer... If you know what you're after, then ask away and have the owner dig bits and pieces out for you.

DSC04720 DSC04721 DSC04722

I happened to want one of the controllers in the window; turns out they're all damaged and just for display. I was then lead to a draw, on the left as you walk in, and a motherload of C64/Atari items was presented. Pretty ... much ... heaven. The owners are really friendly and let me take pictures inside the store... so do chat with them; their wealth of knowledge was very helpful!

DSC05140 DSC05141 DSC05143

As you can see from above, I picked up two Atari controllers and my first ever C64 cartridge: Rat Radar Race. Am still to test it, but have been told it is in working order. I couldn't trek half-way across the globe and not purchase a few goodies when they were there in front of me. I actually tried a few of the 'markets' around Amsterdam but found zero retro gaming items.

Check this shop out if you're ever in Amsterdam!


Commodore 64: Serial Interface to Arduino

So, in my previous post, I was heading towards building an archaic circuit to control trains with the User Port. This would've worked, had I spent a lot more time and built a very complex circuit. Instead I've now chosen a new path... let's hook the C64 up to an Arduino and do most of the work there. The C64 can be the display and input/output for controlling the trains.

Interfacing both components

The C64 User Port has both a 'parallel port' with 8 i/o pins and a serial port. I initially wanted to use the parallel pins, but came to the conclusion that I'd have to write my own language on both sides and deal with the data transfer timings and clock synchronisation. Instead, it'll be easier to use industry-standard RS-232!

I suppose this is a bit of a cop-out. I wanted to build something that was dated to the level of technology that existed back when these machines were in their prime... unfortunately my electronic knowledge isn't up to scratch... so getting to a variable 12v output wasn't overly easy. It also would not have been PWM. Due to all this, including the Arduino into the mix isn't such a bad idea. Plus, everyone I'd asked for help told me to do this... even sending me links to my own blog posts :)


Serial plugs have a single channel, with each end having one transmit (TX) and one receive (RX) pin. Each end will send data down the cable via the TX pin and expect to receive data on the RX pin. Standard serial cables are 'straight through', meaning that the TX pin is connected to the TX pin and likewise with RX. Doesn't quite make sense, does it? How are to separate devices meant to eachother if they are both transmitting down the same singular TX wire and hearing silence on the RX?

This all becomes clear once you realise that devices fit into two categories: DTE (data terminal equipment) and DCE (data circuit-terminating equipment, also known as data communication equipment.) In the end, these two devices boil down to one being the master (the DTE) and one being the slave (the DCE.)

Of course, you can purchase 'cross-over' cables for serial connections. These are known as null-modem cables and allow you to hook two DTEs together. Say, for example, you want to transfer a file from your PC to your Amiga, or somesuch!

In my previous serial project, when I connected the IBM receipt printer to the Arduino, I needed the Arduino to be the master, and so I hacked around until I had correctly configured it as a DTE. This time around we want the Arduino to be the DCE. Due to this, be careful to follow the pinouts and wiring from the serial port to the MAX232 in the circuits below!

Note: For further reading/wiring on RS-232, there's a good article at avr Programmers and another at Advantech.

C64 Serial Port

The User Port on the C64 also has serial connections. These are TTL and so need to be brought up to the RS-232 5v standard. The MAX232 IC will do this for us quite easily. We'll also use one at the other end for the Arduino.


The circuit is derived from This circuit was also correct in that the pins are wired up as DTE. This means that you could use it, as-is, to also hook to a modem or any other DCE device.

The MAX232 needs few extra components. Fortunately, these extra components are identical on both ends, so buy everything in duplicate! The capacitors are all 1.0uf electrolytic. I used 1k resisters on the LEDs so as not to draw too much current from the User Port.

Arduino Serial Port

This is nearly the same circuit as the C64 end. The funniest thing happened here... if you google enough 'arduino max232' you'll just loop back around to my post, from ages ago on interfacing an IBM printer to the Arduino. Just make sure you don't use that circuit! It's DTE, we need DCE as per below! I've left out the RTS/CTS as I don't intend on using any form of handshaking in this project. It's still in the circuit above for the C64 so that you can use the port for other purposes.


As per usual, make sure you DO NOT apply 5v in the wrong direction... I did and it ruined a few caps and possibly the IC. Garbage then came through the serial port. If this ever happens, then throw out the components and start again; you'll never be able to trust them.

Also make sure that you use the 5v pin on the Arduino. AREF is NOT a valid voltage source.

Hooking it all together

Build both circuits above and give one a male and the other a female db-9 connector. The DCE device usually gets the female, so put this on the Arduino-side!

DSC03947 DSC03956 DSC03954

DSC03955 DSC03950

If you want to roll your own cable, then grab some grey IDC and two crimp-style plugs. Just make sure that you have pin 1 matched to pin 1. If you're splitting the cable, then paint a wire (or use a marker) to ensure that you get the orientation correct. It's really easy to confuse pin 1.

DSC03998 DSC04000 DSC04002

From above, you can see the pin numbering. I slid the second port all the way to the end, prior to crimping, to ensure that the numbers matched up. Using the red '#1 wire' on the cable worked wonders too.

Testing with Strike Terminal 2013 Final

Download Strike Term 2013 Final from here and then get it to your C64. I copied the D64 to my SD2IEC and loaded it up. Hit M and select User port. Hit b and switch it to 1200 Baud (or other baud, depending on what you've configured in the Arduino.)

DSC03976 DSC03978 DSC03957

DSC03958 DSC03964 DSC03965

Once ready, hit f5 and then hit enter on the default server. This'll start sending modem AT commands down the serial and they should start showing up at the other end. Either open the Arduino Serial Monitor... or edit the code to display it. I bought some 8x8 LED Matrices to render the data coming in.

DSC03963 DSC03971

There were no real caveats here... everything just worked! Press f3 to get to the terminal. Hit commodore+e for local echo and then commodore+i to 'send id'. You should now be able to type freely... everything will be sent down the wire.

DSC03983 DSC03984 DSC03985

DSC03986 DSC03987 DSC03988

At that point I only had one matrix... so the last char typed was displayed.

Writing C code to use the Serial Port

Nanoflite has written a 2400 baud User Port Serial Driver for cc65. I originally tried to use this at 1200 baud, as that's what I'd been using everywhere and heard it was the max the User Port was capable of. It turns out that this driver only supports 2400 baud! Download it and put the source somewhere.

Switch to the driver directory and compile it:

cl65 -t c64 --module -o c64-up2400.ser c64-up2400.s

Copy this to the folder that has your source file it. I slightly modified the example.

#include <stdlib.h>
#include <stdio.h>
#include <conio.h>
#include <serial.h>
#define DRIVERNAME  "c64-up2400.ser"

static const struct ser_params serialParams = {
    SER_BAUD_2400,      /* Baudrate */
    SER_BITS_8,         /* Number of data bits */
    SER_STOP_1,         /* Number of stop bits */
    SER_PAR_NONE,       /* Parity setting */
    SER_HS_NONE         /* Type of handshake to use */

int main (void)
  int xx;
  puts("C64 serial ...");

  // Load driver

  // Open port

  // Enable serial
  ser_ioctl(1, NULL);

  for (xx = 0; xx < 10; xx++) {
  return EXIT_SUCCESS;

Compile this:

cl65 -t c64 -O -o trainctl2 trainctl2.c

I then put it on the SD2IEC and loaded it via LOAD "0:TRAINCTL2",8 followed by a RUN.

DSC03993 DSC03989 DSC03991

DSC03992 DSC03994 DSC04003

Shit... worked... this is great! Next it's time to put a PWM throttle onto the Arduino and control it from the Commodore... I'll tinker with graphical programming in C also.


Commodore 64: Tape Drives

This was really a lesson in jumping in the deep-end. I'd bought Double Dragon for the C64 recently on eBay, somewhat blindly, and found out that it was on datasette. It had been relegated to museum shelf until I happened across a cheap tape drive. Below is the story of learning how these things work.

The Datasette drive arrives

The seller had mentioned 'original box' and 'complete'. Indeed it was. I take it, though, that the box had been in the back of the shed for quite some time. The manual pages were mould-glued shut and the box was probably releasing spores every time I touched it. Due to this, I took photos for historical-sake and then destroyed the evidence; keeping only the actual drive.

DSC03787 DSC03788 DSC03789

The first game: Double Dragon

Double Dragon (for C64), released by Melbourne House (more information here), is a side-scrolling beat-em-up. The name of the company is confusing, as it sounds like it might be Australian, but was actually started in London. There is/was an Australian branch though, but it was known as Beam Software.

DSC03818 DSC03819 DSC03820

I'd played this game with my brother decades ago on the 286/386. Actually, I think nearly every Australian kid who grew up in the 80s/90s would've played this on a platform somewhere... maybe sega/nintendo/x86/amiga/atari/etc... Or even at the arcade! Either way, I wanted to check this out on the Commodore 64.

Intricacies of a Datasette Drive

This device has a single cable that plugs onto the PCB edge-connector 'port' at the back of the C64. It's a similar connection to the User Port; very raw and very cheap for Commodore to produce en-mass. The cable also has a grounding wire, but I don't quite know where you'd connect this to?

DSC03790 DSC03791 DSC03817

As you can see, everything was there, ready to hook up and run. I did just that, plugging the tape drive in, the power and TV. Switching it all on brought me to the usual BASIC prompt. I had heard the tape drive make a few faint clicks. The tape needed rewinding, so I let that run it's course (hah, how I don't miss having to do that!)

I'd found out, by accidently typing only LOAD previously, that this was the command to load tapes. After hitting enter, you get a prompt to press the Play button on the tape drive. So, at this point, I did exactly that. As I hit Play on the Datasette, the tape spun, then slowed down... then .... stopped......... Sure, this 30 year-old equipment had been stagnating in someones shed for decades... probably worn-out and dead.

As I was pressing the eject button, the tape started playing again... demons? ghost in the machine? not quite... turns out that a slight bit of pressure on the eject button releases the bottom-right 'guide' that keeps tension on the magnetic tape in the tape case as the tape is playing. This component was able to apply WAY too much tension and therefore effectively 'braked' the tape and cause the motor/band to slip.

'Band', you say? Yes. Band. No belts with teeth here... the drive mechanism is a cute little motor with a rubber band driving the other pulleys. There is then a further rubber band to drive the counter. 'How do I know this?', you ask? ... I took the thing apart as soon as I could!

DSC03824 DSC03826 DSC03827

DSC03828 DSC03829 DSC03830

The bands looked pretty stock-standard. A quick google showed zero results for replacements... so... searching around the house I found some probably-too-small substitutes. Having a band too tight will probably pull on components and put waaaay too much pressure on old equipment that may not be rated for it; but hey, you can only try!

DSC03847 DSC03850 DSC03851

Replacing the main band required 3 screws to be removed. See above. Once removed or loosened, you can slip the main band out.

DSC03844 DSC03845 DSC03831

I then put my two replacements in. Lo'and'behold... the bloody tape started playing. The results? The screen went blue for 15.5 counts, the tape paused and then a message came up: Found Double Dragon! Woah.. then a slight pause and then the tape continued. Then it was ... rubbish?

DSC03822 DSC03823 DSC03832

I gave up after 20s of garbage picture and noise... must be a crap tape or damaged head. But... it did recognise the data on the tape... I mean, it knew the name?

Another Tape: The Android

Along with the datasette drive, I also purchased a 5-tape set of miscellaneous games. I whipped the first one out, named Android and tried it. The C64 successully saw that it was indeed The Android and then ... more crap loading. Loosing heart, full bladder, too much Sapporo... I excused myself, letting it play...

DSC03832 DSC03837 DSC03839

Returned a while later and.. WHAT THE!?... It loaded!? So... wait... those loading images are expected!? That crappy video that would trigger an epileptic fit and that sound that's drilling into my inner-ear is normal?

Android Control (different name on tape vs. name on 'found' vs. name on title?) loaded, I played it for 5 seconds... but I'll try that again later.

Back to Double Dragon

So, now knowing that I need to sit back and wait... I slapped Double Dragon back in again. It took the same 15.5 counts to the Found Double Dragon message and then 58 counts to the next message.

DSC03835 DSC03841 DSC03843

Ok, we're getting somewhere... I hit space...

DSC03852 DSC03842 DSC03853

DAMN! 3 minutes of waiting... first time around the tape actually reached the end... that actually indicates a data issue. Second time around I got the error above. So Android will load, but Double Dragon wont! Might have to clean the heads... Will report back when I have time to try again.