-
-
Notifications
You must be signed in to change notification settings - Fork 124
PIODev Board
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.
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.
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.
It 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 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, 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 200ohm 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 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 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.
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 below the JTAG section for more details on this feature.