When MuleSoft engineering recently organized a two-day internal hackathon, our team of four:
immediately got to work brainstorming what to build. Very quickly we gravitated towards creating an interactive IoT installation that would illustrate how MuleSoft’s technology makes it easy to connect the world’s data and devices together in interesting and useful ways. Moreover, we also wondered how far we could stretch the limits of connectivity. What if we could connect to something that didn’t have an API ready for us to use? What if we could connect to something that had never been a part of the internet before? That was when we decided to try and turn a Commodore 64 into an IoT device!
The Commodore 64 was introduced in 1982 and was the best selling personal computer in history. In its day, it was the best gaming machine available, due to its innovative graphics and audio chips. As great as it was in 1982, there were major limitations we knew we had to overcome to bring it into 2016.
The first problem is, obviously, there is no ethernet port and certainly no WiFi, so how do we connect it to anything? The second problem was that it has “only” 64KB of RAM, so even if we could somehow feed it some Twitter JSON input, we would not even have enough space to store all those bytes, let alone process them!
We wanted the Commodore 64 to display data from various services, like Twitter, real-time weather, and the MuleSoft visitor log. Our goal was to have the Commodore 64 sitting in our lobby, greeting visitors and showing that MuleSoft can truly connect anything. To make the Commodore 64 into a fully functional IoT device we designed a RESTful API to allow it to be controlled from a phone where users can send certain commands such as changing the displayed colors or making it play a sequence of beeps.
To achieve all of this we came up with the following reference architecture:
On the left-hand side, we have the various sources of data that we wanted to draw from. There’s the weather API service, the Twitter API service, and also the web/mobile control site. Processing all of those data sources is a Mule application running in Cloudhub that uses DataWeave to trim and transform the raw data into commands that can be understood by the Commodore 64 and then places those commands as messages onto our cloud messaging solution, Anypoint MQ. On the right hand-side, we have a Raspberry Pi running a slimmed-down version of Mule that has the internet connectivity to pull the messages off of the queue and send them to the Commodore 64. Architecting the solution this way led to concise, loosely coupled components that could all be developed and tested in isolation and then brought together later to form the finished product (almost like microservices).
On the Commodore 64 side, the first issue we tackled was connectivity. It has a general purpose I/O port, which, after some internet trawling, turned out could be used as a primitive serial port. Then we found schematics for a simple cable which converts the I/O signals into standard RS-232 serial signals that could be read from and written to by the Raspberry Pi. As for programming the Commodore 64 itself we used a mixture of Commodore Basic and 6502 assembly language, which could read simple command strings from the I/O port and display them on the screen. Finally, for a bit of graphical flair, we thought it would be really cool to render the MuleSoft logo and an animated mule in a pixelated form on the screen. To accomplish this we spent some time and effort resizing and cleaning up the MuleSoft logo to match the Commodore’s 40×25 character screen resolution and then packaged the raw bytes into the code in a way that was simple to render. All of this prototyping was possible using a Commodore 64 emulator running on our laptops, which was great because it would be a while before we had the actual hardware.