Introducing the μJoypad, the worlds smallest NES controller! Measuring in at 25.4×12.8×3.2mm (1.0×0.5×0.1in) this is, by my best research, the worlds smallest, fully functional NES compatible controller. A couple months ago I saw an article or video of the world’s largest game controller and thought to myself “I bet I could make the smallest” and so I did. The project is open hardware and available on GitHub. More pictures and a description of the design process after the jump.

As you may remember, this isn’t my first custom NES controller, but I started the project off hunting down a controller schematic so that I could make a proper clone. There is a surprising amount of inconsistency among these things online. Thankfully, I was able to find a nes controller scan and a replacement pcb layout which helped a lot. Knowing the basics of the controller functionality, I set off in search of the smallest footprint 4021 shift register available that I felt I could hand solder.

Next was to find some tiny push buttons since i didn’t want to deal with trying to make a bunch of tiny rubber dome buttons like in a normal gamepad. After a little searching, I found some sufficiently tiny ones.

Next was finding some resistors. I found a nice and compact resistor network for the button pull-ups and used some SMD resistors I already had on hand for the latch and clock pull-ups.

The hardest part to find was the NES controller cable. For my NES-chuck project, I just borrowed a cable from another NES controller, but I can only bear to take apart so many vintage controllers. Eventually I found some extension cables on Amazon that I could cut the ends off of guilt free.

The next step was taking the footprints for these parts, putting them into a new pcb layout, and cramming them into a small area. After guessing at a few different optimal placements, I came up with the arrangement seen here. Routing the traces was a bit tricky, but it all fit.

About a month ago, I sent the design off to OSHPark with a silk screen designed by a fellow SkullSpace member. The board arrived a couple weeks ago and I built one up. I was very much expecting my poor SMD soldering skills (evidenced by all the crooked buttons) or my first revision layout would have screwed something up, but to my surprise and delight, it worked right away when I booted up the NES. I even managed to play through the first level of Mario without getting hurt!

I’ve had a few people play with it already and, while everyone agrees that it is cool, they also agree that it is a painful experience. I’m not sure I really expected much more than that though, and honestly it is much more playable than I thought it might be. I’m going to see if I can laser cut a hotel key-card or something to make a bit of a case to reduce the pressure of the tiny buttons.

If you are interested in giving it a spin or want more details on how I did the design, I am organizing an embedded/electronics night at SkullSpace (125 Adelaide) on November 5 to which anyone is welcome. The plan is for me to talk a bit about the project followed by some project working time where everyone can work on their projects together with others interested in similar things. SkullSpace will also have a table at this weekend’s Central Canada Comic-Con and my μJoypad will be on display there too.

Kanban

The whole third day of the conference, I was at a working shop focusing on personal kanban. Kanban was started in Toyota, and can be summarized as visualizing your workflow and minimizing work in progress. A pretty simple strategy, but it has some interesting effects. We spent most of the day putting together boards that would work for us. This started off with 3 columns full of stickies with tasks on them. The columns were to-do, doing, and done. The idea was that you want to only have a couple items in the doing column or else you will not be able to effectively concentrate on any one thing. Moving things into the done column lets you see how you are achieving things and what your work flow actually looks like. I have built a kanban board on my cubical wall (pictured above), as have my coworkers that were also at the conference, and so far I am liking it.

Test Driven Design (TDD)

I was already investigating this before attending the conference, but there were a couple talks that really drove this home. The idea is that you write unit tests before you write any production code so that you can come up with an effective, minimal solution to your needs that can quickly and easily be verified any time you make changes to your software. I have been using this on my current project at work and so far I am really liking it. I can understand how this would be incredibly useful once your projects start to get really large.

One of the conference organizers pointed me to James Grenning who does a lot of embedded TDD (he literally wrote the book on it) and he has some really great, practical tips.

Pair Programming/Code Review

While not really that related, they share some common benefits. With pair programming, two (or more) developers sit together at the same workstation and work on the same problem together. This can be useful for getting out some quality code as well as transferring knowledge to another employee without spending time on documentation. Code review has a similar goal, but the second person just looks at the code after it has been written (and ideally before it is released) and they can make their suggestions/changes at that time. While not as effective, it can take fewer dev-hours and works to the same goal. We are moving to Git at work, and so I will be suggesting using Git merge requests as a good way to ease into peer reviews; any changes to code should be reviewed and checked in to the main repository by someone else.

