Arduboy 2 My Ultimate Hardware Wishlist

We keep trying to get the factory to break out the frame sync pin, but they keep trying to get me to buy a million units.

I’m gonna take a stab at custom LCD next year and see how far I can get.


Maybe the controller chips from some of the current screens are re-programmable? It seems insane to me that all of the screens out there are either 1bpp or 16bpp but nothing in the middle.

You all seem to miss the point @bateske is trying to tell you. You have to buy A LOT of screens (millions) if you want something out of the custom range. Yes all those screens are possible, but factories will not even startup production if you don’t order at least 100K. There are example screens floating around, but those have been produced in small badges, just for example purpose.

Bottom line: EVERY screen size, resolution, bpp is possible, BUT you have to order a lot before the factories want to produce. And as long as Arduboy doesn’t get an 500K arduboy order, they will NOT stock 1M screens.

1 Like

If anyone points us in the direction and can get a sample of something else that is better, we are all ears! :slight_smile:

There is a Color oled that is 160x128 pixels so that is only 16 shy of the original game boy, maybe it wouldn’t be too terrible to lose those. You could have a hardware switch to cut the top and bottom 8, or shift it 16.

But to be honest, the 128x128 color oled seems to be the most available, but it’s so expensive it probably is cost effective to have a custom LCD built. But then the power consumption is higher and the controller chips are typically much larger.

the good news is, it may not be much thicker, I’ve found some LCD screens that are basically as thin as what we are using now, but I don’t know what the cost is like.

Pocket Chip has a color screen but it’s about the worst quality LCD you can buy, and it still has a resistive touch screen. That’s 10 year old technology, but then again most people seem not to care.

Further more, you could buy an amazon fire tablet for $33 this year, and it’s got an HD IPS screen with capacitive touch screen so theoretically we should have all bought one of those if the equation was simply the cheapest product with the best screen.


Actually I like the current hardware of the Arduboy :heart_eyes:. It provides a nice playground with acceptable hardware contrains to be not overwhelmed when creating games for it.
One thing I would like to see is to get more RAM and space for content. An SD card is definetely an option and beside that we could add an SPI RAM like described here:

It would give us the chance to add more graphics/bigger levels without adding too much expensive hardware.
Another thing goes around in my head is to add a second atmega like a copro that is offloading the first one and doing any calculation on data in the spiRAM… Signalling between the two CPU’s on who is allowed to access the spiRAM is something one must solve. Also possible would be that the second CPU is reading from the SD to the spiRAM so the main CPU can just work on the data (maybe even preprocessed by the second one)… I know… sounds complicated, just wanted to drop this idea here… :joy:

1 Like

SPI RAM is really slow and isn’t random access. You wouldn’t be able to use it for a larger screen buffer.

I think you’re getting overly complicated in the quest to retain the ATmega32U4 processor. The Arduino Zero compatible ATSAMD21G18 processor in my ArduboyZ prototype is cheaper and provides more RAM, flash and CPU speed.

I’ve already ported the majority of the Arduboy library to it and have a microSD slot working as well. It currently uses the same 1 bit display as the Arduboy, but the increased RAM and flash in the processor would likely be able to handle easily a larger display with more colours, if a suitable one could be found.


Yeah you are right. I just wanted to drop the idea here. Ths ATSAMD21G is a nice chip and I believe it will provide a lot of performance. I am only a bit concerned that changing the processor that early will drop a lot of old games that are optimized for the atmega. As far as I know all the optimizations done for a 8 bit CPU will be pain on a 32bit CPU. E.g. 8 bit accessess are not possible on an 32bit ARM. I think only at 4 byte boundaries and all the rest will be shifted around by the compiler when you do an unaligned access. Maybe for the cortex M0 thats different but that is what I remember from other ARM CPUs when you look at the assembler code. The C programmer will not recognize it when you give 8bit optimized c code and compile it for the ARM but the result will be not optimal.
On top, I think many games for the Arduboy will likely provide some nice libs and optimizations even with assembler for the atmega. All that will not work anymore.

Do no get me wrong, I like the ATSAMD21G18 idea. But I fear the old and yet young Arduboy platform will starve soon if we change the CPU in that direction. Or at least we will generate two different communities.

Isn’t there an atmega with more flash/ram? E.g. the ATmega1284P…

Sure they are, no problem. The compiler takes care of it.

The main problem with switching from Atmega to ARM is Atmega code written in assembler for optimisation purposes, but the ATSAMD21G is so much faster that you could probably just write the equivalent code in C++ and it would still be faster.

Keep in mind that this is Arduino Zero compatible, which is a “real” Arduino. A good portion of the standard Arduino libraries are available for it, such as the SD card library I used for testing, and more are being ported all the time.

Sure I know they are possible but look at the assembly code when e.g. accessing unaligned addresses (8 bit access to odd addresses). I do not know the M variants but ARM9 and high range Cortex assembly code will not be optimal here. Usually the code is much faster when just working with 32bit aligned addresses.

Anyway I get your points. Maybe I just like the atmega architecture :wink:

People should be avoiding assembly unless absolutely necessary. Compilers do a pretty good job of optimisation these days.

Even adding just an SD card is going to split the community somewhat. People with the new hardware are going to take advantage of it. Working to a “lowest common denominator” means new features won’t be fully utilised.

Wow I checked the datasheet of the ATSAMD21 (>1100 pages) and it quite a cute beast. It even provided a full fledged descriptor based DMA unit. That will give us an extra boost when it comes to data transfers between the display and sd card. There are so much devices that we could spare a dedicated SPI for SD and the display (not sure about the max tsck timing here but looks like the APB clock can be evenly divided from CPU clock, so maybe 48, 24, 12, … MHz are possible here).
There is even a I2S interface so a real audio codec could be connected :joy:

I wonder if all this infrastructure is already supported by the Arduino community.


Should be possible to put a small DAC + Amp chip that requires few external components. There are for sure speakers that will fit. :slight_smile:

Prototyping on this will start next year, I’ll be looking for beta testers to send developer kits to :wink:


The ATSAMD21G18 has a true 10 bit DAC on board, so unless you want higher resolution or stereo sound an external DAC isn’t required. An amp may or may not be required, depending on the speaker used and desired volume.


How about the sub-miniature phone jack, which is 2.5 mm?
On some devices, like cameras, it carries audio and composite video.
Audio out would be cool.

Have you guys seen the Raspi Boy?:

Based on Raspberry Zero.

The problem with raspberry based systems is that they are not dedicated systems. The biggest downfall in my opinion is waiting 30-60 seconds or more just for it to boot up.


Agree. The only way to improve that is with a heavily customized, barebones distro. And even there, you have to wait a bit.

Might be, I’m actually looking into having female pin headers exposed on the outside so you could use prototyping wires and plug it into a bread board for lots of neat projects.

I would probably prefer to do something like having the audio adapter in the micro-usb port using a dongle just because it keeps the exterior clean.

If anyone is good at CAD modeling then we should talk more :slight_smile:

SPI starts to be ridiculous at some point, that’s why most of these controllers also support 4 or 8 bit control modes… if we’re trying doing 16-bit color in the future we should consider dropping SPI as the interface.


Better power managment unit. The MCP73831 used to charge the LiPo doesn’t support much in terms of host interfacing and GPIO chit chat.