Archive for February, 2009

NinBendo (cont’d): Zero-knowledge, realtime music tweaking example

This is a followup to this post.

Quick video example of finding and bending the music data that plays during Super Mario Bros. 3’s World 1 map, using the FCEUX emulator’s advanced 6502 debugging features. Full-screen if you’ve got it – the video did not survive compression well, and I don’t feel like investing hours tweaking around with it…

Video: Using FCEUX features to bend SMB3’s World 1 map music

Once on the screen of interest, go to the Debug menu and open the Trace Logger window. Tick the two ‘Only log new data…’ boxes, choose a filename for ‘Log to file’, and press Start Logging. These options require the Code/Data Logger to also be running, so FCEUX will prompt you to open it (hit Yes). Pay attention to the ‘Bytes logged as data’ count, it is slowly increasing as data is fetched from the cartridge. Most of the game code is running a complete loop every frame, so the ‘Bytes logged as code’ count should max out quickly. Likewise, MOST of the data being accessed here (e.g. sprites, etc.) will go through their entire rotation within a second or so, but the music takes over 20 seconds to do a complete loop (you can see the data byte count roughly keeping time with the music). Thus the last >20 seconds of data in the logfile will consist of music data fetches. Open the log, scroll near the bottom and notice the resulting disassembly, consisting largely of e.g.:

$E47A:B9 71 A7 LDA $A771,Y @ $A7C5 …

In English that is: Cartridge address $E47A onward contains an instruction with data bytes (B9 71 A7). The first byte is a CPU opcode (LDA $xxxx), telling the CPU to load the data at memory address (specified by the next two bytes, $A771) into its A register. Some subsequent code (purposely omitted from your trace log since it runs every time new data is fetched) processes the sound data. Thus corrupting one or more of those address bytes will cause incorrect sound data to be fetched and parsed, causing audible glitching depending on what the fetched data tells the sound loop to do.

NinBendo – circuit bending by corrupting 8-bit game code.

Yeah, back in junior high I had not enough friends and too much time, and discovered that keying in random Game Genie codes would sometimes cause a NES game to (harmlessly) glitch out in interesting ways. :-p Some codes just locked up the game (drat!), while others caused screen glitches, messed with colors, and rearranged levels. Still others would screw up the game music or sound effects. I was always strangely mesmerized by the bleepy sonic barf of a good sound loop crash.

Of course, now that I’m all old and exposed to the Internets, I come to find out there are entire groups devoted to pretty much exactly this–glitching out electronic toys to produce interesting sound effects (circuit bending). So for those folks, here is some info and samples from codebending on the original NES. Hardcore circuit benders might consider this software-bending stuff cheating since the case never comes off ;-)

Better Better DXF Output for Inkscape (layers!)

I started using Inkscape, a sweet open-source vector graphics program, to produce (and/or steal from the internet and convert) designs suitable for carving on the CNC as Inkscape has a plugin to export the file as a .DXF. Converting some files, I discovered the current export script does not correctly handle all types of transforms, so some parts of the file may export out-of-proportion to each other or in strange size units regardless of the drawing units of the original drawing (Inkscape’s internal drawing unit is apparently equal to 1/90 of an inch, wait, wtf?). Also, if the drawing contains curved (Bezier) lines, these will be exported more or less as-is (DXF splines) and many free/cheap/itch-scratch-ware programs will not handle the resulting file (since the ‘correct’ representation or interpretation of splines is never disclosed in the published DXF file specifications, so everyone kind of does them in their own way, with less-than-stellar results).

Bob Cook noticed these limitations and updated the script to fix many of the ‘unusual transforms’ scaling issues, and convert Beziers to standard polylines that any program will import. It also adds some support for layers, including special ‘drill’ layers whose drawing objects will be output as single points (no lines) for hole drilling.

In theory, the layer support as he implemented it ought to work (it’s correct and in conformance with the DXF spec, which allows drawing objects to be assigned to arbitrarily-named layers throughout the file). In practice, many of the same free/OSS, low-cost and weekend-warrior tools do not handle this any better than splines. I dug up a copy of the DXF spec, played around a bit and found that these programs expect all layers to be formally declared in a DXF LAYER table in the header section of the file before use. So here is an update to the export script that generates a proper LAYER table, allowing a wider variety of toolpath generating programs to import them correctly. So far it has been tested with ACE Converter and CamBam and seems to work well, but as always this is a quick n dirty, not exhaustively tested script and there is no lifeguard on duty. (Inspect the imported files for problems before commanding your big machine to cut them!)

Better Better DXF Output for Inkscape

Just unzip into your \Inkskape\share\extensions directory. Note that the updated ‘’ replaces an existing file.

