Alternative Screen and CPU Arrangements

What about:


Is a ~1.6$ on digikey, and guess what, it is in stock :joy:

In case of ESP32-S2 there are versions with or without 2-4MB of FLASH and 2 MB of PSRAM integrated into the capsule, and has RISC-V coprocessor :yum:, maybe an emulator can be created in order to run current arduboy games.

Lot of support on Arduino, Wifi all you need for a preety feature rich device…

Games stored on a uSD card for easy updating or an onboard FLASH memory.

To see arduboy web server, arduboy home appliance controller, arduboy hacker device :sweat_smile:

1 Like

It really depends on context. For example the venerable pic16f84 and subsequent A variant has been on the market for a good 30 years I think and still available today, albeit at a higher price now. In this case it’s not like they raised the price at the peak of demand, it’s literally a good two decades past that peak before they did that. They only keep it around for the few niche applications that need it and due to the low demand and old manufacturing process of course they are going to raise the price.

I like the way you talk.

Advantage of using raspberry-pi baked uC is that we can sit back and ensure bootloader support.
Disadvantage will be throwing our control out of the window.

I prefer something found on Arduinos. They allow us to “hack” harder.

How would this be throwing our control out the window? I’m just a bit confused. RP2040 is open and well-documented, very capable, and found on the Arduino Nano RP2040 Connect. It’s also available as a featherboard from adafruit which is at about half the price of the Nano RP2040 Connect, and has USB-C instead of micro-USB. Plus the RP2040 has more I/0 capability than most Arduino boards, so I don’t really see how other Arduinos would be better. If anything I’d argue the RP2040 allows us to “hack harder”. Am I wrong?

My main issue with RP2040 is the same issue I have with most ESP chips - I think they’re too powerful.
Part of the appeal of the Arduboy (and similar devices) is that the resources are limited.

Limited resources means you have to limit the scope of your games, which in turn means you’re more likely to finish them because you’re less likely to have feature creep.
It also means you have to be more clever with how you use memory, which is a rare experience these days.

Here’s some numbers for some of the chips that have been discussed:

Spec ATmega32u4 SAMD21 SAMD51 RP2040 ESP32
Architecture AVR ARM Cortex M0+ ARM Cortex M4F ARM Cortex M0+ Xtensa
Cores Single Single Single Dual Dual
Clock 16 MHz 48 MHz 120 MHz 133 MHz 160 MHz
Clock Max 16 MHz 48 MHz 120 MHz 400 MHz 240 MHz
SRAM 2.5 KB 32 KB 192/256 KB 264 KB 320 KB
EEPROM 1 KB 32 KB (Flash) 64 KB (Flash) N/A N/A
Flash 32 KB 256 KB 256 KB/512 KB/1 MB 2 to 16 MB 448 KB

Aside from anything else, with RP2040 you’ll be competing with things like the PicoSystem.


I’ve spend the past few months playing around with the RP2040 (I actually own 3 by now :sweat_smile: with several displays etc.) and I really like it, it’s not really different to Arduino stuff.

I also think it is extremely hack friendly.
E.g. Some people wired it up to VGA monitors, some even to HDMI (you can also buy pre-build VGA/HDMI extensions, didn’t want to post links and make it looks like an ad :sweat_smile:, but it’s easy to find)
E.g. It has interpolator hardware, which does UV interpolation for texture mapping for you, it’s insanely fast! (That’s also what people use for getting HDMI work).
the manual has a few examples already, I think there is plenty this community could invent.

Availability: I’ve seen it at some shops for <$1/piece if you order 1000 pieces, imho that’s quite impressive compared to Atmel chip prices.

I think the limits are part of what made the Arduboy that appealing for me. I wish there was some random stuff on it to experiment (e.g. I liked the LED based data transfer demo ), people here so very creative and with every sensor/output etc. added, the insane ideas multiply :slight_smile:

1 Like

The RP2040 price is good but like I’ve said it before if I were to make a product with it, there would probably be a lot of opportunity for them to help on marketing side too.


Limited resources means you have to limit the scope of your games, which in turn means you’re more likely to finish them because you’re less likely to have feature creep.
It also means you have to be more clever with how you use memory, which is a rare experience these days.

I agree in regards of the working set (RAM), but I would wish there was more space (ROM) for assets. I don’t see a benefit to have less sprites or less text (or to invest the majority of dev time in trying to squeeze data, that makes it rather less likely “to finish a game”. Maybe a tech demo, yes, cause that’s a challenge, but not every tiny game has to be a tech challenge.).

That’s also why I’d prefer a 32bit CPU, you don’t have to derail from game dev to invest into hand generated assembler, cause you can’t express all the fine details in plain C. (And you don’t want to always use plain 32bit, cause it’s significantly slower). edit: I mean, like you probably care on 8 bit CPUs.