Communication

This point was stressed with many different techniques, from stand up meetings to silent brainstorming. Everything sounded interesting, but the core idea was to promote open communication. The one thing that I have been doing already is keeping an IRC channel open with some friends/coworkers where we can chat about any obstacles we come across. I have found this to be incredibly useful and I think I will try to get more of my coworkers involved in that. The thing that I really like about IRC is that, even if you can’t provide an answer to someone, you get to see what is going on and perhaps learn something that you could use down the road. I had one of those moments this afternoon.

There was a bunch of other great stuff going on at that conference too. I hope to be able to attend more events like that in the future.

Git and CVS, while they aim to achieve the same goal, do have some significant differences. In order to ease the transition for the rest of the developers, I ran a few training sessions. I based the majority of my talk on “Git For Ages 4 and Up” by Michael Schwern, a fantastic talk using Tinkertoys to show how a Git repository grows. I didn’t have any Tinkertoys, but I did bring in a bunch of K’Nex, enough for everyone to follow along. I think using something physical really helped keep people engaged a lot better.

If anyone wants me help them out with a similar talk or just wants to chat about Git, I’m always up for talking about it.

A few weeks ago I was hanging out at SkullSpace and a group of fellow makers were working on their Arduino controlled hi-fi setup. They already had all the hardware for the setup constructed and were working on the interface when they realized that a soft-shutdown mode would be useful for saving state. Unfortunately, the power controller in the system just cuts power to the transformer that provides the Arduino 5 volts. We figured out a solution to this problem and I thought it was pretty clever, so I thought I would share it.

The power controller module used in the system takes input directly from a momentary switch and uses that to toggle a relay that passes mains power to the system’s transformers. The controller circuit operates at 12V and as I understand was chosen to allow a wider variety of fancy lower voltage buttons and power LEDs to be used. Getting the Arduino to act as a momentary switch (via transistors or relays) works fine for powering the unit down once settings have been saved. However, the actual physical power switch needs to work directly with the controller when the system is off, but talk only to the Arduino when the system is on.

To do this, we decided to hook the power button up through a DPDT relay that is switched directly by the 5 volt supply. This way, the button is connected to the power controller when the system is off (ie. no 5 volt power is present) and then once the system is on, the button is connected to the inputs on the Arduino. Since the relay physically switches the button between circuits, it doesn’t really matter that one circuit operates at 12 volts and the other at 5.

In my schematic, I assume that the input pin on the Arduino has the internal pull up resistor activated. I also assume that the relay can be driven directly by the Arduino, which often isn’t the case. You will likely need to use a transistor to drive the relay. Note that thus far the circuit is untested and should be used at your own risk.

For those interested, my schematic is available in gschem format here.

Last weekend my wife and I made ourselves made a new coffee table (well, more like we helped my dad make it for us). As you can see, our table comes with a door knob, a relic from its past life. A few weeks ago we stumbled upon another’s efforts to repurpose a door into a table and decided to try for ourselves.

My father-in-law already had some old doors sitting in his basement, but they were single panel doors. In order to get a cleaner look I decided that we should miter the cut and make the table look like it had just been folded over.

Since we have a rather long couch, our original idea was to use two doors: one for the table top and one side, the other for a shelf and the other side piece. However, after measuring to see how much longer this would make the table, we realized that we would only gain about 15 cm as we would still be cutting off the top and bottom to get us our folded look. Once we added in the fact that the second door was in much worse shape and was actually slightly narrower, we decided the extra effort wasn’t worth it so we ended up just using the one door.

At this point, we were still thinking we wanted a shelf and possibly also feet. One advantage of using a single panel door over a multi-panel door is that the height is much more flexible. We aimed to have the height of the table be slightly shorter than the couch seat height to allow for the addition of feet, but after a minor measurement error, we ended up with the table being almost the exact height of the couch. This turned out to be a blessing as, once we had the table assembled, we realized that we liked the looks of the table without feet or a shelf.

