Retro-Computing Takes to the Cloud

Old Meets New

Ever leave the house and forget to close your garage door? To address that problem, Todd set out to design and build a cloud-connected solution that checks the door after he’s driven away. To add to the fun, he built it using “retro” electronics, including the ’80s-era Hitachi HD68P01.

Several years back, I built something that more or less worked, but was really only good for notification if something had changed. I wasn’t able to determine what state the door was in once I left. Also, it didn’t make use of an IoT cloud service so much as an Internet-based notification tool. Then, about nine months ago, a friend gifted me with about 10 NOS (New Old Stock) samples of the Hitachi HD68P01 microprocessor, manufactured sometime between the late 1970s and early 1980s (Hitachi Semiconductor is now Renesas Electronics). It was a licensed version of the Motorola 6801, which itself was an extended version of the venerable 6800 (Motorola is now NXP Semiconductors). Motorola extended the base 6800 with things like onboard EPROM/Mask ROM support, some new instructions, and peripherals such as timers, a UART and GPIO. It incorporated a few setup pins that allowed the part to operate in different modes.

In turn, Hitachi took these extensions and added a few twists of their own. First, they added a PROM socket that is built into the top of the 40-pin microprocessor package. This makes reprogramming the device significantly simpler. They also added support for a larger code space, when using the built-in memory socket.

I wanted to do something with these parts because, in addition to being an electronics geek, I’ve become something of a retro-computing fan as well. For example, last year’s project was building a wire-wrapped Z80-based CP/M machine from the ground up. So, now I had these HD68P01 chips and I wanted to do something with them. It occurred to me that I’d never satisfactorily solved my garage door problem, which got me thinking … What if I could marry the HD68P01 with some kind of modern networking device that would allow me to have the features I’d always wanted? My solution is the subject of this article.

BOOTSTRAPPING THE PROJECT
My first steps involved figuring out how to use this venerable device. My initial plan was to get some simple code running on it—just to satisfy my retro-computing goals—and then move on to some other project. Obviously, I ended up going a bit further than that.

First, I needed to find some information about this processor. I managed to pick up a copy of the original reference manual from the Bitsavers website [1]. With the technical data for the part in hand, next I needed some way to write code for this thing. Doing the inevitable web searching, I discovered that C compilers for 6800-series processors were, and remain, pretty hard to come by. And when you can find them, they either don’t run on today’s operating systems, or they don’t support some of the instruction-set extensions for the 6801. Because assembly language was the existing programming approach, that meant I’d need to find an assembler that could run on either Windows or Macintosh.

After more web surfing, I was able to locate the C source code for several 6800-variants that Motorola had released sometime around 1984. Since I only needed the 6801 assembler, I modified the source code for that one to be ANSI compliant. I then took a bit of time to understand the MAKE file that was provided with the assemblers. Using that knowledge, I created a project in the Code::Blocks IDE [2] and compiled the assembler for both Windows and Macintosh.

Once the assembler was built and I could successfully assemble a simple program, I went in search of the source for some form of pre-existing monitor application that I knew Motorola typically provided for their processors. I was familiar with MIKBUG from my work with various of their evaluation boards, and I wondered if there were a port for the 6801. As I was digging, I found a few references to a monitor for the 6801 called LILBUG, but wasn’t able to find the source code anywhere. I did find a PDF of the LILBUG manual [3] that happened to contain a source listing.

As I struggled to extract the source code from the PDF, I kept scouring the web, and finally found a site from a developer who had built a custom bit of hardware around the 6801. It also happened to use LILBUG, albeit heavily modified. The developer made the source code available, so using the original LILBUG manual as a reference, I walked the modified source, restoring it back to its original form. Then, using my shiny new (in 1984) assembler, I was able to create object code for LILBUG (Figure 1).

Now I needed to program some device with LILBUG and plug it into the processor. The HD68P01 has that nice EPROM socket on the top, but I don’t own any old EPROMs or a UV eraser. I do, however, happen to have a device programmer that can program all kinds of current and older devices. But what to use? I didn’t want to purchase a UV eraser or to hunt down compatible EPROMs. Luckily, Microchip Technology still sells a 2764-compatible, through-hole EEPROM known as a 28C64. It’s an 8KB device that will work in any application where a 2764 EPROM was required—and my programmer supports it. That seemed like the way forward.

One of the beauties of the 6801 (and 6803, HD68P01 and others) was what Motorola called “single chip mode.” This was a configuration that allowed the device to operate without the need for external RAM (which would require address decoding, and other glue logic), using either the built-in EPROM (in the case of the 6801) or the external EPROM socket (in the case of the Hitachi version). Because I was initially only interested in getting something simple running, this mode seemed ideal. I built up a circuit on a breadboard and wired it so that the processor would execute in single chip mode (Figure 2).

