Jon Thysell

Xbox engineer. Fiction writer. Returned Peace Corps Volunteer. Ukulele nut. Nerd.

Chordious 1.0.0 now available at!

Chordious Image

It’s here! Over a year since my first code check-in, and I’m finally ready to release Chordious 1.0.0 into the world. Need chord charts for your favorite stringed instruments? Want to make your own? Chordious helps you find chords and make customized chord diagrams for free.

It’s my first major cross-platform application, and is available now for Windows, Mac OS X, and Linux, with fancy-pants installers to boot.

Find out more at the new official Chordious website.



The Port Townsend Ukulele Festival 2014

Class photo after the first session of the Baritone Ukulele Support Group

The first session of the Baritone Ukulele Support Group

Last year I attended the first annual Port Townsend Ukulele Festival, and had so much fun that I jumped at the opportunity to preregister for this year. Yesterday marked the end of this year’s festival, and I thought I’d take a moment to review some of the wonderful things I’ve learned in the past few days.

The festival consisted of four sessions of ukulele workshops a day for three days, along with ad-hoc non-ukulele classes, daily open-mics, jam sessions, and two live concerts featuring the instructors. The classes were held in the various buildings at Fort Worden, and included one-day drop-in sessions for shorter topics, along with three-day classes let you really dig into particular subjects.

Besides all of the wonderful opportunities to just sit down and jam with other ukulele players (there were some 160 participants this year), I also came away with a bunch of new techniques to practice, songs to learn, and a greater appreciation for all of the music that these little instruments can make.

Of particular note this year was the acceptance and accommodation of baritone ukuleles. In fact, one of the biggest highlights for me was the positive reception to my playing of Hawaiian slack-key on my baritone uke by both the staff and other participants. (I really need to make some videos, at the very least so I can get on Humble Baritonics again.)

The other highlight was showing off Chordious, which also elicited a positive response from some of the instructors, especially those with upcoming books.

It would be impossible to list everything that happened this weekend, but here are some of my notes (grouped by class and not in any particular order):

Baritone Ukulele Support Group (Aaron Keim)

  • Embrace the wound string. Enjoy the color it adds to the music. Only you will hear the squeaks.
  • There are only so many string factories, so pick the material and gauges you like and feel free to make your own sets. For baritones (tuned dgbe’), Mya-Moe uses D’Addario silver-wound classical guitar strings (0.033w and 0.028w) for the basses, and Worth clear fluorocarbons (0.0319 and 0.0260) for the trebles. (Mya-Moe sells their strings here if you’re not interested in making your own).
  • Keeping your thumb behind wherever your 2nd (middle) finger is will make chording easier.
  • Barre with the bony side of your finger, not the fleshy part, for a cleaner sound.
  • Hang your hand at your side, then raise your elbow – that loose grip, straight wrist, is how your hand should be shaped when fretting.
  • If you play smaller ukes too, use your knowledge of those chord shapes by jumping down and barring at the fifth fret on your bari to play them.
  • When you’re the only bari player in a  group, look at chord names, not grids, and not other people’s hands.
  • Play around with chord fingerings to try to get the root note on your bass string, ie. the 2130 E7 with the root note on the bass sounds better than the 0100 E7 with the 7th note on the bass.
  • Don’t worry about transposing or being in the same key as the paper when you’re playing by yourself.
  • Swapping out that low-d for a high-d will give you a nice, more “ukulele” sound, and isn’t a new idea – jazz ukulele master Lyle Ritz has been playing that tuning on the tenor uke for decades.
  • There is no “official strumming pattern” for songs. Some strums just sound better than others, depending on the feel you want the song to have.
  • It’s not hard to make up your own strumming patterns – just think of it as reductive rather than additive – start with your basic down-up, down-up, down-up, down-up and then remove strokes, replace one with maybe a thumb on the bass, change which fingers you use, etc.
  • In a 4/4 strum, put emphasis on the back-beats (2 and 4). Say chat-ta-noo-ga chat-ta-noo-ga as you strum.
  • If you want to capo, do it. Arron uses Kyser banjo/mandolin capos on his bari.
  • For that dreaded key of F, capo at the first fret and play the shapes for the key of E.
  • For picking like Maybelle Carter, almost everything is lead and played with the thumb.
  • Start by learning the melody, then the chords, then play just melody, using chord strums to fill gaps in the melody

Baritone Chord Magic 3 (Ginger Johnson)

  • When you see scary jazz chords (9ths, 13ths, etc) you can substitute a 7th. Note it doesn’t always work the other way, using a 9th for a 7th might sound good, but might clash with a non-jazzy song.
  • Baritone ukulele can sound deep, sexy, and sultry – don’t get caught up trying to play it like a smaller uke, use its strengths.

Fretboard Roadmaps (Fred Sokolow)

  • Learn your minor pentatonic scale to solo over bluesy songs by just playing in the key of the song (no need to worry about chord changes, just key changes).
  • If the song isn’t bluesy, slide down (toward the head) 3 frets and play the minor pentatonic there.
  • Learning your chord shapes mean playing those I, IV, V chords anywhere on the neck, wherever it’s convenient for the chord changes or melody notes.
  • Learn that circle of fifths. There’s no substitute for just sitting down and committing it to memory.
  • Learn the common progressions in multiple keys so that they become second nature.
  • Learn where major scales are relative to the chord shapes so you can stay in the shape and solo easily

My Three Strums (Casey MacGill)

  • Swing strum is alternating between using your thumb and finger at the same volume, which gives a off-beat natural accent when the nail hits the strings.
  • Keep your hand near the uke, you don’t want to waste energy.
  • You’re pulling your wrist out perpendicular away from the strings and “pinching” it with your thumb like you’re picking apart a cotton-ball.
  • Then flick down with your finger and mute with your palm for the 2nd beat, leading with your wrist.
  • Shuffle strum is using the fleshy part of your finger, again keeping your hand near (or even on the uke) the whole time, and muting between strokes.
  • Rumba strum is down, roll, down-up, down-down-up. Ups are hit with your thumb nail, and there’s no muting.

Hawaiian and Hapa-Haole Songs (Francis Doo)

  • Hawaiian music doesn’t have to be fast, fancy and complicated – simple chord progressions with simple strums give you room to express yourself in the song.
  • The Hawaiian vamp is II7, V7, I, I, then repeated.

Unobtrusive Percussion (JoJo Mascorella)

  • If he could only have one thing, it would be wire brushes. Wire brushes on a sheet of paper on a chair and you have enough sounds to have a good time.
  • Play thinking as if you’re whipping down from your shoulder, to get the right attack, but don’t actually do it as you’ll get tired too fast.
  • Lots of warmups go a long way.
  • Practice slower and speed will come naturally
  • Practice with a metronome to test (and humble) yourself

The biggest refrain was about practice. It’s a dirty word to some, but it really is the only way you get better. Period.

I could fill up post after post with highlights from the festival, but writing about it just isn’t the same as having been there. This year there were some 160 participants with another 180 or so on the waiting-list, so rumor is that next year they’re going to try and meet the demand with two separate festivals back-to-back.

I can’t wait to register.

Happy strumming,


Revisiting how to practice the ukulele

A little over a year ago I outlined an index card based system for organizing my ukulele practice sessions. I designed it to help me retain old material while always learning more, to keep my practices structured but still interesting. I used it to create and execute regular practice sessions for several months with great success. In fact I even had the great opportunity to share my system at the first Port Townsend Ukulele Festival during Cathy Fink‘s session on practice tips.

Now, the system wasn’t without its flaws – the biggest complaint was its complexity. While I still believe in the system’s core goals, I’ll admit that the particular implementation I came up with isn’t for everyone.

With that in mind, and in light of this year’s ukulele festival, I thought I’d take another whack at the problem, and distill last year’s system into something a little more user-friendly.


My goal has never been to become a professional musician. I just want to be able to make some nice music for my family and friends without any notes, aids, and with a little more than a basic up-down-up-down C, F, G7.

With that in mind, the system needs to:

  1. Track all of the new material I want to learn.
  2. Track my progress with the material I’ve already started learning.
  3. Make it easy to create fun practice plans that balance learning new material with retaining old material.

The New System

