Future Arduboy

People would do flickering anyway to get 7 tones. :stuck_out_tongue:

This is both a good and bad thing. The restriction forces people into smaller scopes, so it’s easier to actually finish a project. There’s no room for feature creep or year-long projects.


So true. :+1:

1 Like

An Arduboy with a 2.5in 128x128 px 2 bit monochrome oled/lcd screen, more ram and eprom, if necessary with a SD card, a start and select button, and an SD card slot will make me happy. Then it will be a lot more close to Gameboy both look and power wise, guessing that the hypothetical future Arduboy is still designed to look like a Gameboy, but it’d be also nice for it to rock it’s own look.


In my experience that’s hasn’t been true.

A decent chunk of the time that went into Dark & Under was going around cutting the size down or deciding which features to drop from the original design because of size constraints.
In fact if it hadn’t been an issue, I probably wouldn’t have been called in to help in the first place.

It also hasn’t stopped my own games from progressing slowly or features creeping in.

While I still support the 2-bit screen wish, I agree with this.
The bottleneck is almost always the progmem.

Though I think if there was an SD card that could be read from then most games near the progmem cap could load levels from the SD card, in which case RAM would then become the bigger issue.
(E.g. Arduventure could load its maps from the SD card, which would save a fair chunk of memory.)


Why not just step up from Arduino Leonardo specs to Arduino Mega?

256KB Flash / 8KB RAM, the assembly code portions of the library remain compatible, and you retain the Arduboy’s 8-bit spirit!

Seems like all of this is moot though - the decision to jump to Arduino Zero specs has already been made, but I have to agree it makes me sad somehow that the Arduboy / Pokitto / META will all be essentially the exact same device, but with 3 different screen variations…


Not if the next Arduboy:

  • Sticks with the same 128 x 64 mono screen.
  • Remains compatible with the huge number of current Arduboy games at the C++ source code and library level, requiring just a re-compile for the majority of games.
  • Doesn’t add a lot of new “whiz-bang” features that make the overall unit capabilities difficult to grasp and more complicated for “noob” programmers to work with.
  • Keeps the same credit card size. (Preferably the exact same case, with minor mods for an SD card slot and/or other decided on additions.)
  • Costs less than the two mentioned in the quote and any other similar ones.

You have to consider the momentum that the Arduboy has, in terms of numbers and game availability. In addition to official Arduboys shipped, look at the number of Chinese “clones” available as a testament to its popularity. There are literally hundreds of games and other sketches available for the Arduboy (with over 20 more added just in the last few weeks due to the game jam). A substantial number of those are well done and very enjoyable to play.

If the next generation Arduboy strays substantially from the current one, much of that momentum will be lost and, as @uXe says, it will just be another new, different device in a sea of competitors. (Honestly, I’m sceptical that the Pokitto or META will ever gain the popularity that the current Arduboy has.)

So, as my philosophy has always been: Give developers a bit more processor power and memory resources, so they’re not pulling their hair out wasting time on these, but keep it as backwards compatible and inexpensive as possible. It should remain slotted as a relatively simple, easy and fun beginners/learning platform that can none the less produce decent, enjoyable games. My Arduboy Z prototype embodies this philosophy.

As for the popular desire to have more than just a monochrome display, IMHO it would have to remain compatible with the commands, resolution and speed of the current display (at least at the library level) when run in 1 bit mode, so as to remain backwards compatible with current games. Its size should be a consideration in terms of maintaining the unit’s credit card size. And, its cost shouldn’t impact the desire for a low cost unit. I challenge anyone to find such a beast.


The price of a 2560 ($10,25) compared to the price of a 32u4 ($3.49) when something with much better specs can be had for much less ($2.66). :thinking:

I’d prefer solving the limited progmem problem with an SD card and keeping the 32u4.

Okay, I closed the polls, as it’s pretty clear what we want for the next generation Arduboy.
Also I agree with most of these statements.
That the Arduboy is unique with it’s “credit card” gaming system.

