ArduBigBOY (WAS: My Homemade: Pro Micro, SSD1309, with Flash Cart)

@Mr.Blinky - by the way… Since you already have some carts made up, I wanted to try and use the same pinout for the expansion header. But I ultimately ran into some limitations, so this will come with a new expansion header layout.

First, I think you are re-using Rx for your external cart select? I would prefer to reserve Tx/Rx for linking two Arduboys. With my proposed expansion header, I broke out some additional un-used pins (PF0/PF1 = A4/A5) that can be used for the cart select instead.

Also, I am planning on running the internal flash select on a separate un-used pin (PE2). This means (in theory) we could have a cart management app to clone flash carts, or copy between internal and external.

Also, I am running everything at 3.3v, which reduces the need for voltage level converters. Yes I know this is technically out of range for the ATmega32U4 at 16 MHz, but the official Arduboy does it like this, and it doesn’t seem to cause problems in practice, so…

I also wanted to make it possible to plug in both a serial link cable as well as an external cart at the same time. This would make it possible to copy from a second Arduboy over the serial connection.

So, my proposed layout is:

  • 1x3 header with Tx, Gnd, Rx (on the bottom of the board)
    • This makes it possible to simply reverse the cable on one end to establish proper Tx->Rx and Rx<-Tx cross-over.
    • Both Tx and Rx would have a series resistor to limit the current if it was plugged in backwards and both sides were trying to actively drive the lines inversely.
  • 2x5 header with MISO, SCK, RESET, PF0/A4, PF1/A5 on the top, and 3V3, MOSI, GND, PD1/SDA, PD0/SCL on the bottom.
    • The first 2x3 section of the 2x5 has the same layout as a 6 pin ISP header making it easy to hook up to an external programmer.
    • An external flash cart would use the same 2x3 header plus one other pin for chip select (potentially PF0/A4).
    • A Bluetooth serial card would only need to use the 1x3 and some portion of the bottom part of the 2x5 port (i.e. for power and possibly gpio).
    • There would probably be a ‘key’ for the 2x5 section, potentially integrated into the case itself.


Yes it was the last pin available on Pro Micro using alternate pin assigment and chose it for that reason.

I understand you want to keep Tx/Rx for serial stuff but why not use SDA SCL (I2C) for Arduboy connectivity instead? Then multiple Arduboys can be connected.

Note that the bootloader only can support one CART_CS. So you could only load games from one if you use multiple CART_CS.

Another method you could use is disable the internal flash when external flash is connected. You can do this by connecting a 1K~4.7K resistor in series to the flash chips chip select.

  • So the CART_CS out connects to one end of the resistor and to a expansion connector pin.
  • the other end of the resistor connects to internal flash chip CS and to a expansion connector pin

By connecting flash chip CS external pin to Vcc the internal flash chip gets disabled. The CART_CS will function normally for the external cart (or can be used for Rx)

Keep in mind that using series resistors will limit cable length and speed.

Note that a 6 pin IDC connector can not connect to a 2x5 pin header.

For the serial part you could use the same pinout as those USB to serial boards or have the required wires near each other so an USB to serial cable can be connected.

@Mr.Blinky- Thanks for all your comments.

Yep makes sense. Since this is using the raw IC, though, it has more pins available, and I think it is wise to use them…

… as long as it doesn’t break functionality with the official version. Which is why I kept all the pins and accessories the same as the official, even though there are probably better choices to be made, especially if the goal is to provide better expansion options. (i.e. 5 pins ‘wasted’ on LEDs… why not just use one or more WS2812 RGB LEDs?, does the display really need a separate reset?.. why not just tie it to vcc or ATmega reset?, one could also use a serial shifter IC for the buttons like the NES/SNES controllers, etc…)

Yeah, I thought of that. I think Gamebuino Classic does it that way. But, my thoughts were that Tx/Rx is easier to implement for 1-to-1 communication (and supports easy linkage via Bluetooth serial modules). I think it is less code too, although I’ll admin I have never tried to use I2C for Arduino to Arduino communication. Doesn’t I2C require a ‘master’ device? Not sure how best to negotiate that. The expansion header has all the above pins available, so if I2C works out better, that’s fine.

If true multi-player actually ends up being a thing for this platform, we could also make a serial hub that took care routing Rx/Tx lines between different endpoints. Or, maybe add a nRF24L01+ module to the expansion port and communicate wirelessly. That said, I’m not sure how often multi-player would get used over 2-player. Anyone with an official Arduboy will be left in single player mode anyways (or have to do some hardware modifications themselves).

Yes. Although, possibly the bootloader could be modified to support switching between two different carts at run time. I also thought of adding a hardware switch that controlled the bootloader flash cart, but ultimately decided to keep it simple and only support bootloading off of the internal flash (for now).

