Creating a schematic diagram from an existing board can be done. It is somewhat time consuming and accuracy is not perfect, but it can yield a usable schematic to work with an old board. In this project, the board is a VME Bus CPU board using a Motorola 68000 CPU. There is a reasonable amount of DRAM storage and EPROM storage on the board as well as a 2 channel UART for communications. The VME Bus interface is standard, so documentation on that connector is readily available. Data sheets on all of the chips on the board are available. The CPU and all of the programmable parts are socketed, making them easy to remove.
Since I only have one of these boards, destructive methods such as de-populating the board are out. The board is at least 4 layers and may be 6. Holding it up to a light, you can see light through areas that are not covered by components, so there are no ground or power planes in the board.
Before I invested the time required to create the schematic, I wanted some indication that the board was not completely dead. I connected a 5V power supply and ground to the appropriate connector pins and looked for activity on the address and data buses around the EPROMs. There was none. VME boards are designed to be run in a card cage with a backplane board providing power and a number of signals. Thinking that some of the control signals might need to be pulled up or down before the CPU would start, I laid out a PCB with the VME connector, the required resistors and a power connector. When the boards came back from OSHPark, I built one up and repeated the test. Watching the EPROM chip select signals, the processor was performing 4 read operations, attempting to load the reset vector and then halting. The 68K processor will only accept an even value for the reset vector, and if it gets an odd value, it shuts down. The 4 read operations were promising. I dumped the contents of the EPROMs using an EPROM programmer tool and examined the data. The vector table starts at address 0 in the EPROM. All of the addresses in the first 32 bytes were showing 0xFF values. It appeared that most of the other vectors might be sane, but bit rot had trashed the reset vectors. This would explain the 4 read attempts (2 16 bit reads for the stack pointer and 2 16 bit reads for the actual reset vector). Bit rot was not a surprise since the date on the board itself was from 1986, and beyond 10 years EPROM data gets suspicious. Without documentation, creating replacement EPROMs is not possible, but so far it looks functional.
Power supply current on this relatively small board seemed pretty high, at about 1.6 amps. Digging through the data sheets on the parts that seemed to be getting warm, I added up the current draws and the total came out to about 1.6 amps, so that put that issue to rest. I had forgotten how power hungry these old boards were.
In the past, I have reverse engineered a few boards. The method that I used was to use an ohm meter, look for continuity from pin to pin on the IC's, drawing the results on a piece of paper. This method involves constant digging through the data books on the parts to get signal names for each pin.
This time, using my CAD software, I put schematic symbols for all of the parts visible on the board on a few B size sheets of paper. Part placement on the pages was done via best guess and if found to be bad, moved around as I learned more. Part designators on this board are mostly underneath the parts or absent. I hand drew a map of component locations using my own designators that matched the parts on the B size sheets. Working from these sheets, getting the address and data buses penciled in went pretty quickly. Those connections got added into the growing schematic sheets. Mapping the control logic took a lot longer. Using the growing drawings, I could tell where signals were missing and was able to fill most of them in. After numerous iterations, the schematics are about 80% complete. Most of the signal connections on the CAD schematic are connected by net name rather than wires to keep the confusion down. The most useful connection information is what signals are going in and out of individual chips, so this method works well.
Chips marked with the green squares in the photo of the board, had smaller parts (14 and 16 pin package) underneath them.
Control logic like address decode, dtack generation and interrupt handling are done in PALs (Programmable Array Logic) on this board. PAL chips on the board are marked with dark red squares in the photo of the board. Using a PAL programmer, I extracted the contents of the PALs to JEDEC files. JEDEC files were converted back to logical equations using the jedutil program that is available in the open source MAME software package. In an attempt at security, PAL chips have a security bit that if set, prevents reading the contents of the chip. I got lucky and the manufacturer of the board did not set the security bit on any of the PALs on this board. If the security bits had been set, there are other, more painful methods that can be used to get the contents of these combinational logic parts. Using the signal names on the schematic, I filled in the signal names in the equations to get an address map for the hardware. This is enough to compile code to run on this board now.
The DRAM control logic is implemented in a mixture of 5 "popcorn logic" chips and one PAL. It is still somewhat of a mystery to me, as it did not yield well to the continuity testing. This section contains most of the unknown circuitry. Knowing the address space and size of the DRAM array is enough to use the board, so I did not push to understand the DRAM control logic fully.
The EPROM programmer and PAL programmer mentioned above are a single instrument, a Data I/O Unisite. Numerous general purpose programmers were made that handle many different devices and manufacturers. They tend to be old, as JTAG programmed single chip microcontrollers have replaced the separate CPU, memory and logic chips that were once common.
A note on using an ohm meter to look for continuity: the open circuit voltage on some ohm meters is high enough to damage chips. The meter I am using (HP34401A) can put out 9 volts. It has a "Diode" setting, that restricts the open circuit voltage to 1.0 volt, which is safe. If your meter open circuit voltage is above 5 volts, it would be a good idea to put a zener diode across the test leads to clamp the open circuit voltage to less than 5 volts.
At this point, I am testing the board on an In Circuit Emulator (ICE) box which replaces the socketed CPU chip. In Circuit Emulators were amazing development tools that have been pushed aside by rising clock rates and JTAG tools. So far, the board is working. My next steps are configuring the assembler and cross compiler to be able to write code to run on this board.