| Home | Job | Pinball | Photo Album | Automotive | Press/Awards | Contact |
PIC68 Project - Williams Pinball CPU Diagnostics Module
A module that can test Williams, Data East, Classic Stern and Bally CPU boardsLink to Previous Page (Original Williams CPU Tester)
If the CPU board under
test is unable
to run the ROM code, diagnosis is almost impossible. As a
result,
I decided to build a test system that does not rely on the resources on
the CPU board (except for power) in order to diagnose the
board.
This would take the form of a module that plugs into the board at the
location of the CPU chip, and it would communicate to a user via a
serial interface. The user would be able to read and write
any
register location, and this info can be used to find out what the
problem area of the board is.
Since the processor essentially bridges the above mentioned serial connection and the CPU board's bus, it would also be in principle possible to control the entire machine from another computer. One example is a computer running Pin MAME, or one could rewrite the rule set in a new language. I calculate that one could achieve at least 2500 bus read/writes per second, and this would be fast enough to scan the lamp and switch matrix, and write to the solenoids and sound processor.
Layout of the board that forms the diagnostic module.
It plugs into the CPU board at the processor chip's location.
The finished diagnostic tester board. The RS232 shifter is in the background,
and the serial interface connector is on the left of it. The FLASH
programming header is on the right.
Bottom view of the module. Note the four rows of double ended
pins.Since the processor essentially bridges the above mentioned serial connection and the CPU board's bus, it would also be in principle possible to control the entire machine from another computer. One example is a computer running Pin MAME, or one could rewrite the rule set in a new language. I calculate that one could achieve at least 2500 bus read/writes per second, and this would be fast enough to scan the lamp and switch matrix, and write to the solenoids and sound processor.
Layout of the board that forms the diagnostic module.
It plugs into the CPU board at the processor chip's location.
Test
Module
Design
My choice for the processor is the 40-pin PIC. This has sufficient I/O and program space to do the job. Essentially, the PIC and board emulates the pinout of the 6800/6802/6808 CPU chip, and can thus manipulate the address, data and control lines to read the registers and memory chips on the board. I also decided to make this small board compatible with the 68B09 chip, and as a result, this module can be used to diagnose a variety of Williams, classic Bally and Stern, and Data East CPU boards. In addition, some Williams sound boards also use these processors.
The module has an RS232 shifter, and plugs into the serial port of a computer. Using this interface, the user can navigate menus and display data such as the results of tests and memory dumps. As mentioned above, low-level reads and writes are also possible via this interface.
My choice for the processor is the 40-pin PIC. This has sufficient I/O and program space to do the job. Essentially, the PIC and board emulates the pinout of the 6800/6802/6808 CPU chip, and can thus manipulate the address, data and control lines to read the registers and memory chips on the board. I also decided to make this small board compatible with the 68B09 chip, and as a result, this module can be used to diagnose a variety of Williams, classic Bally and Stern, and Data East CPU boards. In addition, some Williams sound boards also use these processors.
The module has an RS232 shifter, and plugs into the serial port of a computer. Using this interface, the user can navigate menus and display data such as the results of tests and memory dumps. As mentioned above, low-level reads and writes are also possible via this interface.
The finished diagnostic tester board. The RS232 shifter is in the background,
and the serial interface connector is on the left of it. The FLASH
programming header is on the right.
Another benefit of this
PIC processor
is the FLASH program storage. I can program in C, and
download
the compiled program in seconds without having to remove the processor
from the Diagnostics Module. With the 20 MHz on-board
crystal, I
can achieve 5 MIP performance.
These are used to plug the module into the target CPU board.
The photo above shows
the bottom view
of the Diagnostic Module. Of the four rows of double-ended
pins,
two rows are used for 6800/6802/6808 emulation, and the other two are
for 68B09
emulation.
To clear components on the board, long pin adapters such as these are used.
The module plugs directly into these long sockets.
The new module under test in a System 11 board. I inserted the Logic Analyzer
adapter to see how all the control lines are manipulated.
I used the Logic Analyzer
adapter to
test the new module. With this, I could verify the software
properly toggles the address, data and control lines at the correct
time.
Logic Analyzer output with the above adapter. One can see the PIC setup the
address, data and control lines to read and write from the CPU bus.
I had one mistake on
this first
revision of the board. It required some jumpering around the
RS232 translator chip. However, other than that, the board
worked
well, and I was soon reading and writing the processor bus. I
was
able to do RAM tests, dump the contents of the ROM, verify the PIAs are
working, etc.
Photo of the Diagnostic Module plugged into a System 11 board. The ribbon
cable on the left goes to the serial port of a PC for the user interface.
Test
Software
As soon as the CPU board
is powered
up, the PIC will spring to life and output a start-up banner and main
menu (see screen snap below). Based on the presence of the
two
clocks (E and Q) and other signals, the software makes a best guess at
what type of System it is used on. It can automatically
detect
System 3-6, System 11, and WPC. However, System 9 is too
similar
to System 11, and a manual command has to be entered to put it in that
mode.
This system information affects only pre-canned tests such as ROM reads, PIA tables, and RAM tests. The low-level read and write of any address are always possible and unaffected by the System mode.
For example, I know from the System 11 schematic that there is a PIA at address 0x2400(hex), and I developed a test consisting of reads and writes to all of the PIAs registers to test it. That passes in the case below. Pointing to a bogus memory location causes the test to fail (not shown), and indicates what part of the PIA is bad.
I then test the RAM chip, which (on System 9 and 11) is located from address 0x0000 to 0x07FF (2kbytes). The test I developed does several reads and writes to each memory location, and prints an 'X' in case of an error. By arranging the test results in a grid, one can better tell if the whole chip is bad, or just a portion. This will tell us if it is an address line issue. Of course, individual RAM cells can be queried by using menu items 'r' and 'w'.
This system information affects only pre-canned tests such as ROM reads, PIA tables, and RAM tests. The low-level read and write of any address are always possible and unaffected by the System mode.
For example, I know from the System 11 schematic that there is a PIA at address 0x2400(hex), and I developed a test consisting of reads and writes to all of the PIAs registers to test it. That passes in the case below. Pointing to a bogus memory location causes the test to fail (not shown), and indicates what part of the PIA is bad.
I then test the RAM chip, which (on System 9 and 11) is located from address 0x0000 to 0x07FF (2kbytes). The test I developed does several reads and writes to each memory location, and prints an 'X' in case of an error. By arranging the test results in a grid, one can better tell if the whole chip is bad, or just a portion. This will tell us if it is an address line issue. Of course, individual RAM cells can be queried by using menu items 'r' and 'w'.
Screen snap of an interactive session with PIC processor on the
Diagnostic Module.
Next, in the test above,
I dump a
section of the ROM, starting before the chip is enabled. At
first, you see the data is just 0xff, but when the ROM is enabled
(after 0x4000), the ROM code starts spilling out. Again, by
comparing with the ROMs contents you can tell if there is a problem
with the address or data lines.
The last test in the above screen snap is described below.
The diagnostic module and C code also incorporates a 'Probe' pin. This special input on the PIC can serve as a digital voltmeter (using the PICs A/D converter), or as a simple logic probe. The user simply attaches a test clip to the 'P' pin on the board (shown in one of the photos above), and the user interface screen will show the data. In voltmeter mode, the screen scrolls upwards displaying a bar which length is proportional to voltage, so it can even function as a simple scope or chart recorder. This feature is similar to the "mini-scope" mode of the CPU Tester. In that case, the LCD screen is used as the display.
This 'Probe' input also serves another more powerful role. As a bit of background, each of the peripheral chips on the CPU board are enabled by logic that decodes the current address. If there is a failure in the decoding logic, it could cause multiple chips to be enabled at the same time. The resulting bus contention could cause corruption of the data read, and could (for example) prevent the ROM code from running. This condition can be detected by 'scanning' across all 16 bits of the address bus, and verifying that only the proper address range(s) causes the selected enable line to be asserted. The last test in the above screen snap shows the result of the 'Probe' input as the address bus is scanned from 0x0000 to 0xffff (all 16 bits of address). The resulting 'map' shows the status of the line that is being probed for all combinations of the address bus.
A small portion of the System 11 CPU board schematic showing
the decoding for the PIA control lines.
For example, referring to the figure above, we can see that there is a
PIA at 0x2800 (pin 13 of U37). The bottom part of the screen
snap
above was obtained by connecting the "Probe" input to this pin, and
performing a mapping of this enable line. It shows that from
0x2800 to 0x2bff, this line is low (blank space in that row/column
location), and the PIA is enabled in this interval. It is
also
enabled at 0x0800 to 0x0bff, but this is expected based on the
circuitry above. The difference between 0x0800 and 0x2800 is
in
the A13 address bit. Since that is not used by the U37 decoder, it
explains why either address range results in the enabling of the
PIA. By using this "enable map" feature, unique to
this tester as far as I know, one can verify the decoding of all the
address decoders on the board.
Not shown are other tests, such as the IRQ test. On the CPU board, this circuit divides the processor's E clock by 928 to produce the interrupt. The Diagnostic Module checks this circuit by rapidly clocking the E clock under program control, and counting the number of cycles needed before the IRQ input goes low. If that number is correct, the IRQ test shows a "Pass".
The last test in the above screen snap is described below.
The diagnostic module and C code also incorporates a 'Probe' pin. This special input on the PIC can serve as a digital voltmeter (using the PICs A/D converter), or as a simple logic probe. The user simply attaches a test clip to the 'P' pin on the board (shown in one of the photos above), and the user interface screen will show the data. In voltmeter mode, the screen scrolls upwards displaying a bar which length is proportional to voltage, so it can even function as a simple scope or chart recorder. This feature is similar to the "mini-scope" mode of the CPU Tester. In that case, the LCD screen is used as the display.
This 'Probe' input also serves another more powerful role. As a bit of background, each of the peripheral chips on the CPU board are enabled by logic that decodes the current address. If there is a failure in the decoding logic, it could cause multiple chips to be enabled at the same time. The resulting bus contention could cause corruption of the data read, and could (for example) prevent the ROM code from running. This condition can be detected by 'scanning' across all 16 bits of the address bus, and verifying that only the proper address range(s) causes the selected enable line to be asserted. The last test in the above screen snap shows the result of the 'Probe' input as the address bus is scanned from 0x0000 to 0xffff (all 16 bits of address). The resulting 'map' shows the status of the line that is being probed for all combinations of the address bus.
A small portion of the System 11 CPU board schematic showing
the decoding for the PIA control lines.
Not shown are other tests, such as the IRQ test. On the CPU board, this circuit divides the processor's E clock by 928 to produce the interrupt. The Diagnostic Module checks this circuit by rapidly clocking the E clock under program control, and counting the number of cycles needed before the IRQ input goes low. If that number is correct, the IRQ test shows a "Pass".
System 11 Sound boards
Boards of this generation use the 68B09, so they can also be tested with the PIC68. See the WPC section below for more information.
PIC68 Testing with System 11 sound boards such as this D-11297 from Pinbot.
The PIC68 allows a 'scan' of the integrity of the hardware on the sound board such as the PIA, RAM and ROM chips.
WPC
Board
Testing
Tester module plugged into the Logic Analyzer module
for a WPC CPU board.
With a DMD driver board connected (above CPU board), the combined
assembly can be tested with the Diagnostics Module.
Tester module plugged into the Logic Analyzer module
for a WPC CPU board.
The next application of
the
Diagnostics Module is on WPC. By offsetting the rows of pins
on
the bottom of the Module, the correct pinouts of the 68B09 processor is
emulated. I was able to successfully reuse all the
higher-level
functions such as verifying RAM, dumping memory/ROM, etc by tweaking
the low level read/write code. The biggest difference between
the
68B09 and the 6802 is that the former is clocked externally.
Upon
startup, the Module's firmware looks for this clock, and if it is
present, does not drive this pin. By sampling this clock at a
fast rate, edges can be detected, and the Module knows the right time
to read and write data to the busses.
With a DMD driver board connected (above CPU board), the combined
assembly can be tested with the Diagnostics Module.
In the image above, the
DMD RAM has
been filled with a pattern of bars via the user interface. My
WPC
test bench has an FPGA
board that converts the DMD serial stream to VGA for display
on a
monitor. I can thus test safely on my workbench without any
high
voltage present.
With the Diagnostics Module, I can read the ROM on the CPU board, test the RAM, checkout the switch scanning hardware, and access the ASIC's registers. A tool such as this would have been useful during the time I was developing the FGPA replacement for the ASIC.
In addition to WPC, Stern used the 68B09 on their "Whitestar" boards. So it should be possible to use this Module on those boards as well.
With the Diagnostics Module, I can read the ROM on the CPU board, test the RAM, checkout the switch scanning hardware, and access the ASIC's registers. A tool such as this would have been useful during the time I was developing the FGPA replacement for the ASIC.
In addition to WPC, Stern used the 68B09 on their "Whitestar" boards. So it should be possible to use this Module on those boards as well.
System
3 and 4
After I wrote about this project on the pinball newsgroup, I was informed that System 3 and some System 4 machines use the 6800 processor (info on the processor generations here). It turns out that there is one significant difference, just like the 68B09, the 6800 is externally clocked, and accepts a two-phased clock. One of the phases of this clock is applied to the 6800 on the same pin that the 6802 uses to output its E-clock.
The System 3 board with acid damage from Mike Felden (FL).
With 6800 CPU compatibility verified, the Diagnostics Module should
also be usable on the classic Stern pinball machines
that use the M-100 and M-200 boardsets, and
Bally machines with the "-17" and "-35" boardsets.
After I wrote about this project on the pinball newsgroup, I was informed that System 3 and some System 4 machines use the 6800 processor (info on the processor generations here). It turns out that there is one significant difference, just like the 68B09, the 6800 is externally clocked, and accepts a two-phased clock. One of the phases of this clock is applied to the 6800 on the same pin that the 6802 uses to output its E-clock.
The System 3 board with acid damage from Mike Felden (FL).
I received a System 3
board courtesy
of my friend Mike, and using this was able to write the test code for
this type of board. The code operates similar to the 68B09
mode,
where it samples the system clock and applies the read/write signals at
the precise time to communicate with the board.
With 6800 CPU compatibility verified, the Diagnostics Module should
also be usable on the classic Stern pinball machines
that use the M-100 and M-200 boardsets, and
Bally machines with the "-17" and "-35" boardsets.
Links
- Quickscan-80. A similar module for Gottlieb System 80 CPU boards by Ed Krzycki.
- FIXIT module. A similar module for Bally "Dash 35" boards.
- This module is similar to the operation of the Fluke 9010A.
- Paul Swan's Arduino In-Circuit Tester.
- 9/5/09 - PIC68 Board design is finished. Order placed.
- 9/13/09 - First board assembled and initial C code works in 6802 mode.
- 9/20/09 - On WPC, access to RAM and ROM works. Read/writes to ASIC and peripherals not finished.
- 9/23/09 - Release 1 finished. System 4-11 and WPC boards can be tested.
- 11/11/09 - Added System 3 compatibility. Thanks to Mike Felden for the test board.
- 11/11/11 - System 11 sound boards added.
- 3/24/21 - Numerous software updates done over the years. This device is still extremely useful to me for repairs.
(c) 2021
Edward Cheung