The Talking Microtronic Computer System Emulator

An updated firmware (January 2022) for the Microtronic Mega Emulator Version 3 from 2016 is available here.

Like the 2016 version, it supports speech output over the Emic-2 speech synthesizer. Please refer to the 2016 documentation for further details.

Note the following changes to the 2016 version:

• PGM programs are no longer stored in EEPROM, but in PROGMEM (hence, ignore all instructions in the 2016 documentation referring to a prior programming of the EEPROM, this is not necessary any longer).
• The 1 Hz clock signal is now properly implemented by means of a timer ISR.
• Speech output can be en/dis-abled. Default is off.
• Some bugfixes to the CPU emulation (e.g., SHR).
• HAL9000 quotes and Magic 8 Ball speech functions disabled.
• CPU throttling is now non-blocking, e.g., delay is not used in order to not slow down reactivity of the emulator.
• Increased speed.
• Code refactoring.

This compiled with the Arduino IDE Version 1.8.15 in January 2022.

What could be next steps for this project? I am planning to make a PCB for the project. I am learning KiCad and started work on the schematics. A first version of the schematics can be found in the files section of this project. I am not sure how to add the Mega 2560 and SDCard shield functionality to the PCB though. Also the Emic 2 will have to stay separate, right? It will be a good learning project for me.

I liked the Emic 2 so much that I decided to buy a second one, and this one was going to be installed permanently, making the emulator speak all the time. I found two more unused IO pins that would work with the software serial library (not all pins support the required change interrupt), and mounted the Emic 2 to the base board. I purchased a (passive) ham radio speaker; the Emic 2 has an internal amplifier which is powerful enough to drive a passive speaker. The sound was loud and clear.

The inclusion of the software serial library into the Arduino sketch plus many more strings for the utterances of the Emic 2 now caused some major headaches. Suddenly, with the Emic 2 being part of the setup and all these strings being created dynamically using the String library, the file IO operations and LCD shield were no longer working properly. One effect was that the file bowser crashed, showing random characters on the LCD. Only a hard reset would resurrect the emulator then.

After a lot of debugging and trial and error I found a major culprit - the String library, and the SDCard library using the String library internally. Since there are neither destructors nor Garbage Collection, it seems that dynamically created strings are causing memory leaks, and at some point, the Arduino simply runs out of SRAM. I had to bite the bullet and removed the String library completely from my code, using character arrays / buffers instead. In addition, I replaced the SDCard library with the SdFat library. That solved all my stability issues, but it required some major code revisions.

The built in Emic 2 now confirms every keypress and function key, and the cursor keys - when not being used for file operations - trigger the following Emic 2 operations:

• Left : describe current system status
• Right : describe content of 7segment display and of the 4 digital outputs
• Up : general Microtronic emulator information
• Down : emulator software version
• Cancel : get an answer from the Magic 8-Ball
• Back: listen to HAL 9000!

Also, activities such as loading a PGM or SDCard program, clearing the program memory, and displaying or setting the time, are confirmed and spoken by the Emic 2. The clock program / PGM 4 is turned into a talking clock. While PGM 4 is running, a press on the right cursor key make it speak the current time.

So, the monitor program / operating system was speaking by now - but of course, I also wanted to program the Emic 2, making it speak arbitrary sentences. The previous setup in Phase Six used the digital outputs of the Microtronic as well as another Arduino Uno as an intelligent receiver buffer and baud converter for the Emic 2. Obviously, it would be much nicer if the Emic 2 could be accessed and programmed directly by means of certain 2090 machine instructions, with no extra hardware nor wiring required. However, there are no unused OP codes in the Microtronic which could be used for that purpose (all OP codes from 000 – FFF have a meaning!) So, I couldn’t just invent a new OP code for accessing the Emic 2. But wait - there are redundant op codes. The effect of a MOV xx = 0xx instruction is to copy the contents of register x onto itself, so these instructions are basically vacuous, and no real Microtronic program is using them for anything. I hence gave them an extra meaning / extra effect – in addition, a MOV xx also sends a (high- or low) nibble x to the Emic 2. A full ASCII character with decimal code xyz (e.g., 120 = xyz for character “x”) is thus sent via instructions 0ww, 0zz, where w is hexadecimal for xy - note that xy <= 12 (ASCII goes from 0 to 127), and hence w can take hex values from 0 to C. This decimal-based hex coding is used in order to make the entry of ASCII character codes more convenient. In order to speak a sentence, the Emic requires a heading “S” as well, and then a trailing CR (ASCII code 13). To make the Emic 2 thus speak “xyz” ("ex why zee") it takes the program “088 033 0CC 000 0CC 011 0CC 022 011 0033”. Consequently, the Microtronic program memory can now store 126 characters of Emic 2 speech.

I have always been fascinated with speech synthesis - I guess a good dose of SciFi movies in my childhood nurtured this fascination, from "Colossus - The Forbin Project", over HAL 9000 in "2001" and "2010", to "Proteus 5". In 1984, when I got my original Microtronic, a page in the Microtronic Manuals announced that a speech module for the Microtronic was under development, and that it would be available soon (the manuals were printed in 1981). Well, that never happened. 35 years after this announcement, I decided it was time to make this promise true, and finally have a speaking Microtronic Computer System - I hence ordered the Emic 2 TTS module, and started tinkering with it. Programming it over the software serial port from an Arduino turned out to be really easy. All it required were two digital pins, on for RX and one for TX, and the software serial library at 19.200 baud.

However, it was more challenging to actually connect it to the Emulator or even the original Microtronic. The Microtronic only has 4 digital outputs, and can achieve something in range of a couple of bauds (perhaps 5 to 10?). I was investigating how to increase the baud rate using UARTS and similar devices, buffers and shift registers, but it turned out to be too complicated. Notice that the baud rate has to be accurate within 10%, otherwise the Emic 2 will not receive anything, and the Emic 2 can not go slower than 19.200 baud. It turned out that the simplest solution was to use another Arduino Uno as an intelligent "buffer" and baud converter. The Uno would listen to the 4 digital outputs of the Microtronic and act as a receiver / input buffer. When ready, it would flush the buffer at 19.200 baud over software serial to the Emic 2, making it speak.

Listening to the 4 digital outputs of the Microtronic (and of the Emulator as well) turned out to be difficult, too. First, I had to "invent" a data transmission protocol which would be timing independent and hence more robust - I needed a "self clocked" data transmission protocol, without any start or stop bits, which would also not require a fixed baud rate. I decided to use the zero as a clock signal in the data stream - in order to then transmit zeros in the data stream, I simply added +1 to all data nibbles. That way, a zero always means "wait for the next nibble". The second challenge was that even with data transmission rates as low as a couple of bauds, the digital inputs of the Arduino were somehow too slow and I couldn't get reliable readings. I was using a 4bit counter as a test, and received values such as 0, 1, 3, 2, 3, 5, 4, ... I tried reading directly from the PORTB register of the ATMega, instead of using the Arduino IO. This solved the speed problem (reading is much faster then!), but still the read values were shaky. I could only overcome this problem by using the Arduino's analog inputs, and setting analog-to-digital conversion thresholds manually.

Finally, it worked with the emulator, and a little bit later also with the original Microtronic! The Microtronic could finally speak. The sketch for this Emic 2 Uno buffer is on the Github page as well. There is one version for the emulator, and another one for the original Microtronic. But version are shown in the videos below. The small Microtronic program memory cannot hold Emic 2 messages longer than 58 characters. Each character requires at least three machine code instructions (two instructions for loading the upper and lower nibbles of the ASCII character into appropriate registers, followed by a subroutine call which does the +1 conversion, and then sends the two nibbles over the wire to the Emic Arduino, interleaving it with zeros for clocking). Two more subroutines are required for initializing the Emic, and one for sending a CR, causing the Uno to flush its input buffer to the Emic 2, which makes it speak. After all this, there is only program memory left for 58 characters.

I have also coded a simple terminal program for the Emic 2. Instead of storing the characters via MOV xx instructions in Microtronic's program memory, one could just enter the ASCII values over the hex keypad, and the terminal program would send it over the wire to the Emic. This is demonstrated in following video - entering all these ASCII codes by hand is a tedious and time consuming process though. The .MIC file for the terminal program is on the Github and the files section of this project. The terminal program would also work with a real Microtronic, but I haven't really tried, because it is a little bit tedious to enter longer programs into the original Microtronic without SDCard:

Next I was trying to connect some simple Electronic circuits from the Microtronic Manuals to the emulator, using the original Busch Electronic Kits. I had built the transistor-based sound oscillator and when I connected it to the Arduino, there were some leakage currents. I hence added for signal diodes such that current can only flow "out" of the outputs, and not back in and through to another output.

For another experiments, I needed the four digital inputs of the Microtronic. The experiments from the Busch Manuals require the input levels to be roughly TTL compatible. I experimented with various pin modes on the Arduino, including INPUT_PULLUP, and INPUT, and figured that the inputs will only work correctly and reliably if I added external pulldown resistors and used INPUT pin mode.

So, the outputs required 4 signal diodes to prevent leakage currents, and the inputs required external pulldown resistors. This also had the nice effect that the inputs would correspond to non-inverted TTL levels, and the circuits from the Manuals worked. I soldered the signal diodes and pulldown resistors on two little perboards and mounted them on the base board (notice that the Arduino only has pullup resistors build in).

This step is documented here:

I decided I wanted a good looking, fancy front panel for my Microtronic emulator. I designed a front panel blue print and tried to cut it out from plywood. I even acquired a used scroll saw, but I was unhappy with the result. I decided I wanted a more professional looking front panel, and was excited when I found the Custom Laser Cutting Service offered by Pololu Robitics and Electronics. All they required was the blueprint as a PDF, and 6 days later I had my transparent acrylic iced, fantastic looking front panel in the mail.

