Posts Tagged ‘Video Game Crap’

Vectors, or “My Man Inf Left A VEC and a 9 At My Crib”

Thursday, August 8th, 2013

So awhile back my man Andrew Reitano dragged home a vector monitor from an old Asteroids arcade cabinet.
Here’s what we’ve done with it so far:

It was a long road to get there!
For those of you born after the cold war, Asteroids was a hugely popular game by Atari which used a now-obsolete style of monitor. If you haven’t played one in an arcade you owe it to yourself to do it, because they look like nothing else. The phosphor artifacts are trippy and beautiful.

Anyway, the trick with these things is that they get driven more like an oscilloscope than like a normal TV or raster monitor. Meaning, you send them voltages and deflect an electron gun to a certain spot on the screen, rather than drawing an image out line by line like an NTSC or RGB display. This presents all kinds of problems.

First, you have to move this electron gun at an even rate, and you need to do it on a halfway stable and reasonably fast way. I think Asteroids drew at 4MHz, meaning you needed to be pushing the gun that often AND slewing a beam that fast. After blowing up a handful of output transistors in the monitor, we came up with these:

VEC9_FPGA_and_Amp_small

That’s a Xilinx Spartan-3E FPGA on a Nexys2 dev board which Andrew programmed to be our vector generator, and a DAC/Amplifier board I designed to sling the beam around at 20 MHz and 12-bit resolution. First thing we did (this was with some gnarly R2R dac) was get a cube to display on the scope (I think the monitor was still fried from earlier “tests”). It kinda sucked:

Vec_test_05_small

Encouraged, we got drunk, fixed the monitor, Andrew wrote a rasterizer and we put the patron saint of Bed Stuy on the screen. It sucked less:

Vec_test_02_small

By then we were pretty sure we had a new arcade game in the works and the heavy lifting started. Andrew tuned the hell out of the VHDL and got the FPGA tweaking all kinds of gun parameters. I fixed the amp a couple times to get it running that gun right, and both of us spent a lot of time coding in C. I’ve wanted to make video games ever since I was a kid, but somehow this was my first foray into coding 3d rotations, particles, dynamic memory, and a lot of other generally non-embedded stuff. It ruled. We got to the point where we could rudely waste 3d polygons:

VEC9_Screenshot_Jul25_small

We wrote a storyboard about the Soviet Union blowing up Chicago, threw in a bangin track by Nicholas “Windbreaker” Read and coded a chaingun. Lastly, one awesome thing is that since we’d basically made a vector “video card”, it was not too hard to generate a commlink / stores display / HUD using a monochrome VGA display, running as a secondary monitor. It looks amazing!

We’re pretty sure we’re on our way to a totally kickass arcade cabinet once we get the real game coded. If you know what we should do with this hot mess once we’re done, hit us up!
TB, August 2013

PS2 Fiddling Part 2

Thursday, December 16th, 2010

Looking for trouble on the PS2 Controller

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:

Throw some dees on it

PS2 Fiddling Part I

Tuesday, December 14th, 2010

Mucking with the serial stream on the PS2 Controller

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.

What the analyzer had to say

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.

Playstation PGA Golf Tweakery

Thursday, March 18th, 2010

More new media art binnis for Cory.
This is basically an installation specific version of that little SBC/datalogger thingy I made. This one hangs out on a silly putting practice stand and plays back controller keypresses on a PS1 when you whack the ball.

To do this, first (well, first you design a weird SBC for new media artists, but) you replace the controller’s MCU (in this case some proprietary TQFP guy) and figure out where his data lines are. I happened to already know that the PS1 basically talks SPI. Some low temp solder and a rework station was used to perform said brain surgery.

The datalines and switch lines are then brought out to my baby, where it handles communication with the PS1. You can then record the game into it, put it on your PC, and do whatever mess you need to with the data.

That golf tee had a set of optical photointerrupters inside it which were originally used to keep track of how hard you hit the ball and how badly you shanked it. I wired one of them to just give me a clean square wave when the ball moved appreciably, since that’s all we needed to know for our game. The code on the “TiVo” had to get changed to account for this, which was no biggie.

Eventually, these things had to get re-built cause Cory got worried that art students would have a few too many PBRs at the openings and eventually whiff and take out one of the external PCBs. I ended up ultimately shock mounting them inside the stand itself. That’s also why Cory is a good client, because he is almost certainly correct. There is a good chance that would have happened before leaving Narrat1ve labs :-)

“Video Game TiVo” Revised for Production

Monday, January 4th, 2010

So over the last couple years I’ve been building different variations on this thing for my client/buddy Cory. It’s had many names but the one we tended to call it the most often was the “Video Game TiVo”. It’s basically an AVR with a ton of Atmel Dataflash as well as some Vregs, level translators, and RS-232 chips.

The idea with these guys is that they sit around on a video game controller and log what the user is doing, and then spit that biz back out when you tell them to. The original ones simply hung out watching or asserting the actual switch lines using WPUs and the like, and as time went by they began to actually replace the controller interface entirely and deal exclusively with serial. Depending on the game system, they can sometimes play a game back deterministically, but mostly not because of RNG and/or timing issues. Either way, they’ll record MONTHS of game and can loop arbitrarily, etc etc. They also have a fancy terminal built in for communicating with a PC and recognizing different video game consoles.

Cory wanted them so he could throw infinite gutterballs in Playstation Bowling games. They do that just fine :-)

This one was tested on a PS1 and the canonical bowling.
This January I had geared up to finally make a TON of them so Cory could just have them handy and not need to call me when he needed one, and this was the final test run before we went into production.