Background

So far, the Microtronic firmware was lost to history - even the original developers (including Jörg Vallen of Busch Modellbau) are no longer in possession of the firmware file and its sources. This project is going to change that.

In June 2024, we acquired permission from Jörg Vallen, CEO of Busch, to publish the Microtronic firmware online - quote from the permission granting email (in German):

Von: Jörg Vallen <....@busch-model.com>
Gesendet: Freitag, 21. Juni 2024 10:37 An: 'Michael Wessel' <.....@gmail.com>
Betreff: AW: Neues Microtronic-Video aus dem Saarland

Sehr geehrter Herr Wessel,  

<snip>
Finde ich genial, dass Sie auch das Betriebssystem ausgelesen haben. Natürlich dürfen Sie gerne das Betriebssystem auf der Microtronic-Github-Seite veröffentlichen
<snip>

Ihnen alles Gute und weiter erfolgreiches microtronicen…

Viele Grüße Jörg Vallen


A few bits of Microtronic history: Development of the Microtronic started back in 1979, and as revealed in a historical document that recently surfaced (Jörg Vallen's Master Thesis / Diplomarbeit), the development of the Microtronic hard- and firmware was carried out by a subcontractor to Busch, the company "MRT: Mess- und Regeltechnik" in Kaisersbach, Germany. This company no longer exists; insolvency was probably declared as early as 1984. We were unable to establish contact with anyone who worked there. We also tried to contact Texas Instruments (TI) in Freising, Germany to get access to the company archive which might potentially still contain some Microtronic-related documents, but to no avail - after more than 40 years it is becoming difficult to retrieve such documents (after all, the original employees that worked on the project are no longer around, etc.) TI in Freising manufactured the first 10 mask-programmed Microtronic TMS1600 prototypes in September 1981 (see pp. 7 here).

Why do we care for the original Microtronic firmware? Two things: first, it will enable the fully authentic re-creation of the original, i.e., by using a TMS1600 software emulator running the original firmware ROM. So far, Microtronic emulators had to be implemented without the original firmware (see here, here and here for @Michael Wessel's various Arduino-based re-implementations in C). Secondly, the Microtronic firmware is an important historical artifact, and is the key to really understanding the system. Without it, the system and its inner workings remain shrouded in mystery - an unacceptable situation for every Microtronic enthusiast. So it would be absolutely awesome if, after being buried deeply and thoroughly in the bits of its mask-programmed TMS1600 for more than 43 years, we could finally excavate it to lift the veil of obfuscation - we would finally be able to understand what makes the Microtronic tick, and how!

Now, what's so difficult about retrieving the firmware from a TMS1600? Simply put, nobody knew how to do this - until recently! After all, a mask-programmed TMS1600 isn't something that you can simply put in an EPROM programmer to read out the firmware. @Michael Wessel knew about Sean Riddle's TMS1000-family chip decapping projects where he managed to retrieve the firmwares of certain TMS1000-family powered devices (such as Simon, TI calculators including the Little Professor and DataMan, and many more!) by reading the bit patterns directly from the die shots of the decapped chips! He even has a bit pattern to TMS HEX file converter program. Amazing! However, @Michael Wessel was hesitant to send one of his rare Microtronic TMS1600 chips to Sean, as decapping is obviously a destructive process, and few Microtronics are left these days.

All of this changed when @Michael Wessel acquired a TMS1100-powered Science Fair Microcomputer Trainer (SFMT) in January 2022, published a series of demo videos on YouTube, and got contacted by @decle and @Jason Jacques who had previously succeeded in retrieving the Science Fair firmware! They shared information and schematics on how to put the TMS1100 into the so-called "test mode" which allows for firmware dumping in a serial manner. The details of this involved process can be found here and here. Would we be able to adapt their techniques for the Microtronic TMS1600? No documented case of TMS1600 firmware retrieval via the test mode was found on the Internet so far. So we are in pioneer's land...



Step 1 - Preparing a Microtronic for ROM dumping

In April 2024, we started by studying the schematics of the circuit for Arduino-based SFMT ROM dumping kindly provided by @decle

to determine how this could be adapted for the Microtronic and its TMS1600. Comparing this to the TMS1600 setup in the Microtronic schematics: 

it quickly became clear that most signals required for firmware dumping should be readily available, but would probably require modifications to the Microtronic motherboard to cleanly isolate them from the surrounding circuitry.

From Decle's schematics above it also became clear that pin #3 = R10 of the TMS1100

needs to be connected to 9V - R10 is crucial here, as this is what puts the TMS1100 into test mode, hence enabling firmware dumping in the first place. It was unclear if R10 would also be effective for the TMS1600, so we knew that experiments might be required in order to determine how to enable TMS1600 test mode. Moreover, it was also important to remember that we were dealing with PMOS devices here; so VDD = GND, and VSS = 9V

Michael still had his original 1983 Microtronic in his possession. It had lost its console / enclosure decades ago, making it the perfect victim for firmware dumping .Given that it already offered convenient access to the motherboard it facilitated the required trace cuts and bodge wires to cleanly isolate the TMS1600 signals.

First, we replaced the 7segment LED display with a NOS display to which proper red lens filters could  be glued on. The original Microtronic had the lens filters in the (now absent) console, and the original display's plastic frame did not facilitate lens filter mounting, unlike the new display. Moreover, given that the Microtronic cannot be operated conveniently without its console as the membrane keypad is suspended in mid air without its (console) support structure:

, second order of business was to create a more practical keyboard substitute - the Gerbers for the external Microtronic keyboard PCB are attached to this project:

Whereas the new external keyboard wasn't strictly necessary for the firmware dumping project, it nevertheless made sense in order to restore general utility and usability of this old Microtronic (provided it will - hopefully! - survive the firmware retrieval torture). As can be seen from the Microtronic schematics, we needed access to K1, K2, K4, and K8, and these are directly connected to the keyboard, so putting in pin headers and the external keyboard made sense from that perspective as well.

Next, the required PCB modifications / trace cuts were applied. Bodge wires and DuPont cables were routed to the outside - by closing the DuPont wire, the original trace can be easily restored. By opening the DuPont wire, the corresponding TMS1600 pin can be connected directly to the firmware dumping circuit.

Moreover, chips such as the 2114 SRAM and the 4016 keyboard / input port multiplexer were put into sockets so that they could be removed easily in order to minimize chances of interfering with the firmware dumping process.

Removal of the 4016 (analog switch) multiplexer chip was also triggered by the observation that the K8 driver transistor was getting hot! Given that there was no significant difference in the way the different K1, K2, K4 and K8 were connected to the 4016, the only possible explanation was a defective 4016. And indeed, after socketing and replacing the 4016 the problem went away, and the transistor stayed cool. Interestingly, there was also a discrepancy in the actual 4016 configuration and the schematics: the Ki's are connected to the 4016 pins 2, 3, 9, and 10, which amounts to y1, x2, x3, and y4 (xi = input, yi = output). 

This is inconsistent with the schematics, and it is surprising that xi is not consistently used for inputs - however, the BC4016 is (supposedly) a fully bi-directional chip, so it probably doesn't matter that much (well, famous last words...) In any way, it was safer to run the firmware dumping procedure with 4016 removed, so that's what we did.

Jason spotted one more interesting inconsistency in the schematics: the transistor for driving the ~WRite signal of the 2114 SRAM via TMS1600 pin R13 seemed to have collector and emitter swapped (rightmost transistor in this row of five):

Fortunately it turned out that this was a schematics artifact only, and that the transistor was configured correctly on the motherboard - all five emitters are tied together as can be seen clearly in this picture:

In hindsight, we cut more traces than required - we initially didn't succeed in enabling the TMS1600 test mode via pin R10, so we tried various alternatives, which resulted in trace cuts to isolate the corresponding pins. The various "candidate pins" included, for example, R14 and R15.

With the Microtronic motherboard prepared we were now ready for

Step 2 - Recreating Decle's SFMT firmware dumping circuit

Our first firmware dumping circuit was assembled on a breadboard; 

after a lot of trial and error, we finally found that pin #9 = R8 enables the test mode on the TMS1600. In the beginning it wasn't clear at all that we would succeed in enabling test mode, as there were rumors that TI might have crippled or disabled the test mode capability in later (i.e., after the TMS1100) microcontrollers. When R8 started to do its magic, it was a huge relief and we were able to retrieve the first firmware candidate in April 2024.

In a nutshell, three modifications were required to Decle's TMS1110 SFMT Arduino firmware dumping program; the first version of the Microtronic / TMS1600 firmware dumping program containing these changes can be found here

Michael made a YouTube video about the firmware dumping process; unfortunately, it turned out that the retrieved firmware file still had some problems as Jason would later realize. This was surprising, given the fact that we were able to retrieve the very same firmware file repeatedly without any byte differences. A potential explanation is provided below.

A disassembly listing of this first retrieved firmware was also produced, using Decle's Python-based TMS1100 disassembler. Logistically, the firmware dump shows up in the "Serial Console" of the Arduino IDE which is connected over a USB cable to the Arduino in the dumping circuit, driving the test mode protocol and retrieving the serial ROM data. The Arduino's "Serial Console" output is then simply copied & pasted into a text file, the "Chapter" and "Page" annotations are removed, yielding a plain 16 bytes per line HEX file, with bytes cleanly separated by spaces. This HEX file can then be converted into a BIN file using either a tool like xxd via "reverse mode"

xxd -r -d "microtronic-firmware.hex"

or an online converter, e.g., https://tomeko.net/online_tools/hex_to_file.php?lang=en

The resulting BIN file is the digestible by Decle's TMS1100 disassembler and produces a disassembly listing.

Now it was time to have a look at what we got there!


Step 3 - First peeks into the retrieved firmware

How did we know that this was actually legit firmware code? First, we retrieved this dump consistently. Secondly, Michael suggested to look for traces of one of the Microtronic ROM demo programs in the firmware, in particular, the NIM Game (PGM 7) - we knew that the firmware must contain code for loading the game into the 2114 SRAM as well as a representation of the NIM program itself somewhere. The program starts with 

F08
FE0
F41 
FF2 
FF1 
FF4 
.... 

and, sure enough, Jason spotted this code fragment: 

Apparently, the first instruction, F08, is handled / loaded into SRAM in a slightly different way than the following instructions. But, this was exciting - it seemed we were on the right track! We declared victory on the firmware dumping process, and Michael disassembled the dumping harness... which would bite him 4 months later.


Step 4 - Four months later, doubts about the retrieved firmware arise

Michael was a bit exhausted from the trials and tribulations of the project so far, restored the Microtronic into usable state, disassembled the firmware dumping harness, and put it back on the shelf for a bit. However, Jason kept working at decoding and understanding the firmware, while Michael was planning on learning some TMS1600 assembly (starting with the"TMS1000 Family Programmers Reference" and the "TMS1100 Instruction Set Overview"). It wasn't until August 2024 that Jason noticed that something wasn't quite right with the retrieved firmware, triggering another round of firmware dumping!

Unfortunately, Michael had already disassemble the dumping harness, so it needed to be rebuild. This time, he opted for a more durable solution and put the circuit on a proper perfboard:

For the previous breadboard version, we investigated different schemes for powering the Microtronic + Arduino ROM dumping harness combo: from Microtronic PSU-supplied, over separate power supplies for Microtronic + harness combo, to externally supplied power. The latter proved to be the most practical and stable solution. As can be seen from the Microtronic schematics, the system uses  -9 V and -5 V; the latter is used for the additional support chips (e.g., the 2114 SRAM chip which was socketed and removed for firmware dumping). Hence, the -5 V rail was not really required as only the TMS1600 needed to be powered for firmware dumping. It was hence straightforward to feed 9 V into the Microtronic and hence the TMS1600 via the cassette interface expansion socket: 

Again, note the weird PMOS (negative) voltage levels: as already noted above, VDD (= -9 V in the above picture!) is really our external GND, and VSS (= 0 V in the picture) is really our externally supplied 9 V.

Later we would see that it was important to not supply more than 6 V, as the Arduino was getting "low" levels that were not "low enough" - lowering the VSS voltage to 6 V was required in order to get a consistent firmware dump.


Step 5 - Retrieving the firmware(s?) again 

What triggered a second round of firmware dumping was that Jason had noticed a few bytes in the firmware BIN didn't seem to make any sense. Having inferred the most likely correct bytes via informed guesses and from hist emerging understanding of the Microtronic firmware, we then retrieved various firmware candidates to be vetted by Jason by double checking the offending bytes and ensuring that they match his expectations.

Why were we (consistently) getting different firmwares in the first place? The mystery wasn't fully resolved, but clock timing and supply voltage certainly seemed to play a role here, see below. Also, Michael had added an additional LED to visualize the incoming serial bit data from TMS1600 pin O7 = Arduino input pin D2 to Decle's circuit, hence raising some suspicion that maybe this LED was responsible for the problematic bytes. This turned out to be not the case; Michael removed the LED and still was able to retrieve the same firmwares for the same (clock and voltage) settings. So it was put back again.

We then started monitoring the Arduino-generated clock pulse (Arduino pin 3) and the incoming TMS1600 serial data from O7 (Arduino pin 2) on the scope, and could observe that either the Microtronic PCB, or the harness (maybe its long test wires?) seemed to have a significant parasitic capacitance: If we didn't wait long enough before measuring a "0" with the Arduino, we ran the risk of actually getting a "1", because the signal hadn't had enough time to settle to GND yet. We thus needed to wait long enough after the falling edge of the initiating clock pulse before measuring. We also found that we need to wait long enough for the 07 signal to "fully settle" or "fully discharge" to GND before sending the next clock tick! 

Note that it takes six clocks ticks to retrieve one bit from the mask-programmed ROM; the TMS1000 family requires 6 ticks to execute one instruction. We found that when O7 was "bleeding into" the next clock tick phase, as shown in the following scope shot, it would result in significant errors in the retrieved firmware (07 in yellow): 

This "bleeding into the next clock tick phase" effect could still be observed with a much reduced clock rate:

We would hence slow down the capture process / clock frequency so that O7 had plenty of time to "discharge" / settle to GND for a digital "0", before ticking the clock again; these scope shots correspond to successful firmware captures: 

Now, all of this is purely phenomenological speculation, but matter of fact is that Jason was more satisfied with the dumps retrieved at slower clock frequencies.

In addition, it seemed that the "low" voltage levels for "0"s were still somewhat too high for the Arduino, so if we read the signal too quickly after the falling edge of the clock signal, it didn't have enough time to settle, and was still high enough to be read as a "1". This effect was also enhanced by the rather high 9 V supply voltage (note that we have a 10 k resistor at the Ardino D2 input where we read the signal, but still) - we could observe that lowering the voltage to 7.5 V and even further to 6 V resulted in a reduction of D2 peak-to-peak levels from ~ 6.2 V to ~ 5.7 V, resulting in "faster discharge" and a faster "0 reading capability" on the Arduino side. It should be noted that D2 has a 2k pull down resistor in Decle's design, but maybe a smaller resistor (1 k) would have been beneficial here as well.

To alleviate this problem, we hence added some logic to the Arduino code that requires 100 or so consistent reads of the same digital value before moving on to the next clock tick. This "double checking" and waiting for the signal to become stable meant an even further reduction in clocking frequency.

This is where another interesting effect kicked in - if we now spend too much time in between clock pulses by ensuring consistent reads, certain bits were flipping again from 0 to 1 in the retrieved firmwares! In particular, at some point we required a 300 or so consistent reads of D2 - this took significantly longer time between clock ticks, and 3 bytes changed consistently in the firmware. We don't really have an explanation for this - other than the hypothesis that while dumping the ROM, the externally supplied clock speed can neither be too high, nor too low, else stranger things are happening! 

Anyhow, Jason was the arbiter of the retrieved firmware candidates given his expert TMS1100 family knowledge and partial understanding of the Microtronic firmware (so far, he is the only one!), and he was the one who approved the final retrieved firmware candidate (HEX file, BIN file) which is now attached to this project. The disassembled version is here as well. Going forward, these are the files we are going to use for the commented ROM listing.

The current Arduino firmware dumping program can also be found here.

Step 6 - Jason gets his first Microtronic! 

Jason got lucky and acquired his first Microtronic from eBay - and what a nice set it is! It even comes with the incredibly rare 2095 cassette interface!

Being a bit more daring than Michael who even lifted some pads when putting in sockets for the 2114 and the 4016, he decided to socket the TMS1600 - and succeeded in cleanly extracting and putting it in a socket!

Given the problems that Michael faced in producing a clean ROM dump, we hope that the dump obtained from a fully isolated TMS1600 will be be much cleaner and with less ambiguity. Looking forward to Jason's ROM dump soon. So stay tuned for a really final firmware file on this channel soon!

Step 7 - Really Final Firmware extracted by Jason

Free of interference from the extra circuitry on the Microtronic motherboard, Jason was able to extract the "cleanest" firmware image so far! He was also able to confirm the observation that the voltage levels make a difference, and that a somewhat lower voltage level is required to retrieve the "desired" (i.e., logically most consistent) firmware image. The image ROM also settled the debate on three bytes for which varying values had been observed in previous dumping attempts; turns out they should really be 00. The really final firmware image is attached, and we are going to use this for all further analysis. And here is the really final disassembly.

Step 8 - Writing up some "Notes"

Michael asked me to write up my notes on the Microtronic firmware disassembly. I got rather carried away, and wrote the beginnings of a textbook. The document covers a variety of Microtronic disassembly topics:

The full write-up is available here: Disassembling the Microtronic 2090.