Reverse Engineering - the MacLab from ADInstruments

Reverse engineering is working up documentation for some piece of equipment for which documentation is unavailable. At least that is what it is for me. It is also a great way to learn about electronics and software. It has a bad name among some people who view it as a means to rip off intellectual property, and may in some cases be illegal.

A case history - the MacLab

As with all reverse engineering projects that I get involved with, it begins with the acquisition of an interesting gizmo of some kind. Recently I bought a pallet of odds and ends at an auction, which included among other things a "MacLab/4 Mark III". This looks to be a box with analog to digital and digital to analog parts inside, along with some kind of interface to connect it to a computer (given the product name, presumably a Mac). I can imagine such a thing being useful as it is (instead of being a source of parts for other projects), if I can figure out how to connect it to one of the computers I have laying around.

Online research

The first thing I do in a case like this is to go online and see if manuals can simply be downloaded (this makes the labor and adventure of reverse engineering unnecessary). Even if online manuals cannot be tracked down, this often turns up useful information.

In the case of the MacLab, this product is no longer supported, and although the manufacturer (AD Instruments) is still in business and provides online manuals for their modern products. This particular item (the MacLab) has been replaced by their "PowerLab" series, a note in their online FAQ says:

The original MacLab units were developed in the late 1980's to run only on Macintosh computers. Since then, ADInstruments software applications (LabChart and Scope) have been developed for Windows and MacOS. The recording units were renamed 'PowerLab' to reflect the cross-platform (MAC & WIN) nature of the system.
In addition they say:
ADInstruments no longer supports SCSI due to unavailability of neccessary hardware. Modern operating systems no longer reliably support SCSI.
The last sentence is a bit of a stretch, but alright, this is a dead end.

Look it over, front and back

Before we actually open her up, a look at the outside of the box will yield some clues. The front has 11 BNC connectors. One is labelled "Trigger". A pair is labelled "Output" (+ and -). 4 pairs are labelled Ch1, Ch2, Ch3, Ch4. There is also a 7 segment display labelled "Status".

My take on this is that we have 4 analog input and 1 analog output, oddly presented as differential pairs with each member of the pair on a shielded cable.

The back of the box has an AC cord inlet with switch and the following connectors:

Also next to the SCSI connectors is a rotary switch to set the SCSI ID, with labels 1-6 (apparently 7 id disallowed).
And, last but not least the proud label:
Made in Australia by: ADInstruments Pty. Ltd.

Plug it in

Before we get too far into this, let's plug it in and see if clouds of smoke pour out. The only visible signs of life (other than sounds like relay contacts clicking) is the front status display which starts with the central "-" lit, then transitions to a "2", then after perhaps 2 seconds transitions to a blinking "0". This seems ominous, but I really don't know enough to say what this means.

Open the box and look inside

The case opens easily with two giant screws allowing a look inside, and a quick inventory of the integrated circuits used. This lets us know what we are in for in a general way.

There are two big circuit boards inside.

The bottom board is an analog input/output board. Each of the four analog inputs is handled by an Analog Devices AD6211 chip (an instrumentation amplifier), followed by a Burr Brown PGA202. The analog output connector on the rear is routed to an Analog Devices ADG526AKN chip (a 16 channel analog multiplexer).

These days most manufacturers have online datasheets, which is fine for products still in production. Chips become obsolete faster than I would ever have expected though, and this means that you may or may not find online data for chips in use. And there is now the plague of online datasheet pandering companies. My advice is that you will be well served by a decent collection of databooks if you can afford the shelf space.

Datecodes on the chips are almost uniformly 1992.

In other words, this thing is 20 years old (and getting ever older)!

The upper board has a power supply section and the logic section. The power supply is driven by a toroidal transformer (nice in a piece of equipment with low noise analog circuits), and the upper and lower boards are separated by a metal partition (more nice low noise design). The logic section has the following parts:

The AD6677J chip is a 12 bit microprocessor compatible D/A converter with 3 microsecond settling time.

The ADS7800 is a 12 bit analog to digital converter with a 3 microsecond conversion time (capable of 333,000 samples per second).

And of course there are lots of standard TTL chips, as well as 3 programmable logic chips (GAL devices from lattice semiconductor).

So the heart of this thing is an 8 bit 6502 microprocessor, running at 4 megahertz.

Given a 4Mhz 8 bit processor with 40K of ram, I don't expect amazing data acquisition performance from the MacLab. The ADS7800 is quite capable, it will be curious to find out how much of that ability can be realized.

Whatever the case, for many things I am thinking of doing with it, I am sure it will be just fine.

The SCSI interface for this, is at best awkward. In this day and age I would hope for USB, or even a network interface. Of course USB did not even exist back in 1989, and designers were not yet adventurous enough to put network devices in what were viewed as "peripherals". For what I have in mind though, I'll wager that we can put it to use as is. Back in the late 1980's when this thing was designed, Mac computers were all about SCSI, and it was a point of pride with Mac owners, as were many other things.