That’s half of what the FX chip is for. It can store assets as well as games. It just happens to be the case that very few people have actually attempted to use it that way yet.

Hardly anyone has had to resort to hand written assembly to get their games finished, at least partly because most of the time it’s possible to express what’s needed directly in C++. Most of the time hand-generated assembly won’t be that much better than what the compiler can generate.

But even then, assembly isn’t actually as hard as its reputation would have you believe. It only gets difficult if you start messing around with the important registers, forget to mark clobbered registers as being clobbered, do things that violate the compiler’s expectations or if the compiler does a bad job of inlining a function implemented in assembly (which is quite rare).

Assembly is also more useful for improving speed than memory usage. If memory usage is the problem, usually a different algorithm/strategy is a better option. E.g. using compression for sprites and levels.

(People often forget there is actually built in support for compressed bitmaps in Arduboy2. Probably because the only tool for generating such bitmaps is Cabi.)

int is actually 16-bit on AVR, as are the pointers.

32 bit values hardly ever get used in most Arduboy games because values larger than 65535 are almost never needed.
Sometimes larger integers might be used for scores, but that’s a small enough part of the whole program that it’s not going to make a big impact on performance or memory usage.

At worst, using 32-bit arithmetic on AVR just means one or two extra instructions here and there. It’s not a big problem unless you need to do multiplication or division, or you’re using 32-bit values absolutely everywhere.

Most of the time the biggest space and performance issues on AVR are actually loops and function calls.

For example, it’s much more efficient to use a switch to set a group of variables and then pipe those into a function call after the switch than it is to put function calls in each case of the switch. That’s probably true for most processors, but the difference is much more notable on AVR.

C++, not C. (If we only had C things really would be dire.)

1 Like

Provided the difference in cost isn’t prohibitive, if the choice is the SAMD21 then I’d consider using the SAMD51 instead.

I’ve edited it into the chart.


That’s half of what the FX chip is for. It can store assets as well as games. It just happens to be the case that very few people have actually attempted to use it that way yet.

I was talking about the ROM space on the base system (and future base system). I agree, you could target some mods, with more space or faster chips (or create your own Arduboy clone that matches the need of your dream game), but usually when you make a game for a “console”, you wouldn’t want to exclude most people that own it (cause they need to buy a mod)

most of the time it’s possible to express

But if you could have “more of the time”, cause your system has even less limitations, why not? There is little value, from a programmer pov, to worry about:

It’s not a big problem unless you need to do multiplication or division

or the other things you’ve enumerated.


I agree, nothing is hard, it just takes time. But I’d also expect, >50% who got/bought an Arduboy, never invested the time to program a line of code for it. The higher the bar, the less engagement there is, even with the shiniest device.


I’m well aware you know all the details about it, including all pitfalls ofc. If games could be made without these possible quirks, e.g. by using alternative chip, it would open the system to more people that don’t have that deep of an experience like you have (and maybe not the time to ever get close to your experience)

But that’s probably more of a decision to make. Is the goal to narrow the user base to people who are willing to invest the time to learn how to bypass many historical quirks, or do you want to address a broader audience, maybe even kids. If it’s the former, then I wouldn’t bother to create a new device. Arduboy is just as fine nowadays as it was on release, to create a tiny game in narrow limits, no need to create the same again and scrap the user base. If it’s the later, I’d not keep “multiplications, loops, … are a big problem [because it] appeals” and catch up to the simplicity of a GBA from 20y ago.

Your addition of the SAMD51 to the chart shows N/A for EEPROM but 32 KB (Flash) for the SAMD21. The SAMD51 can actually allocate up to 64 KB of flash to emulate EEPROM and has a more advanced “SmartEEPROM” mode for doing so.

Also, up to 8 KB of RAM can be set for battery backup. This could be used to emulate EEPROM with the additional advantage that there would be no restriction on the number of write cycles. However, the contents of this memory would be lost if the battery were ever allowed to completely discharge.

The SAMD51 series has versions available with 256K, 512K and 1M flash available. The ATSAMD51G18, with only 256K flash, would be one of the most likely candidates for a next generation Arduboy.

I would assume that the flash chip currently included with the Arduboy FX would also be included in the “base” version of a new system.

Something the SAMD51 has is a Quad Serial Peripheral Interface (QSPI), which could interface to the W25Q128 flash chip used in the Arduboy FX. The SAMD51 QSPI can execute code directly from such a serial flash chip.

The SAMD51 also has a true SD/MMC card controller, if we wanted to add a (fast) microSD slot.

1 Like

I would assume that the flash chip currently included with the Arduboy FX would also be included in the “base” version of a new system.

Crossing fingers :slight_smile:

Running code from an external flash chip sounds interesting. Can it also access it for data directly? (It’s Arm, hence I’d assume, it can, cause the memory space is usually unified, but does it?)

Have you tested how many pixel/s the (Q)SPI could push?

I believe so.

The Tachyon Kickstarter hasn’t produced, so I got a refund and bought a SparkFun Thing Plus. Unfortunately, I haven’t been able to find the time to do anything with it.

I’ve checked the Datasheet, it looks insanely powerful. In CoreMark it’s 3x of RP2040 (Core2Core), including some SIMD, FPU, Crypto unit.

google also spit out another arduino based device, using SAM21D :open_mouth:


The FX chip is the base system.
Arduboy FX is the official sequel to Arduboy, it’s not a homebrew thing.

The limitations are part of the appeal because they’re part of the challenge.
If you remove too many limitations you might as well just be programming for phone, tablet or desktop.

Adding and subtracting aren’t a problem unless you’re doing them absolutely everywhere.
For adding and subtracting, it’s effectively one instruction per byte.

Assembly isn’t mandatory. As I said, most people will never need to use assembly because there are other, much better ways to save memory. It’s rare enough that I couldn’t even name a game that does it.

That’s not unusual by any means. The vast majority of people who buy any sort of console aren’t going to be the ones writing the games.

If anything, the Arduboy’s actually had more people writing games for it than most other similar consoles.

The point of mentioning that int is in fact 16-bit not 32-bit was to highlight that a 32-bit CPU would not be an automatic benefit because most Arduboy games cope perfectly well without needing 32-bit integers.

All chips have quirks. And if you did eliminate all the quirks of each chip, you might as well just be writing for desktop.

You don’t really need that much experience to make a simple arduboy game. Knowing the advanced stuff helps a lot, that’s going to be true for any kind of programming, but people have made decent Arduboy games without even knowing what a struct is.

If you’ve got enough time and talent to max out progmem (assuming you didn’t do it by filling the memory with massive sprites) then you’ve probably got enough time and talent to learn how to cut down on your progmem usage.

I think that’s unfairly dismissive of what the Arduboy is capable of.
There are some very impressive Arduboy games out there.

Besides which, making ‘big’ games is hard regardless of device. Increasing the resources won’t make creating ‘big’ games any easier, because making ‘big’ games is a matter of dedication more than anything. (Dedication and the ability to resist feature creep so the game actually gets finished.)

They are not a big problem, they are a minor problem.

Loops are going to be a bottleneck on any platform, that’s precisely why there’s an entire category of compiler optimisations deticated to loops.

At any rate, most of the problems with the progmem limits are solved by the FX chip, which as I stated earlier is not some homebrew mod, it’s the official thing - the sequel to the original Arduboy.

I wouldn’t call the GBA particularly simple.

It has half a dozen different screen modes each with their own quirks and limitations, and you can’t even begin to get mode 7 working unless you have at least a rudimentary grasp of matrices.

Lastly, if the Arduboy were to ‘spec up’, it’s important to be wary of the competition, like the PyBadge. Any ‘specced up’ device is not going to be a guaranteed success just because it’s got ‘Arduboy’ stamped on it, it needs to fill a niche, have a unique selling point or have very good marketing.

That’s because the pages I looked at on Sparkfun and Adafruit made no mention of EEPROM as far as I could see.

I also completely glossed over the GPIO differences and other features (like accelerated cryptography) to avoid the table becoming too complex. The intent was to provide a basic overview to highlight the scale of the differences, not a comprehensive comparison of all variants of each chip family.

I’ll add in the stats you’ve mentioned, but I don’t think it’s worth doing much more than that. At this rate the table is going to be buried halfway down the thread anyway. Someone could start a topic to act as a wiki holding the table if anyone thinks it’s actually going to be useful at all.


ATxmega64A4U/128A4U 64/128KB FLASH, 8K RAM,32 Mhz integrate 4 channel DMA, USB FS/LS and some more.

You can use a 8Bit paralel display and use DMA to push data to the display at core frequency speed thru an entire 8bit GPIO, or use SPI display and use DMA to transfer datadoing other stuff, the bootloader flash is outside of the 64/128K FLASH, you can implement two stage bootloader, because they have two zones for bootloaders, one in a dedicated 4KB area and one inside the application area als 4KB that eat from the application FLASH, each zone with its own locking fises…

And you stay in the same platform :yum:, you change only the drivers for timers, UART, SPI …

The advantage of ATxmega is that all modules are identical, if have 4 UARTS all are identical you work with structures, you can change UART’s SPI’s and timers from one to another with no driver change you move only the pointer address.

I already have a SDK for those uC’s:

As a reference.


Unless your new system is 100% binary compatible, you’re going to have to re-compile sketches for it, so it doesn’t matter if you stay with the same “platform”. As long as the libraries are ported and compatible, and the sketch doesn’t contain any code that directly manipulates the hardware (very few do), a change in processor architecture won’t be much, if any, more difficult.

1 Like