Embedded Files
Debugging a DEC PDP-8 that has not run in 20-30 years is a nearly impossible task. So much of the processor is usually broken that there is not enough functional logic to even begin debugging. When we started working on the DEC PDP-8/L we could debug and repair about 1-2 FlipChips (the boards in the PDP-8/I, PDP-8/L, and PDP-12) per Saturday workday. It was going to take years of Saturdays to get the system running. Our volunteer Waren Stearns made a tester for the FlipChip used in these systems.
Standard 0.1" jumpers connect the pins on the FlipChip socket to the SPI chips so that individual signals can be disconnected for debugging.
Additional resistors are located on the board that can be connected to high-current signals to provide an additional load.
The original design of the FlipChip tester was implemented with five Microchip MCP23S17 SPI 16-bit input/output port expanders. The SPI bus on each of these chips was connected to individual pins on a laptop's parallel port. Warren wrote software to read a test vector file and control the FlipChip tester. The 5x SPI buses were "bit-bashed" by wiggling the parallel port pins. Some of the simple FlipChips have just a few test vectors. Complicated FlipChips, like the M220, have over 2,000 test vectors.
_______________________________________________________________________________________________
02/14/18
A group of interested PDP-8 enthusiasts revived Warren's Flipchip tester design. Vincent Slyngstad made a PCB based on Warren's original design, and kept the original component locations.
Click on the image for a larger view.
The top side of Warren's FlipChip tester.
Click on the image for a larger view.
The PCB version of Warren's tester with an M220 from a PDP-8/I installed.
Click on the image for a larger view.
The bottom side of Warren's FlipChip tester.
During testing of this new PCB we found some interesting issues with the original design.
The tester needs a real PC parallel port for the interface. Modern PCs and laptops don't have this.
The tester software needs the Porttalk driver installed so it can interact with the PC printer port's registers. Modern operating systems and processors don't allow this, so the Porttalk driver is loaded, and then the tester software. This works OK Windows 2000 and Windows XP, but we need to try it on Windows 7. It likely will not work on Windows 10.
There is a lot of crosstalk between the SPI reset signal and one of the SPI MISO signals in the printer I/O cable. This may be the cause of the SPI GPIO chips periodically resetting. Cutting the ribbon cable and moving the MISO-A signal reduces the crosstalk.
The SPI MISO signals between the MCP23S17 chips and the 7406 driver chip are unterminated. This causes 10MHz ringing on the MISO signals on the printer I/O cable. adding a 10k Ohm pull-down resistor to these signals fixes this.
The pull-up resistors on the printer port are undefined. With my PC the pull-up resistors are very light, so the rise time of the MISO signals is about 2us. Adding a 1k Ohm pull-up resistor to +5V fixes this.
The MISO-A signal was connected to the printer I/O cable pin 3, but needed to be connected to pin 5.
To Do:
Install Visual C V1.52 and see if we can recompile the original source code.
Done. Works OK.
See if the recompiled tester application works.
Done. Works OK.
Make some minor bug fixes to the tester application.
Done. Works OK.
Long Term goals:
Replace the parallel printer interface on the tester with a USB interface using an FTDI C232HM Serial/I2C/SPI cable.
Done on 3x testers.
Write a new GUI tester application in C# using Visual Studio, but keeping the original test vector file format.
In process.
Use the FTDI CDM cable device drivers and the FTDI ftd2xx.dll, FTD2XX_NET.dll, libMPSSE.dll, FTCSPI.dll to allow the C# application to access the SPI port on the FTDI cable.
Done. Works OK.
Wire the MISO and the MOSI signal of all 5x of the SPI GPIO chips in a bus connected to the USB cable. Use the 5x SPI CS signals from the USB cable to select an individual SPI chip.
Done on 3x testers.
The Windows GUI to run the tester is operational, but still undergoing test and development.
It uses the same test vector file format at the original tester.
The tester performance is much lower than the parallel port version.
This is due to the way the FTDI supplied USB/SPI libraries are working right now.
We are investigating and optimizing the GUI code so we can get better utilization of the SPI bus.
Even though the GUI performance is much lower than the parallel port version, it is still very useful.
Page updated
Report abuse