The I2C interface might actually be more easily useful (maybe), and there is no telling what could be done with the serial port (never mind the screwy connector they chose for it).

Read out the PROM

Well, why wait -- I pry the prom out of its socket and stick it into my prom burner and read it out, this takes all of 5 minutes once I get the machine dusted off, cabled up, and booted. I get a 32K binary image file, and the burner reports a checksum of 4DE7. I copy this file from the machine hosting the prom burner and start the process of studying it. I have a little ruby program which does what the od -x command used to do so nicely. It gives me addresses, hexadecimal, and ascii (without hieroglyphics) all side by side. You can look at this dump right here. I did fiddle with my dump script to add 0x8000 to all the addresses, as I suspect the ROM is placed at the end of the address space.

Studying this shows me that the PROM has almost the exact same contents repeated twice. This seems mysterious, and a bit of further study shows there are actually two not quite identical code images in one ROM, and either one or the other needs to be placed at the end of the address space (0xc000 through 0xffff) to run. I expected to find a switch or jumper on the circuit board to select one or the other, but there does not seem to be such a thing. A little poking around with a meter demonstrates that pin 27 (A14) on the 27C256 EPROM is connected to ground, pulling this address line low, and permanently selecting the first of the two images. I wonder why there are two?

There are only two recognizable strings in the PROM:

At address 0x29F0 there is: 

ADI     MacLab/4 3.2

At address 0x2E5A there is: 

MacLab/4 III ROM by MCM & MJAH Sept 91
There is a big block of unused bytes (read as 0xff) from 0x30c0 to 0x3ff0, so one PROM image really only contains about 12K of unique information.

There are 9 interesting bytes right at the end as follows: 

0000Fff0 ffff ffff ffff fffe ab3e 6aed b1eb f100

The R65C02 processor

The R65C02 is an enhanced CMOS version of the 6502 with 32 additional bit-oriented instructions, and an extra address mode.

Details on the R65C02 processor here.

IO chips

Ignoring the 53C80 scsi chip for now, we have: The VIA has two 16 bit timers, two 8 bit PIO ports, and a shift register gizmo.

The NCR 53C80 chip and SCSI

First there was the NMOS 5380 chip, then the CMOS 53C80 chip came along. Then there was the 53C90, and then a host of 53Cxxx chips came along when Symbios took over the product line. Today apparently these chips are still sold by a company called Logic Semiconductor. AMD even manufactured a compatible part known as the AM5380 for a while. The 53C710 chip has an entirely different architecture, and is of almost no relevance to this project, but does have some interesting comments on the 53C80 in its introductory sections.

A disassembler for the R65C02

There is an open source assembler called "xa" that targets the 6502 family, including the R65C02. This may be useful if we decide to write code and do some experiments, but not the direction we are going as yet.

There is also a piece of software called dis6502, written by Robert Bond to analyze Atari files. It was posted to net.sources in October of 1986 and then to comp.unix.sources June of 1988. It was modified by Udi Finkelstein to support Commodore 64 object files and posted again to comp.sources.amiga in November of 1988.

Apparently this version (0.12) is GPL and available online.

Another program (but not open source) written by Eric Bacher is available online by the same name. There are links that offer the source code, but in fact are fraudulent and only provide the windows binaries. This is of no interest whatsoever.

I obtained the source files for dis6502-0.12 and built the disassembler (after making a few necessary modifications) and I find the code clean and the disassembler clever and nice. I then tidied up a couple of things and added the R65C02 instructions to the disassembler, which took me most of an evening. It now does a very nice job of disassembling the ROM.

Put my own code in ROM and try some things

After putting a fair bit of time into studying (and annotating) the disassembled firmware, I find myself wanting to put some of my own code into ROM and do some experiments. The main thing I am itching to do is to set up some "scope loops" that incessantly read some IO device address, so I can poke around with an oscilloscope and find out which chip is being addressed.

To do this requires (along with a cross assembler) either a way to burn roms, or some kind of rom emulator. I have blank rom chips, and a UV eraser, and an EPROM programmer, but would much prefer to use a rom emulator, which I also have. See my notes on using the promice rom emulator.

A 6502 assembler

I find myself yearning to do some experiments that require building code. The first thing I tripped over online was xa (xa65), an open source cross assembler.

What next?

The next thing is to dig out some of my databooks and do some homework, in particular find out what I can about the 68B50 and the R65C22 chips.

It may also be helpful to read out the GAL devices (if their security fuse is not blown) and figure out how address decoding was done for this device. This may not be necessary if IO port address use can just be sorted out by studying the firmware and doing some experiments.

Stay tuned.

Feedback? Questions? Drop me a line!

Tom's Computer Info / tom@mmto.org