Great, now I just needed to burn my newly assembled LILBUG monitor into one of those 28C64 EEPROMS, pop it into the HD68P01 socket and I should have an operational system, right? Um…no. At least not really.

HITS AND MISSES
I lashed a USB-to-Serial cable up to the processor (making sure the voltages were compatible), configured my terminal emulator, and applied power. I got bupkis. Hmm… Power was a nice solid 5VDC. The oscillator was running—confirmed that with my scope). Double-checked the processor wiring. Wait—the NMI pin was floating. I checked the documentation and sure enough, you’re supposed to pull that up. Ok, I added a 10kΩ pull-up to the NMI and the IRQ lines, and fired it up again.

This time I got what amounted to part of the LILBUG start-up banner. I could tell because I had the LILBUG manual, so I knew what to expect. I cycled power a few times, and, sure enough I got the full banner. At that point, I thought things were good, and so I tried a few commands. They worked—sort of. Things were really inconsistent. Sometimes the full banner and prompt would appear. Sometimes I could enter commands. Sometimes I would get part of a response. Sometimes the second command would fail. It was all really hit and miss. Back to double-checking all the wiring. All good there. Verified that the clock was not only running, but that the frequency was correct. Again, all good. Now I was really scratching my head.

Ok, go back to the documentation and take a closer look. What was I missing? Well, well…the Hitachi documents describe three versions of the chip: the HD68P01S0, the HD68P01V05 and the HD68P01V07. The parts my friend gave me were the HD68P01V07 model, and the document references using a 4KB, 2732-compatible memory. Yeah, I’m using a 2764-compatible 8KB EEPROM, and I located the code at the top of the device. From the document, it became clear the A12 address line on the device was floating, since the HD68P01V07 variant lists that pin as “NC.” That explains why the code is running inconsistently.

If the line floats high all is well, but if it drifts low the lower portion of the device is selected where there is no legitimate code. With that address line floating, reaching the upper 4KB of the memory requires it to be asserted all the time. Ah ha! I soldered a 10kΩ resister from V_CC to the NC A12 pin on the processor’s memory socket, and plugged the EEPROM back in. Voila! LILBUG worked like a charm. I could have also pulled the A12 low and located the code in the lower half of the device, but since V_CC and A12 are physically adjacent pins it was easiest to pull A12 up right there.

Once I had LILBUG executing reliably, I just couldn’t leave it at that. It was time to start thinking about how to make use of this processor in an IoT application. And what better application than solving my long-standing garage door issue?

LINKING TO THE INTERNET
Because there’s no wired Ethernet available in my garage, my only option for reaching the Internet was Wi-Fi. With that in mind, I started looking into what I could use to establish a network connection for my 70s-era processor, with its limited RAM, code space and peripherals.

I briefly considered ideas like wiring a “bare” Wi-Fi radio up to the 6801, and letting it do the work necessary to manage communicating with it, along with the network protocol and so on. However, it was painfully obvious that this wasn’t going to work for a few reasons. First, when configured in single-chip mode, the processor relies solely on its internal RAM (128 bytes. Yes … Bytes) and the PROM (up to 4KB for code). This small amount of data and code space would never be sufficient to manage a networking stack, plus do the monitoring and control I wanted. Still, owing to the simplicity of the circuit, I fully intended to use it. Second, I would need to build some kind of interface between the Wi-Fi and the 6801, and so I would also need to rely on the onboard peripherals of the processor. Those would only be completely available to me if I ran the part in single-chip mode.

Having quickly ruled out the notion of the 6801 doing all the work, I started wondering what I could bolt onto the processor that could handle the networking, cloud connectivity, application logic and so on. I’d done some recent work with the ESP32 family of devices from Espressif Systems, but never with its older sibling, the 8266. I did a bit of research and found that I could purchase a module based on the 8266 from Seeed Studio [4] for about $7 in single-piece quantities.

It seems to be designed specifically for providing Wi-Fi connectivity to serial port-linked devices. It has Wi-Fi connection management and TCP/IP support, along with a ton of supporting libraries to do just about anything I could imagine—and it’s about the size of a quarter. You can write and download application code to the module using a variety of different development platforms, including Arduino. Perfect for my 6801.

Having found the Seeed Studio module, I decided that code for the 6801 would be designed to make it essentially a passive I/O manager, driven by anything that has a 9600 baud serial port. That way, if I chose to link something different with it, I could. I bought a few of the 8266 modules and started experimenting. That module would be the “master,” providing the network connectivity and application control logic, while managing the 6801, which would handle the low-level I/O to the outside world.

With the overall design concept in mind and working on the breadboard circuit, I started developing the code for the 6801. As I mentioned, I had decided to assign it to the role of I/O manager, while the 8266 would be the high-level application manager and connectivity bridge.

Since my 68xx assembly language skills were long unused, it was also my goal to keep the code in the device as simple (and short!) as possible, while making it easy to use via a UART.

I designed a simple ASCII protocol that would work for a connected processor, yet would also be something a human could type and interpret. The basic ideas of the protocol are that you can SET or READ I/O ports, memory, configuration values, versions and so on. Some values can only be read, while some can be both written and read. All memory and I/O values are read or written in 8-bit ASCII hexadecimal notation. The 6801 only responds to commands and never sends unsolicited data.

The protocol doesn’t make use of any packet validation, but if I encounter any issues with message corruption (due to noise, for example), I may include a simple checksum or something like a Fletcher’s checksum. We’ll keep an eye on it.

CONTROL PROTOCOL
I wanted it to be simple for the 6801 to determine when a new message is starting and when a full message has been received. Since the protocol is all ASCII, I decided to use a “:” as the preamble and a “;” as the message-termination character. The characters in between are expected to be printable ASCII, and the total number of characters received by the 6801 cannot exceed 12. I chose to keep this compact for the sake of the limited RAM available to me, and to make it simpler for a human operator to remember how to enter commands.

Following the message preamble is either a “C” (command) or an “R” (response) message-type indicator. Messages being received by the 6801 expect to see the C following the preamble character. When it responds to the controlling host processor, this character will be an R. After the message-type character follows the operation character. As you may have guessed, an “S” is used for SET operations, while “R” is used for READ operations.

Depending on the command, there can be additional parameters. In the case of port READ operations, the message must contain the ID of the port being read, whereas for Port SET operations, both the port ID and a value must be provided.

Examples:

:: Read the current value of the inputs on port #3 of the 6801:
:CRP3;

The response to this would look something like:

:RRP3V0A

As you can see, the 6801 responds by placing an “R” character following the message preamble indicating this is a response, then returns the remainder of the original command. This is followed by the value read from the port. The “V” indicates the 2-digit hex value that follows is what was read from the port. Note that the port is 8-bits wide, and the value provided represents the values read from all the pins on that port.

:: Set the value of port #1 to 0x04 (bit # 3 SET, all others CLEAR).
:CSP1V04;

The 6801 will respond:

:RSP1V04;
:: Read the value of memory address 0x0004:
:CRM04;

The 6801 returns the value of the byte located at address 0x0004 (AA):

:RRM04VAA;

By default, the 6801 will not echo the characters of commands back to the sender. This is useful when it’s connected to a control processor like the 8266, but isn’t terribly friendly if a human is sending commands via a terminal emulator. However, there is a command that will enable echo of input characters:

:CSE1;

– The “1” indicates to the 6801 that echo should be enabled.
– “0” would then be used to disable further echos.

And the response:

:RSE1;

WHICH IOT CLOUD SERVICE?
Next, I needed a cloud service on which to base this whole thing. I spent a bit of time searching for a simple-to-use IoT platform that would also offer libraries that I could use with the 8266. I preferred the Arduino environment, since I wanted to try that out, too. I also wanted the ability to create Web-based management dashboards, so that I could easily check on the status of my system. It would also be nice to provide IFTTT integrations, so that I could roll-in email and push notifications. IFTTT is a cloud server, and IFTTT stands for “If This Then That.”

I initially tried two different Maker-oriented IoT services, Blynk [5] and ThingSpeak [6]. Both offer nice features for low or zero cost, and both offer some kind of “visualization” features to create your own dashboards for your projects. I still wanted to see if there was something that might more closely match what I had in mind.

Given that I purchase stuff from Adafruit fairly frequently, it’s odd that I didn’t think of them earlier in my investigation. While I was looking for some components for another project on Adafruit’s website [7], I saw a reference to “I/O” near the top of their home page. When I spent some time looking at what they had to offer, it became obvious pretty quickly that this was almost exactly what I had in mind. They also offer supporting libraries for 8266-based devices, and since I planned to use the Seeed Studio 8266, I downloaded them. In the space of an hour, I had an application running that could move data to and from the service and the 6801 over the serial connection. Another half hour’s work, and I had a decent web-based dashboard to do both (Figure 3).

Adafruit offers both free and paid tiers. For my garage door application, I can use the free tier. However, the paid tier offers higher-frequency messaging, email notifications, unlimited data streams and more. All tiers offer IFTTT integration, creating all sorts of interesting and powerful possibilities.

