Ready for some Mega Man 7

I was inspired for this build by an instructables user who used my teensy ps3 gamepad code to build a SNES USB controller for the PS3.

I can’t say enough good things about the Teensy development board. It’s affordable and just so damn versatile.

John’s code is great and all but I just needed something to work with my Linux media center PC so I set out to create a simpler version. Click through for some build tips, links to the code, and a few more photos.

Download

• source code from here or here
• source compiled to ihex for flashing

Tips & Photos

Teensy /w SNES controller wires

In tight spaces like a gamepad it’s no fun at all to be wrestling with a rats nests of wires. Heat shrink tubing is great for managing bunches of wires, but it can make the whole thing difficult to bend. Using a few small rings will still give you a neat bunch of wires, while maintaining flexibility.

Teensy installed

John had a really great tip. Cut off the USB plug housing with a sharp knife to make fitting the cable easier.

Make room for the Teensy

The Teensy will just fit inside the controller without too much fuss. The only modification required is to remove a plastic post in the middle of the rear cover. Break it or cut it off and then use an x-acto-knife to clean up the remaining material.

Bench-top power supply

I stumbled upon this video by Phil Levchenko showing how to turn an ATX power supply into a bench power supply. I had an old PSU laying around and thought this would be a perfect way to give it a new life. Phil’s video is great, but I found the video tutorial format a bit tricky to follow at times.

Click through for some pictures, tips and diagrams that you may find helpful.

Diagrams

Standard ATX wire colours…

Schematic…

Tips

Lots-o-wires

When I started tearing down the PSU I was tempted to start de-soldering all those extra red, yellow, orange, and black wires. Twisting them together and routing them to binding posts seemed like too much of a pain. Then I realized that these PSUs are capable of providing a pretty significant amount of current (~20 Amps on 5v rail)! The wires in my power supply are 18 AWG, and I couldn’t find a definitive answer to how much current a single wire could safely carry. So in the end I kept 6 wires per colour… just to be safe.

In my PSU I chose to pull out +12v, +5v, and +3.3v to binding posts since I can’t imagine a use for -12v or -5v.

One last glamour shot

Arduino - It Only Does Everything!

Several months ago a friend of mine really into making bread inquired about a possible solution for proving bread dough and making pre-ferment starters in the winter. You see, here in Canada winters are cold. Very cold. And heat isn’t free. Yeast likes to be in nice warm moist conditions, but my wallet likes to be in the cold with a thick sweater.

So the goal was to create an efficient device that monitors temperature and switches a heat source on/off as necessary to maintain a constant temperature inside of an enclosed space such as a camping cooler.

And here is the result! It’s based on the bare minimum circuitry needed for an Arduino compatible board and then builds on top of that; character LCD display, two buttons, DS18S20 temperature sensor, and a small relay for switching an AC lamp.

Source code, schematic, PCB layout

v1 PCB - component side

• source files from my git repo, or github
• see README file for ATmega flashing details
• v1 PCB artwork [PDF] for toner transfer or exposing pre-sensitized copper clad
• v1 schematic [PDF]

What’s inside

The doughduino deviates slightly from the Arduino on a breadboard; it does not have a power supply regulator so an external 5v supply is needed. I was pleasantly surprised to find that the guts from an old cell phone charger worked just fine (many chargers are 5 volt, 1 amp supplies).

Guts from a cell phone charger

Fully assembled internals

Assembled PCB with annotations

Questions/Comments

Feel free to post a comment or short questions below. If you need help please use the forums.

Are you as annoyed as I am about the superfluous screen real estate consumed by the toolbar buttons in Nautilus 3? Of course you are, that’s why the oracle brought you here.

To remove them, modify /usr/share/nautilus/ui/nautilus-toolbar-ui.xml and comment out all the <toolitem> elements.

<ui>
<toolbar name="Toolbar">
    <!--<toolitem name="Back" action="Back"/>
    <toolitem name="Forward" action="Forward"/>
    <toolitem name="Search" action="Search"/>-->
</toolbar>
</ui>

If we look at all of the popular mobile platforms, they each provide some sort of native development kit all based around a GCC toolchain with OpenGL ES 2.0. So obviously we want to use as much portable C/C++ as possible, but what about all the little (and not so little) differences between the platforms? I needed to get my hands dirty and write a proof of concept.

The result is a simple bouncing ball simulation and it runs on Android, iOS, and desktop (Mac, Windows, Linux). Box2D is used for the physics engine, and the rest of the code is licensed under the permissive beerware license; please respect the license and buy me a beer… if we ever meet.

The code: what it is and is not

This is 2D only. This is not a framework. This is not everything needed to make a game. The purpose of this demo is to get an idea for how one might structure a project to maximize the use of portable code.

As it turns out using C/C++ for our game engine, logic, and graphics accounts for quite a lot. But several platform specific aspects are worth mentioning.

The obvious first difference is the fact that Android is Java/Dalvik and iOS is Objective C/Cocoa Touch. The basics for application development differ significantly from platform to platform so we have to just grin and bear it. For Android we need to use JNI¹ to call into our C/C++ code (avoid JNI inside render loop due to overhead). On iOS Objective C is a pure superset of C so it mixes nicely. You can also tell XCode to use the Objective C++ compiler which lets you freely mix C++ and Objective C by simply making sure your implementation files have a .mm file extension.

The second is the way OpenGL context is setup. On Android we have GLSurfaceView, on iOS EAGLContext/CAEAGLLayer (see GLES2Sample), and desktop freeglut.

The third is asset loading. To handle this in the demo I defined a basic set of function declarations that need to be implemented on each platform (see assets.h).

/// Structure containing raw asset data and length of data.
typedef struct asset_t {
   uint8_t *data;
   int size;
} asset_t;

/// Load asset from relative path.
asset_t * loadAsset(const char * path);

/// Deallocate an asset structure returned by loadAsset() function.
void freeAsset(asset_t * asset);

On iOS the implementation is simple: resolve the path relative to the applications bundle and read the file into memory.

Android was a bit more complicated. I had to do some JNI voodoo to call back into the Dalvik VM to open and read files. The Java code itself was simple, and the JNI code isn’t that bad either, but there is some serious implications when it comes to JNI state. Basically in order to call back from C/C++ into Dalvik we need a valid pointer to the JNI interface and the JNI pointer to the instance of Activity but these pointers are only guaranteed to be valid within the scope of a JNI call. I ended up just saving the JNI related pointers into global variables before calling any engine code that will call the loadAsset() function².

The last platform difference I want to mention is user input handling. In the demo a simple struct is defined to abstract out the type of action and the related (x,y) coordinate:

/// Action structure containing the type of action and x,y coordinates.
/// Touch actions use x,y coordinates in screen space. Tilt action uses
/// x,y values to represent a force vector in the range -9.18 to 9.18.
typedef struct action_t {
   action_t(action_type_t t_, float x_, float y_) : type(t_), x(x_), y(y_) { }
   action_type_t type;
   float x, y;
} action_t;

The render loop extracts these actions from a queue and handles them. The threading model varies from platform to platform so it’s important to make sure that actions are queued on the same thread as the renderer to avoid potential race conditions.

Running the demo on desktop

To build on the desktop a few libraries are used to simplify the use of OpenGL: freeglut for creating the window and OpenGL context, and GLEW to check for OpenGL 2.0³ support and include the various OpenGL headers.

Use your distro’s package manager to install freeglut and GLEW:

sudo pacman -S freeglut glew

On Mac OS X an implementation of GLUT is provided with XCode. To install GLEW first install MacPorts and then run:

sudo port install glew

On Windows MinGW needs to be installed and configured. Download the Automated MinGW Installer package⁴ to simplify things and select C++ Compiler and MinGW Developer ToolKit during setup.

Once installed download the freeglut and GLEW source packages and compile/install them from the MinGW Shell:

unzip glew-1.5.8.zip
cd glew-1.5.8
make
make install GLEW_DEST=/mingw


tar -zxvf freeglut-2.6.0.tar.gz
cd freeglut-2.6.0
./configure --prefix=/mingw
make
make install


To build the demo just run make in the desktop directory. The asset loading implementation looks for assets in the path ../assets so be sure to run the balldemo executable from inside the desktop directory.

1. when targeting Android 2.3 and up the NDK supports writing all code in C using native activies
2. when targeting Android 2.3 and up the NDK provides a native asset loading API
3. OpenGL ES 2.0 is a subset of OpenGL 2.0
4. at time of writing the mingw installer was mingw-get-inst-20110316.exe

Yet another use for an arcade button

Here is a nifty weekend project. It’s a 2-stage shutter remote for my Canon T2i DSLR. The red push button is a full press and the arcade button is a half press. Since it requires less force to push the arcade button than it does the red push button, it functions exactly as the cameras built-in shutter switch. I got the inspiration for this project from a guide on diyphotography.net.

Everyone loves graphs...

This really is depressing. Being Canadian and all I really want to root for the home team. Moreover I hate polluting my blog with complaints about BlackBerry development. Alas, here we go again…

Todays topic: BlackBerry Push Service. BlackBerry push can be routed through BlackBerry Internet Service or it can route through a BlackBerry Enterprise Server. The difference? BIS is the one you want to use if you are a developer targeting the consumer market at large. To route push notifications through BIS, you must request to evaluate the push service. It also appears you must submit another request when you want to go live, but I haven’t made it that far.

This is where the problem lies. I have submitted three requests in the past two weeks with no response. Each time I submit one, I’m greeted with a friendly message:

“Thank you, someone will contact you in two business days“

Bottom line I can’t finish OR test my app without access to this service.

What about the other guys?

This is where it gets sad. The software I’m working on is also being developed in parallel for Android and iOS. So what does the process look like for the other platforms?

Android

The Android Cloud to Device Messaging framework also requires developers to signup to access the service. The difference being two seconds after you fill out the signup form you are ready to go!

Slightly off topic, but the C2DM API is extremely simple to use. It was a pleasure to work with since I could use basic Unix shell scripting to send requests to the service during testing.

Apple

After you register as an iOS developer (and you drop $100 US for the privilege), Apple gives you access to something called the iOS Provisioning Portal which is a web interface for generating all manor of certificates and mobile provisioning bits and bobs. In this portal access to the APNS (Apple Push Notification Service) can also be enabled with a few mouse clicks… instantly.

So what have I done so far?

Not wait on RIM, that’s for sure! In the last two weeks I have managed to completely finish the iOS and Android versions of my app including full push integration.

Let me say that again. In the time it’s taking RIM to grant me permission to write software that uses their services, I have created the same thing on competing platforms.

A wire harness promoting proper dental hygiene.

I don’t pretend to be a master of wire lacing. To be honest this is my first attempt but I am thoroughly pleased with the results. I was inspired by a recent article by Keith Neufeld in which he showed off his x0xb0x Wiring Harnesses.

This is my latest arcade joystick build incorporating my recent teensy++ based controller. Locating resources on the web describing the art of wire harness lacing can be tricky as it doesn’t seem to be a popular practice but I found a decent writeup here. The wires on my controller are 24 gauge so the thick string Keith used would have been overkill. Instead I opted for waxed dental floss to wrap the wires (tip: waxed is important as it helps the knots stay tight).

Full harness

Teensy++ on a breakout board

It’s no secret the PS3 will work with most USB HID gamepads or joysticks. However the Home button is something special. If you connect your sixaxis controller to your PC and monitor button presses, the Home button comes up as button number 13. If you then create a standard gamepad with the same button mapping, the PS3 will refuse to recognize the Home button.

After some tracing of the USB traffic from an official Madcatz Street Fighter IV FightStick I was able to come up with a solution! There are 8 bytes transfered during the enumeration phase, just after the device sends it’s report descriptor. Mimicking the same exchange results in the Home button functioning correctly when button 13 is pressed.

I used the amazingly awesome Teensy++ development board after being inspired by this guys work. I also used the report descriptor from Toodles UPCB project which appears to come from the SEGA VIRTUA STICK. This descriptor is very similar to the one from the Madcatz controller, except their is one endpoint instead of two which simplifies things somewhat.

I also created a shield (pictured above) which brings several pins on the Teensy to convenient screw terminals.

Source code and Eagle files are available in a git repository. Code is licensed under the GPL v3 and the PCB design is distributed under a Creative Commons license Attribution-ShareAlike 2.5.

Terminal reference

This document can be printed onto transparency for exposing your pre-sensitized copper clad. To use this for toner transfer, be sure to mirror the image first.

And a compiled version of the code in ihex. This is for the teensy++ 2.0. The code might work with other versions of the teensy, but a re-compile will be required.

Gamepad Circuit Board

Export from EagleCAD with terminal labels

It’s based on another design by Raphaël Assénat.

You’ll find the source code and Eagle files here, both licensed under the GPL.

PS: It’ll also work just fine on a Window/Linux/Mac OS X computer as well since all operating systems come with drivers for USB HID gamepads.