The new system can be quickly summarized as:

  1. Keep a stack of cards, each with:
    1. Something to practice written on the face.
    2. How many times you’ve practiced it tallied on the back.
  2. When you want to practice, turn the cards face down and draw a random set. Remember:
    1. The more cards the longer the practice session.
    2. Try to have a mix of cards, ie. some with no tallies, some with a few tallies, and some with lots of tallies.
  3. After you’ve practiced each card, add a new tally to the back and return it to the stack.

Simple enough? Too simple? Let’s walk through the details:

The Practice Stack

The new system starts, like the previous one, with a stack of index cards. This is your Practice Stack. Size, color, lines or plain, it’s up to you. Just get a good sized stack.

Now, each card in your Practice Stack is going to represent some particular thing you want to practice. It can be a technique, an exercise, or even a whole song.

So on one side of the card, write or print exactly what you want to practice and for how long. If it’s a technique or exercise, give it at least five solid minutes. For a song, at least long enough to get through the whole thing two or three times.

You can be as vague or specific as you want, whatever works for you. For example, let’s say you want to practice picking your C Major Scale. You can write a simple “C Major Scale / 5 min” or a more elaborate “Finger-pick first-position C Major Scale with a metronome for five minutes”.

Personally I prefer being a little vague, one because it’s easier to write, but also so I have room to experiment while still using the same card. In the beginning, I might practice that C Major scale as slowly and accurately as possible, staring at the fretboard the whole time, but after a lot of practice I might decide to use a metronome to rock out that scale with my eyes closed. Being vague on the card lets me use one instead of two.

Your Stack is Personal to You

Now to start out your Practice Stack, I recommend creating at least a good thirty index cards. Remember, this is your list, so pick things that you want to practice. Your stack won’t be the same as anyone else’s, and that’s okay!

If you’re having trouble coming up with thirty, try the following for inspiration:

The only recommendation I have is to keep a mix of songs and techniques. It’s tempting to list out just the song’s you’d like to learn, but you’ll get much better if you throw in some technique practice.

Tallies Mark Your Progress

Where the front of the card keeps track of what you want to practice, the back keeps track of how many times you’ve actually practiced it. Every time you practice what’s on the front, you’re going to add a tally to the back. How you tally is up to you – you can use pen marks, stickers, colored squares, whatever works for you.

The goal is here is to give you both a physical representation of how much practice you’ve put in and also an easy and quantitative way to compare cards with one another. You’ll use this information to help you decide what to practice.


When you sit down to practice, you’re going to draw some set amount of cards from your Stack. Remember:

  1. The number of cards you draw will dictate how long you practice.
  2. By placing them face down and choosing randomly, you’ll make sure that no practice is the same.
  3. By watching the tallies on the back, you can make sure you can get that balance of new and old material.

Now, what will happen is, over time you’ll build up this nice set of index cards with all of the things you’ve learned, and you’ll be able to quickly see the things you’ve focused on and the things you haven’t. It’s quite the feeling to have a physical artifact in your hand of all of the effort you’ve put into playing the ukulele.


That’s it! I hope this helps folks out there, especially those that were intimidated by all of the charts in the first iteration of this system. Does this work for you? Have improvements or other ideas? Let me know in the comments!

Happy strumming,


My Vows to Anne

By the time this post is published, I’ll have made the happiest decision in my life, saying “I do” and marrying my girlfriend Anne. We had a small, intimate wedding, and wrote our own vows (well, really the whole ceremony, but what do you expect from two people who met because of National Novel Writing Month?) Anyway, this is what I wrote:

Anne, what we have is built on trust, love, and understanding. Trust that our love will overcome any passing strife in our lives, trust that we can hold hands even as we butt heads.

We understand one another, and though others may look at us and tilt their heads or raise an eyebrow, we know we’re better together than apart.

Side by side, back to back, or even facing off – I trust that we’ll always come out the other side together, ready to face whatever lies ahead. With love, respect, and a little bit of elbow grease, we can handle everything life throws at us, from the little to the large.

Sickness and stubbed toes – we’ll make it through.

Boobercuts and random sleep interrogations – we’ll make it through.

Dragons, zombies, and alien invaders – we’ll make it through.

Yes, mortgage payments, homeowners’ associations, and even tricksy little children – I know we’ll make it through those too.

I promise to love you and to stand by your side, to always have your back and to catch you when you fall. These are my vows to you.

I told you once you’re the girl who’s got it going on, who knows the difference between Romulan and Klingon. I’m so lucky to wake up each day next to the hot geeky girl of my dreams.

Anne, I love you more than any words I could ever say. It’s an honor, privilege, and joy to stand here with you today, and I can’t wait to spend the rest of our lives together.

And if that’s not enough, here’s a shiny ring.

Even with such a “small” wedding, it’s been a whirlwind to get this through the gate. I just thought I’d take a moment here to loudly and proudly shout that I am the luckiest man on Earth. I love you Anne!


Reading Sega Genesis controllers with Arduino



The Sega Genesis was my first and favorite childhood game console, so when I first picked up an Arduino a couple years ago, my first thought was to build something, anything, that used a Genesis controller. Unfortunately I got side-tracked by other projects, and the Arduino Uno I’d purchased got set aside.

Fast-forward to this year’s picade build, when I had to re-flash the main controller board, which at its heart is an Arduino Leonardo. Seeing how easy it was to work with, I finally decided to break out my Uno. After a couple sample sketches, I figured it was time start interfacing with some Genesis controllers.


I started poking around online to see what others had done, and couldn’t find quite what I was looking for. What I did find was plenty of information on how the three-button pads worked. Some used that info to implement full three-button support – others, it seems, were satisfied with having just some of the buttons working (essentially using the controller’s innate backward compatibility with the simpler Sega Master System’s two-button controller design). No one had six-button controllers working.

What I want is full three and six-button support, something that I can plug any Genesis controller into and it’ll “just work”, like an actual Genesis console. My requirements therefore are:

  1. Correctly reads connected three-button controllers.
  2. Correctly reads connected six-button controllers.
  3. Automatically detects which type of controller is connected, with hot-swapping.
  4. Bonus: Support more than one controller at a time.

The real godsend to the first two was finding Charles Rosenberg’s Sega Six Button Controller Hardware Info. There he describes almost everything you need to know about how Genesis controllers work. I highly recommend giving it a full read for the really gory details before continuing, but here’s a “quick” overview:

How Sega Genesis controllers work

All Genesis controllers use a standard nine-pin DB9 serial port. On your regular three-button controller, you really have a total of eight buttons: Up, Down, Left, Right, A, B, C, and Start. With nine pins to work with, Sega could easily have gone with one +5v in and eight outputs back to the console and be done with it. But instead, in the interest of backwards compatibility with the Sega Master System (and potentially other DB9 based controllers like the old Atari joysticks), they implemented a simple multiplexer circuit.

Essentially you have three control pins (+5v power, ground, select) and six output pins. By default, all of the output pins are set high (meaning a button press will bring the pin down to ground). The Genesis (or more specifically, the game running on the Genesis) sets the select pin (DB9 pin seven) low, then reads the state of the six output pins to get the states for the Up, Down, A, and Start buttons. Then the game toggles the select pin to high, and re-reads those same six output pins to get the states of the Up (again), Down (again), Left, Right, B, and C buttons.

DB9 Pin Select is low Select is high
1 Up Up
2 Down Down
3 Ground Left
4 Ground Right
5 Control: +5V
6 A B
7 Control: Select
8 Control: Ground
9 Start C

The algorithm is pretty straight forward to implement on the Arduino, polling the controller exactly the way a Genesis game would. This satisfies my first requirement. Now, things get a little more complicated with the six-button controller:

DB9 Pin Select is low Select is high Every 3rd select pulse
1 Up Up Z
2 Down Down Y
3 Ground Left X
4 Ground Right
5 Control: +5V
6 A B
7 Control: Select
8 Control: Ground
9 Start C

First, let’s call each dropping of the select pin to low then back to high a “select pulse”. Now, on every third select pulse the six-button controller will instead report back the states of the X, Y, and Z buttons (instead of Up, Down, and Left). On its face, it looks like we couldn’t have a game that supports both three and six-button controllers, because how does a game know what kind of controller is connected? On every third pulse how does a six-button enabled game know whether to use the first table or the second? On every third pulse, how does a six-button controller know not to report X, Y, Z for games that only support three-buttons? If the game and controller aren’t on the same page and they use the wrong mappings, they’ll record incorrect button presses.

How do the games and controllers make the right decisions?

One part of the answer (as described in Rosenberg’s notes) is in how often games actually poll the controller. The three-button controller uses dumb direct logic, which means it always uses the first table. It also means that technically you can poll the controller state super-fast (say every 50 microseconds) or super-slow (say every 20 milliseconds) and always get the same result. Now typically, a game is only going to poll the controller once per game frame (sixty times per second, or every 16.6 milliseconds). Which means, at the time of the six-button controller’s release, the vast majority of the games already published (which were three-button enabled only) only sent a single select pulse every ~16 milliseconds.

The six-button controller can use this to its advantage. Instead of dumb direct logic, it uses an IC to watch how often the select pulses come in. The IC knows that (given the game indicates it wants six-button mode), it should return the states of X, Y, and Z on every third select pulse. But it also knows that most games only support three-button mode, so a safe default is to just pretend to be a three-button controller and ignore reporting X, Y, and Z on every third pulse.

How does the controller decide? The frequency of the select pulses. If the IC only sees one select pulse every ~16 milliseconds, or one pulse per game frame, then its best bet is to take the safe route and assume three-button mode. In this way, the six-button controller is backwards-compatible, and most games will never get any incorrect button presses.

If that’s the case, how does a game indicate that it actually wants those X, Y, and Z buttons?

If the game believes that a six-button controller is attached, it will instead pulse the select line three times very quickly in one game frame. The first two times the game reads (and the controller reports) the button presses for three-button mode. Then the game pulses the controller a third time. At that point, the controller’s IC, seeing how quickly those pulses came in, presumes the game wants X, Y, and Z, so it reports X, Y, and Z.

So to sum up: if a game just wants the three-button control states, it pulses once every frame and uses the first table to read the results. If a game wants six-button control states, it pulses three times in one frame, using the second table to read the results. With this in mind, we can now read both controller types, which satisfies the first two of my requirements. We can easily implement an Arduino sketch that implements one or the other algorithm, if we already know which type of controller we’re going to have connected.

But what about my third requirement? What if we want one sketch that implements both modes? How do we make our board detect what kind of controller is connected?

This one took a little bit of experimenting to figure out, since Rosenberg’s notes don’t address the issue. Turns out the six-button controller’s IC has another trick up its sleeve with watching how fast those select pulses come in. As we just saw, since most games only expect three-button controls, the controller can default to three-button mode, and seeing slow pulses, will stay in three-button mode.

But now, if the game wants to check for a six-button controller, it can send rapid select pulses when a controller is connected, and if it’s a six-button controller, the IC will report that both the Up and Down buttons are being pressed at the same time!

Under normal circumstances this is impossible, as the controller’s d-pad rocks in the direction you press it. So with this neat trick, the controller lets the game know that a six-button controller is connected, giving the game to option to start polling the controller in six-button mode.

The way we implement this is simple: by default we poll in three-button mode very quickly. For three-button controllers, this works perfectly. After every pulse, we can check for both Up and Down being pressed at the same time. If we see that, we know a six-button controller is attached, so we switch to six-button mode, pulsing more slowly so that we don’t reset the IC.

This solves the first part of my third requirement: detecting when a six-button controller is connected. But what about the other way? The way it stands, once we connect a six-button controller, and our board switches to six-button polling, it’s stuck that way until we reset the board. If we hot-swap from a six-button to a three-button controller, we’ll get those annoying paired inputs (specifically, pressing Up will return Up and Z, Down will return Down and Y, Left will return Left and X).

What we need is a way of knowing when a controller is disconnected, so that we can switch back to the default three-button polling. Turns out we have everything we need in the tables above, something that works for both three and six-button controllers.

At the very beginning I said that by default the console puts all six of the DB9 output pins high, so that a button press causes the pin to drop low. So if no controllers are connected those output pins should stay high. Only a button press from a connected controller will drop a pin low, right? We could just press a button to let the board know we have a controller connected, but wait, there’s a better way!

As we can see in the tables above, when the select pin is low, DB9 pins three and four both go low, regardless of any button presses. So in effect, the controller presses imaginary buttons on pins three and four when select is low automatically. So, all we have to do is watch those pins – if they go low when select is low, then we know a controller is connected. If they’re high when select is low, it means the controller is no longer connected.

In implementation terms, when select is low, we can simply check those two pins like we would for any other button, and map the results of those imaginary “On” buttons. Watching those “buttons” we know when a controller is connected or not, and therefore we can easily switch back to three-button mode when a controller is disconnected. With that we now have everything we need to satisfy my main three requirements for the board. As for the 4th and final bonus requirement, recognizing that we only needed seven pins to read one controller, we’ve got plenty of left-over pins on the Uno to cover connecting one more.

The Sketch

Ok, so now for the sketch. Our basic algorithm is the following:

  • Default to three-button polling as fast as possible, using the first table and select pulsing algorithm.
  • If you ever see both Up and Down pressed at the same time, switch to six-button polling, using the second table and select pulsing algorithm.
  • If you ever see the “On” button state go away, switch back to three-button controller polling.
 * Sega Controller Reader
 * Author: Jon Thysell <>
 * Version: 1.0
 * Date: 7/26/2014
 * Reads buttons presses from Sega Genesis 3/6 button controllers
 * and reports their state via the Serial connection. Handles hot
 * swapping of controllers and auto-switches between 3 and 6 button
 * polling patterns.

// Controller Button Flags
const int ON = 1;
const int UP = 2;
const int DOWN = 4;
const int LEFT = 8;
const int RIGHT = 16;
const int START = 32;
const int A = 64;
const int B = 128;
const int C = 256;
const int X = 512;
const int Y = 1024;
const int Z = 2048;

// Controller DB9 Pin 7 Mappings
const int SELECT[] = { 8, 9 };

typedef struct
  int player;
  int pin;
  int lowFlag;
  int highFlag;
  int pulse3Flag;
} input;

