Skip to content

PIODev Board

Nicolas "Pixel" Noble edited this page Jun 29, 2020 · 28 revisions

Background

Many of the carts available for the PlayStation that plug on the PIO port follow the same core principle: they have a piece of code written on some form of permanent storage, that is accessible through the parallel bus exposed through the PIO. The code will then be injected through the boot process. Some carts will feature additional devices on the bus, such as communication logic, selected using basic logic comparison chips. The communication logic is generally using some form of DB25 plug, some of them being a straight IEEE 1284, which is easy to adapt onto the PlayStation bus.

The Caetla rom introduces a lot of features, the most useful one being centered around debugging.

Motivation

There are several drawbacks using these older carts.

The first major drawback is that the IEEE 1284 parallel port is extremely outdated, and full support for it has dwindled in recent computer systems. Some other carts require an ISA or PCI card to communicate, which is even more difficult to handle these days.

Communication using modern age systems such as USB is what's being targeted here.

The second drawback is that while debugging is a powerful and useful tool, it usually requires modifying the running code in order to introduce debugging opcodes markers. While this is easy to do on a software running in RAM, this isn't possible for something that's running off a ROM, such as the BIOS code itself, or the Caetla ROM. Writing an emulator such as PCSX requires being able to debug these when running on the real hardware.

Substituting the ROM chips for an asynchronous SRAM would unlock the ability to debug these softwares.

And finally, this is old hardware, that didn't necessarily age very well, and might prove challenging to source. Some of the carts might also be of poor quality, and wouldn't function very well.

Versions

The proposed PCB went through several iterations of the design, the latest one being version 3. The first 2 weren't functional for different reasons, and are then not discussed here. Version 3.0 of the PCB had 5 pieces manufactured and fully populated. All 5 of these boards have been claimed and in use. Version 3.1 of the PCB had 10 pieces manufactured, and haven't been fully populated yet. They haven't been claimed yet.

The latest version of the PCB EagleCad files, BoM, assembly, and Gerber files can be found here, in the repository. Note that the BoM contains everything except typical 2.54mm through hole headers. The reader is advised to carefully review all the information in this Wiki before deciding on ordering any hardware.

If ordering the pcb through jlcpcb, you will want to populate the bottom layer using them, and then populate the rest manually using this digikey cart.

In case jlcpcb is unable to populate the memory chips, you can order this SRAM, and this Flash.

There is a dedicated page to explain how to populate the top portion of the board.

Changelog

Version 3.0 had several mistakes on the silkscreen, that all have been corrected in version 3.1:

  • The 5v regulator for the USB plug is incorrectly labeled as L7805. It is an L1117.
  • The 22uF output capacitor of the 5v regulator is incorrectly polarized on the silkscreen.
  • The GPIO pins numbers can no longer be read once the header is soldered.

Version 3.0 of the PCB had the FT2232H port B data header pins inverted, causing transmission errors if using straight jumpers. See the JTAG page for more details.

Version 3.1 of the PCB added the following features:

  • Longer solder leads for the TSOP48 memory chips.
  • Added two solderpoint jumpers, that can be used in verilog to indicate the presence of the memory chips being soldered. These pins are grounded in version 3.0.
  • Removed the pullup resistors for the CPLD dip switches and momentary button. This means these signals are now "sticky". See "recovery mode" for more information.
  • Added through hole power headers, that can be used either on top or bottom of the PCB.
  • Added a diode near the power input, so the board can be powered on while plugged into a powered off PlayStation without damaging anything.
  • Added plated holes for the USB-A plug, for better assembly strength.
  • Following Xilinx's suggestions, added a few 4.7kΩ pullup resistors on the jtag lines.

Version 3.1b is currently the work in progress version of the PCB, and has the following changes:

  • Narrower solder pads for the various decoupling capacitors on the bottom layer, per jlcpcb feedback.

Design

The board is sporting a Xilinx XC95144XL-10TQG100C CPLD, a 2MB 55ns NOR flash chip, a 2MB SRAM chip, a 2MB flash socket, an FT2232H, and a CH375B, along with a few minor passive components such as LEDs, dip switches, momentary buttons, and debugging headers.

The PCB has been designed with oshpark and jlcpcb's capabilities in mind. The bottom layer contains the most complex parts to solder, and are all featured in jlcpcb's catalog. The top layer only contains 603 smd components, or easier components to solder manually. The flash and sram however are typically out of stock for jlcpcb, and they won't replenish them when asked. In all cases, these two components are technically optional, as long as the flash socket is populated, and version 3.1 of the PCB features longer solder leads for these components, making it easier to populate manually.

