Code, the Universe and everything…

In the previous post we looked at implementation details of the Cloud enabled Commodore 64. In this post I would like to sum up the project and retrospect of what I might have done differently.

In general, I am extremely happy about how the project turned out. First and foremost – it does work! I was able to put all technologies together and line all the stars up to the point where an almost 40-year-old computer is talking to cloud and thus can connect to other – more modern – devices.

I also have to admit that I am amazed how great the Vice emulator is. I was not confident that it would be possible to implement the project end-to-end on an emulator and – even if it were – that the code would run on the actual hardware without any additional debugging.

Having said that after looking back at this project I found a few things I might have done differently.

Time management

I have not put any timelines on this project. I worked on it only on and off – when the time allowed, and when I felt like it. As a result, it took almost a year to drive it to completion. This was only a hobby project so it is not a big deal, but I feel that if I were more focused, I could have finished it in half of that time.

Use the C language instead of assembly

When I embarked on this project, I decided to solely use assembly for the Commodore 64 code. Halfway through I looked more at what the cc65 had to offer and pondered moving to C. There were a few downsides to this approach like the ramp up time or having to figure out how to mix assembly and C especially in the context of interrupt handling. I also was concerned about the size of the binary produced by the compiler. This was probably unreasonable as I did not include any artifacts like graphics or music. Switching to the C language could increase my productivity in the long run, reduce the number of hacks I implemented (especially towards the end of the project) and make the code more accessible.

Run the SignalR client on the board instead of on the C-64

One of the principles of the project was to use the NodeMCU/ESP8266 board only as a simple network card and have the C64 run everything else. I felt like pushing more logic to the NodeMCU board would be “cheating”. Relying more on NodeMCU/ESP8266 could have a couple advantages:

• having to write much less 6502 assembly and, as a result, potentially finishing the project faster
• a general use SignalR client in C oriented towards embedded systems

Run serial communication at more than 1200 bauds

To simplify the project, I decided to run communication between C64 and the C64 WiFi modem at 1200 bauds. This is really, really slow. If “1200 bauds” does not tell you much: this is roughly 120 bytes per second. C64 can potentially support up to 2400 bauds. The C64 WiFi modem supports speeds up to 9600 bauds. To run at these speeds, I would have to use special routines for handling serial traffic. This would bring the transfer to almost 1KB/s. To be honest, given today’s transfer speeds, I don’t think achieving 9600 bauds would make any difference. This project does not and will never have any practical use, so 1200 bauds is probably as good as 9600 bauds. We also only have less than 60 KB of memory to fill (after disabling all ROMs).

Addendum

There is a quite hilarious twist to the paragraph above. I wrote it after briefly testing the project on the actual hardware but before making the video I posted on youtube. When I was shooting the video I started seeing garbage on the screen. It started innocently – apparently the exclamation point was not shown properly. I immediately knew something bad was happening because I did have a dedicated code to handle punctuation marks. Nevertheless, I ignored the error hoping it won’t get worse. Unfortunately things went south really quickly – see for yourself:

I took a break to debug the issue and was only able to reproduce it on the actual Commodore 64 but never on the emulator. I concluded that I was hitting one of the bugs in the KERNAL code handling serial communication which would result in occasionally flipping bits. Indeed, after lowering the serial connection transfer speed from 1200 bauds to 600 bauds the problem disappeared. So, for the demo, I ended up with 600 baud for the real C-64 and 1200 baud for the emulator as the emulator did not have any issues at “higher” speeds.

These are my biggest take aways from this project. In the next post I am planning to provide steps to anyone interested in trying this project out on their own.