Subscribe via RSS

Virtual Box vs. Hyper-V (Visual Studio Android Emulator)

I've had Virtual Box running for ages. I use it for experimenting... I also use it to host VPN'd OS'. The whole concept of having applications and OS' fixed into a container is fantastic.

I also dabble with Smart-phone development; usually using a Macintosh or Android Studio on Windows. I recently became aware that Visual Studio Community 2015 comes with the opportunity to code Android/iOS apps via Xamarin.

I've attempted Xamarin before, but never built anything productive. This was years ago and have since forgotten about it. Seeing this option in VS meant that MS were somehow backing it and I therefore took the plunge.

Installing it was fine and building a sample 'WebView' application harmless. It even ran successfully in the emulator!

VirtualBox Conflict

Later in the day, I attempted to boot up my trusty VM to acquire a few things. I was greeted with the error that VT-x was not available. I attempted to re-configure the machine, but the Acceleration tab was disabled as Virtual Box could not actually find any acceleration to use.

It turns out that installing the Android Emulator for VS also installed Hyper-V Virtualisation. On any windows machine, only one Virtualisation manager can be installed and VirtualBox is not compatible with Hyper-V! There's a blog post here of someone asking the same questions.

I have found one blog post by Scott Hanselman that tells you how to 'multi-boot' into Windows where Hyper-V is disabled, but then you cannot run your Android Emulator. This post was actually from January in 2014! I'm surprised I've only just hit this issue.

It turns out that VirtualBox simply cannot work with Hyper-V. I'm not sure if the Android Emulator can work without it.

I attempted a switch to VMWare only to find that it is also not compatible with Hyper-V! At least it presents you with an appropriate message.

The Answer

The solution to all of this is to use the Hyper-V Manager which is installed as part of Hyper-V and create virtual machines from there. I haven't done this yet, but am not expecting too many issues.


Creating a bootable DOS HDD without a boot device

I've come across this problem twice now. Both times it has been with older 'subnotebooks' which have no internal removable media and don't have the ability to boot from external drives. You also may just not have the ability to create a bootable floppy disk.


The problem also occurs when you have a harddisk, a USB to IDE converter and you want to make a bootable DOS partition on it. This can be done with USB keys, but HDDs, when attached to the USB bus, appear differently and most tools wont want to work with larger drives.

Using a virtual solution

Most emulators allow 'direct disk' access to physical drives attached to your PC. This can be a godsend, or can be seriously dangerous! I've tried a few now, and I'm a total fan of VMWare. Both DOSBOX and Virtual Box failed me.

DOSBOX got very close... I created a partition using diskpart in Windows 10 and then mounted the new drive as c in DOSBOX. I then mounted a DOS 6.22 disk image and tried to run the fdisk/sys/format commands, which all reported Incorrect DOS version. Booting DOSBOX with the floppy image resulted in not being able to access the HDD at all.

Virtual Box, with a lot of trickery, allowed direct physical access to the HDD. Unfortunately, the format and fdisk commands failed miserably with out of space (or other random) errors.

Preparing your disk with VMWare

Find a suitable version of VMWare Workstation and create a new virtual machine. It doesn't need to be high spec; give it 64mb RAM and no storage. Attach a floppy image (grab one from AllBootDisks). Next, go to Disk Management in Windows and work out your drive number. You can see below that I want drive number 3.


Once you've got this, you can configure a new storage device in your new virtual machine.

set-phys-1 set-phys-2 set-phys-3

set-phys-4 set-phys-5

If you chose Entire Disk then you'll be able to do the whole lot, regardless of the drive state, with VMWare. Otherwise, choosing Individual Partition will mean that you'll need to partition the drive somewhere else first.

98se-boot-disk fdisk sys

Once you're booted, you should be at a DOS prompt with all the tools you'll need. Run fdisk first and create your partitions. Make sure you set one to active!

Reboot the machine at this point, just to make sure all settings stick. Once back in, run fdisk /mbr for good measure. This will properly re-create the MS-DOS Master Boot Record that'll allow your BIOS to find your active boot partition.