// Controller DB9 Pin to Button Flag Mappings
// First column is the controller index, second column
// is the Arduino pin that the controller's DB9 pin is
// attached to
input inputMap[] = {
  { 0,  2,  UP,    UP,     Z}, // P0 DB9 Pin 1
  { 0,  3,  DOWN,  DOWN,   Y}, // P0 DB9 Pin 2
  { 0,  4,  ON,    LEFT,   X}, // P0 DB9 Pin 3
  { 0,  5,  ON,    RIGHT,  0}, // P0 DB9 Pin 4
  { 0,  6,  A,     B,      0}, // P0 DB9 Pin 6
  { 0,  7,  START, C,      0}, // P0 DB9 Pin 9
  { 1,  A0, UP,    UP,     Z}, // P1 DB9 Pin 1
  { 1,  A1, DOWN,  DOWN,   Y}, // P1 DB9 Pin 2
  { 1,  A2, ON,    LEFT,   X}, // P1 DB9 Pin 3
  { 1,  A3, ON,    RIGHT,  0}, // P1 DB9 Pin 4
  { 1,  A4, A,     B,      0}, // P1 DB9 Pin 6
  { 1,  A5, START, C,      0}  // P1 DB9 Pin 9

// Controller State
int currentState[] = { 0, 0 };
int lastState[] = { -1, -1 };

// Default to three-button mode until six-button connects
boolean sixButtonMode[] = { false, false };

void setup()
  // Setup input pins
  for (int i = 0; i < sizeof(inputMap) / sizeof(input); i++)
    pinMode(inputMap[i].pin, INPUT);
    digitalWrite(inputMap[i].pin, HIGH);
  // Setup select pins
  for (int i = 0; i < 2; i++)
    pinMode(SELECT[i], OUTPUT);
    digitalWrite(SELECT[i], HIGH);

void loop()

void readButtons()
  for (int i = 0; i < 2; i++)
    if (sixButtonMode[i])

void resetState(int player)
  currentState[player] = 0;

void read3buttons(int player)
  // Set SELECT LOW and read lowFlag
  digitalWrite(SELECT[player], LOW);
  for (int i = 0; i < sizeof(inputMap) / sizeof(input); i++)
    if (inputMap[i].player == player && digitalRead(inputMap[i].pin) == LOW)
      currentState[player] |= inputMap[i].lowFlag;

  // Set SELECT HIGH and read highFlag
  digitalWrite(SELECT[player], HIGH);
  for (int i = 0; i < sizeof(inputMap) / sizeof(input); i++)
    if (inputMap[i].player == player && digitalRead(inputMap[i].pin) == LOW)
      currentState[player] |= inputMap[i].highFlag;
  // When a six-button first connects, it'll spam UP and DOWN,
  // which signals the game to switch to 6-button polling
  if (currentState[player] == (ON | UP | DOWN))
    sixButtonMode[player] = true;
  // When a controller disconnects, revert to three-button polling
  else if ((currentState[player] & ON) == 0)
    sixButtonMode[player] = false;

void read6buttons(int player)
  // Poll for three-button states twice
  // After two three-button polls, pulse the SELECT line
  // so the six-button reports the higher button states
  digitalWrite(SELECT[player], LOW);
  digitalWrite(SELECT[player], HIGH);
  for(int i = 0; i < sizeof(inputMap) / sizeof(input); i++)
    if (inputMap[i].player == player && digitalRead(inputMap[i].pin) == LOW)
      currentState[player] |= inputMap[i].pulse3Flag;

void sendStates()
  // Only report controller states if at least one has changed
  boolean hasChanged = false;
  for (int i = 0; i < 2; i++)
    if (currentState[i] != lastState[i])
      hasChanged = true;
  if (hasChanged)
    for (int i = 0; i < 2; i++)
      Serial.print((currentState[i] & ON) == ON ? "+" : "-");
      Serial.print((currentState[i] & UP) == UP ? "U" : "0");
      Serial.print((currentState[i] & DOWN) == DOWN ? "D" : "0");
      Serial.print((currentState[i] & LEFT) == LEFT ? "L" : "0");
      Serial.print((currentState[i] & RIGHT) == RIGHT ? "R" : "0");
      Serial.print((currentState[i] & START) == START ? "S" : "0");
      Serial.print((currentState[i] & A) == A ? "A" : "0");
      Serial.print((currentState[i] & B) == B ? "B" : "0");
      Serial.print((currentState[i] & C) == C ? "C" : "0");
      Serial.print((currentState[i] & X) == X ? "X" : "0");
      Serial.print((currentState[i] & Y) == Y ? "Y" : "0");
      Serial.print((currentState[i] & Z) == Z ? "Z" : "0");
      Serial.print((i == 0) ? "," : "\n");
      lastState[i] = currentState[i];

All you have to do is upload the sketch and connect the controller’s DB9 pins to the Arduino following the mapping in inputMap in the code. Then start up the Serial Monitor so you can see the output from the controller on your PC.

Here’s a closeup of how I’ve wired my Uno to a male DB9 breakout board (you can wire straight to the controller, or a male DB9 port, but I found the board the easiest solution):


The sketch is also set up for a second controller connected to the analog pins on the other side of the Arduino, though I only had one male DB9 breakout board. Also note that this is my first real Arduino sketch, so I’m sure there are some best practices I’m breaking in my design.

I can already see room for future improvements. Right now I report the controller states over the serial connection as strings – easy to debug, but slow and wasteful. Of course, in your own sketches, you can just read the currentState integers directly.

Hope this helps anyone else out there trying to interface with Genesis controllers. Happy hacking!


PS. Obviously in the process of plugging and unplugging controllers, you may see some errant random button presses recorded. In the world of video games, this is to be expected, and only lasts for a second. If however, you’re planning on doing anything “bad” with a button press (say enabling a thermonuclear detonator), you might want to avoid hot-swapping controllers.

PPS. Final note, concerning the six-button controller’s “mode” button. Some games (notably Ms. Pac Man), don’t follow the rule of only polling the controller once per game frame, and select pulses more often. This causes erratic behavior as incorrect buttons presses are recorded. Ostensibly, when you plug in a six-button controller with the mode button held down, that signals the IC in the controller to always be in three-button mode and never report X, Y, or Z. Unfortunately, I couldn’t get it to work with my sketch and gave up because I saw no reason to limit my six-button controller to three-buttons anyway.


Get every new post delivered to your Inbox.

Join 492 other followers