I mounted the big 20x4 LCD white-on-blue display as well as the two blue 7segment I2C-based LED backpacks (each with 4 digits) from Adafruit, and the 4x4 keypad. Since I was no longer using the LCD+keypad shield and had also lost the additional 8 buttons from the TM1638, I needed a lot of discrete N.O. pushbuttons, as well as LEDs (blue of course), and another 3x4 keypad for the function buttons.

Turns out that I would be using most of the Mega's IO pins now for wiring up all the buttons, LEDs, keypads, etc. An additional 4 pins were needed for the Microtronic's digital inputs, one more output pin for the 1 Hz clock signal, and so on. In the end, not many ports were left.

After I had wired up the front panel hardware, I simply used a wooden base board of matching dimensions, and hinges and L-brackets from Osh to create the triangular case you are seeing on these pages. The Arduino is mounted on the base board using screws. Hotglue was my friend, too. The case is easy to open up and this is still the only way to gain access to the SDCard in the SDCard+Ethernet shield (Ethernet is not used for anything currently btw).

The software had to revised significantly - after all, most of the hardware had changed, the only constant being the Mega 2560, the keypad, and some buttons. In order to drive two Adafruit LED backpacks of I2C I learned that the address of one of those had to be changed, by soldering a jumper. I also learned how to wire up the contrast potentiometer for the 4x2 Hitachi HD44780 LCD display. The contrast potentiometer was part of the LCD+keypad shield in the previous version, which I was no longer using.

Finally, Version 2 was working! At the end of Phase 2, Mega Emulator Version 2 looked as follows:

All these additional IO ports on the Mega 25650 couldn't be left unused! So I used 4 digital outputs of the Mega 2560 as Microtronicdigital outputs, and made some experiments connecting simple circuits to them. For example, I built a 555-based tone generator using a simple resistor ladder that created some crazy sounds.

Then I began thinking about a cabinet for the project....

When the Arduino Mega version arrived I added an SDCard+Ethernet Shield to it, as well as an LCD+Keypad shield (a standard Hitachi HD44780 LCD plus 6 push buttons). The LCD shield was required for operating the SDCard interface, e.g., browsing through files for PGM 1 (Load) and creating new files via PGM 2 (Save). It turned out that they didn't quite work together -I had to disconnect PIN 10 (I used extension headers and simply bent PIN 10 out of the way such that the LCD shield did not connect to it). I implemented the file operations using the String library and SDCard library. These two choices in libraries would cause major headaches later... see below.

The 6 push buttons on the shield were used for enter, cancel, and cursor movement. In addition, the 8 push buttons on the TM1638 were still being used for the Microtronic function keys.

I came up with the .MIC fileformat described in the Detail section above, and used an OCR program to scan programs from the Busch Microtronic Manuals. Suddenly, I had a large software library, with relatively little effort!

Running some larger programs I spotted some errors in the implementation of some instruction code - after all, I had reimplemented the virtual CPU based on the descriptions in the manuals, and the descriptions were incomplete and missleading in some cases (but only in 4). After a while of debugging I was able to run even the largest programs without differences from the documented behavior.

I figured it would be a shame to only use the LCD display for file operations, and hence implemented a CPU status display, showing register contents and a simple Mnemonics display during program editing etc. Very helpful for debugging.

The state of the emulator after Phase Two is represented by these videos:

This project is basically done, but here are some log entries in retrospect, highlighting some construction issues and how solved them.

I started this project with an Arduino Uno R3, a 4x4 matrix encoded keypad, and a TM1638 module equipped with 8 7segment digits, 8 push buttons, and 8 LEDs. This was enough for a first version. The 8 push buttons of the TM1638 module were used for the function keys of the Microtronic, 4 LEDs for the digital outputs 1 to 4, a carry, zero, and 1 Hz LED flag. The nice thing about this setup was that it is basically a software project - only the keypad needs to be wired up. For a software person such as me this was a perfect starting point!

Examples PGM / ROM programs were stored in the EEPROM of the R3. It had difficulties storing longer PGM ROM example programs in the Uno, though. For example, the Lunar Lander program needs over 140 instructions. In my first attempt, I tried to store PGM ROM programs as

const char *string_table[] = { "F10 510 C00", ... }

The tight memory on the Uno also prevented adding much needed features, such as the SDCard shield for storing and loading programs from SDCard, given that these shields and required libraries needed some memory, too.

Even though I couldn't store larger ROM example programs with this setup, the emulator was functional enough to enter longer programs such as the Lunar Lander by hand, and then play them, but there was no way to save the program. I continued to develop the Uno Version until my Mega 2560 arrived. I also added some buttons to the breadboard, such as a soft-reset (as the Uno's hard reset clears the program memory of the emulator), the CPU throttle pot, and the Microtronic's 4 digital outputs.

The state of the emulator after Phase One is represented by this video:

The project log can be found here.