PS2 input display/adapter project

Discussion in 'Modding and Hacking - Consoles and Electronics' started by zzattack, Aug 9, 2018.

  1. zzattack

    zzattack Spirited Member

    Joined:
    Nov 19, 2014
    Messages:
    161
    Likes Received:
    62
    Competitive gamers and speedrunners often decorate their live streams with so called 'input displays', an animated overlay showing which gamepad buttons are being pressed at each moment. For some retro consoles a number of solutions exist, and I was repeatedly being asked by multiple interested parties whether a PS2 solution was available. I could not find anything online and took it upon myself to build something instead. Maybe somebody on here can find some amusement in this 'blog'.

    What are we getting into?
    First step was learning about the protocol used to exchange data between console and gamepad. I had previously worked with the SNES and N64/NGC protocols which were incredibly simple and easy to capture with bit-banging in pure software. Luckily the protocol is well-documented. The PS2 (and even PS1) actually use a communication that is basically SPI with an additional kind of acknowledge signal. I thought that was pretty neat because there should be minimal issues with sampling and synchronization if we can simply employ a microcontroller with hardware SPI peripheral to take care of this communication.

    Requirements
    Next step is determining what the hardware should look like. I wanted the device to be usable in 2 ways:
    • as 'sniffer' where communication between console and gamepad is tapped and relayed onto the PC
    • as 'poller' where the console is disconnected and the microcontroller polls the gamepad, i.e. for use of the controller as input device with emulators/actual games
    In the sniffer mode, we use 2x SPIs as receive-only slaves, and in poller mode the microcontroller becomes a full-duplex master node. This meant I'd need a microcontroller with USB and at least 2 SPI peripherals. I went with a €2 STM32F042 and have not regretted it for a moment. Yes, they're more complex than the PIC18 stuff I've used so much already. But the sheer number of peripherals, pins and processing power you get from these is well worth the additional efforts during development.

    cubemx.png


    Hardware design
    Additionally, some circuitry to switch the data lines between console and microcontroller would be required. I ended up with a digital bus switch for most signals, an analog switch for the SPI clocks and simple mosfets for the higher voltage vibration motor supply.
    With the components figured out, I wired up the schematic and drew a board that would fit my default go-to project box.

    eagle.png

    Prototype
    About a week later I had my components, my PCBs and most importantly, spare time. After assembing one board it was time to have a detailed look at those signals. Turns out it wasn't half bad for a first board revision. Initially I felt I may have gone a little overboard with the number of probe points and unnecessary breakout connections I polluted the board with, but they've been useful enough to warrant them. For what it's worth, my 2nd board revision no longer has these because they were mostly a deveopment aid and they've served their purpose.

    musia_proof_of_concept.jpg

    Software pt.1: firmware
    All work up to this point has been fairly straightforward and minimally time consuming. This is where that changes: we're gonna have to write the software. First up is writing the firmware for the device. Some key features that I wanted:
    • device should present itself as driverless USB HID
    • a config interface on the device should allow switching between sniffer and poller mode
    • settings should be persistent (hence the EEPROM chip)
    • should have a bootloader for upgrades to be performed by end-user
    In order for the sniffer mode to sample both data lines (ps2-->controller and controller-->ps2), they should sample simultaneously in DMA mode. Turns out this works very well and is 100% reliable. All STM32 devices have a built-in bootloader which is quite useful. I'd have some trouble fitting one in the remaining flash ROM and would probably have had to resort to the slightly heavier STM32F091 instead. This MCU is pin-compatible but has 4x as much flash memory available.
    Eventually I ended up adding a cheap 16x2 LCD to configure the device as well in the 2nd hw revision.
    For whoever's interested, the code is available on my Github.

    devenv_2018-08-09_17-52-39.png
    Not much flash memory left :)

    Software pt.2 - input viewer
    With the firmware good to go, it was time to adapt my input viewer to support PS2 gamepads. A few years back I already developed a pretty powerful program for this. It uses SVG skins and was aimed at SNES/N64/NGC gamepads, so I mainly needed to add a skin and button mapping for the PS2 controllers. This is the result:

    munia_sw.gif


    Finishing up
    Aside from not having anything that would survive a 2 mile shipment most of the technical milestones have been completed. I drew up a controller port outline, measured out the holes for the USB and 8p8c connectors and CNC'd some boxes. Pretty happy with how everything turned out. Thanks for reading :)

    20180711_005116.jpg
     
    wisi likes this.
sonicdude10
Draft saved Draft deleted
Insert every image as a...
  1.  0%

Share This Page