The one down side to using a single panel door is that the centre panel is not very strong, but it makes up the majority of the table top. In order to help solidify the top in case someone decides to sit on it or something, we added a few 2×4 support pieces to the underside of the table.

So far we have decided not to add a shelf as the look of the table is currently quite clean and has enough room for us to store some baskets full of board games. We still have some finishing work to do (fill in some of the joints and screw holes with wood filler, re-stain the heavily sanded corners and support beams, etc) but for now it is in service and we are really enjoying it.

Over the past few weeks I have been working on tweaking a bunch of configuration files (aka “dot files”) for programs I regularly use, primarily those used on the command line, and I now have things working really well. Part of the reason for this recent effort is my switch from the bash shell to zsh. I don’t want to get too much into the “why” of that, but the main driver for that change was improved completions and other fancy features. I found a couple of really neat tricks to improve the usability of zsh. One was syntax highlighting while typing commands, another was toggling the cursor colour to red when in vicmd mode. While both are really neat tricks, I just cannot get things to work with my setup 100%.

For the syntax highlighting, I found that on at least one of my computers, enabling the “root” highlighter would cause every key stroke to emit an annoying beep while acting as a normal user, and then just wouldn’t work when root. The highlighter basically just inverts all colours to emphazise that you are in a special mode, which is nice, but I can live without, so for the time being I have just disabled it.

The vicmd cursor colour trick is a little more frustrating. I really like the extra feedback it gives to the user. It even works for me most of the time. The problem I’m having is that when I have it enabled and I am using tmux (a terminal multiplexer, similar to screen) and I am using all that inside gnome-terminal, I occasionally get a beeping sound and an escape code 112 gets printed to the screen. This code is emitted by tmux when it wants to reset the cursor colour to default, usually performed when the tmux status bar updates. Unfortunately, gnome-terminal doesn’t know what to do with this escape code, so it just prints it to the screen and beeps at you. One person online said that gnome-terminal does this on purpose to emulate xterm, but when I tried this in xterm, everything worked as expected. I tried for a little while to get xterm to do all the things I was used to having in gnome-terminal (URL detection, copy/paste without using the mouse buffer, paused tty scrolling, proper unicode display, decent font, etc.) but that was just more of a headache.

For now, I’m just disabling the vicmd cursor highlighting when I’m using tmux. I had been planning to switch from using gnome-terminal tabs to using tmux locally (right now I’m just using tmux on my remote connections). If I do make that switch, I’ll basically lose the vicmd colouring completely. What I need to do is find a way to get tmux to suppress the 112 escape code, get gnome-terminal to just ignore the code, find a less frustrating way to move away from gnome-terminal, or at the very least detect that I am both within a tmux session and gnome-terminal (which might not even work when reconnecting to a tmux session). I’ve been fiddling with this for a few days now and can’t seem to get a proper solution and just felt like ranting about it. If anyone has any suggestions for fixing this problem, I’m all ears.

To start things off, I’ll write my first progress report on my bluetooth Kinesis mod. Earlier this year I wrote about my new-to-me keyboard, the Kinesis Essential. I have a few friends who also have this style of keyboard and one of them asked me if I could convert it to bluetooth for him. We did some brainstorming, ordered some parts, and now I’m ready to start prototyping.

My friend’s Kinesis is one of the newer, USB variants. However, it turns out that the new and old boards just use a common main board and the new ones add a USB hub with an integrated PS/2 to USB converter. Since PS/2 is a pretty simple protocol, we decided to start his mod off there; a PS/2 to bluetooth converter. I later plan to replace the whole keyboard controller in my board for better battery life and mouse integration (and to further confuse people who try to use my keyboard) but that will be phase two of the project.

To get the prototype going, I’m just using an Arduino and a PS/2 socket breakout board from SparkFun. As I’ve mentioned before, I’m an avid vim user. As a vim user (and not a masochist, despite what you might know about vim), I think the Arduino programming environment is terrible, so the first thing I did was set myself up with an alternate environment in which I could stay sane. I added Arduino filetype detection to my .vimrc, found a way to build and upload code using vim’s :make command (I chose the scons method described here), and copied the PS/2 Arduino library (found here) into my project directory since the scons setup didn’t seem to find it in the default location. From there, I loaded up the example PS/2 to serial sketch and got the Arduino to read from my Kinesis! Now I need to get a simple proof of concept for my bluetooth module going and then I just need to blend the two together.

I was recently trying to add an image to a PCB I was making. Being so modular, gEDA pcb does not have an image import feature but instead relies on the program “pstoedit” to convert PostScript vector images into gEDA pcb objects. I have tried doing this before, but usually ended up with poor results. I finally collected the steps necessary to get repeatable, high quality results, which I will document here for anyone else trying to do the same.

1) Load your vector image into Inkscape (I will assume that you already have a vector image and have Inkscape installed)

2) Ensure your image uses only a single colour: black. All black objects will be added to your pcb object and all empty space will be left empty

3) Convert all objects to paths by selecting each object and using Path -> Object to path

4) Remove all overlapping vector paths by using Inkscape’s merging tools (union, difference, intersection, exclusion, division, etc) found in the Paths menu. If you end up with any paths that are touching (or are even just too close to each other without being joined) you are likely to end up with gEDA pcb carving gaps between them to meet the specified tolerances.

5) Adjust the file size to be appropriate for the scale it will be on the board. I have not yet found a way to reliably re-size the imported image once in pcb, so it is important to get this step right.

6) Save your image as a *.ps (PostScript) file. Make sure the “Convert texts to paths” box is marked. You may also want to have the “Resolution for rasterization (dpi)” setting cranked up to its maximum of 10000, but since the graphic remains a vector through this whole process, I don’t think it will make any difference (I haven’t tried playing with that number yet).

7) From the command line, change to the directory that your *.ps file is in and run a command like this:

$ pstoedit -psarg "-r1000x1000" -f pcbfill -ssp 'inputfile.ps' 'outputfile.pcb'

When I was first doing this, I didn’t add any of the optional parameters and I was using ‘pcb’ instead of ‘pcbfill’. -f pcbfill helps to ensure that the objects generated are solid, filled objects, which they might not be otherwise. -ssp forces things like letters with holes (‘o’, ‘d’, ‘p’, etc.) to convert correctly. The man page warns that this may be CPU intensive, but all the conversions I have done have run pretty well instantaneously. I also found I needed the -psarg “-r1000x1000″ to get a good resolution out of the conversion.

8) Open your new *.pcb file in gEDA pcb and see the results. You may need to tweak some numbers or add/remove arguments, but so far this seems to work alright for me. Another option that might allow for a little more flexibility is including -xscale and -yscale flags if your image isn’t quite the right size. It may even help to make the image too large on purpose and the use the scaling flags to condense the resolution (again, I don’t think anything is rasterized during this process so I doubt this will make a difference, but it might be worth fiddling with it, even if I haven’t). You might also want to move the object into the top left corner of the pcb layout so that, in case you load it in a layout that is smaller it will still be visible.

9) At this point, you are ready to load your newly created pcb object into your full pcb project.

This process is not an exact science. Play with it until you find something you like. I have had success leaving out some of these steps too, so there is no need to redefine any defaults. Have any other tips for pcb graphics? Leave a comment!

While working on a project this week, I was trying to see what some silk screen art would look like on a PCB I’m working on, but the “photo realistic” export mode of gEDA pcb was restricted to only green solder mask, tin plating, and white silk screen. The fab house I plan to use only provides purple solder mask, gold plating, and white silk screen. Rather than try to tweak the green image in GIMP until it looks half decent, then repeating the process for each candidate silk screen image (and then each future project as well), I decided I would just write a patch!

My patch for gEDA pcb allows the user to now select a solder mask colour of green, blue, red, purple, black, or a (questionable) white, a pad plating colour of regular tin or gold, and a silk screen colour of white or black. All of these options are pictured above. You can find my proposed patch here, and hopefully it be accepted into the core software soon so that you can get it from your system’s repository.

I’ve been a fan and advocate of open source software for some time now, but I am pretty sure that this is the first time that I have actually submitted a patch to a somewhat mainstream open source project. I’m pretty pumped and I hope to do more soon. I heartily recommend it.

Update 2012-06-14: After some suggested improvement to my patch (additional yellow silk as well as the addition of copper and silver pad plating) my patch has officially been accepted into the gEDA pcb repository! You can get the latest version of the code here: git clone git://git.geda-project.org/pcb.git

A while ago I read this excellent article by Evil Mad Scientist Laboratories describing the need for some form of visual diff tool for open hardware projects. I had been thinking this was a great idea, but while working on a recent project, decided to actually start implementing something. I use the gEDA suite of tools, so that is what I’m creating this for, but the majority of the plumbing should be reusable for other file formats.

The first piece of this puzzle for me was automatically making image files of my schematics and PCBs that have changed and adding them to each commit. GitHub has image diffing capabilities built in, so this works great. I implemented this a pre-commit hook in .git/hooks/. My git hooks can be found here. I have designed them to work with the git-hooks tool by Benjamin Meyer.

This script seems to work fine for me, though I’m open to suggestions for improvements. My major issues with how the hooks work (which are more issues with git than my hook) are

1. The status message in the auto-generated commit comments is not being updated with the new image files and
2. Hooks don’t get pushed into remotes

The first issue feels like a bug to me, but I suspect that it was done intentionally for some reason I’m not aware of. I have played with a work around by adding a prepare-commit-msg hook that just regenerates the commit message comments, but I have tested the pre-commit hook enough that I don’t feel I need to be aware of the addition of the images.

The second issue I am told is a security issue as it would cause arbitrary code to be executed on the machines of others who might clone (and possibly even the server). One nice feature of the git-hooks tool is that it can use hooks in a local repo directory, so if you include my scripts in the git_hooks repository, you just need to run ‘git hooks –install’ and you will have the hooks working. Without that tool, you can just manually copy them into the proper file in the .git/hooks/ directory.

This method works well if I want to view visual diffs online, but sometimes I might be offline or perhaps I just don’t want to push my project to a public GitHub repo. For that, I plan to make some simple scripts that call visual diffing tools on my local repository. Git has the capability to set your git diff tool, so my plan is to write a wrapper script that picks the right tool based on file types. This script might also generate an image from files that cannot be diffed directly and don’t have the above auto generated files

Edit: Of course not 20 minutes after I publish this post I discover schdiff, a tool bundled with gEDA since the start of 2012 that is designed to hook into git-difftool to provide a visual diff of gschem .sch files. One format down, some more to go.  :)

Edit 2: Less than a day later and I discover there is also a pcbdiff tool on my computer that came with gEDA pcb. In Arch Linux, it installs to /usr/share/pcb/tools/pcbdiff, but it is not in the path, so in my .bashrc I just added ‘export PATH=”$PATH:/usr/share/pcb/tools”‘ at the end. I feel pcbdiff outputs images that are too low a resolution, plus it can’t handle when the .pcb files change in physical size, so I might submit a patch or two. Long story short, now I just need to make a script that auto-calls these diff tools based on the file type.

Photo by Wi Bing Tan

A little over a year ago I posted about switching back to the Dvorak keyboard layout. I have stuck with it since then and that is pretty much all I have used. I thought that I would give a quick update as to how that is going and what else is going on in my keyboarding life.

So far I am very pleased with how Dvorak is working for me. I find that when I am typing for long periods that I don’t have to move my fingers very much and it is quite relaxing. My major complaint with the layout would probably have to be the placement of the ‘L’ key. I think it is used a bit too frequently to be a pinky key. During general typing this isn’t too bad, but when typing for extended periods or while doing a lot of work on the command line (ie. running ‘$ ls -l’, all right-hand pinky keys), it can become a little annoying. Not quite enough for me to go back to qwerty, though.

When I do go back to a qwerty layout for short periods, I have a couple of minutes where I have to think about what keys I am pressing, but I have retained much of that muscle memory and if I have to type for longer periods, it comes back pretty quick (though I rarely need to do this). One thing that is annoying about switching back to qwerty on those rare occasions is keyboard shortcuts. I am a pretty regular Vim user and I have found trying to use Vim for short edits on a qwerty keyboard not to be worth the effort. I should probably force myself to use it, just to help maintain my abilities on that setup, but I generally just fall back to the likes of gedit/nano for those quick qwerty edits.

