When MuleSoft engineering recently organized a two-day internal hackathon, our team of four:
- Jeff Harris – Principal Engineer
- James Hall – Interaction Designer
- Steven Butt – Senior Software Engineer
- James Nieper – Senior DevOps Engineer
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.
Feeding the Commodore 64 data from the internet is an application we developed using Mule ESB and Dataweave and then deployed into the cloud using Cloudhub. The Mule application retrieves information by polling Twitter and weather APIs for updates. We also packaged into it a responsive web UI that interfaces with a RESTful API control layer to accept direct input from any user accessing that UI on any computer or mobile device. All of the data from API calls and external service updates get processed through the Dataweave transformation language to form simple messages that could be handled by the Commodore’s minimal processing power. For example, a single Twitter status update coming from the Twitter API yields a large JSON payload with all kinds of metadata, but the only things we needed to display on the Commodore were the username, date, and text of the message. A few lines of Dataweave code made it extremely easy to convert that complex original JSON into a concise message that the Commodore 64 could handle.
To enable simple, reliable, fault-tolerant data transfer between the Cloudhub application and the Commodore 64 we created a message queue on Anypoint MQ and pushed all information updates as messages through that queue. On the receiving side, the Raspberry Pi connected to the Commodore 64 would poll the queue regularly for updates and when it received a message it would send it across the emulated serial port to the Commodore. All of this was configured quite easily using the pre-built Anypoint MQ connector that only needed client credentials and the queue name to push and pull messages from both the Cloudhub application and Mule running on the Raspberry Pi. Using Anypoint MQ was a great option because it meant the Commodore could dictate at its own pace when it would process the updates, and it gave us built-in fault tolerance and scalability!
After the hackathon was over and our emulated setup was proven to work we purchased a real 1985 Commodore 64 and the necessary accessories from eBay. We connected the I/O port to a Raspberry Pi with a custom-made cable, and with only a couple of minor changes, our application ran on the actual hardware! At last, a real Commodore 64 was connected to the application network as an IoT device!
We were invited to demo our hack at MuleSoft Connect, and for that, we made a few enhancements. First, we added an extra screen which allows a tweet to be sent directly from the Commodore. Behind the scenes, once the tweet text is entered on the Commodore keyboard, the data is sent through the I/O port to the Raspberry Pi where it is processed by the Mule application. This actually made it really easy to implement, as all the heavy lifting of authentication and knowledge of the Twitter API is inside the Mule application, not on the Commodore. In fact, it was so easy that we then decided to add even more functionality by connecting the Commodore to a set of Philips Hue smart light bulbs. Once completed, the Commodore 64 space key toggled the lights on and off, and the number keys changed the colors. The implementation was very similar to sending a tweet, with the complexity of detecting and controlling the lights via the Hue API handled by the Mule application.
This was a great hack, but it also serves as a fun illustration of the power of connecting real business systems together into an application network. A more real-world example might be trying to modernize a legacy order fulfillment system that doesn’t provide a RESTful API naturally on its own. If a solution similar to what we built here exposed an API to the antiquated ordering system then it could provide a wealth of previously unused data and open new opportunities for the business.
The Commodore 64 was an amazing machine 30 years ago. In 2016, MuleSoft technology enabled us to expose its capabilities to the world. If you’ve got another great idea, give Anypoint Platform a try and see what you think!
