After going months without a lot of time for working on my hobby projects, I finally had a few free days to work on debugging my embedded Bluetooth stack for the Propeller. I got it working well enough to demo a Serial Port Profile device, implemented using only a Propeller Demo Board and a $2 USB Bluetooth dongle:
Posts Tagged ‘video’
Propeller Bluetooth Stack Demo
July 25th, 2010Gitaroo Man + DDR Pad
January 15th, 2010As much as I like the long, complicated projects that involve weeks of soldering, gluing, coding, tweaking, re-tweaking and debugging, it’s really refreshing to occasionally do something cool with no more than an hour or two of work.
This mini-project was my boyfriend’s idea. It’s an experiment in cooperative two-player Gitaroo Man, played using a gamepad for attack/charge and DDR pad for defense.
For those who aren’t familiar with it, Gitaroo Man is a rhythm game where you do battle using music. You play music on your gitaroo to attack or to charge your health bar. To defend against the enemy’s attacks, you dodge by pressing buttons in time with icons that fly toward the center of the screen. We thought the dodging phase of the game might map well to a DDR pad.
Videos first, tech details below. My boyfriend is on the gamepad, and one of my friends defends with the DDR pad. Theoretically you can play this with one person, but we suck too much at the moment. When we filmed this, we hadn’t played Gitaroo Man in years.. so we definitely could have done better with some more practice 
Resurrection
Bee Jam Blues, Master mode
Implementation Details
This turned out to be such a quick project because it was really just some special-purpose firmware for my old Unicone2 controller emulator project. The firmware combines inputs from the gamepad and DDR pad, maps the DDR arrows to the buttons used for blocking in Gitaroo Man, and it includes a one-shot timer which converts sustained pressure on a dance pad arrow into a brief tap of the corresponding controller button. This way, standing still on the DDR pad won’t affect your ability to use the controller buttons normally during the attack phase.
Overview of all hardware and software components:
The Unicone2 hardware:
Links:
- Special-purpose firmware source code
- Unicone2 Subversion repository
- Gitaroo Man on Wikipedia
- Original post about the Unicone2 (August 2007)
Temporal Hex Dump
October 16th, 2009After building some hardware to trace and inject data on the Nintendo DSi’s RAM bus, it became obvious pretty fast that there’s a lot of data there, and (as far as I know) no good tools for analyzing these sorts of logs.
The RAM tracer has already given us a lot of insight into how the DSi works by virtue of letting us inspect the boot process, the inter-processor communication, and most of the code that runs on the system. But all of that knowledge comes in an indirect way, from using the RAM tracer as a platform to run other experiments. I’ve been interested in figuring out whether there’s a way to use the RAM trace itself to help understand a system’s dynamic behaviour.
The RAM is on a packet-oriented bus, so it would make sense to have a tool that looks kind of like a packet-based protocol analyzer. Think Wireshark, but for memory.
But there are also a lot of complex patterns that show up over time. As the DS loads a file, or initializes itself, or renders frame after frame of a UI, there are obvious patterns that emerge. So it also might make sense to have a visual tool, like vusb-analyzer.
Unfortunately, both of these approaches ignore the spatial organization of memory. The bus is a stream of packets that say ‘read’ or ‘write’, but the contents of RAM as a whole is more like a file that’s changing over time. Like in a version control system.
So the tool I’ve been imagining is kind of a hybrid of these. It would have a graphical timeline that helps you visually navigate through large datasets and identify timing patterns. It would have a packet-by-packet listing of the reads and writes. And most importantly, it would be a hex dump tool. But instead of showing a hex dump of a static file, it would be a two-dimensional hex dump. The hex dump shows space, but you can also scrub forward or backward in time, and watch the hex dump change. The hex dump could be annotated with colors, to show which data is about to change, or which data recently changed. You could right click on a byte, and see hyperlinks to the memory transactions that are responsible for that byte’s previous and next values.
As far as I know, nobody’s written a tool like this. So I have no idea how useful it will actually be for reverse engineering or performance optimization, but it seems like a promising experiment at least. So far I’ve been working on an indexing and caching infrastructure to make it possible to interactively browse these huge memory dumps, and I’ve been working on the visual timeline widget. Here’s a quick screencast:
The top section shows read/write/zero activity binned by address, with each vertical pixel representing about 64 kB. The horizontal axis is time, with continuous zooming. The bottom section of the graph shows bandwidth, color-coded according to read/write/zero. Blue pixels are reads, reds are write, and orange is a write of a zero byte.
This log file is about a gigabyte of raw data, or about 2 minutes of wallclock time. It shows the Opera browser on the Nintendo DSi loading a very large web page, then crashing. You can see its heap growing, and you can watch the memory access patterns of code, data, and inter-processor communication.
There’s a lot of room for improvement, but I’m optimistic that this will be at least a useful tool for understanding the DSi, and maybe even a more generally applicable tool for reverse engineering and optimization.
As usual, the source is in svn if anyone’s interested. It’s implemented with C++, wxWidgets, sqlite3, and Boost. I’ve only tested it on Linux, but it “should” be portable.
Robot Odyssey Mouse Hack 1
April 12th, 2009Yesterday I spent some more time reverse engineering Robot Odyssey. This was a great game, and it’s kind of a nostalgic pleasure for me to read and figure out all of this old 16-bit assembly. So far I’ve reverse engineered nearly all of the drawing code, big chunks of the world file format, and most of the code that’s responsible for moving around objects on the screen.
So, I thought I’d try manipulating some of that data. I extended my existing binary patch to add even more code to the game’s per-frame blit function. It sets up the mouse using DOS Int 33h, and lets you manipulate the game’s table of sprite locations by dragging objects with the mouse.
I took a video to show the results. It’s still obviously a hack, but it may actually be kind of useful for assembling circuits more quickly:
The source code is available, but it’s a bit rough. This patch is getting kind of unwieldy in its current state, and I think my next step will be coming up with a better tool for doing these kinds of patches. I’m thinking either:
- A pre/post-processor for NASM, which has binary patching oriented features.It would use signatures (byte mask + md5sum) to identify interesting code and data regions in the original binary, and allow you to replace or invoke snippets of code in the original binary using this mechanism. This should make it easier to do very invasive patches which can apply against slightly different versions of a game.
- Or, scripting support for DOSBox.This could be a lot like the Lua support in FCEUX which made Super Mario Drag & Drop possible. As much as I like the idea of self-contained binary patches that operate in the same environment the game itself runs in, a Python plugin interface for DOSBox could be extremely powerful. Imagine a real-time level editor, or various kinds of real-time memory comparison tools…
Robot Odyssey: 4-way low latency flip flop
April 5th, 2009Robot odyssey rocks. Also, I didn’t realize that you could upload a video captured with VMware Workstation directly to Youtube. It’s pretty neat that they support our video codec.
Here’s a video of a chip I was just designing, a low-latency 4-way flip flop:
The Kilowatt Clock
October 11th, 2008I thought I’d try putting together a YouTube video to show my latest crazy project. As usual, the schematic and firmware is in Subversion.
Helicoptering
August 22nd, 2007I’ve been remiss in my duty as blogger extroardinaire. A new hobby, and I haven’t yet informed the world!
For the past couple months, I’ve been fascinated by R/C helicopters. As far as I can tell, this all started when I was at Fry’s drooling over the Lego Mindstorms in the toy aisle. The abundance of toy helicopters caught my eye. I didn’t buy one right then, but the thought was planted in my mind.
I have been exposed to a lot of aerospace-related enthusiasm over the years. My dad works in aerospace, Jen has been squeeing about anything that flies for as long as I’ve known her, and then there was that whole Space Grant thing I did in college… Anyway, despite all of that I never really took the time to fly anything myself.
Within a few days, I walked out with a $25 infrared microhelicopter: a cheap clone of the Silverlit Picoo Z. This is a really fun little toy, and it was an instant hit at work. After I flew mine around the office a bit, at least three coworkers ended up buying one. It’s a lot of fun for the price, but it’s frustrating if you’re expecting to have a reasonable amount of flight control. There are only two low-resolution channels, and it’s pretty unstable.
Following in footsteps of one of my coworkers, I graduated from the Microgear helicopter to an E-flite Blade CX2. This is a really great helicopter for the price. Stable, maneuverable, upgradable, and ready-to-fly with a good supply of spare parts for about $250. This was Paul’s birthday present to me
I’ve been having a lot of fun with this. It’s very easy to fly indoors, and with a little practice it’s flyable in low winds. I usually fly it in the
apartment’s courtyard, though it’s insanely fun to fly around the new buildings at work.
Things that interest me about model helicopters:
- Aerobatics. I’m working on flying smoother and faster figure-eights on the BCX2, and I often run into the limits of the heli’s design when turning sharp corners. I’m curious what it’s like to fly a more capable heli like the Blade CP Pro or the Align T-Rex.
- Airborne nerf gun!
- A homebrew light kit for flying at night, perhaps with navigation lights plus a variable-power spotlight.
- Aerial photography. This interests me a lot, actually. The OpenSourceQuadroCopter or a similar quad-rotor design seems to be a better bet for stability, but I’ve been experimenting to see what’s possible with the Blade CX2.
- First Person View (FPV) flight. I’ve done some experiments with mounting a small wireless security camera on my Blade CX2, but some folks out there really know how to do this right. Some of those videos are very impressive.
- Tune-ups. Crashes suck, but the mechanic in me loves tinkering with small electro-mechanical parts.
Besides the little security camera, I’ve been experimenting with taking video from the Blade CX2 using a Flip Video camera. These are little solid-state camcorders that can hold an hour of TV-quality video. I stripped down a Flip Video camera to just a bare PCB and lens (without LCD) to reduce weight and power consumption. The board is conformal-coated in Acrylic to add a little bit of protection from the elements, especially electrostatic discharge. The whole camera is about 25 grams, and it can be powered via an extra +5V input on the proprietary connector. I run it from one of the extra servo connectors on the BCX2′s 4-in-1 control unit. (If you try this yourself, it’s important to use the same +5V input. The battery power input is designed for 3V only, and the +5V input on the USB port will put the camera into downloading mode.)
The only problem this leaves is how to mount the camera to the helicopter. My BCX2′s lower rotor is quite steady, but the upper rotor is a bit wobbly. The vibration is significantly less if you’ve just replaced both the inner and outer shafts, but even after a lot of mechanical tweaking I couldn’t get my heli running smoothly enough that a camera velcro’ed to the body would give me a clear picture. I ran experiments with a few different mounting systems. The one that seemed to perform the best was based on a rubber-band suspension (to isolate the camera from high-frequency vibration) plus a bit of foam to damp out oscillations in the rubber bands. I also coiled the camera’s power cord, to minimize the amount of vibration it would transmit. The prototype looks kind of silly, but it’s a significant improvement over mounting the camera directly.
The heli’s CG is quite good in this configuration. The servos and the battery holder are reversed, so the camera on the “front” of the heli is actually where the tail would normally mount. Its weight is counterbalanced by the 4-in-1 control unit on the opposite side. The heli has less rotational inertia than it would normally, but I compensate for that by decreasing the gyro gain. It doesn’t fly as well as a stock BCX2 flies, but a stable hover is still possible. Flight times are also quite good. I can get about 8 minutes of video+flight on a charge. It weighs nearly the same as the stock BCX2 body pieces, so most of the overhead is probably electrical. Without the LCD, the camera draws around 350 mA while recording.
None of the videos I’ve recorded so far are terribly impressive. This is the unedited footage from one test run. Individual frames from the image are quite clear, but the residual low-frequency vibration is causing some really strange wobbling in the picture. I saw this behaviour for the first time when I tested the camera outdoors.
(The video on YouTube, in case your RSS aggregator strips out <embed>s.)