In my quest to perfect my keyboarding experience, I have made a few other tweaks to my setup. I think basically re-learning how to type makes you re-evaluate the things that you have lived with up until then. For quite some time after switching to Dvorak, I grew more and more frustrated by the typewriter-inherited stagger of a standard keyboard’s keys. It got to the point where I was ready to tear apart a bunch of keyboards in a quest to make my own. In the end, I was introduced to a bunch of columnar/matrix keyboards that are available on the market like the TypeMatrix, TrulyErgonomic, Kinesis Contoured, and Maltron, to name a few.

I ended up picking up a ~10 year old Kinesis Essential (with custom/hacked footswitches and upgraded memory, and much cleaner than the one pictured above) second hand from someone on the geekhack.org forums in like-new condition for much less than a brand new, modern version. This has been my primary keyboard at work now for almost 5 months and it is great. The hand separation and the use of thumb keys instead of pinky keys are welcome improvements (though at times I wish the hand separation were greater). The bowl shape of the keywells puts the keys into what feels like a much more natural location. The first thing I noticed when I started using this board was that when I reached for the keys, they seemed to almost press themselves as my fingers got there much earlier than my brain expected. All in all, I would say this is a great keyboard. A friend of mine has a more modern version of the Kinesis (though the PCBs inside look identical) and we are planning to convert it into a bluetooth keyboard. I’ll try to post updates as they come.

The other less major thing I have been doing is tweaking my Vim configurations. I have moved all my plugins into the vundle plugin manager and have made a number of keyboard remappings. The main one that most people would probably get thrown off by if they used my Vim setup is that, while in insert mode, I have swapped the numbers and symbols for all of the number keys (excluding the num pad). I find that when programming, variable names are used much more often than static numbers, as are many of the symbols, so this makes programming a bit quicker. This change is one that I think is taking longer to adjust to due to the fact that it is only remapped in the one mode in Vim and not across my whole computer, but I find that it is really only useful while coding anyway, so a system wide change isn’t really justified. Having said that, I do really find it useful and there have been times outside of Vim that I have wished I had it too. If anyone is interested in my Vim configuration, you can find it here.

Back in October I had the opportunity to compete in the 5th annual IEEEXtreme programming competetion, a 24 hour challenge to complete as many programming problems as possible. There were a total of about 16 problems, released roughly once per hour or so. Our team completed around 5 or 6 problems (some were remarked after the completion of the competition due to a bug in the test system, so I am not sure about the final tally). Our team started with 3 members, but unfortunately we were down to 2 about 8 hours in, but we still felt as though we managed to do pretty well. We recently got the results back and were pleased to discover that we came in 240th (out of a total of 1515 teams), putting us in the top 16%! We also came in 14th place in Canada and 3rd place at our home University. I somehow managed to miss this event every other year it has happened but have always wanted to go, so I am glad that I got this final chance to compete.

Photo "borrowed" from Leif Norman (click image for source)

This past Saturday was Nuit Blanche here in Winnipeg. Some 30,000 people went around the city checking out various exhibits of art and culture. One of the exhibits at the art gallery was ARTcadia. A bunch of displays setup with indie games and hacks. I had the NES-chuck out again and it saw a lot of use. Click here for some more pictures from the WAG.

While similar to Re:Play, the core difference for this event was that the games were setup as displays rather than booths. Because of this, there wasn’t someone around to provide instructions on how to start the game (ie. how to access the start and select buttons). We had a sign up with some instructions, but few people showed any interest in reading the signs. I may have to re-evaluate how this thing works for any future public displays.

CBC was running a contest called “Culture Vulture” where you have to go to cultural events and text in the posted word for an entry. SkullSpace must be getting some attention because the keyword posted at the WAG was “hacker”.

In addition to this fun comic, I have added some pictures to my previous post about the NES-chuck which I had originally forgotten to upload. Scroll down to the bottom of the post to see what makes the NES-chuck tick.