I don’t think I want the internal automatically disabled just because and external flash is plugged in. I think being able to ‘share’ carts would be useful, and having a utility to copy from external to internal (or vice versa) would be handy. To do this properly both carts need to be accessible from software.

Good point. Any idea on how to calculate such things (or is there a general guideline available)?

Calculating a resistor value based on max current draw of 10 mA (at 3.3V) means 330 ohm total series resistance (165 ohm resistor on either side of the cable). This is substantially less than the 1K series resistors that are common on many Arduino boards, so it should allow for better cable lengths and speeds than those boards, but I’m not sure how to further define it at the moment.

I suppose one would have to take into account cable capacitance and take a look at rise/fall times of the signals to determine the safe frequency.

I will keep a resistor footprint on the board, but it can always be populated with a 0 ohm or wire link if needed.

Yes. I am aware that there is a key above pin 3 (top middle) on the 2x3 IDC connector. I was thinking this could be incorporated into the case design (i.e. an offset key). I was not planning on using a 2x5 housed pin header, just raw 2x5 male pins and leave the key to the casing. We don’t actually want someone plugging a 2x5 IDC connector in anyway because the 2x5 ISP has the wrong pin layout.

How useful would that be? We already have direct USB capability on these boards. You could very easily have an external adapter (or use dupont) cables if you actually need external USB-to-serial capability. I think I would prefer to keep the serial pins optimized for linking two devices together as easily as possible.

It’s could be fine to define a ‘pseudo’ standard to communicate between our consoles (Arduboy, gamebuino, maybe Pokitto (i don’t know alot about it)) with wire or wireless (better with both). Maybe games can be ported from a console to another so if we make multiplayers games, it’s could be great to be able to play with different consoles based on Arduino. It’s unofficial, it’s just an idea between game makers with ‘compatibles’ consoles

I would do the same.

I asked myself that too as it’s easier to interface with. The only good reason I could think of is that there is no low profile version that fits Arduboy or that it that such a version was too expensive.

I’ve actually tried that (except connecting to ATmega reset) and it didn’t work. The display hardware apparently needs more time to stabilize. Making a proper (delayed) power on reset will probably work but would require some extra parts.

That would require a shifter chip increasing parts again and there where enough pins available

Yeah you’re probably right.

When going down that road you might as well consider using an USB host instead.

There are a few bytes left and when kicking out the non mandatory Manufacturer discriptor name a few more that mayt be enough and if that’s not enough you could break the 3K boundary

The idea of exchanging games at a meeting/convention sounds nice.

Not really. But I know that the original GameBoy link cable was 8192 baud and Game Gear link was just 4096 baud

I ment to say that when using a 2x3 IDC connector (cable side) you need to have 1 pin space at each side. Because of the assembly construction of the IDC connector.

Had a brainfart at that moment. I ment RS232 to TTL but there is not a real standard pinout for those.

About a ‘link cable’, when using a 3 pin header. A cable might come loose with little force.

Looking forward to see your project develop.

1 Like

The other good reason is that the code required to control WS2812 LEDs is quite large compared to just toggling pins for regular LEDs. And, there were enough pins available to control all the individual LEDs. The original Arduboy isn’t meant to be expandable, so those pins would otherwise go wasted.

I’m not sure if code to drive a WS2812 would take much more then using Analog write for PWM-ing non primary colors. There also wouldn’t be a conflict with sound.

1 Like

I havn’t looked at the code to control a WS2812 but I think it has to be bit-banged. The Arduboy2 setRGBled() code is quite simple.

Plus, as you mentioned, the cost of 5 WS2812 LEDs would be substantial, compared to 5 regular LEDs and dropping resistors. The reliability of the WS2812 is also a consideration.

Yes, but the bit-bang code is pretty simple too. Roughly, there is a reset pulse, and then 32 bits are clocked in with NZR encoding. And as @Mr.Blinky mentioned, it would have freed up the ATmega’s timers and PWM pins for other purposes.

Why 5 WS2812 LEDs? Each one is already an RGB LED, so at most you would only need 2-3 (to replace the RGB and Rx/Tx LEDs). I just checked on aliexpress, and they can be had for 7-8 cents each (100pc order). Hardly seems consequential for a $49 device.

But, I agree that there wouldn’t have been any reason to look into this if future expansion wasn’t a consideration. And, I am not looking at them for this build either. I want to maintain backwards compatibility as much as possible. I was just mentioning that it’s unfortunate that 11 pins are spent on buttons and LEDs and that is making it a bit tougher to add some things that may need a bit closer connection to the ATmega (for ease of use and performance) than buttons and LEDs.

I thought we where just discussing why a WS2812 wasn’t chosen above a RGB LED.