OH YEAH, MY GARAGE
I opened this article with a description of my need to know when I’ve left my garage door open. With all the work I did to get a functional assembler, get a monitor running, design a protocol, write the firmware, find a Wi-Fi module and select a cloud service, I thought it would be a travesty to just put something on a piece of perf board for a one-off solution.

While I had a bit of time off during the Christmas holiday, I decided to do a proper schematic and lay out a couple of PCBs. I’m a software engineer by profession, but using the excellent open-source KiCad [8] package on my Mac, I managed to design two PCBs. The processor board hosts the 6801, 8266, power supplies and some glue logic. And the other board acts as a hosting baseboard for my garage I/O requirements. I designed the processor card to plug into various baseboards, in case I found other applications that would suit it. This makes the controller aspect of the project more generally applicable than just as a garage monitor.

The baseboard offers some opto-isolated relays, along with routing some of the other I/O from the controller board out to terminal blocks, to make it easy to connect various bits and pieces from my garage. It also hosts the power input jack for both. I can run the solution using about 9V (AC or DC) up to about 15V. The processor card provides regulated 5VDC and 3.3VDC that is passed back down the connectors to the baseboard, in case I want to power other circuits someday.

As shown in the schematic (Figure 4), the circuit is fairly simple. The only “complication” was related to the fact that the 8266 module uses 3.3VDC for both power and serial I/O, whereas the rest of the circuit requires 5VDC. As a result, I added a linear 3.3V regulator and 3.3V-to-5V level shifting for the serial port RX/TX lines. Since another goal was to make use of commonly-available through-hole components, the level-shifting is built from discrete FETs and supporting resistors. Due to the low TTL-drive numbers for some of the GPIO, I also decided to add some buffering between those lines and the interface connector to make driving/receiving from off-board a bit more robust. The buffers are currently wired to be unidirectional, so some ports are input-only, and some are output-only.

As shown in Figure 5, there’s really not a lot to the circuit. The top of the board primarily holds the power supply circuitry, while the remaining is essentially digital “glue” logic. Note U6, the 3.3V regulator (left top in the photo). This provides the supply for the ESP6266 (lower right in the photo). The transistors you see near the middle left are the level shifting components for interface between the HD68P01 and the ESP8266.

The Seeed Studio ESP6266 module plugs into a dual-row 0.1” spaced header, so that it can easily be removed for reprogramming, if desired. The module has a built-in antenna, so no other accommodations are needed for it to work reliably. Figure 6 shows the controller board mated with the base board. This version is populated only with the terminal blocks, relays and other support components necessary to implement monitoring and control of my garage door.

Because the 6801 code is mainly structured to do general I/O control, the main application-specific code runs on the 8266. This provides a lot of flexibility in how I make use of the processor card. At the moment, it runs my garage monitor/control code with Adafruit.io but I also have a nice platform for future applications. Between the ease of coding for the 8266 and the Adafruit I/O service, I’ve got a great platform for just about anything I’d like to do. You might call it overkill, but I like to think of it as preparing for the future.

FUTURE APPLICATIONS
I am always on the lookout for other applications for my projects, and this one is no different. Because the system is currently designed for digital I/O only, I believe I’ll be adding support for either I²C or SPI so that I can add some analog sensors to the system. With one of those protocols, the features of the package will allow me to monitor and control a wide variety of input and output types. Plus, it will let me extend my assembly-language skills a bit further!

My original plans obviously ballooned—so much so that I ended up designing two PCBs: the main 6801/8266 controller and one that it plugs into to manage the I/O requirements of my garage. It ended up with considerably more capability than my garage door application demands, but I’m pretty sure I can leverage those added features. Meanwhile, my Adafruit.io / controller system is working great, allowing me to make sure I haven’t left the house with the garage door open—and letting me get it closed again if I did. Now it’s time to get started on some other uses for this project. 

RESOURCES

References:

[1] http://www.bitsavers.org/components/hitachi/_dataBooks/U71_8-Bit_Single-Chip_Microcontroller_Data_Book.pdf
[2] www.codeblocks.org
[3] https://usermanual.wiki/Document/MC6801L1UMLILbugMonitorfortheMC6801LAug80.2060579305
[4] https://www.seeedstudio.com/WiFi-Serial-Transceiver-Module-w-ESP8266-1MB-Flash-p-2485.html
[5] https://blynk.io
[6] https://thingspeak.com
[7] https://io.adafruit.com
[8] https://kicad-pcb.org

Adafruit Industries | www.adafruit.com
Espressif Systems | www.espressif.com
Microchip Technology | www.microchip.com
NXP Semiconductors | www.nxp.com
Renesas Electronics | www.renesas.com
Seeed Studio | www.seeedstudio.com

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • JUNE 2020 #359 – Get a PDF of the issue

Sponsor this Article