30 years later: The revival of my old 80535 microcontroller board
Over 30 years ago, I was working on a small project with a friend. We wanted to build an inverted pendulum similar to the one we had admired at the Deutsches Museum in Munich. Unfortunately, the project was never finished and since then the microcontroller board has been lying around in a box at my parents' house until it was finally completely forgotten. On my last visit, however, it fell into my hands again and suddenly a question arose that wouldn't let me go: Does it still work?
The board is now at my place in Vienna and I've spent the last few evenings getting familiar with it. Funnily enough, I can't remember in the slightest where this board actually came from. Did I buy it, or did my father? But he can't remember either. Did I solder it together? A blackout like this is almost a little worrying.
The 80C535-Compuboard
Unfortunately, there was also no printed documentation such as books or magazines, at least I couldn't find any. Another mystery. Where did I get the information from back then? The Internet was not yet an option in 1992. Even today, information about it is very limited on the web. At least I found out that it was a project of the magazine Elektor, which was published in issue 9/92.
A look at the board shows its most important features:
- Siemens SAB-80C535-N Microcontroller
- HY62256ALP 32Kx8bit CMOS SRAM
- M27C256B 256 Kbit EPROM
- 12Mhz clock
- RS-232 interface
The SAB-80C535-N from Siemens is an 8-bit microcontroller from the 8051 family. Introduced in 1983, it is an enhanced version of the 8051, which was introduced by Intel in 1980. The main features are:
- 256 byte on-chip RAM
- External program and data memory expandable up to 64 Kbyte each
- Six 8-bit parallel I/O ports
- One input port for digital input
- Full-duplex serial port, 4 modes of operation, fixed or variabie baud rates
- Three 16-bit timer/counters
- 16-bit reload, compare, capture capability
- A/D converter, 8 multiplexed analog inputs, programmable reference voltages
- 16-bit watchdog timer
- Idle and power-down mode
- Power-down supply for 40 byte of RAM
- Boolean processor
- 256 directly addressable bits
- 12 interrupt sources (7 external, 5 internal), 4 priority levels
- Stack depth up to 256 byte
- Most instructions execute in 1µs (750 ns) at 12-MHz operation
- 4 µs multiply and divide
- Compatible with standard SAB 8080/8085 peripherals and memories
The following table shows a comparison with the now somewhat outdated ESP32 DevKit C V4 board from Espressif:
80535 Compuboard | ESP32 DevKit C V4 | |
---|---|---|
Year | 1992 | 2016 |
SoC | SAB-80C535-N | ESP32 |
Type | 8051 (8 Bit) | Tensilica Xtensa LX6 (32 Bit) |
Cores | 1 | 2 + 1 |
Clock | 12 MHz | 240 Mhz |
RAM | 256 B + 32 KB | 520 KB |
ROM | 32 KB | - |
Flash | - | 4 MB external |
WLAN | - | 2,4 GHz, 802.11b/g/n |
Bluetooth | - | 4.2 BR/EDR & BLE |
GPIO | 48 | 34 |
Timer | 3 x 16 Bit | 4 x 64 Bit |
ADC | 1 x 8 Bit | 2 x 12 Bit |
SPI | - | 4 |
I2C | - | 2 |
UART | 1 | 3 |
First test
A very important question arose right at the beginning. What supply voltage does the board need? The data sheet for the 80535 states -0.5 to 6.5 V. As there is apparently no voltage regulator on the board, I simply tried 5 volts.
But there was still a problem. The board only has an RS 232 interface. They haven't been available on modern PCs for years. However, it was state of the art back then; the USB standard was only introduced in 1996. But there are USB to serial adapters for cases like this, so I ordered one of those.
Now it got serious. To monitor the serial interface, I used the Serial Monitor of the PlatformIO IDE. So, I connected the board to the power supply, connected the USB adapter, and pressed the reset button. And... nothing happened. I have to admit, I was a bit disappointed at that moment. Then, I checked the baud rate. It was set to 115200 baud, which was way too high for such an old board. So, I set it to 9600 baud, which was a fairly common value back then. Pressed the reset button again. And lo and behold!
At least there's some activity on the serial port now. I've also tried it at 4800 baud.
Unbelievable. After 32 years, the board still works. At that moment, I actually had a bit of a racing heart. It's far from guaranteed that the hardware isn't damaged after so many years. The electrolyte of the capacitors could have leaked by now, or some bits of the EPROM could have flipped.
The first program on the 80535
Now, of course, I also wanted to load a program onto the 80535 board. But how? Fortunately, I have a well-functioning backup concept. So I still have all the programs that I wrote for the 80535 back then. This folder also contains some programs and examples that were apparently supplied by Elektor with the Compuboard at the time. Among them is a small program for communication with the board. However, the EXE file no longer works under 64-bit Windows. Kindly, Elektor Verlag also supplied the Pascal source code. I couldn't do much with it either, but together with ChatGPT and Google Bard Gemini I migrated the code to Python very quickly. The result looks like this:
import serial import time import sys import msvcrt # Functions for communication via the serial port def sndbyt(ser, byte): while ser.out_waiting > 0: time.sleep(0.001) # Wait until the buffer is empty ser.write(bytes([byte])) def getbyt(ser): if ser.in_waiting > 0: # Check whether data is available in the receive buffer return ser.read(1)[0] # Read and return the received byte else: return None # Return None if no byte is present def setcom(ser, speed): # Change baud rate ser.baudrate = speed # Change parity ser.parity = serial.PARITY_NONE # Change data bits ser.bytesize = serial.EIGHTBITS # Change stop bits ser.stopbits = serial.STOPBITS_ONE # Apply configurations ser.apply_settings(d={}) # Main function for file transfer def download(ser, fname, intel): print("DOWNLOAD OF:", fname) try: hex_f = open(fname, 'r') except FileNotFoundError: print("ERROR: FILE", fname, "NOT FOUND") return for line in hex_f: if line.strip(): # Check that the line is not empty print("<<", line.strip(), ">>") ok = down_line(ser, line.strip(), intel) print('.') if not ok: print("ERROR DOWNLOADING FILE!") return print("FILE TRANSFER COMPLETED") ser.write(b'\r') # Forces an EMON51 prompt hex_f.close() def down_line(ser, line, intel): error = False ack = 6 if not intel: sndbyt(ser, ord('h')) # Sending the 'h' command to EMON51 received = get_in_time(ser) if received == ack: # Waiting for the ACK byte from EMON51 for ch in line: sndbyt(ser, ord(ch)) # Sending the remaining line sndbyt(ser, ord(' ')) # Sending a trailing space to end the hexadecimal number if get_in_time(ser) != ack: # Waiting for a new ACK error = True else: error = True else: for ch in line: sndbyt(ser, ord(ch)) # Send each character of the line return not error def get_in_time(ser, timeout=1000): start_time = time.time() while time.time() - start_time < timeout / 1000: if ser.in_waiting: return ser.read(1)[0] return -1 # Main function for V24 communication def do_v24(ser, intel): filename = None esc_key = 27 # ASCII code for ESC ctrl_f_key = 6 # ASCII code for CTRL+F ctrl_d_key = 4 # ASCII code for CTRL+D while True: # Display received data while ser.in_waiting: received_byte = ser.read(1)[0] sys.stdout.write(chr(received_byte)) sys.stdout.flush() # Check for key press if msvcrt.kbhit(): inbyt = ord(msvcrt.getch()) # Handle input if inbyt == esc_key: print("ESC key. Exiting...") break # Exit loop on ESC elif inbyt == ctrl_f_key: filename = input("Enter filename: ") print("Start download with CTRL+D...") elif inbyt == ctrl_d_key: if filename is not None: # Check if filename exists before calling download download(ser, filename, intel) # Start download else: print("No filename entered.") else: sndbyt(ser, inbyt) def main(): fname = "" com_adr = "COM1" no_dialog = False exit_code = 0 v24_speed = 4800 intel = False # Parameter handling for arg in sys.argv[1:]: arg = arg.upper() if arg.startswith("-COM"): com_adr = arg[1:] # Removes the "-" from the argument elif arg == "-1200": v24_speed = 1200 elif arg == "-2400": v24_speed = 2400 elif arg == "-4800": v24_speed = 4800 elif arg == "-9600": v24_speed = 9600 elif arg == "-NODIALOG": no_dialog = True elif arg == "-INTEL": intel = True else: fname = arg # Open serial interface ser = serial.Serial(com_adr, v24_speed, timeout=1) if intel: print("INTEL HEXFILE mode") # Setting the COM parameters setcom(ser, v24_speed) if no_dialog: download(ser, fname, intel) else: do_v24(ser, intel) ser.close() sys.exit(exit_code) if __name__ == "__main__": main()
The script is simply executed with
python v25com.py -COM10 -4800
and then waits for input. The following video shows the upload of an example that puts the 80535 into power-down mode:
This example was also a good opportunity to measure the power consumption of the 80535 board with my new Power Profiler Kit II. The following image first shows the upload, the peaks correspond to the "ACTIVE" output in the terminal and then the 80535 goes into power-down mode.
The board therefore normally consumes around 220 mA, in power-down mode the value drops to 155 mA. For comparison, an ESP32 consumes only 15 µA in deep sleep mode.
Hello World with the Keil C compiler for 80535
Finally, I also wanted to write my own program for the 80535 compuboard. Not in assembler, however, but in C. I compiled my programs at the time with the Keil C compiler. The Keil company has been part of ARM since 2004, but the compiler still exists. So I downloaded and installed the test version of Keil µVision. The program looks a bit antiquated, but it does the job.
At first I had some problems starting the program. The reason was the memory structure of the board. After a bit of research, I found out how the ROM and RAM are divided up on this board:
ROM 0x0000 – 0x3FFF RAM 0x4000 – 0x7FFF ROM 0x8000 – 0xBFFF RAM 0xC000 – 0xFFFF
The program was only assigned to the correct code segment after the compiler had been configured correctly. To do this, line
CSEG AT 0
in the STARTUP.A51 file must be changed to
CSEG AT 4000H
This tells the compiler that the code segment on this board starts at 0x4000.
The Keil compiler generates programs in Intel HEX format, so this time the upload program must be started with the -INTEL option:
python v25com.py -COM10 -INTEL 4800
The video shows the whole process again:
This proves that the board is still fully operational. I would have liked to write a more complex program, but the test version of the compiler is very limited and only allows very small programs.
Conclusion
The past few evenings have been incredibly exciting for me and actually make me want more. However, the board also has a major disadvantage. The programs are always stored in RAM, which means that as soon as the power supply is switched off, they have to be uploaded again. This limits the practical use considerably, as there is neither a buffer battery nor flash memory or similar options. Nevertheless, the process of getting from a completely unknown board to a functioning C program was extremely interesting and instructive.