Nerdy Texts of Analog and Embedded Systems Wizardry

I went to Tokyo with my GF’s family over the New Year. It was, in a word, OFF THE CHAIN. The above is a stall in Akihabara, which defies everything I know about retail shopping. In a bin, hanging out like so many gnarly street fruits, are op-amps, AVRs, weird eeproms, name it. It was crazy. And there were streets of these. As if that wasn’t enough:

That store just sold stuff with threads. If it had cut threads, you could buy it there. If it did not, you couldn’t. Why not? I got some bags of clear polycarbonate metric machine screws, cause hey, you never know when you might need THOSE.

Obligatory picture of 5G, one of the worlds most awesome synthesizer stores. This is the tech bench. You can tell because it looks like a messy-ass tech bench.

Getting the PS2 data to playback correctly took some doing. The first problem was getting the controller synced to the PS2, which was necessary to handle the configuration streams. “Modern” Ps2 controllers can be set up in lots of different ways — as a standard digital controller or all flavors of analog. You can tell them (if you’re a PS2 or l33t haXX0r) to send stick data, analog button pressure, to configure the vibration motor in different ways, etc etc. So, when the PS2 does this, our doppleganger controller has to respond correctly. The big PITA there is that the PS2 will send any number of “don’t care” digital reads before this happens. In the terminal above I’m counting polls before we switch over to analog and begin a pre-determined configuration routine which is similar from game to game.

The next problem was buffer overflow. I used to use these fancy Atmel Dataflash AT45DB642D parts to record data, and they ruled. They had onboard RAM buffers and generally took care of erasing and writing flash memory at the same time. Then every distributor ran out of them. [2011-07-06T12:42:33+00:00 — they’ve been back for awhile now, thankfully] So I made a daughterboard and used a “peoples’ flash memory” IC by SST. It was a lot more like “normal” [read: annoying] flash in that you had to handle buffering and sector erasing yourself and it was painfully slow. This coupled with the fact that when this one bowling game used the analog button pressure (O GOD WHY?) the controller was spitting like 20 bytes a read led to trouble. Specifically, I needed to buffer all the data coming off the controller while the erase happened and that could take seconds. I ended up with a 3-way ping-ponged buffer AND compressing the data so that it would only log CHANGES in controller readings. This did the trick. I felt smug.

Here’s the pretty pretty result:

So I’ve been building a bunch of video game controller controllers (game TiVos we call them) for Cory Arcangel for a big Barbican show. It’s pretty much everything from the Odyssey / Atari 2600 to the PS2. Basically, their job is to play back (repeat) a played video game in an artsy way, and to talk to a host computer for file transfer, etc etc. Most of them work by snooping the active-low buttons during the recording, then pulling those buttons low during playback at the right time. There is NO WAY this stays in sync with the system, but that kinda wasn’t the point.

However, it turns out for the PS2, that some of the bowling (yes, bowling) games Cory wanted used the ANALOG BUTTON PRESSURE coming off the controller. I was already an advocate of reading and replaying the serial stream from the controller rather than messing with the switches, but it turns out to do these games you pretty much have to do that. So, here I am, learning PS2 serial protocol. There are tons of notes online on this, but I especially liked and used Andrew McCubbins’ “PSXCONT” notes (though I couldn’t find his source code). The UPCB project, as usual during this video game project, was very helpful. Micah Dowty’s notes were really helpful. Lastly, the curious inventor PS2 site rules.

There had to be a lot of bus turnaround kind of thing to both read and playback the PS2 stream, so I needed an external MUX which I made from a 74HC157.

Armed with all that, I hooked up the TiVo, wrote some test code, let her rip, and watched the serial stream for boo-boos using the Saleae Logic analyzer.

There were lots, and they had to do with non-deterministic boot times and the initialization sequence it takes to convince the PS2 that the controller is legit. More later.

It’s official — I’m dropping cash on WTPA2. This is part of an order to my dudes at Taiwan Alpha for 1000 10kA pots, 1000 100kA pots, and 1000 very fancypants encoders. The cool thing about having the factory make this shiz for you is that you can get whatever specs you want on these guys, not just standard part numbers. All these components have long shafts to make it easier to project through a normal enclosure, and the encoders are both relatively high res and clickless. And most importantly, the pots cost like 20-25% of what they cost at Mouser!

Dealing with Taiwan Alpha has been good to me before. Shipping from China is a real bear, and there are always some weird exchanges, but generally they really want to make some business happen and this time they sent me some really complete spec sheets. Cross fingers!

So the first iteration of WTPA2 has some dumbass mistakes — bus problems during flashing hardware (missing pullups), some switch latch goofiness, and turns out all those RC filters in the encoder datasheet really ARE a good idea. However, once all the traces got cut and the little merce-resistors got in place, the thing works great. The VCO is spot on. More importantly, so is the FLASH MEMORY! The SST flash kinda sucks in that it’s not fancy and requires you to manage erasing-before-writing and demands paying attention to buffering and stuff, but you can totally turn off WTPA2 and turn it back on and keep playing with that perfect burp sound you made.

Also, equally excitingly, the ISR has gotten A LOT FASTER — this proto recorded and played back just fine at 45kHz. A lot of this had to do with taking some very good suggestions from Olivier over at Mutable Instruments (of the Shruthi-1 fame) who is a great programmer and shamed me out of much laziness in my code.
As if that wasn’t enough, I finally licked the lion’s share of the noise sources that plagued WTPA1. I’d always been really careful about analog signal routing, but I’d been pretty cavalier about ignoring the hell out of some of the “Analog Noise Cancelling Techniques” in the Atmega datasheet. Turns out I traced most of the noise back to on-chip activity which had to do with reading and writing to the SRAM (toggling GPIOs) while the ADC conversion was taking place. I moved some of the accesses around and that NAILED it. Like, totally duh!

Also, re: the picture — I bought one of those Saleae Logic analyzers the moment they started supporting Linux because it seemed like a cool toy. But it’s actually really useful and works great! In addition to actually seeing what’s going on over the bus (as attached here) it’s REALLY handy for timing ISRs. Like, you toggle a pin high when you vector, and then low again when you exit. I always did this with a scope, but the logic analyzer is great because it records a lot of them and you can analyze variation, see what happens between several different calls, use many channels, etc etc.

Anyhoo, WTPA2 had an exciting week. It may take a break for a minute as I have a really busy winter coming up, but still, good time.
xo
TB