Now that you've got a valid partition, run a format c:/s to format C as FAT and transfer system files to make it entirely bootable. Give the partition a label when it asks.

Copy Windows Setup Files

Grab a copy of your favourite windows from WinWorld. This particular laptop was 'built for Millenium'... hah... so I retrieved that ISO. I loved the screenshots!


The best thing to do at this point (and the whole reason why we're here) is to copy over an entire Windows setup folder to the disk. This means that setup will be really quick and, down the track, you'll always have setup files handy. Remember how many times WFW311 used to ask for the network disk? Even if you were just changing IP configuration?

Note that the copying of the Windows Setup folder can be done outside of an emulator. The proviso here is that your host can read the format of the newly partitioned drive. Once copied, cleanly unmount the disk and get it back into the target machine.

If you get to a DOS Prompt, then you should only have to change to the windows setup folder and then run setup.exe.


Japanese Medical Massage Chair

I could not resist going back for this item. Not only was it an antique, it was also a random Japanese item from the early 60s which had somehow made its way to Melbourne.


Hah, it's crazy. Could it be the first edition of those chairs you put coins in at the airport.


DSC06447 DSC06448 DSC06422

I have more information on that sticker above here. This was the only link with a similar chair. I wonder if I'll ever find the exact details? The shop owner told me that it was sold as-is. The cord was missing a real plug and it had never been electrically tested. I didn't mind at all... I mean... how difficult could the internals really be?


DSC06453 DSC06454 DSC06455

DSC06456 DSC06457 DSC06458

Getting it going...

The mechanics seemed in very good working order. I applied a little more grease just to ease the friction further. The internals showed very simple wiring: the mains was fed into a double-pole double-throw switch which allowed speed control. There was a capacitor which seems to be an induction-motor capacitor to facility motor start. I must admit that it won't spin up on the low speed without a rolling start. I'll look in to replacing this.

I was initially going to find a replacement engine and overhaul the guts to 240v, but then realised that there were pretty cheap transformers that could cope with the wattage. One of these arrived from Sydney in no time at all!

DSC06444 DSC06432 DSC06433

You can see that the cable it was supplied with was junk. This was removed pretty quickly and replaced with a USA power cord found at Jaycar. Their site says they are out of stock everywhere, but the Melbourne City store had 100s. I used a terminal block to hook it up internally and the cable worked perfectly.

DSC06438 DSC06440 DSC06442

And, just to see it in action:

The rest is history... the chair just worked. 60 years later? Not too bad at all.. the massage it gives is great too!


Remove batteries from unused electronics!

Recently, on one of my weekend visit-a-new-area-of-melbourne trips, I ventured into a thrift shop and stumbled across a wireless keyboard/mouse combination from Logitec. Usually I wouldn't look twice at the combo, but this time I did as I saw that it had PS/2 connectors at the other end!

My 386 was on its way, so this keyboard would be a perfect complement. I don't often go for wireless input devices as I'm not a fan of battery replacement, but I do remember that a wireless mouse from a previous company worked for around 6 months before showing the haywire symptoms of a dying battery.

Getting it home, I found that the keyboard was void of batteries. I was happy with this, as I didn't want to see anything corroded in there. Unfortunately, this wasn't the same for the mouse. The previous owner had left two cheap AAA batteries in there and one had failed.


I pulled it apart straight away to assess the damage. Most of it was on the actual plate that runs into the battery chamber... but the corrosion had edged its way to the PCB also. Fortunately, on a redundant track. I quickly cleaned this off with alcohol wipes and a bit of scrubbing.


The next trick was to fashion two new plates. I'd recently been dismantling a satellite decoder and this had a lot of RF shielding. One of these metal shields came in handy.

DSC06407 DSC06408 DSC06414

A bit of soldering and some thick legs off a few power diodes and I had two new plates in and new batteries connected!

DSC06415 DSC06416 DSC06418

This is one of the smoothest mice I've ever used, in Windows for Workgroups anyway!


Random New Acquisition

I would've really loved to have been told the story behind this... Who would bother importing it to Australia? No real idea as it was in an antique store from an estate. Someone must've enjoyed the technology during the last war and taken it home with them?


And the text version:


型式認可 91-7948 厚生省認可 47B-371
定格電圧 100V 定格周波数 50/60Hz
定格消費電力 4P 150/125W 6P 125/100W
定格時間 30分 製造番号 721 0280
製造者名 株式会社 日本医療電機研究所

100v will mean a new motor or a step-down transformer that can handle the wattage. Stay tuned...


Commodore 64: Fixing RS-232 Serial Limitations

This is going to be a bit of a rant, so I apologise in advance. I have just spent a good 75 hours getting the C64 to talk to an Arduino via RS-232 and each step of the way has been painful. Initially, communications were sorted and data made it across to the Arduino. All wasn't as it should be as I realised that the character mappings (PETSCII vs ASCII) meant that the data had to be translated. Once that was sorted, it was a matter of sending data back. Again, character mappings were required. Past this, I then wanted to send 64-bits of raw data. Not characters, but 8-bits-to-a-byte raw data as I wanted up to 64 sensors and therefore only 8 bytes to transmit this. Turns out that the C64 is hard-coded to transmute the serial value zero to something else...

Diagnosing the issue

I'd already built up a large-ish application on the C64 for controlling the trains. There was also a large amount of code on the Arduino side. Due to this, any support libraries or includes or other interrupt-hacking routines could've been interjecting and mangling data. After a lot of to-ing and fro-ing, compiling on windows and switching to SD card... I got jack of the speed of which I was able to debug on real hardware.

Fortunately, VICE came to my rescue. Not only does it have a debugger, but it also emulates the RS-232 User Port Serial and shit... it even reproduced the error! Let me show you how to set that up...

Configuring VICE's User Port Serial

rs232-userport-settingsOpen VICE and choose Settings -> Catridge/IO Settings -> RS232 userport settings.... Enable the RS232 userport emulation, leave it as device 1 and set the baud rate to 2400. Hit OK.

rs232-settingsBack to Settings -> RS232 settings.... We want to edit RS232 device 1. Fill in the text box with the relevant IP and port of the machine you wish to communicate with. If you're going to use my TCP server below, then enter

Close VICE. Next time you open it, VICE will attempt to connect to a TCP Server listening on your localhost IP on port 25232. You can configure this to whatever you want, but we are going to use the default. VICE will then treat the connection as RS-232 and provide any data received to the internal C64 user port. It will also send out any data sent to the user port via this channel.

Now that we're done with the settings, we need to give it something to connect to.

TCP Server in C#

Download the code here. I've rigged up a very simple C# TCP server for VICE to connect to. The TCP server must always be loaded first, otherwise VICE will continue silently and never send out any data. The code is also overly-primitive and, upon closing VICE, the TCP server will need to be restarted prior to starting another instance of VICE.


Once running, you can use the 1-8 keys to set the bits of the byte to be sent. Alternatively, pressing any keys of the alphabet will set the byte to that letter in ASCII.

Finally, hitting Enter will transmit the byte.

C64 RS-232 Serial Test Program

Grab the Serial Test Application here that I wrote to test the RS-232 serial port on the C64 using Johan's driver. There's a batch file in there that you can use to run the program. Just make sure it knows where VICE is.

Make sure the TCP Server is loaded first, then run the batch program. It's set to auto-start the binary. If this doesn't work, then you can open VICE and via Settings -> Peripheral Settings... configure the directory where the binary is. You can then LOAD it as per usual.


Once loaded, you'll be in the app. It's pretty straightforward and will just print out the data that has been received.


Make sure that the TCP Server has shown that the connection has been established. You can now press the keys as per the instructions above on the TCP Server and send data. At the bottom is a timer and a number of bytes received. As each byte comes in, it'll be displayed up the top. It'll also be numerically represented down below, next to in:, above the clock.

At this point, type random letters from the alphabet and send them to the C64. You'll note that lowercase get translated to uppercase thanks to the ASCII to PETSCII translation. Tinker with the 1-8 keys to set the relevant bits in the byte to send and then hit enter. Watch that 1 = 1, 2 = 2, etc... until you try to send a raw zero... bugger.

Debugging the problem

Ok, we've now worked out that, even in the land of emulation, sending a zero to the RS-232 serial port on the C64 produces an 0x0d. This rules out the 'client'... both the Arduino and my TCP Server send raw zeroes and both VICE and a real C64 render the wrong character once received. From here, it could be the custom driver, the cc65 support libraries or something much more evil.

Debugging on real hardware is something I'm scared of... I'm so used to multiple windows and multi-tasking that I'd like to do it in a more comfortable environment. Thankfully VICE has a monitor that can help us. Open this up via the File menu and prepare to delve into the land of assembler! Note that, when open, the C64 emulation is paused.


Once the emulator and application are loaded, choose View -> Disassembly Window. You'll get a little window showing the entire memory of the emulated C64, disassembled. This means that VICE, with it's knowledge of C64 6502 CPU op-codes, has translated the raw memory into known commands. Fortunately, it also has information on the mapping of the memory and therefore does a very good job of this translation. Unfortunately, there is no search command... so we will need to scour over this to find what we are looking for.

What are we looking for?

The million-dollar question. The serial test app that we've compiled for the C64 (and executed in VICE) is based on the sample code by Johan. It also includes his 2400-baud serial driver. Looking at his source code, we can see the routines that are called when we call the ser_get function from our main loop. If you browse over to his source, you'll find the relevant lines in driver/c64-up2400.s.

        ldx #2
        jsr CHKIN
        jsr rshavedata
        beq GET_NO_DATA
        jsr BASIN
        ldx #$00
        sta (ptr1,x)
        jsr CLRCH 
        lda #<SER_ERR_OK

vice-disassemblyThe snippet above was copied on the 24th of June, 2016. This code has hopefully been updated by now, but what you see above is the function, as it was back at that time, which reads data in from the RS-232 Serial port. I can't fully explain each line, but what we can do is find this chunk of code in the disassembly window. Unfortunately, we'll be doing this by hand as I don't know a better method to search for it.

After a lot of scrolling... this code has been found in memory location $238A. ldx #2 is seen as LDX #$02. The further jumps are visible, but their happy names are gone. Instead we see the memory addresses of each of those functions. You can see that I've also clicked the row in question. This sets a breakpoint, represented as a red highlight on the row.

Triggering the debugger

From here, we can actually close the debugger. Make sure that the red row is set prior to closing the main Monitor window. If you just did this, then you'll find that the debugger window popped back up straight away and now our red breakpoint is a lovely shade of teal. Teal? What happened to Red? In the disassembly list, a blue line indicates the location of the next line to be executed. Ours is teal because it's a set breakpoint AND it's the next line to execute. If you're bored, click the line and it'll turn blue. Click it again and it should return to teal.

Ok, we've triggered it... but why? No data was sent down the channel! It turns out that, if you look at the source above, there's a hint on the line with GET_NO_DATA. The ser_get is called from our code on each program loop; it returns a SER_ERR_NO_DATA when there is no data... so this line we've broken on is too early in the driver code. We really want to set a breakpoint at the first line executed when there is data.

So step through the code. To do this, press the 8th button on the toolbar in the Monitor window. Press it a few more times and watch the execution. We're currently 'stepping over' functions; the two JSRs might well send the program counter off into other parts of memory and execute code, but we don't care. Once you're on the BEQ GET_NO_DATA line, press it again. Note that we now jump down to the location of GET_NO_DATA and exit out. We can assume that this jump is the significant point where, when data exists, the execution continues straight through and does not jump.


Now that we know where this junction is, we want to clear our previous breakpoint and set one on the line directly after BEQ. Set the breakpoint and close the Monitor. It should not pop back up this time.

Viewing the data coming in via Serial

Ok, we've set our breakpoint in the driver and it hasn't triggered yet; let's hope it does when data is received. To test this theory, we'll need to use the TCP Server from above. If it's not already running, close VICE first and then start the Server. You need to have the TCP Server running prior to VICE for the connection to be correctly established. Once everything is running, ensure that the server has reported that the connection is established. Confirm your breakpoint is still in place; VICE doesn't save these, so you'll need to go hunting again if you lost the position. Once everything is configured, make sure you close the Monitor window to allow the C64 emulation to proceed. When the Monitor window is open, the CPU emulation is halted!

Once ready, focus on the TCP Server window and press the a key. Make sure it reports back that the byte is set to 97, which is ASCII. Press the enter key and you should trigger the breakpoint in VICE.

Ok, we've got it, our breakpoint was hit and we presumably have data somewhere? Our breakpoint is actually on a JSR through to the address $FFCF. At this point in time, this address is unfamiliar. All our previous driver code has been around the $2300 mark. Due to this, we're going to step over it. The next call is an LDA which uses a pointer + offset to load a value into register A. Stepping over this, we see the following in the Monitor window:

(C:$2394) n
.C:2397  A2 00       LDX #$00       - A:61 X:03 Y:00 SP:f2 ..-.....    6728381

Interesting... A:61 hey? That's the ASCII HEX value for a lower-case a! So there it is, the value has come through and we can see it in memory. You can close the debugger now and play around with data on the TCP server to see how it arrives on the C64.

Note that as soon as you try to send a zero from the TCP Server, it'll appear as an 0x0d. At this point, we've honed in on the location where the char is read in, but we don't know what code is hosted up in the $FF00 range?

C64 Memory Mapping

Time to go deeper. Thank god we're working on a seriously old system that has been thoroughly documented. You'll find the memory map of the Commodore 64 here. If you scroll down the page, you'll find that the area in question contains the Kernal (Kernel?). At this point... we might as well retire.

Retire? Yes. The KERNAL is ROM, you know... READ-ONLY MEMORY. It's the raw system code burnt onto chips on the motherboard and it is a fixed entity. Those bytes can't be hacked... anything we try to do will require reproduction of kernal commands in the 'user' area. Should we try this? Sure... but first it'd be nice to know what's going on.

C64 Kernal Disassembly

Again, thanks to the age of this system, there's a full disassembly of the C64 Kernal here. We know that we're jumping in to location $FFCF, so browse down to that area.

FFCF   6C 24 03   JMP ($0324)   ; (F157) input char on current device

Oh look, it's just another JMP. Fortunately it's commented and we know to browse through to $F157. Now we are in murky waters... not many comments here. We get a heading of ; input a character, but then not much else. The assembly, to the naked eye, looks like a switch statement. It seems to be going through checking which device to read from. In our case, we can actually step through it in the debugger. If you step into the JSR #$FFCF then you'll be able to watch it jump as you send in characters from the TCP Server.

The basic trail jumps through: $FFCF -> $F157 -> $F166 -> $F173 -> $F1B8 (a.k.a. read a byte from RS-232 bus) via F177. At $F1BD, there's a comparison of the incoming byte to 0x00. If there's no match, then the code jumps out to $F1B3 and returns the value. If there is a zero, then the following occurs:

F1C1   AD 97 02   LDA $0297
F1C4   29 60      AND #$60
F1C6   D0 E9      BNE $F1B1

If the AND fails to compare, then the jump happens at $F1C6 to $F1B1. Looking at $F1B1 made me cry. The code implicitly inserts an 0x0d, overwriting the byte that was read into the buffer and then returns it.

I don't quite know what the LDA from $0297 is and why it is AND'd with #$60. I'm sure there's some RFC or some prehistoric rule back in the late 1980s that said if a modem or other serial device returned a zero, then it actually meant it to be a carriage return. Maybe it was a BBS thing? I'll continue digging and attempt to comment this area of code, but for now... we know that it's futile. The KERNAL ROM is fighting us and thinks it knows better!

A valid workaround

Righto... what do we do here? I initially thought it was a complete loss and gave up. Further Sapporo made me realise that this call was made from our custom driver. What if we specifically mention that our custom driver is built to handle 'zero' byte data and implement a work-around? If we copy out the code from the Kernal and re-produce it in the driver, then we can effectively resolve this (I wont say bug, I'm sure they had their reasons!) issue.

So, the trick here is to grab the portion of code from the full disassembly of the C64 Kernal and build it into a function in Johan's driver.

We know the entry point is $FFCF. This is a JMP to the switch statement which chooses the device. We know that this is the RS-232 driver, so we can skip that part and copy the code from $F1B8 to $F1C8. I've pasted this in below.

; read a byte from RS-232 bus

F1B8   20 4E F1   JSR $F14E
F1BB   B0 F7      BCS $F1B4
F1BD   C9 00      CMP #$00
F1BF   D0 F2      BNE $F1B3
F1C1   AD 97 02   LDA $0297
F1C4   29 60      AND #$60
F1C6   D0 E9      BNE $F1B1
F1C8   F0 EE      BEQ $F1B8

That CMP #$00 is the pain. Let's just jump to $F1B3 all the time. Actually... $F1B3 is just CLC and RTS. Let's just write that. We also can't directly BCS to $F1B4, so we'll need to JSR to a closer function and then call JMP. If we JMP directly then we'll lose our position in the stack.

F1B8   20 4E F1   JSR $F14E
F1BB   B0 F7      BCS $F1B4   ;re-write this to a BCS and JMP
...    ...        CLC
...    ...        RTS

With my patch above, I've removed (what seems to be) a re-try loop in the code. If it falls all the way through to $F1C8 then it returns to $F1B8 and tries to read a character again. I haven't seen this state occur in real life, but I'll keep an eye out and try and work out when this actually occurs. It seems that the AND #$60 must check for an error state which I'm yet to encounter.

I don't actually know the assembled opcodes off-hand. We will write this as standard assembly into the c64-up2400.S driver source file and then it'll write the opcodes on compilation. So, from line 139 we slap in:

; OTHERFUNC: Shortcut to Kernal code

		jmp $F1B4
; OURBASIN: This is a minimised call to get the character from the buffer.
; The Kernal code does not allow zero bytes (0x00)... this does.

		jsr $F14E
; GET: Will fetch a character from the receive buffer and store it into the
; variable pointer to by ptr1. If no data is available, SER_ERR_NO_DATA is
; return.

        ldx #2
        jsr CHKIN
        jsr rshavedata
        beq GET_NO_DATA
        jsr OURBASIN
        ldx #$00
        sta (ptr1,x)
        jsr CLRCH 
        lda #<SER_ERR_OK

I'll give the kernal function a real name soon. Right now the basic point is that we write our own BASIN function that is just a tiny subset of the greater procedure and then skip the part where it inserts that shitty little 0x0d.


Either way... compiling this (see notes on that here) saw the bloody thing work! I'm going to get in touch with Johan now and determine what needs to be tidied up to get this trick included in the trunk.

That was fun!


Skype now has chatbots…

Seems to be all the rage, of late, adding bots... Facebook has done it, so Skype just has to follow along? There's a new icon, top-right of the main window that looks like a happy computer. Next time you're sad and lonely, click it and choose a bot to talk to...

I wasn't... I was happy and devious... and so I chose the CaptionBot. Supposedly it can 'caption' any 'image' you throw at it... What would a devious mind choose to send?


Bravo, old chap! Two-outta-three ain't bad.


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.


Parallel Port: Digital to Analog

Most parallel ports on most computers (Amiga, C64, PC, etc...) have (at least) 8 true digital pins that one can interface with for either input or output. This can be extended using shift registers or multiplexers; I've written up an example of this here.

With a lot more pins at one's disposal, more items can be controlled; as long as what you want to control is in the digital realm. To control a standard DC motor, for example, you'll need to be in the analog world and we'll describe how to get there below.

Digital to Analog Converters

The basic principal is to use a number of digital inputs and map these to relevant resistance values on an output. If you had 4 pins available, then you could determine the maximum resistance you needed and divide by the number of pins. You'd then make sure that, as each pin was brought HIGH, that the resistance summed towards the final value that you required.

You can either use a bunch of resistors to do this, or an integrated DAC circuit.

R/2R Ladder

This circuit consists of a bunch of resisters in parallel/serial, using properties of such combinations to provide a stepped resistance output. This is known as an R/2R Ladder and is a popular method for converting digital signals to analog.

We're going to implement one using 10k/20k resistors and an LM358 opamp to buffer the output. This part of the circuit is borrowed from the 8-bit digital to analog converter circuit over at IKALOGIC.

Combining it into our Parallel Port Interface

The 8 outputs from the 595 need to be de-coupled from the LEDs and provided as the inputs to the resistor ladder.


As that we can send any value to the 595, you don't really need to be careful as to which end is the MSB, but do remind yourself of it as it'll become important when writing the software.

DSC03731 DSC03732 DSC03733

You should now be able to check the voltage on pins 1 or 2 to see the variance between 0 and 5v when you're switching the bits on and off.

DSC03740 DSC03745 DSC03746

To my surprise, the output voltage was nearly exactly double the byte value being output by both the Commodore 64 and the Windows Parallel Port.

Once the test breadboard produced the result I wanted, I confirmed it all by soldering it together on the PCB. Not the ugliest mess I've created, but not very far off! And... it works.

DSC03755 DSC03754 DSC03751

What's next?

Now that we have an analog interface, we can control a PWM throttle. To do this, we'll go back to the Arduino world and steal a motor controller. I've previously worked with H-Bridges before and will use a module to make this easy. Controlling direction will be easy also!


Parallel Port: Shift Registers

Now that we've controlled a LED by a single pin on the Parallel Port, it's time to expand our abilities. The goal of this post is to describe the usage of Shift Registers and then consume a minimal amount of pins, 3 out of the 8 available, to control up to 64 outputs!

A Shift What?

So, you have 8 digital input/output pins on the Parallel Port. This isn't the greatest amount and it'd be really nice to extend the amount available. There are a few ways, but a popular method is to employ a shift register.

A shift register is an IC which takes a 'serial' input and then outputs this on it's output pins in 'parallel'. By 'serial', we mean that the IC accepts input data on one pin only. This data is provided by you, as either a '1' or a '0'. Once you've set the value on the input pin, you then toggle another pin, known as the 'clock' pin, to tell the IC that the data is ready to be consumed.

The shift register, once the clock pin is toggled to a '1' and then back to a '0', will look at the input pin and then copy this value into it's internal register. We're using a 74HC595 which has 8 internal registers and therefore 8 output pins. At this point, the IC shifts all values on it's 8 internal registers up one slot and then sets the very first internal slot to the value you've provided.

You can then provide 7 more values, toggling the clock pin between each, an the IC will shift them along it's internal registers. What you've now done is set an 8-bit value inside this IC. Once the IC contains the value you've requested, you toggle the 'latch' pin and the IC will shift these 8 values out to the 8 output pins. These are known as 'parallel' as there is a single pin for each value; as opposed to the input which is serial (or one-after-another) on a single pin.

So, we've used 3 pins/wires here to control 8 output pins... pretty neat hey? We've turned our original 8 Parallel Port pins into (8-3) + 8... 13!

But wait, there's more! There's an 'output' pin on the shift register that reports the 'shifted off' value. What can you do with this? Feed it into a neighbour shift register as the 'input'. Hook up the same clock/latch wires as the first register and then, when you shift the 9th bit into the first, the very first bit you shifted in will be shifted out of the first register and into the second.

This means that, with the same 3 wires, you now have 16 outputs! Of course, you can keep doing this. I can't find anywhere that mentions how many you can effectively chain up. Of course, as you add more, the time to toggle out the values increases and you need to make sure that your code/hardware has time to think about other things instead of spending it all talking to the shift registers.

Connecting it to our previous circuit

We only used one line of the parallel port in the previous circuit and therefore only controlled one LED. For this first shift register, we'll need 3 lines. First thing is to hook up three LEDs with matching resistors. We could just hook two other lines up direct to our new shift register, but I like being able to visualise the data (and troubleshoot issues!)

Parallel-Port with 74HC595With this circuit, you'll be able to use the sample code in the previous post to control the 3 LEDs.

Sending out a 1, 2 or 4 should switch them on individually. Sending any combination of these, by adding them together, will turn on the associated LEDs. For example, sending out the decimal value 3 will switch on the first and second LED. The value 5 will switch on the first and third LED. As the value makes it to the port, it is split into it's individual bits, which are then translated to the data pins.

Once these are working, we're going to splice in some opto-couplers. We don't want any untoward voltages getting back to the parallel port. Optocouplers contain an LED and an internal light sensor. When power is applied to the input, the LED lights and the light sensor receives the signal. This is then output to the secondary circuit. This effectively provides an 'air gap' between the two circuits.

From these couplers we can control our shift register(s). Hook the three outputs to the 74HC595 shift registers SERIAL, CLOCK and LATCH pins. Remember the order as they each play key roles (as per the description of how they work above.)

Once you're ready, check that the three input LEDs react accordingly to basic Parallel Port data. Note that you may get erroneous data coming out of the shift register from the get-go. Data coming off the Parallel Port during system boot cannot be controlled and may cause havoc. We'll do something about this in a later article.

Building this required a LED array... you could do it easier and get one of those bar-graph arrays. Wiring up all the individual LEDs gets a little tricky.

DSC03682 DSC03683 DSC03684

Controlling the data output

Based on the initial description of the shift register, we know that we have to control the 3 data lines in a special sequence. First thing we need is an 8-bit data value to send out. Once we have this we can send each data bit out via the SERIAL line; toggling the CLOCK signal in-between. Finally, toggling the LATCH should see our value displayed in a glorious binary LED representation!

I've used Windows and the Parallel Port code here to manually try and turn on LEDs. My wires are hooked up as D0:SERIAL, D1:CLOCK and D2:LATCH. I am going to send 00000001 as the value to ensure that all LEDs are turned off bar the first.

  1. Ensure that LATCH is low (red)
  2. Toggle D0 to RED, this is a '0' for the first bit of the serial value.
  3. Now toggle the CLOCK (D1) on and off 7 times.
  4. Toggle D0 to GREEN.
  5. Toggle the CLOCK on/off once more.
  6. Toggle D2 on and off...

If everything is hooked up, then you should now have one LED showing on the output of the 74HC595. It didn't quite work with this initial circuit... LEDs would light a little randomly.

DSC03685 DSC03691 DSC03693


Although the above circuit worked, it was not reliable! Every now and then one LED (or two) past the one I wanted to switch on would also switch on! Sure, my soldering was dodgy, let alone the wiring also being messy. Either way, noise was being introduced and the flipping of the serial and clock was jumbled, causing random output.

The solution to this was to put a 100nf capacitor across the +5v and gnd supplying the 74hc595. This cap should be put as close to the IC pins as possible. Once in place, this stabilised the data from the PC Parallel port.


- HowTo: Understand the 74HC595 (David Caffey)
- Gammon Forum: Using a 74HC595 output shift register as a port-expander
- protostack: Introduction to 74HC595 shift register – Controlling 16 LEDs

What's Next?

Next is a 12v throttle. I intend on using the described sample here. The only issue is that it wants a potentiometer to vary the output voltage. This is an analogue method; we'll convert it to digital by calculating 8 resistor values to imitate the throttle at 8 positions.

I'll write this up soon once I've completed the circuit.