PSCD32 Development Diary

"Work has been proceeding in order to bring perfection to the crudely conceived idea..."

Throughout July, for Reasons of Science, I found myself playing the Amiga's last great mascot platformer, Brian the Lion, on the Amiga CD32. If you're not familiar with the CD32, it's a 32-bit CD-ROM based console (the first of the misadventurous 16/32-bit fourth-and-a-half generation consoles released in the UK). And it looks a bit like this. It's an Amiga 1200, magically transmuted into the form of a video game console. It has two 9-pin controller ports on the side, which are the same as those found on the Amiga home computer series (but not the CDTV, even though it's an A500, though Commodore pretended it wasn't). As such, it's compatible with all Amiga controllers, such as the magnificent, clicky, and magnificently clicky Zipstik joystick, and two button pads like the Sega Master System. However, since it's a nifty video games machine, it has its own special, completely-incompatible-with-everything-else, controller. That odd, telephone/dogbone looking thing, there. The CD32 pad has seven buttons: four coloured face buttons, two shoulder buttons and a central button. The face buttons are coloured Red, Blue, Yellow and Green and, like the rest of the buttons on the controller, are decorated with video-player-like emblems as if you could play videos on the system. Which you can't, really. The shoulder buttons are not labelled L and R, instead game manuals refer to them as the 'top left feature button' and other adorably weird names CHECK. (Except for Guardian, which is sensible.) I'm going to call the shoulder buttons FF (on the right) and Rew (on the left), because they remind me of the Time Controls from Blinx the Time Sweeper. The directional pad is digital and has four directions: Up, Down, Left and Right. It's circular, somewhat like a Mega Drive pad, except five billion times more fragile. Replacement directional pad design by Ndo Design. It's a disc shape with protruding fingers on its base to lock it into a notched circular holder inside the pad. With minimal use (and thirty years of age) the notches can break, freeing the disc to rotate underneath your thumb, which moves the cardinal direction studs and contacts underneath out of position, making the pad nearly unusable. That's no good, especially if you just want to be a lion. I looked up possible ways to fix the pad, along with schematics for it. I wondered how difficult it would be to build a new pad from scratch completely - which didn't seem to be particularly difficult as it consists of eleven contacts and two standard logic chips. Designing and 3D printing a new pad case or D pad was possible, even plausible, but a little beyond what I felt like doing at this point. I hadn't done any microcontroller work in a while and also wondered if I could simulate the function of those chips in software. Since Playstation pads and their cheap-but-effective clones are still being manufactured by the million to this day (2019), a Playstation to CD32 convertor was the natural choice. The first thing to do is to research absolutely everything. • How does a CD32 power a CD32 controller (if it needs to)? • How does a CD32 console talk to a CD32 controller? • How does a Playstation power a Playstation pad? • Can a CD32 power a Playstation pad? • How does a Playstation console talk to a Playstation pad? • Can a CD32 power a Playstation pad together with some guys that translates the messages? The CD32 stuff The first two questions were answered by searching for schematics and pinouts of a CD32 pad online. I could have (and should have) taken my own one apart to see if I could fix the broken directional pad at the same time, but having bits of irreplaceable plastic raining down on my lap would've just depressed me. Here's a mirror of Gerd Kautzmann's CD32 controller page. ( Oddly enough it seems to exist because Gerd was frustrated that the directional pad was on the left side of the pad, which didn't suit their grip, rather than the thing being an unresponsive, fragile, irreplaceable pile of tat. They have a wonderful, if needlessly confusing, schematic of the pad: This pinout from the KTRL CD32 project is a definitive CD32 pinout: The mechanics of the CD32 can be mystifying at first, but I've got to master them if I want to create a device that speaks the same protocol. For example, in isolation, this is meaningless: By using these sources of information together with a bit of background information about the Amiga, we can determine what the CD32 pad does and why. First, here's a basic description of a simple one-button Amiga joystick: • The function of the joystick is to allow the user to input Up, Down, Left, Right, Fire or any combination of these. These are on/off inputs. • All five inputs are implemented as switches within the joystick linking pins 1, 2, 3, 4 and 6 from the Amiga to the ground connection. • The Amiga contains internal pull-ups which pull the voltages at these pins high by default. • When the buttons are pressed or directions are pulled on the joystick, switches to ground are closed, pulling the voltages at these pins low. • This means that when the switches are open, the voltage is high. When the switches are closed, the voltage is low. These states are read as 1 and 0 by the Amiga hardware. On a two-button joystick or two-button mouse, pin 9 provides Fire 2/Right Mouse. On a three-button joystick or a three-button mouse, pin 5 provides Fire 3/Middle Mouse. As a schematic, the joystick itself looks like this: If you wanted to play B.C. Kid with two buttons, this would be all you need! However, this doesn't explain how the CD32 is able to provide eleven unique binary inputs to the Amiga (Up, Down, Left, Right, Blue, Red, Yellow, Green, FF, Rew and Pause) with only seven data lines. The secret is that the above explanation is a simplification! It's true that the Up, Down, Left and Right inputs to the Amiga are simple pulled-up pins that are switched to ground, but the three Fires aren't. Let's have a look at the Amiga schematics at This somewhat-combed spaghetti shows a few things: • The two joystick ports are identical. • The box labelled RP401 is a resistor array that pulls all the directional input pins up. • The directional inputs are read using a uni-directional 74157 multiplexer so the Amiga can't set any pin high or low to change the behaviour from the described. • The three Fire inputs link internally to points labelled _FIRE0, POT0Y and POT0X within the Amiga chipset. _FIRE* links to a CIA on an A500 (Akiko on a CD32), and POT** link to Paula in both an A500 and a CD32. (The POT** pins are used for two axes of analogue input on each joystick port, for paddles and pens and other inventions.) Functionally, this means that all three can act as general purpose bidirectional IO pins, and can be configured as output low (sinking current), output high (sourcing current) or High-Z (no effect on output voltage, reading value from external effects), and can be read during any of these settings. This means that with some fiddling magic, the Amiga can actively perform a protocol to read values from the controller. Here's the pad schematic again: First, I'll define a table of pin names and roles:
Pin NumberAmiga NameCD32 Pad RoleDirectionality
1UPUPController --> System
2DOWNDOWNController --> System
3LEFTLEFTController --> System
4RIGHTRIGHTController --> System
5POT0XJOYMODE/FRAMEController <-- System
6FIRE0FIRE1OUT/CLOCKINController <-> System
7+5V+5VController <-- System
8GNDGNDController <-- System
9POT0YFIRE2OUT/DATAOUTController --> System
• The Up, Down, Left and Right inputs on the directional pad are just switches to ground, as in a normal joystick. • There is a connection from pin 7 +5V, so the pad requires/uses the power supplied by the joystick port. • The upper left IC is a 74LS165N, which is a 74165 low power schottky 8-bit parallel to serial shift register in a DIP package. • The triangular symbols are the gates of a 74LS125N, a 74125 low power schottky active-low tri-state non-inverting buffer in a DIP package. Let's assume that pin 5 JOYMODE/FRAME is set to High by the Amiga: • If pin 5 POT0X JOYMODE/FRAME is set to High, this sets gate IC2A to tri-state, which allows the enables of IC2D and IC2B to be pulled to ground and enabled. • When IC2D is enabled, the Red input is buffered through IC2D and out towards pin 6 as FIRE1OUT. • When IC2B is enabled, it passes Low to the SH/_LD input of the shift register, putting it into Load mode, making it update internally with the states of the Blue, Red, Yellow, Green, FF, Rew and Pause buttons. • With the shift register in Load mode, the current state of the Blue button linked to input H is passed directly to the shift register output. • The output of the shift register is buffered by an always-on buffer IC2C towards pin 9 as FIRE2OUT. Ultimately, this means that: • If the JOYMODE pin is set high by the Amiga, the pad is set to a dumb joystick mode. The states of Fire 1 (Red) and Fire 2 (Blue) are reported to the Amiga by grounding the FIRE1OUT and FIRE2OUT pins respectively as if Fire 1 and Fire 2 were simple switches to ground. This is exactly the behaviour of a two-button joystick or a Sega Master System pad. Great! Now let's assume that pin 5 JOYMODE/FRAME was High, but is now set to Low by the Amiga: • If pin 5 POT0X JOYMODE/FRAME is set to Low, this sets gate IC2A to enabled, which passes a High signal to the enables of IC2D and IC2B, disabling them. • When IC2D is disabled, the RA1-3 resistor is free to pull the CLK input of the shift register High, unless it is pulled low by pin 6 as FIRE1OUT/CLOCKIN. • When IC2B is disabled, the RA1-1 resistor is free to pull the SH/_LD input of the shift register high, putting it into Shift mode, freezing the internal states of the eight inputs with the states of the Blue, Red, Yellow, Green, FF, Rew and Pause buttons, followed by a 1 (High) due to R2. • The output of the shift register is buffered by an always-on buffer IC2C towards pin 9 as DATAOUT. Now the pad's behaviour is different. Pin 6 FIRE1OUT/CLOCKIN is being used as an input to the controller, and pin 9 FIRE2OUT/DATAOUT is sending the output of the shift register. Now this table makes more sense. :) • The Amiga can now read the value of the Blue button at pin 9 DATAOUT. • On the rising edge of pin 6 CLOCKIN (controlled by the Amiga), the value at pin 9 DATAOUT will change to the next input, which is Red. • On each new rising edge of pin 6 CLOCKIN, the next input will be presented, in this order: Blue, Red, Yellow, Green, FF, Rew, Pause, 1, 0, 0, 0... The sequence of inputs returned can be seen on the schematic as pins H through A on the shift register, with the SER shift-in input being used to provide an endless sequence of zeroes (Lows) once the eight variables have been exhausted. This means that: • If the JOYMODE pin is set low, the pad is set to seven button shift register mode. On the falling edge of the JOYMODE signal, the states of the Blue, Red, Yellow, Green, FF, Rew and Pause buttons are captured, and the state of the Blue button is presented on FIRE2OUT/DATAOUT. FIRE1OUT/CLOCKIN is treated as an input signal. On each rising edge of FIRE1OUT/CLOCKIN, a new button state is shifted onto the FIRE2OUT/DATAOUT line in a set sequence. When all seven buttons have been shifted, a final 1 signal is reported, followed by endless 0s. In both modes JOYMODEs, the Up, Down, Left and Right inputs are exactly the same as those of a dumb joystick. To summarise: • The CD32 pad has two modes, determined by the state of the pin 6 JOYMODE pin. This pin is controlled by the Amiga, and is one of the three bidirectional pins the Amiga joyport has. • If the JOYMODE pin is set High by the Amiga, the pad is set to a dumb joystick mode. The states of Fire 1 (Red) and Fire 2 (Blue) are reported to the Amiga by grounding the FIRE1OUT and FIRE2OUT pins respectively as if Fire 1 and Fire 2 were simple switches to ground. • If the JOYMODE pin is set Low, the pad is set to seven button mode. CLOCKIN is treated as an input signal. On each rising edge of CLOCKIN, a new button state is shifted onto the DATAOUT line in a set sequence. When all seven buttons have been shifted, a final 1 signal is reported, followed by endless 0s. Notice that the FIRE1OUT/CLOCKIN pin is bidirectional in this protocol, and its role changes based on JOYMODE. Specifically, it is an output if JOYMODE is high, and an input if JOYMODE is low. Because the Amiga can change the state of pins 5, 6 and 9 on each joyport at any time, and because the system runs arbitrary game/program code directly with no hypervisor or hardware locks, the states of these pins are able to change at any time. This means it very possible and likely for a device plugged into the joyport to cause bus contention, with both the device and the Amiga attempting to drive one of these pins at the same time if it doesn't react properly. This is Not Good. I asked on the English Amiga Board for information about the electrical characteristics of the Amiga's joystick ports. They supply 5 volts through a 4.7 ohm resistor. Good to know. Phew! So any device I design will have to have the above behaviour, and do it safely in such a way that it doesn't self-destruct, kill the Amiga it draws power from or kill the controller it powers. The Playstation stuff Now we can consider the Playstation side. For the question of how much power the Playstation 2 pad draws, I asked on the Electrical Engineering Stackexchange. I got one comment saying 'do an experiment'. Several weeks later, the question was deleted. You're great, lads. I guess questions nobody immediately knows the answer to make you look bad, huh? Google didn't help much either. I found more information about the Playstation pinout and interface online. • Curiousinventors PS2 interfacing page's site's github gist You Have Always Wanted to Know about the Playstation But Were Afraid To Ask by Joshua Walker. Future Laboratory - PlayStation 2 Logic Analysis The Playstation pinout indicates that the pad requires two power supplies: one for the logic and one for the motors. I found differing sources indicating that the logic supply can be anywhere from 3.3V to 5V or above. However, it seems to be commonly found that the consoles themselves supply 3.3V for the logic and 7.6V for the motors. The protocol itself is a SPI-compatible protocol, which is very considerate of Sony. I've used SPI before in the Ocelot Arcade System to control a TLV5618A 2-channel DAC reet-quick, so I know what it's all about. Specifically, it seems like it resembles Framed SPI. More on this specific later! In the Playstation controller protocol, SPI is used to exchange 8-bit messages with the controller. This protocol is simultaneous duplex, controlled and clocked by the console. While the console is sending a command message out, the controller is sending data back to the system. Since the controller can't know what the system is asking for until the message has been received, the first response will be a garbage byte. After that, the controller is able to respond to the messages it has received up to this point. since hte console is controlling the rate and number of transmissions, the console must execute the correct number of exchanges in order to receive the full response to any request it makes to the controller. A typical exchange with an original PS1 digital controller or an analogue controller in digital mode looks like this:
0x01 is an attention message to begin an exchange. The controller idles its response data line which is read as 0xFF. • 0x42 polls the controller for its button state. Meanwhile the controller responds to 0x01 with 0x41 indicating its controller type and data length in 16-bit words. • 0x00 0x00 0x00 are dummy messages to allow the controller to respond to the request. • 0x5A is a spacer message used when the controller is not ready to respond yet. • The controller responds to 0x42 with two data messages holding the button state response bitfields. The console stores the responses to its messages and extracts the appropriate values and bitfields. Read the documents for more info!

The Design of The Device (or 'Exploding Shorts and Accidental Whiffs')

Drawing out a diagram of what a hypothetical device would look like and what would be required of it. As you can tell by the upper diagram, I've thought it thought a whole lot: its a rectangular gizmo that connects to an Amiga and a PS2 pad and does stuff. The board will need: • Power filtering and management. • ICSP pins for programming the microcontroller. The microcontroller will need: • 12 GPIO pins total: • - 7 5-volt tolerant pins for connecting to the Amiga side. • - 5 pins for connecting to the PS2 controller. Since I already own a PICkit 2, it would be dandy for the MCU I pick to be compatible with it. That narrows down the list of possible chips to the Microchip range (ignoring oddball hacks to make it work with AVR) (and I later learned that Microchip had bought Atmel anyway, so they're all Microchip chips. How the heck was that allowed to happen?). I've got a list of all the communication pins, their voltages and their roles. Here's the very first sketch of the device. It's either a 5V-compatible MCU, or a 3.3V MCU with 5V tolerant pins. If I'm using a 3.3V MCU, I can't output the 5V High voltage required by the CD32, so I'll have to use open-drain outputs and use pull-ups to provide the High state. The bidirectional pin has a pull-up to prevent unusual states if neither side decides to drive the line. The lower right diagram shows how open-drain outputs can output a higher voltage than the MCU can supply. The PS2 pad has to be powered by 3.3V, so I've made a note to have a 3.3V LDO regulator on the board. This is the same type as the Ocelot since I ordered a pack of 5 samples for future projects. Either side of the regulator has a pair of decade caps: a ceramic and an electrolytic. There's also caps on the power output interface to the PS2 pad to ease things with the pad's power drain. The values I'll also copy from the Ocelot. I never did find out what the current draw of a PS2 pad was. I haven't decided if I'm going to interpose a buffer or driver to the PS2 SPI communication lines. The PS1/PS2 controllers cannot source current: they are open-drain outputs, so I have to provide pull-up resistors to bring the line up when the pad goes into a high-Z state. This applies to the DATA and ACKOWLEDGE lines, which are controlled entirely by the pad. The other lines, ATTENTION, CLOCK and COMMAND, are controlled by the PS2, so I can let the PIC control these directly with no problems. I suspect the PS2 pad's motors are pretty thirsty, and they require too high a voltage anyway, so I'm going to ground the motor supply voltage. Also notice in the lower left of the IC I've decided to allow for jumpers to select special features of the emulated CD32 pad, such as allowing one of the face buttons to be output as CD32 UP to allow the pad to be used on older Amiga games without accidental whiffs of up causing the player to jump inadvertently during play. In this version, a 5V MCU is used. I've added current-limiting resistors on all the Amiga's communication lines, in case of bus contention. (The caption reads 'Amiga is an active system that may try to drive the pins, current-limiting resistor to avoid exploding shorts.' - a common hazard.) In a scenario where one side is trying to drive a line to 5V and the other to 0V, then there'll be 5V across a limiting resistor. To reduce this current to <1mA, the resistors would have to be 5k. I decided against using a 5V MCU because communicating to the PS2 side would be too involved. I asked on the Electronics Stack Exchange for how to find the list of devices supported by my PICkit 2. The question was comprehensively answered by one Bruce Abbott, which was very helpful. Then the question was closed because asking on how to find the correct documentation for a microcontroller programmer was off-topic for an electronic engineering Q&A, which was not very helpful. *raised eyebrow shrug gesture* I'm afraid I just don't get it. I picked out some families at random, and decided to go with the PIC24 series in the end. The PIC16 seemed incredibly basic and old, whereas the PIC24 look like the 'little bro' of the all-singing, all-dancing dsPIC33 which I used in the Ocelot. Like so. It's looking pretty good. It's a 3.3 volt MCU compatible with the PICkit 2, those seven grey rectangles indicate 5V-tolerant inputs. It can do SPI; all those RPx bolded pins can be remapped to the internal peripherals.

The Design of The Software

Here's some drafts of what the device would have to do. I'm writing down the software in note form before I decide what I'm going to make the device out of, or if I'm even going to do it. If I can't come up with at least an outline of an answer, buying a bunch of expensive stuff seems foolish.