NES-chuck Demo from Benjamin Bergman on Vimeo.

I finally got around to making a quick demonstration of my NES-chuck. Code for the NES-chuck can be found here. The future event I mention is ArtCadia, which is part of Nuit Blanche. I’m not yet sure if I (or the NES-chuck) can attend, but I will keep this updated.

After the break, there is a rough draft of my script for the video.

Hi everyone!

I’m here to demonstrate this project that I made recently that I call the NES-chuck. As you can see here, I have a Wii nunchuck, but the cable has been replaced with one from the original NES controller so that it can be directly connected to the Nintendo. So with this, I am now able to play classic Nintendo games with the Wii nunchuck.

I came up with this idea a few months ago while chatting with some fellow hackers from my local hackerspace. We were thinking of project ideas and thought it would be great to play classic video games with a modern controller. The Wii nunchuck to NES conversion seemed good to me as it would be useful for one-handed gamers, people who want to eat a snack while gaming, or people wanting to play cooperative games by themselves. I then took it upon myself to make the NES-chuck at our next hackathon. We were later asked to help out with an event at the Winnipeg Art Gallery celebrating video game culture. The NES-chuck was setup for all the visitors to use and stood up to the use of hundreds of guests.

So here’s a quick demonstration of how it works. I can move the joystick to make Mario walk around, I can press the top button to make Mario jump, and I can press the lower button to make him run or, if he has the fire flower powerup, shoot fireballs.

Those of you really familiar with the NES controller will remember that it also has start and select buttons, but I have run out of buttons on the nunchuck. To compensate for this, I have used the accelerometer in the nuncheck to make the NES-chuck into a modal system. If you hold the controller in a normal playing position, the buttons function as A and B. However, if you hold the controller so that it is pointing upwards, the buttons will then act as Start and Select.

In order to get all of this functionality, I have crammed an ATMEGA 328 microcontroller running the Arduino bootloader into the nunchuck. The ATMEGA then talks over I2C with the nunchuck to get all the state information about the nunchuck (the joystick, the buttons, and the accelerometer) and then uses that information as it emulates the shift register inside the original NES controller.

In the future, there are a few changes that I would like to make to the NES-chuck. Besides getting a better NES that doesn’t constantly hang, I am considering taking the analog values from the joystick and using it to pulse width modulate the NES arrow buttons. That would let the user make Mario run at varying speeds, much like he does in the modern games. This rapid button pressing might get annoying for menu navigation, so when in start/select mode, the joystick will act as it currently does.

A second change I would like to make is to get rid of the Arduino bootloader. Since the NES-chuck is powered from the NES itself, the Arduino starts booting when the NES first turns on. Since the Arduino bootloader is slower to boot than the NES, things get a bit screwy, so I usually have to press the reset button on the NES so that it can get a fresh start with the NES-chuck already loaded up.

Lastly, I am currently experiencing a bug where the Start button gets pressed seemingly at random. It seems to happen most often when I am pressing up and left on the joystick and while jumping. The shift sequence of the NES controller has UP and START directly next to each other, so I think it is just a timing problem, but I haven’t been able to squash the bug yet. I did, however, manage to decrease the bug’s frequency by lowering the sensitivity to the UP button. Another possible solution would be to use an actual shift register to more precisely emulate the NES controller. The downside to this is that there is a limited amount of space in the nunchuck to begin with and so it might be tough to cram it all in there.

If you would like to get more information about the NES-chuck or you have some suggestions for the next version, feel free to leave a comment here or contact me through my website. You can also check out the code from our hackerspace’s GitHub account. I’ll post a link in this video’s description. The code is pretty simple, but a little messy as it was written in an afternoon. Feel free to use it however you would like. Also, if you would like to see the NES-chuck in action, it is looking pretty likely that there will be another video game art exhibit in Winnipeg sometime this fall, so keep your eyes and ears peeled for that.

I hope you liked the NES-chuck and enjoyed this video. Stay tuned to my channel and my blog to see my future projects.

Update – 2011/08/26: I originally forgot to upload the pictures of the guts of this thing. Here they are!

Photo credit: Sean