Reverse engineering a Shop Bot ROM

After dumping the ROM from the shop bot we were intrigued by what we found.  Some of the strings in the ROM indicated that there was a basic interpreter on there, and there was even plaintext BASIC.  After some digging this is what we found.


Blue Earth Research was a company that made microprocessor development boards, presumably for industrial use.  They packaged (in our case) an 80c32 processor, a ROM chip, and I/O expander, and made it all as compact as possible.  They also did work with the 8052 and other processors in that line.  Among the series of boards they offered was the Xplor 32d, the ‘d’ standing for digital as there were boards with on board analog to digital converters.  They provided the BASIC interpreter’s hex file, the assembly source for a program that could load that hex file onto the microprocessor, and the source for libraries for use with peripherals such as a keypad, an HD44780 LCD screen, and X-10 automation hardware.  There were also example BASIC programs that showed some of their BASIC’s more unique features.  There was also a C compiler for this architecture, but since that doesn’t have anything to do with our ROM dump we’ll skip that.

Before even starting in on the code we traced the whole board to determine which pins were where as far as I/O and how the chips were wired up to determine the memory map.  This information is all in one spreadsheet contained in multiple tabs, the memory map was eventually expanded to contain details of the code we disassembled.


To help with this we employed the disassembler dasmx.  This is extremely easy to use, and even though it is not open source it is free to use.  This program is fairly smart, but it’s not magic.  It will interpret all the memory as code memory unless told otherwise and because there are no distinctions calling out the beginning of data it tries to decode plaintext as code.  We originally were concerned that the ROM dump was incomplete because a hole in the BASIC exists between 0x10C1 and 0x13FF.  Upon closer inspection the code after 0x13FF references line numbers that should be in the top code snippet and are not present, implying that it is not from the same program.  In addition to that, one of the new BASIC commands is CALL which jumps to a memory location and starts executing the assembly there, and the BASIC snippet starting at 0x1000 ends with CALL 7000.  Interestingly, that command is referenced in the source files of the example programs explaining how to use this development board, so that confirms our suspicions.



Part of the instructions for how to use this dev board include assembly libraries that can be called from BASIC that use the peripherals.  Things like the LCD, keypad, and X-10 integration were provided by Blue Earth Research and instructions were given for them to be loaded at 0x1E00.  Our ROM includes these exactly, and by adding the line labels to the symbol file they disassemble and are readable (even if I don’t think the main shop bot program is using them).  It’s a bummer that the source for Xplor Tiny BASIC is not provided, but it helps that the same person wrote that as wrote the loader for it.  RELOAD.A51 contains some routines that are almost, but not exactly like routines in BASIC.  Specifically the string printing and console output routines.  The differences seem to come from the fact that BASIC has built in support for the LCD and therefore has to check if it should print there or to the console.


The other source files also helped determine how our program was interfacing to the 82c55.  The wiring only decodes some of the address lines so it would be possible to write to the peripheral chip with a number of memory locations, but the source files clearly show constants of 0x2000 for port A, 0x2100 for port B, 0x2200 for port C, and 0x2300 for the control registers.  This is in the disassembly as well, but the assembler eliminated the constants and now references to these numbers are sprinkled throughout the code.  This helps determine what is going on with certain sections of code and labeling has progressed based on this.  As a note, some of the labels in the source code we have are not present in the disassembled code.  This is because if nothing calls that memory location then the disassembler doesn’t know it is supposed to be logically distinct and there is no placeholder label generated.


This BASIC is interesting in that the coding convention calls subroutines and then immediately after the call is the data to be used in that subroutine.  This means that the subroutine can get the data by looking where the program would jump back to and pulling information from there until it hits the end.  One example of this is the keyword subroutine.  When reading the BASIC program the interperter needs to know if it’s reading a valid command, and if it is then it needs to execute that command.  Our code contains a call to the keyword routine and then immediately after is the basic command in plaintext, except the last character has the most significant bit set.  This is so the routine knows when to stop reading data (there’s code after that).  There are no null terminated strings here, just checking to see if the byte is greater than 0x80, if it is 0x80 is subtracted and that is the last character in the keyword.  This convention is also used when printing strings to the console or the LCD.


Doesn’t this look a lot like the init section of an arduino program, complete with the serial print of what it is and that it’s booting

The remaining parts of the disassembly were made by recognizing when special registers were being used.  Things like transferring data to or from the serial buffer are fairly obvious (either moving things in or out of the sbuf register).  Setting up interrupts and timers, as well as setting the direction of ports can all be gleaned without looking closely enough to see which bits are being set, just that those registers are all being written with values in succession near the beginning of the program.

This is where we are right now with the disassembly, it’s been interesting and we might dig further into this at a later date, but for now our curiosity has been satisfied.  All the files we used for this are up on github, that includes the last version of the disassembler, the rom dump, the latest revision of symbol file for it, and the listing that it decodes.  The board wiring and memory map are also there.  The source files from Blue Earth Research are also there although they are also in the internet archive.

One Response to “Reverse engineering a Shop Bot ROM”

  1. Reverse engineering a Shop Bot ROM #BASIC #ReverseEngineering @abzman2000 « Adafruit Industries – Makers, hackers, artists, designers and engineers! Says:

    […] Evan’s Techie-Blog continues exploration of a Shop Bot. Having dumped the ROM on the control board, what did they find? The answers are unexpected: […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: