Cloud enabled Commodore 64: Part I – Introduction

This is the first post in a series that talks about my recent project dubbed “Cloud enabled Commodore 64”. The project is an attempt to connect Commodore 64 to Cloud (Azure) and let it communicate with a variety of clients – both modern and vintage. Here is a demo of the final result:

I had the idea of connecting Commodore 64 to Cloud in my head for a really long time. When I initially tried to take a stab at it, it was apparent that I didn’t have skills necessary to build the hardware. When the C64 WiFi modem came out I have already moved on and did not pay attention. Until that one, dark autumn Friday night, when I was browsing ebay and came across a C64 WiFi modem which I promptly bought. To be honest I did not even spend too much time looking at the pictures and when it arrived, I was very surprised to notice that the modem is just a NodeMCU Esp8266 board that can be plugged in to the C64 User port. This was a very pleasant surprise because I was already familiar with NodeMCU – I used it for one of the first ASP.Net Core SignalR demos.

The main purpose of the original C64 WiFi modem and its firmware was to allow Commodore 64 owners access BBS’es around the world with software called Nova Term. This did does not appeal to me at all. Due to the times and place I grew up in I did not even have access to a landline and the only way to get new software was via swapping with other enthusiast either at school or over mail. I did spend a night playing with the modem and figured one can use this modem to connect to a BBS directly from a Mac or Linux using screen (or a PC using Putty). This convinced me that the modem works and that my idea suddenly became real.

How? – High level design

The modem pretty much dictated the design. The communication between C64 and the modem would use Serial protocol and the modem would require a firmware that would deal with all network related affairs.

I decided on a few principles upfront:

Modem firmware will only deal with network (i.e. will not include client specific logic)
C64 software will be written in 6502 assembly
C64 software will use built-in Serial routines (KERNAL)
I will use Azure as the cloud provider and will use SignalR

I decided to use 6502 assembly to remember the fun I had using it on my first computer when I was a kid. Right decision or not, it made me appreciate how much progress have been made with regards to programming since then.

The KERNAL routines for Serial protocol are infamous for their bugs but they work OK at low speeds. There are several routines that patch and fix KERNAL code responsible for serial communication and allow reliable transfers at 2400 or even 9600 bauds. After I started investigating, I quickly realized that researching this subject would be interesting but also very time consuming. While it would be nice to have faster serial communication, running at 1200 bauds felt to be fast enough for this project – let’s be honest, in today’s world 9600 bauds is as fast (or as slow) as 1200 bauds and I never thought this project could have any practical usages.

Finally, I decided to go with Azure simply because I am much more familiar with Azure than AWS or Google Cloud. I am also quite familiar with SignalR and how it allows building engaging demos with the canonical example of a chat app being something that might even seem a legit use case for a 40-year-old computer.

These were my thoughts before I embarked on this project. I will however revisit some of these decision in a future post where I will reflect on surprises I encountered and what I could have done differently.

Why?

As noted before – this project was never supposed to have any practical usages. I just thought it would be a fun hobby project. And it really was. Seeing it working live on a real hardware was a blast.

That’s it for today. Next time I will go over the environment I used to develop this.

Raspmodore 360

My brother is visiting us from overseas and I thought it would be cool to set up some kind of a retro gaming environment we could use to refresh our memories from childhood when we spent hours playing M.U.L.E., Kikstart 2 or HatTrick on our Commodore 64. Raspberry Pi seemed a perfect choice – it’s close to the TV (or already connected if you are using Raspbmc) and it has access to the network which makes it easy to acquire software. To play games however you need some kind of a controller. So, what else is close to the TV? An XBox! And it actually has some controllers (let’s forget about Kinect for now). And this is how I came up with the idea of something I called:

– a Commodore 64 emulator running on Raspberry Pi and using XBox 360 controllers. Setting things up turned out to be relatively easy. First you need to install Vice emulator. You can find some steps here but they don’t actually work. Firstly they refer to the “squeeze” distro and you most likely have the “wheezy” distro (the “regular” Raspbian image recommended on the Raspberry Pi download page). Secondly the Raspbian “wheezy” image is a hard float image and when running Vice installed from ftp.uk.debian.org it just dies with the Segmentation Fault error. After my last battle with Raspberry Pi, Mono and EF6 I think it might be possible to install the package from ftp.uk.debian.org on the Soft-float Debian “wheezy” distro but this distro is a bit slower so I kept looking for a version I could run directly on Raspbian. Soon I found this thread which points to something that seems like a private version of Vice built for armhf architecture. If you just follow the steps (btw. notice the _armhf suffix in the Vice package – the package from ftp.uk.debian.org does not have this suffix and I believe this is the reason it doesn’t work on Raspbian):