See the memory map page for more information about the CPLD Verilog code, and how to access the devices from the PlayStation's memory.

CPLD

The CPLD is connected on the Data bus of the PIO, and is the only component on the PCB connected to it. It thus acts as a latch for the rest of the components on the board. It has another Data bus that connects on all the chips on the board.

It also is the sole owner of the !CS0, !CS2, !IN10, SBEN, DACK, DREQ, !WR2 and A20 lines. The idea behind the A20 hook is to enable creating two pages in all of the memory chips on the board, so that one can split each in two, for mirroring the BIOS and the debugged ROM chip. The SBEN line is connected to pin 5 of the PIO port, in order to manipulate a Switch Board that can enable the hook of the !CS2 line on pin 39 of the PIO port. In case the Switch Board isn't installed, a 200Ω resistor is placed in line, so that a misfiring of the SBEN line wouldn't draw more than a few dozen milliamps, as this line is otherwise tied to ground.

Each chip on the board have their A20 and !CS lines hooked onto the CPLD. The FT2232H has its reset line and port A's A0 line also tied to the CPLD. The FT2232H's reset line can also be used as an input to detect if there is a USB cable plugged in. The CH375B has its interrupt line tied to the CPLD.

The CPLD also listens on the A22 to A16 high address lines, the A4 to A0 low address lines, and the !RD and !WR lines, that are shared across all other relevant chips on the board.

It has a hookup to the !RESET line, which is technically a inout, as the CPLD might be able to trigger a hard reset of the PlayStation.

A 12Mhz clock is present on the PCB, in order to drive the FT2232H and the CH375B. This clock line is also connected to the CPLD.

And finally, there are 10 GPIO pins connected to the CPLD and exposed on the top of the PCB, for debugging purposes.

FT2232H

The FT2232H is a powerful and versatile USB chip, which happens to have a "CPU-style FIFO" mode, that's exactly what the PlayStation bus is. It features two ports, named A and B, and both have been connected to the CPLD data bus, directly or indirectly. Each of these ports can be individually driven off a computer using the FTDI D2XX drivers, and very little code.

Each port can also act as a JTAG programmer, using the xc3sprog software. The CPLD's jtag is indirectly connected to the FT2232H's port A, thus making it possible to reprogram the CPLD through the FT2232H. The way this is currently set up means it's possible to use xc3sprog using the "bbv2" cable. See the JTAG page for more details on this feature.

The PCB design is closely following the one from the FT2232H mini module, and has an eeprom that needs to be programmed to change the default settings to:

  • self powered mode
  • CPU fifo for both ports
  • D2XX mode for both ports

Initial testing show that bidirectional communication is indeed possible through this chip, albeit with some jitters, which would require more investigations.

An important detail is that the FT2232H circuitry is self-powered, meaning it needs 3.3v power from the PlayStation to function. The 5v power supply from the USB cable won't be used as a power supply. The FT2232H will however be held in a reset state when no USB cable is connected.

CH375B

The CH375B chip is supposedly a USB OTG chip, allowing older CPUs to use USB mass storage devices, as well as providing communication to a host. At the time of writing this page, testing of this chip has been unsuccessful so far.

DIP Switches and LEDs

There are two octal latches tied to the inner data bus. One takes the data bus as an input and has 8 LEDs as an output, the other one takes 8 DIP switches as an input and outputs them into the data bus. The LEDs are sunk into the latch, so a logic 0 into the latch will activate the corresponding LED. The DIP switches are connecting to ground, with pull up resistors. An "on" DIP switch will be read as a logical 0 in the corresponding latch.

These are technically solely for the usage of the PlayStation CPU.

Direct switches, jumpers and buttons

There are two dip switches, two pcb jumpers, and one momentary button connected to the CPLD. As of now, none of them are used by the Verilog code, but they could be used to configure things like the presence of the Switch Board to indicate the PIO Dev Board needs to override the BIOS, to warn the CPLD of the presence (or absence) of some memory chips on the board, or to enter recovery mode.

Debug headers

There are 16 headers on the top of the board, which are tied to the inner data bus. 8 of them are ground, to use with a typical logic analyzer which would require a ground pin for each data pin.

There are 10 headers at the bottom of the board. These may only be populated if the cart isn't plugged vertically directly at the back of the PlayStation, as they would otherwise interfere. They are 10 GPIOs connected to the CPLD. Their meaning is whatever the Verilog code makes them to be, which can be useful when debugging the Verilog code.