If Arduboy was designed with expandability in mind it might have bean different.

To come back on the NES/SNES shift register, you could also use a shift register to expand I/O

I couldn’t resist and I’ve ordered one of those 2.42"displays with removable display, a yellow one :blush:

Yes, but that may not be as efficient as using one for the buttons.

The buttons only need to be read once a frame, and only require a single shifting cycle of the register to read all buttons, which isn’t really much less efficient that reading different dedicated pins one after the other.

For general I/O, especially for outputs, you may be shifting many times a cycle, and even just toggling one pin (high->low->high) requires two complete shift cycles. This can be way less efficient that using real ATmega pins.

To use a SR for inputs (i.e. 74HC165), usually there are three pins: a latch, a clock, and data input. The clock can easily be shared with the SPI bus, so at most two dedicated pins to read up to 8 inputs (or more inputs with chained shift registers). It would be kind of neat to allow hooking up an external NES/SNES controller as well. Aliexpress prices for 10 pcs works out to 7.5 cents each, so its not really a cost issue. Again, I want to maintain backward compatibility, so I will not be implementing this on this build, but probably would have if starting from scratch.

EDIT: Actually, it looks like a 74HC165 shift register can be hooked up to the SPI bus as well, which might make it even more efficient than dedicated pins. It still needs two dedicated pins, one for the latch, and one for a ‘chip select / output enable’ to make sure the data output doesn’t take over the bus when trying to communicate with other chips.

Sorry, my mistake. You are correct. You could probably get away with 2 or 3.

Another consideration is that if you used them for TX and RX, a custom bootloader would be required. Currently the unaltered Leonardo bootloader is used and @bateske didn’t want to make any changes to it.

Having the buttons directly on the pins means they can be used to trigger interrupts. Although I’m not aware of anyone doing this, using a shift register eliminates this possibility.

Yep, good point. But, does anyone actually care if the bootloader toggles Rx/Tx LEDs? I’ve never needed to monitor those myself.

Still, in our theoretical re-design, a single WS2812B could replace the existing RGB. This only requires a single basic output pin and frees up at least 2 PWM enabled outputs for other purposes.

True. Although I agree that there may not be anyone actually doing this. I suppose it come in handy to wake the device from a deep sleep mode. But Arduboys have an actual hard on/off power switch, so I’m not sure that a soft power on/off would be needed or useful. It might actually confuse people if the device looked like it was off but was just deep sleeping. They would try to turn it back on which would actually turn it off.

Again… all of this is theoretical. I am not actually proposing making any of these changes at this time.

After procrastinating on this for way too long, I finally finished up the v1.0 PCB and sent it out for fabrication (10 pcs ordered).

Now I just have to wait for ~2 weeks for delivery. (I already have enough parts to build 10 of these)

Compared to the earlier draft, this has a lot more pins broken out to the expansion headers (just about everything possible). I also labeled all the expansion pins, added the buzzer, added battery pads, and added some mounting holes.


Nice work … the 2.42" OLED is a nice unit.

I finally received the PCBs today (should have gone with DHL instead of cheaping out).

Anyway, I built one up and tested it out this afternoon. Everything seems to be working great!

The internal flash is using a different chip select pin (E,2) than @Mr.Blinky’s default one (B,2), so I created a pull request for his Cathy3K bootloader repo to add support.

As a reminder the ArduBigBOY has these features (different than the official Arduboy):

  • 2.42" SSD1309 OLED display (need to use @Mr.Blinky’s patcher script or compile with his homemade boards package)
  • Built-in 16 MB SPI flash cart (with bootloader support thanks to @Mr.Blinky’s Cathy3K bootloader)
  • 700 mAh lithium ion cell with protection (TP4056 based charge circuitry)
  • Hardware mute switch
  • Same pinout as the official Arduboy to easy with uploading existing .hex files (after 1309 patch)
  • Expansion header with almost every pin/signal broken out (allows for external SPI, I2C, UART, etc…)

I have enough PCBs and parts for 10 more of these, so if anyone would like one of these built up, send me a private message. The parts cost comes to over $25, and it takes a good hour or so to solder one of these up, so I think $45 + shipping is probably reasonable. I’m also willing to trade one of these for an original Arduboy if someone has an extra one to spare.

I will also be working on a 3D printable case and some expansion modules soon. I already have a double sided ‘cart’ ready to go, but with no software support for it yet, and with a 16 MB internal flash already installed and working, I’m not sure how useful it will be.


Very nice! I like it! Look at all that board space… blackberry keyboard :slight_smile:

You never go with DHL if you can cheap out. Are you going to publish the pcb?

Looking good! Love the pth crystal to smd bodge (I’ve even done the opposite, a smd crystal on a pth pad, on occasion).