wget http://www.frank-buss.de/raspberrypi/vice_2.3.dfsg-4_armhf.deb
dpkg -i vice_2.3.dfsg-4_armhf.deb
wget http://www.zimmers.net/anonftp/pub/cbm/crossplatform/emulators/VICE/old/vice-1.5-roms.tar.gz
tar -xvzf vice-1.5-roms.tar.gz
cp -a vice-1.5-roms/data/* /usr/lib/vice/

you will end up with a working C64 emulator on your Raspberry Pi (don’t forget to copy ROMs or you will have an opportunity to see yet another Segmentation Fault error – verified empirically). Just run a console window in the X Window environment and start Vice emulator with the x64 command.
[Spoiler Warning] Had I run any game at this point I would probably have given up setting up the controllers but I did not and instead[/Spoiler Warning] I moved on to setting up the controllers. It seemed to be very easy. There is this xboxdrv thingy you install and stuff should just work (note: you will need the XBox 360 controller “for Windows” – it contains a standalone USB receiver which you will need to plug into your Raspberry Pi (your “Windows” today)). To install xboxdrv you just need to run the following commands:

sudo apt-get update
sudo apt-get install xboxdrv

Just to see if/that the controller works I started the xboxdrv and turned on verbose output

sudo xboxdrv --v

synced the controller and started pressing buttons and pushing sticks. Unfortunately I did not see any activity on the screen. I “reset” the controller (i.e. removed and replaced batteries) pressed the button on the receiver to initiate syncing and turned on the controller. Again it synced fine but I could not see any activity in the xboxdrv window regardless of what I did to the controller. I even restarted my Raspberry Pi and repeated the process but it still did not help. I found a small app called jstest-gtk that allows testing joysticks but it could not find any controllers attached. I learnt about a few interesting debugging options built in xboxdrv (like debugging at the USB protocol level) but this did not help much. With that I started thinking that it must have been a problem with the controller so I grabbed a different one turned it on and… it synced immediately. That was unexpected since I did not press the sync button on the receiver. This is when I realized that the Problem Existed Between Chair And Keyboard (PEBCAK). I had been trying to sync the controller by pressing the button on the receiver but had not pressed the sync button on the controller itself. Therefore the controller started the Xbox located in a different room and then was syncing with it rather than with the receiver connected to the Raspberry Pi. A complete fail on my side. It took me a while to get over my lameness but when I did the things went smoothly. I disconnected my Xbox and really synced my controller with the receiver connected to my Raspberry Pi. xboxdrv woke up and jstest-gtk finally showed that there is a controller present. I configured Vice to use arrow keys as joystick and space as the fire button. The only remaining thing was to map the controller joystick and button(s). This is not difficult and can be done just by providing parameters when starting xboxdrv – just like this:

sudo xboxdrv –ui-axismap x1=KEY_LEFT:KEY_RIGHT,y1=KEY_UP,KEY_DOWN –ui-buttonmap a=XK_space

I started the emulator and ran a game. The controller worked fine – I was able to use it but I was not really able to play any game. Vice was way too slow – games ran just at 5-7 frames per second and the terminal window I used to start Vice from constantly showed the message:
Warning – Your machine is to slow for current settings
I played for 10 more minutes and gave up. That’s too bad. I still don’t quite understand why Raspberry Pi is not able to handle this. I ended up digging up the original Xbox from my garage. It has an ancient version of XBMC but with a working Commodore 64 emulator. We used it instead of Raspberry Pi. Unfortunately when playing M.U.L.E. pirates helped my brother by stealing all my smithore twice (the second time in the 11th round) and I lost the game. It probably would not have felt that bitter had it happened on Raspberry Pi.

Introducing Vintage Studio

Once in a while I get into this nostalgic mood when I want to go back in time and experience again the excitement I had when I got my first computer. It was a Commodore 64. And yes, the nostalgia is about playing M.U.L.E., Rick Dangerous or Kennedy Approach but also (and maybe foremost) about spending time with TurboAssembler trying to open sideborders or figuring out how FLD/FLI/VSP work. Playing retro games is not a problem these days but trying to code is kind of cumbersome. I really loved TurboAssembler and there are features (like numbered bookmarks) I am still missing but the world has moved on. These days we don’t use 5.25” floppies anymore, our processors are a bit faster than 1 MHz, we have access to the Internet at home and instead of using ← 3 to ‘assemble’ we compile with Ctrl+Shift+B or F6 (some people even use a mouse and and an option from the menu). So, I thought it would be nice to combine these two worlds. The release of Visual Studio 2010 helped a lot – the new WPF editor is much easier to extend than before (I started rejecting COM and all its ATL classes in early 2000s) and the MPF project made it possible to code everything in C#. This is how Vintage Studio – a Visual Studio 2010 based IDE for vintage computers – emerged. I created a short video showing the features and how it works (or maybe showing that the workflow – i.e. building, running and debugging – is pretty much the same as you would expect from any VS project). Binaries and source code are available on github. Enjoy!

Pawel Kadluczka