I would like the most if they added SD card support, so I can play multiple games without a PC (if I get bored with the current one).

And a connection between 2 arduboys (like the Gameboy’s link cable) would be pretty cool for the system.

1 Like

I haven’t looked into this much, but it’s possible that the extra code required just to support the SD card might limit memory available for games, such that a lot of SD data loading (which is relatively slow) would be required for many games wishing to make use of it.

Also, if you had an SD slot, you would probably want to use it to load different games (as well as being used by a game to load/store data). This would best be done by adding such capability to the boot loader or library, but expanding the size of these on the 32u4, while remaining able to load large existing Arduboy games, could present problems (though it’s possible that a version of @Mr.Blinky’s optimised bootloader may be able to squeeze something into the 4K used by the Arduboy/Leonardo bootloader). By switching to a new processor with a fair amount more space for the bootloader and sketches, this problem is probably eliminated.

1 Like

there’s currently 1.5K space in my optimized bootloader. I think it is possible to fit an SD loader with a custom file system in there.But I’m not sure about fat32 as I’ve not done enough research for that. SD will be relatively slow though as data is accessed in 512 byte blocks and requires some extra ram to manage the filesystem.

For this reason I’ve moved my interest to flash storage which can be accessed much faster at byte leve, requires much less code to implement and as a bonus a card reader isn’t required :stuck_out_tongue:


OK, how about splitting the difference with an ATmega1284P for $4.50 - 128K Flash & 16K RAM!

Plenty of work already done on Arduino support for the 1284:


“Pride goeth before destruction, and a haughty spirit before a fall.”

Once the Arduboy Zero is released, and the desired backwards-compatible Cortex M0+ based library established, any “I wish the Arduboy had a bigger / colour screen” threads will have a simple answer: just go buy a Pokitto / META and use a slightly modified version of the library…


The modifications might be a bit more that “slight”. I don’t know about the META but I think the Pokitto’s display would require translation for the commands and format that it uses. And, it appears that it’s quite slow, so fast paced games requiring a high refresh rate may not play properly.

I would like a BIGGER SCREEN (mainly I got used to the hige pixels on my ti-84 graphing calculator). Black and white was fine.
That makes things like the TinyFont more useful, as of now you can almost not see anything they were written in unless you are with really good eyesight, even more so when on a metro.
Pokitto was slow? One consequence of putting too manu fancy things up there–processor’s not up for the job.

Lol this thread. I can tell everyone is excited for something new!

Happy to see what you want is coming down the line.

The screen will not get bigger, it can’t really. Then it wouldn’t fit.


In fact I think you can have it to be a 1.54 inch and the RGB LED to be squeezed to the rright of the power switch, and basically all the ICs responsible for charging to be moved to the bottom-left corner.
Maybe not.

The RGB LED seems to be not of a very good quality-the BLUE light was a bit too blue, so when in flashlight mode it casts a light-blue shade of light. (and the rumor sais those to be damaging to your EYES!)
I don’t know, but we may be able to sqeeze in a better RGB LED…

Really? That doesn’t happen to me.
When my arduboy is in flashlight mode, it shines brightly white.

Some of the older units had the LED soldered on incorrectly.
I can’t remember the specifics, but that would probably explain the light going blue in ‘flashlight’ mode.

1 Like

It would require the front plate to be redesigned (injection mold) which is the most expensive part to design/produce.


It’s probably because the LED dropping resistors weren’t matched to the differing characteristics (forward voltage, lumens vs. current) of each colour. All 3 resistors are the same value (220 ohm), which produces different apparent intensities when driven with the same output values.

Nope. With an incorrectly installed RGB LED, it doesn’t light at all in flashlight mode. Green has to be off for red and/or blue to light. (Plus, red and blue will be reversed and green can’t be lit at all.) Flashlight mode turns on green, so all LEDs remain off.

1 Like