It’s a video site, a PeerTube instance, a friendly place you can post videos, and you can find out more in this collection of unscripted explanations from earlier live streams.
Thank you so much for watching, subscribing, and sharing my videos. And a special thanks to my supporters on Patreon, where recurring donations make this content possible.
This week, nemik posted a package for OpenWRT that makes it really easy to run the Fadecandy server on a cheap battery-powered WiFi router, the TP-LINK TL-MR3040. I just got my MR3040 in the mail, and I recorded a quick video demo:
I recently discovered Micah’s awesome Fadecandy USB controller for WS281x LED pixels. One of the things that I like the most about it is its “fcserver” to control LED pixels using Websockets. That is fantastic, but all implementations I’ve seen have people running it on a RaspberryPi or regular PC.
I wanted to create a sort of “stand-alone” and embedded version of this using less expensive TP-Link routers, running OpenWRT. My current favourite of these is the TP-LINK TL-MR3040 but it would work just as well with the infamous WR703n or others; so long as they have USB support.
I was at the Adafruit warehouse in Manhattan a couple weeks back, where we ran the first Fadecandy boards through their assembly line. The boards are now in the Adafruit catalog, and we made a video about the manufacturing process. Watch Ladyada explain how the assembly line works while I fumble with pick-and-place reels:
This is a 9×16 LED matrix I made by hand back in 2004, with LEDs I had left over from another, even sillier project. It has a USB interface powered by a PIC16C765 microcontroller, one of the first to feature a built-in USB device interface.
This video post is something of a eulogy for the project. I have been trying to simplify and unclutter my life lately, and to that end I’ve been having to recycle, donate, or throw out a lot of things. This includes old projects of mine. This matrix was a fun way to spend a couple weekends seven years ago, but since then it’s just been taking up space in my apartment. So, before throwing it out, I thought I’d take a few pictures and make a silly video.
This is a quick photoblog and a video to document my first experience with using the support material options in Skeinforge. This was on my Makerbot Thing-o-Matic with a MakerGear stepper extruder, 0.35mm nozzle, and aluminum/kapton heated build platform.
The model I’m printing is Yoshi, the familiar Nintendo character. I cleaned up and subdivided the original low-poly model in Blender, ran it through the Netfabb cloud for good measure, then ran it through Skeinforge 35 via a fresh ReplicatorG built out of the git repository. I’m printing raftless using an 0.3mm layer height. No Comb, and definitely no Oozebane. But the awesome newish Reversal and Outline plugins are your friends. I’m using full support crosshatch, with a minimum support angle of 46 degrees, a flow rate of 75%, and gap ratio of 1.5.
There’s a video below, to give you a better idea of the material properties of the support crosshatch. I apologize in advance for my coarse voice in the narration, I’m just getting over a cold 🙁
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.
As 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.
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.
Yesterday 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…
