Check out these fast prototyping images:
PSX
Image by JulianBleecker
The prototype test rig here. It turns out this is _so_ overengineered my head’s going to explode. Why? What the heck happened?
Well, I think I got way too far ahead of myself and designed the circuit before looking closely at the technical problem I was trying to solve. I was a bit eager to create a little interaction ritual and was thinking quite hard about the implications a peculiar kind of game controller like this would have on my playing the game Katmari Damacy. I was thinking so hard about that side of the problem and not even bothering (over the summer) to look at my PS2 and figure out what the electrical signals were doing — or even prototyping on this STK500 development kit I have. I went ahead and designed a circuit, laid out a printed circuit board, and had the board manufactured, mostly because I was excited that I could.
Now I have an over-engineered board where half the stuff on it probably won’t be used!
Sigh..
Oh well. Lesson learned.
What did I learn?
For this particular project, social engineering — creating new kinds of interaction rituals — cannot ignore electrical engineering. The two need to happen simulatneously. I should have been as engaged in studying the electrical parameters of the problem as I was in studying and reading-up on the social engineering aspects. What is the social engineering? Investigating how social practice is shaped by the affordances we are given for engaging in interactions. In this case, the interactions we have with the imaginary logic of this particular game — Katmari Damacy — can be shaped and extended by a device that extends the material aspects of the game into an "offline" experience. How will my imagination of the game shift when I have to do things away from the television screen and video game console as an aspect of the game mechanic?
The electrical engineering — what got over-engineered — could have been made short, sweet and quite modest in its design had I studied the problem a bit more, and had more discussions about what I was doing. As it is, my harvesting of other people’s projects did not go far enough. I found plenty of information about how to connect a PSX game controller to "other things" (like microcontrollers), I came up short on information about making a PS2 console think some "other thing" (like a microcontroller) was a PSX game controller. In other words — spoofing a PS2 console. I guess my Google search parameters were off, but also I just blindly assumed that if I could understand how to talk to a controller, the inverse would be simple. In fact, the inverse is simple — there’s nothing left to learn, really, except that I neglected to consider that the PS2 console fairly well blazes along. Interacting with a controller can happen as slow as you want, whereas the PS2 console wants to make things happen quite fast. So fast, in fact, that the code I had written was missing the beat, effectively. As I had designed things in "bit-banged" mode, I just figured I could pretty much manually communicate with the console, but things happen quite fast, and doing things like using interrupts and such — well, the code couldn’t get into the service routine quickly enough to respond to 2us clock pulses, so then you’re in a situation of "dead reckoning" to find clocks and such. It started to feel a bit krufty — a bit messy.
Pinging todbot helped me to look at using the built-in serial communication hardware found on the Atmel microcontroller, and in short order he had emailed me links I wish I had found two months ago — other folks using 3-wire (SPI) interfaces to do precisely the engineering I was trying to do.
On to prototype number 2.