Note: There is still an outstanding issue with Grouped objects in Inkscape being exported with incorrect size. As I understand it (assuming the document structure sent to export scripts is substantially an SVG file), transforms are applied at the Group level, which is sort of a container that has the actual drawing objects (and possibly further nested groups) as its children. Guessing that to handle this correctly, rather than looking for transforms at the node itself, it must also maintain a stack of transforms that have been applied at the node’s parent level, and parent’s parent, etc. For now, it is an easy workaround to ungroup everything before export. Maybe someone with freetime can update this and release it as ‘Better Better Better DXF Output’ :-) (b3dxf?)

Protected: A decade of thoughts… // Two’s complement (one’s a crowd)

This content is password protected. To view it please enter your password below:

Steppin’ Razor: Yet Another Cheap DIY, Homebrew CNC

After about an entire year of the parts sitting around, next-week, next-month, ya-I-been-meanin-ta, tonight I managed to get my homebrew CNC router* assembled into a usable (or at least testable) state. The entire design (if you can call it that! – it was really kind of ad-hoc) consists, as much as possible, of parts commonly available from any random big-box home improvement store (ours is the ‘Depot). The only ‘specialty’ (not available from the hardware store) parts are the electronics – stepper motors, driver boards, and power supply for the above – and machine parts such as ACME nuts and leadscrews, and some standard bearings to help hold the leadscrews in place. The machine’s linear bearings – commonly regarded as the holy grail of low-cost DIY CNC machines (good linear bearings are hard to come by and hard to make!) – are pairs of big industrial-style drawer slides (also from the Home Despot), carefully squared and bolted into place. Not a recommended approach for any remotely heavy-duty machine, but since I mostly intend to carve wood, plastics and the occasional PCB, this shouldn’t pose a huge problem.

Some videos of the machine running:
First test: carving a small face in a piece of foam
Closeup on the business end (Dremel-style rotary tool affixed to the Z axis)
The finished piece
Carving some zombies – here I got smart and attached a light to the machine
Bonus: Dry run (Dremel spindle turned off), showing the melodic sound of the stepper motors :-) (And in the background, the current-limit relay in my borrowed bench supply going nuts. The stepper motor drivers are now powered by a beefy 19V 6A power brick intended for a big laptop.)


The basic idea (for non-techies):
Imagine spinning a nut on a long bolt – the nut moves up or down the bolt depending which direction it was turned. The same can be done by holding the nut steady, fixing the bolt in place and rotating it – the nut will slide left and right. Attach a cutting head to this moving nut, and mount this assembly (that can move in one axis, e.g. up and down) to two more just like it that move in different directions (left/right, in/out), and you have a cutter that can be moved around in three dimensions by spinning the screws. Attach some motors and a computer can turn the screws automatically by driving the motors forward and backward, moving the cutter in a way that carves out a complex shape.

Components of interest (for techies):
3x Vexta stepper motors, PX245-02B-C8 (6V, 0.8A per phase): $5 each on AllElectronics (sold out shortly after I bought mine)
Stepper drivers: 3x Linisteppers, bolted to a pair of Pentium slot-whatever heatsinks and fan.
Lead screws: 1/2″ x 3′, 10 thread per inch ACME threaded rod (, with matching ACME nuts attached to the linear guides using J-B Weld (this stuff is amazing!). In retrospect, 10tpi is a bit overkill, and I have to spin the motors like crazy to move the axes at any speed (specifically, 10 rotations to move 1 inch), and stepper motors start losing a lot of torque at higher speeds.
Couplings (motor to leadscrews): Fat vinyl tubing sections and hose clamps

There are still some bugs to work out. For one, though the drawer slides on the X and Z axes are working well, the vertical orientation of the slides for the Y table produces unacceptable play. Basically, the internal part of the slide (the part that actually slides) can shimmy left and right slightly in addition to in and out of the rails that contain it, which gets worse the further these inner parts are extended out of the fixed rails. The force of the cutter pushing left and right into the material causes the table to skew a small amount, which both introduces inaccuracy in the cut and causes the Y table to bind (get stuck). I also still have not found a *good* way to hold down arbitrarily sized and shaped work pieces. Detailed build pics, yet-to-be-tested specs (accuracy, etc.), assembly guides(?) will be in a future post.

*What’s the difference between a router and a mill? Semantics, mainly. The terms are somewhat used interchangeably. From what I can gather reading forum posts on the subject, router implies higher spindle speeds, softer and thinner materials being cut (wood, PCBs), and higher speed overall, while a mill implies a heavy-duty, slower-moving machine cutting metal.