NES Controller / GameBoy Button Translation

Probably if you do something like that, they will see the smoke signals. :thinking:

…not sure there is anything here they would object to? Playing a physical copy of “that which must not be named” on a physical GameBoy, and taking a photo of it - where’s the problem? :face_with_raised_eyebrow:

If the issue is hypothetically around using a ROM on a GameBoy flash cart, then a couple of dollars on eBay will buy you the right to play Tetris in your own home:

EDIT: Also -

1 Like

I’m a simple man. I see trip world and I press like.


Oh right, I didn’t realise it was a physical copy.

Disregard my earlier comment.


Super Project !

can someone help me to change the adruino code to read the DMG button presses ?

thank you

Sure - what are you trying to do though? Read the buttons while the GameBoy is running? or use the front board independently of the main board?

Reading the GameBoy buttons is just a matter of taking an input from P10, P11, P12, P13 in the diagram above. Which four buttons are being represented on these pins depends on the state of P14 & P15.

1 Like

Thx for the info, i would like to read the start & select button when de Gameboy is running.

with as less wires as possible running to the arduino (the arduino is running off de DMG GND & 5V)

To read start and select you would need three gpio wires (P12, P13 and P15). Your software would wait till the gameboy polls P15 and then you would read the states of P12 and P13 to know if either start or select was pressed.

…and here is how those pins in the above diagram correspond to the pins on the GameBoy’s ribbon cable connector:

P11 = 4
P14 = 5
P13 = 6
P12 = 7
P10 = 8
P15 = 9

…and a couple of images from @nobble that may help you identify those pin numbers on the ribbon connector:

1 Like

What would change in the code when running this on an Arduino Uno? PORTF is not available (I don’t even see that in the arduino documentation actually, the site says the chips used in arduino only use ports B,C, and D.)

From what I gather that would depend on what you have wired up to what.

If it actually says that then the information is probably wrong.
The Arduino Leonardo board (which uses the same chip as the Arduboy - an ATmega32u4) has PORTF defined.

The Arduino Uno board (which uses an ATmega328P) does not have PORTF defined.

When porting code that references gpio from one target to another that doesn’t have the same pins just swap the instantiations and references to whatever pins you want to use on the new chip. So long as the original software isn’t using specific peripherals that the new chip doesn’t have it’ll be fine (and obviously you may have to rewrite some of the initialization code/transfer anything device specific register-wise).

Thanks for the response. As far as I understand it, Port manipulation allows for faster switching. So would it be feasible just to use a different port on the Uno that is defined, and then change the instantiations from this script to correspond to the pins used in the port I decide to use on the Uno?

I don’t have any experience with port manipulation so that’s what’s throwing me for a loop.

Of course you can use a different port or even a different pin number within any given port. As with all things the datasheet will have all the details you’ll ever need. For direct port manipulation you’ll need to do what is colloquially known as bit-twiddling ("and"ing with a zero to clear a bit (the rest of the port pins are anded with 1 to prevent changing them), "or"ing with a one to set a bit (the rest of the port pins are ored with 0 to prevent changing them)). There are tons of examples of this online. Alternatively you can create bit-masks/defines to make the code more human-readable.

The issue is that I chose PORTF because the code isn’t actually doing comparisons and separate bitwise operations to set some pins up and others down - it just sets the whole port to the current button values, which is fine for the 32u4…

A0 - A3 on the Uno are on PORTC though, and unfortunately so is the RESET pin :confounded:

Thought I found a solution using PORTB, but the crystal pins are on PORTB :grimacing:

Don’t have time to write this for you right now… sorry :frowning_face:

1 Like

Did you had to do anything special to get D-pad working too?

I’m trying to get the code you showed here working on Arduino Nano Every. I’ve got it set up to handle interrupts from DMG and use port manipulation to set the outputs. Everything works perfectly when I test it with some LEDs and buttons, but when I attach it to DMG - only start/select/A/B buttons work, and D-pad does nothing, except for rarely sending one of the other buttons.

I suspect that the issue is with timing, but I don’t have an oscilloscope to check, and Nano Every runs at 16MHz, same as Pro Micro, so it should’ve been just fine.

Do I need some extra electrical components to make it work?

My current code: Makefile · GitHub

And the wiring:

Black connector is where I plug in 5V, GND, and all button pins from the Gameboy. For testing without a Gameboy attached I just connect the LEDs to 5V, so they light up when a corresponding pin is pulled low.

…can you share the code you are using? :upside_down_face:

Sure, sorry :slight_smile: Updated my post above

1 Like

At the time, I was working on the assumption that only P14 or P15 would be low independently of each other - ‘either/or’… but it looks like P14 goes low first, and then P15 goes low as well.

Confirmed this by looking at the example button code (under ‘I/O Ports’) here:

So… maybe instead of using the falling edge(s) - you could try testing for these two conditions to decide which subset of buttons are being sent to the GameBoy at any one time:

  1. (P14 == 0 && P15 == 1)
  2. (P15 == 0)