Refining

I’m getting closer to have a second prototype of the PSX project. Strangely, I seem to be building the breadboard prototype (lower image) simultaneous with the PCB prototype (the thing on top). I think the breadboard prototype is mostly for working on the firmware for the Propeller, which is going better than I had hoped, especially seeing as I’ve never developed for it, and that I’m mostly in Spin assembly (not so ugly, but still..bleech..) The breadboard version is basically a core Propeller with some wiring for programming and for chatting to an EEPROM for permanent firmware storage. I started playing with this PCA9306 bidirectional level-shifter, which is sitting on the right half breadboard. This is basically the same circuit as what goes on the surface mount PCB, except for the addition of a LP2985 3.3v regulator.

This is a curious approach, getting slightly ahead of things, but it’s been a circuitous, round-about project from the original “hey..wouldn’t it be cool if..?” motivation that I thought would maybe be a weekend’s work of getting an Atmega324 to emulate a PSX controller. That’s the one in the image above, from last fall. I began the design last summer thinking I’d be done in short order. It should be..I’ve just got grease in my head or something. I was anticipating perhaps some trickiness because I took the trouble to pull out the boundary scan signals to the edge of the board so I could do some JTAG debugging. What went wrong? Well, mostly timing related things. This project motivated me to get my own logic analyzer so I could figure out what the heck was going wrong. There were mostly timing-related problems that I sort of pushed to the side to pursue another possible solution, which led to this current (v07) design.

How did this all start? I thought it’d be an interesting little bit of game controller provocation to have a controller that “got tired” just as one’s avatar might in a video game. To do this, I figured I’d have to make the data from the controller emulate “atrophy” by attenuating, for example, joystick control inputs gradually over time.

The “cleanest” design in my thinking was to toss most of the heavy-lifting into firmware. I figured if I could decode the data stream between the Playstation 2 and the controller, I could disrupt some of the data, run some numbers, and then tuck my altered data back onto the wire. This is the principle, at least. I sort of realized at first that I’d have to simultaneously communicate with the controller and the console. The console is the master in this situation, so having one microcontroller slaved to it might create weird conditions if the microcontroller was in the midst of reading from the controller.

This was a project that found me using some of these swell, low-cost logic analyzers, which is just what I needed to clear up lots of the confusion here. (I tried first with an oscilloscope, but ou just can’t grok the data easily enough, and you only have a couple of channels.) It really makes debugging possible for something like this, without just lots of serial channel “prints” or stuff like that. You confirm what signals are where (I’ve confused pins, or had code specifying wrong pins — I can recognize this quickly), and you can read data and verify your code. For this project I was basically using the analyzers to make sure that the PSX device was responding to the TWI signals and sending back data as it was supposed to. Often, it wasn’t, but I could see this right away, check my code and make corrections.

(The fine folks at Saleae were kind enough to loan me one of their super-svelte Saleae Logic analyzers to try out. It’s up there to the right of the Logicport, and you can see its visual engine in the image up top there.) I’ll be looking at it in depth and doing a little write up coming up here.)

What I’m doing is making the PSX device appear as a block of registers on the TWI bus. A bunch of the registers are read-only — those are the six bytes from a typical controller: two bytes for all of the buttons, and then one byte each for the horizontal and vertical displacements of the two joysticks. (Next edition, maybe I’ll add data from the pressure sensitive buttons..but I”m not worrying about that now.) Then a block of registers that are read/write — those are what you write to with data to emulate a controller. So, you write here if you want to emulate button pushes or joystick displacements. Then there’s a control register that’s a kind of railroad switch to control whether the device passes the controller data through, or passes the emulated data through. Finally, a sanity check register with fixed byte so you can confirm that the thing is actually listening to you.

One end of this thing will plug into a Playstation console. The other end has either nothing, or a normal controller plugged into it. Early days for this prototype enclosure, obviously. But, the principle is in there. There’ll be connectors on either end, and then a sidecar articulation that’ll probably have a few (SDA, SCL, GND, VIN) recessed 100 mil prongs so that you can use a standard jumper cable to hook up to whatever you’re using as a TWI master, like your Arduino or something. You’ll need the high side of the logic rail so power the controller if you’re using the set up without a console — this can be 5V because of the regulator on the board. (Oh, the next and hopefully last iteration will have a level-shifter to make sure whatever you connect with up to a +5v logic level will be shifted down to the +3.3v the Propeller wants.)

So, like..what gives? Is this a silly idea followed to its illogical and insane, over-determined, over-engineered solution, where really, in response to “wouldn’t it be cool if..?” I should’ve answered to myself – no, not particularly.

I don’t know. Worst case, I’ve been learning quite a bit, including patience. Best case, there may be some real utility for something like this if you think about the interesting possibilities of having a “platform” (dongle, really) for hooking up different kinds of things to control whatever goes on on a Playstation. (Curious if this’ll work for a PS3..) Because you can contorl this thing over the TWI bus, anything that can become a TWI master can effectively control a Playstation. So, you could take your Arduino or whatever and do Arduino-y things, like hooking up weird input things — accelerometers? a Wii controller? a punching bag? the Internet? — processing the input and creating inputs to the Playstation that it understands and, thereby, control your favorite game. That could be cool for gamers or tinkerers or researchers or other kinds of people who want to experiment with different sorts of input modalities for games. For some reason.