PIC68 Project - Williams Pinball CPU Diagnostics Module

A module that can test Williams, Data East, Classic Stern and Bally CPU boards

Link 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.

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.

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.

Bottom view of the module.  Note the four rows of double ended pins.
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
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'.

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".

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.

Sound board
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.

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.

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).

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.

Let me know if you wish to purchase a kit for this tester.

  • 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 90101A.
Project Log
  • 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.

Link to Previous Page (Original Williams CPU Tester)

Main Pinball Page

Back Home

(c) 2012 Edward Cheung