"Dual core" Arduboy with MicroSD loading


Using two arduinos, I put together an arduboy clone that can load games from a micro SD card.

The games are loaded over the ICSP header using a hacked down version of Nick Gammon’s hex uploader.

The screen is the commonly available 2.42" oled from ebay with the SSD1309 controller. Using this required recompiling the games using Mr.Blinky’s arduboy homemade package.

I used an arduino “micro” for the game system and a “pro micro” for the programmer. I went with the larger “micro” for the game system because I originally wanted 100% pin compatibility so I could just download games and not worry about recompiling. But since I have to recompile for the screen anyway, and since the homemade package makes it so easy, I’ll probably swap it out for another “pro micro” to save space. (Recompiling also lets me do things like fix the jump/whip button locations on CastleBoy :wink:

The screen looks good most of the time, but when a large percentage of the screen is lit up it can get wavy and have inconsistent brightness between lines depending on how many pixels in that line are illuminated. I tried adding caps both before and after the charge pump with limited effect. I may try replacing the charge pump circuit entirely. I also have a 2.7" SSD1325 screen on the way that I will experiment with.

My plan going forward is to refine the uploader and have it display a menu on the screen before handing control over to the game system.

(Scott R) #2

For convenience when using SSD1309 you can edit the .hex

Or use @Mr.Blinky’s python uploader


Nice. I always enjoy watching hardware setups like this. Cool idea of using another Arduino to ICSP the Arduboy core.

When you’re replacing the Micro with a Pro Micro. You should know there are Pro Micros with a slightly bigger chip (TQFP package). If you have a soldering iron with a small tip and can solder thin wires, you could stick to the original wiring.

Like @Keyboard_Camper mentioned you could edit hex files or patch them on the fly like I did with my python uploader

Basically you look for the LCDBootProgram and then replace 0x8D 0x14 with 0xE3 0xE3

I don’t know any better then this is ‘normal’ for these kind of OLED displays. But I never really looked into it. Would be great to minimise this ‘ghosting’ effect.

If you’re looking for an idea to interface the display by both cores. I’d give priority to ICSP MCU by connecting the pins directly to the display and lower priority to the Arduboy core by connecting the pins to the display through 1K resistors so there won’t be any shorts when both output at the same time. The ICSP core can release control by turning the pins into inputs (without pullups)

Good to hear you find the homemade package easy to use the feedback is appreciated.


I’ve made significant progress and have a full demo working:

When you power on, it defaults to the arduboy core and plays the loaded game as normal (there is a brief reset hiccup due to debug code running on the programming core). Then when you press a dedicated menu button, the programming core wakes up, pulls reset on the arduboy and displays the game menu. It can display an arbitrary number of files in a list with a 64x64 pixel screenshot of each game as you select it. Loading a game takes about 7 seconds.

Thanks for the tips on pinout and hex editing. I had actually already purchased that package of pro micro with the hopes of doing the pinout hack, but I ran into problems with the hex editing for the display. After a lot of trial and error, I figured out that most of my intermittent problems were caused by the project being strung out between two breadboards. The hex editing works fine and it was just a coincidence that I was having display issues when I first tried it.

The display rippling I described was caused by the two-breadboard power issues, but the line intensity problem seems to be inherent to the display controller. I tried bypassing the charge pump and even running it at much higher voltage - the display gets brighter but the line intensity still varies depending on the number of pixels illuminated. I also tried screwing around with all of the control registers and scan rates and saw no noticable improvement. It’s a bit frustrating because the 0.96" display I have has a flawless image, so I know that if the controller was designed for the larger display it could be made to work properly.

For sharing the display, I simply couldn’t get two arduino SPI pins connected without issues. I tried a few different resistor configurations with no luck. Even just connecting the two SCK pins with the arduboy core held in reset mode caused issues. So I ended up just using a multiplexer chip to switch the spi bus from one core to the other.

I switched the programming core from a 32u4 to a 328p based arduino. The virtual serial port on the 32u4 is just way too finicky, often requiring reset button juggling just to get the thing to start uploading. The programmer core shares the buttons and display with the arduboy core, but is not connected to the speaker or RGB LED. I ended up using every single pin on the arduino, including the analog-only A6 and A7 pins, so there’s just no room left.

Hardware wise, I’m going to put together a charger/regulator circuit to verify that it works off of a battery, check the current draw to figure out what size battery I need, then start designing a PCB. For buttons, my plan is to use rubber domes from an NES controller repair kit (still being made brand new).

Software wise, I want to make the menu togglable between different display modes by hitting left/right. There would be a full screen text mode with a 1-5 star rating for each game (similar to my Romshelf project). The next mode would be half text/half screenshot (like in the video), then full screenshot, then perhaps title screens. There’s a lot of screenshot collection to be done. It should also remember what game you have selected/loaded.

There’s also the issue of backing up and restoring eeprom, which is apparently possible over the icsp header without a helper program. It’s especially important since I can’t figure out how to erase the flash without also erasing the eeprom.

(Simon) #5

This looks fantastic … and I really love your choice of games - 1943 The Battle of Midway in the first demo and Lode Runner in the second. Shameless plug for my games!


Cool to see progress on your project.

I’m asuming you’re doing a chip erase before flashing. In this case you can burn the EESAVE fuse to preserve EEPROM contents. change high fuses from 0xD8 to 0xD0 (standard settings with 4K bootloader)

If you do not flash a hex file with bootloader after a chip erase you may want to clear the BOOTRST fuse also. In this case you need to change the high fuses from 0xD8 to 0xD1 to have both the preserving of EEPROM and a direct application reset.

(Michael Gollnick) #7

Is it possible to communication with the second cpu from the first cpu (that runs the game)? I thought with this architecture you can outsource things like audio to the second cpu. Maybe even add some kind of serial RAM that both cpus access so the first one (that one with SD card support or the like) can fill it with content upon request from the second cpu… :star_struck:


There are SPI ram chips available but, I dunno, once you start down the road of adding extra components there’s no end to it. I think the appeal of the arduboy is the single 8-bit chip design.

If I was going to add sound hardware to the arduboy, I’d probably go for something like the YM3812 or YMF262 for authentic adlib sounds.


I’ve designed a case and internal layout for all the parts.

Here’s a write up and parts list so far: https://badspot.us/ArduboyXL.html


I’ve designed and ordered a PCB: