Alternative Screen and CPU Arrangements

The website states it’s just an upgraded standard/base Arduboy, shipped with 200 Arduboy games. No mention of “Sequel” or anything.

Arduboy FX is an upgraded version from the standard Arduboy

The limitations are part of the appeal because they’re part of the challenge.

Tho, most consider a fun challenge to create something unique, rarely someone thinks it’s a fun challenge solve issues with “Loops” or “functions” cause they are a “big problem”.

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.

These were also not on your previous enumeration of problems.

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.

Arduboy is rather not having the usual user-base who buy a console to play some particular game, it’s advertised with “it’s also an excellent way to learn how to program!”

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.

Yet I was talking about all games. if some games have problems with “X” and some with “Y” … that accumulates. Hence sure, “games that don’t have a problem with X don’t have a problem with X” but if there was no “X” no games would have a problem with it.

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

if I had said that, you’d probably claim Desktop chips have quirks too. I think you understood the point.

I wouldn’t call the GBA particularly simple…mode 7

Maybe cause you aren’t experienced with it. The GBA has only 5 Modes. You can implement the effect of SNES Mode 7 on GBA, but also on Arduboy or RP2040 if you wish. You can accelerate hline drawing on GBA and on RP2040 as well. The simplest implementation would be on RP2040, the most challenging on Arduboy (ignoring performance)

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…

Lowering the bar for these who begin/struggle won’t take the “advance stuff” from you.

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.

assets was my initial point about memory tho, e.g games that cut sprites or sound cause it does not fit anymore. I really don’t see a benefit in that, I doubt you do.

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

I just referred to your words.

the sequel to the original Arduboy.

regarding the website, it’s really just an upgrade and you can upgrade any Arduboy by that " Flash eXpansion" just like you could with an Amiga500, N64, Atari, C64, XBox360 with their expansions (which also were sometimes sold including expansion + game for it)

Lastly, if the Arduboy were to ‘spec up’, it’s important to be wary of the competition,…

USP will sell the hardware, but the “big problems” will rather drive people to hardware, where they can create the games they wish, instead of fighting unneeded challenges, like not being able to fit some assets (unless they really really love the Arduboy).

If you really want to play “Arduboy” you can make it yourself, this is talking about new system. Honestly, it could be not compatible with the Arduboy at all, it’s just nice that it is.

Making it with the RP2040 and same guts as the Micro Arcade might mean it could be half the price and order of magnitude more capable. Now some might argue that isn’t the same niche that Arduboy filled with being truly 8 bit.

But like I just mentioned, you can still make your own Arduboy and enjoy all those games, or track down an old one.

Besides, if we got the color screen and more resolution it is nice because developer can import their game and make some updates hopefully to support the new features easily since the rest of the library function still works.


Maybe this link would be useful for the discussion:

1 Like

actually odroid go for arduino does 8 bit color easy and the frame buffer is smaller than i thought possible. its a clone v 3 on github. i found after you got impatient . 15kb for 320 x 240 8 bit color. what im currently working on adjusting doesnt even use psram just sram. makes playdate look overpriced considering since its a clone install through arduino you can forget the roms and just make a arduino game with all the draw functions you know from arduboy pretty much. bodmer worked on the revision to the adafruit release according the tohe bottom of the file. 1 ili9341 1 devkit c and 6 buttons you got playdate killer for $25 (amazon pricing as of last month) through ali its probably $15 with shipping

they are allegedly still working on snes prts but i doubt they will get far. snes on a esp32 pfff. they got 2 games but the arduino clone its only got 2 arduino games and some rom bin junk flappy bird and tetris

its the 3rd one i found and its all arduino code. your supposed to waste a sd card to treat it like its a raspberry pi but if you just use the example you can see you can make games on it. so you wont be seeing me much probably. i will make my rounds in other places at other times and circulate stuff

its not the same version but its the same screen buffer

Thanks for coming.

You will need to recompile all the sketches anyway for any movement outside ATmega32u4, exception is if your new “chosen one” can run an atmega32u4 emulator :upside_down_face:, so any choose you make you will need to recompile them ALL, the issue on what I understand is not to be “32 cores, 128GB RAM and sevaral TB SSD” but to be a minimal system to bring the same challanges as the arduboy in resources scarcity but using a color display instead of a BW one and if possible not to recompile all the arduboy sketches ( quite hard to pick something ).

iCE40UP5K with ATmega32u4 emulator and HW GFX accelerators LOL, bring enough challanges evoiding making people lazy, slappy and bloating, make arterial pressure to rise above 20, LOL.

Or add a very cheap FPGA from LATTICE to the current arduboy between the uC and the display and uC and the sound, or connect all the uC pins through the FPGA this bring all the flexibility in the world, this way you will have a 100% back compatibility and new accelerators allowing you to use a color screen, the FW of the FPGA can be uploaded using the same SPI interface where the display is connected…


I’m so grateful that one can make your own Arduboy - thank you.

This might sound a bit cheeky but if you were, one day, to move on from making money out of the ATMEGA32U4 version, would you be prepared to open source any more of the hardware design? I may be wrong but I don’t recall the production schematic being officially published. What about layout files?

I don’t think I would use them myself but it is an interesting question about what should remain a trade secret after production ends. On one hand, a justification for openness is the ability to repair systems. With the amount of hacking and modification that people do on Arduboy, being able to order a replacement or modified PCB doesn’t sound like an unreasonable request.

However, although there are many so-called knock-off Arduboys, one may argue that releasing printed circuit board source files for a (hypothetically, one-day) discontinued Arduboy model might reinvigorate competing hardware products that diminishes the feasibility of a replacement model.

Worth a discussion (happy for it to be split from the future chip / display thread)?


Yes, it is an upgraded Arduboy.
That does not mean it should not be regarded as a ‘sequel’ device.
(‘Sequel’ is of course being used metaphorically here, since technically only narratives can have ‘sequels’.)

The point is it’s official, it’s not some niche thing, it’s the current iteration of the Arduboy and thus it makes sense for people to be targetting it and making use of the extra features the FX chip affords.

Aside from being able to store more games, the FX chip can store assets (e.g. sprites, text, bytecode) that can be used within games. Eventually there will be games that only work on FX and won’t work on the old Arduboy because said games store their assets on the external flash chip.

As I said before, they are not big problems, they are very minor problems in the grand scheme of memory saving.

Besides which, if you don’t think solving problems is fun then frankly you’re not going to enjoy programming. Programming is more about problem solving than it is about telling machines what to do.

Anyone can dream up a game, but figuring out how to implement a game will always be complicated, no matter how many resources your computer has.

Yes they were. I said:

Addition and subtraction are a form of arithmetic.
The definition of arithmetic (according to Wiktionary) is:

The mathematics of numbers (integers, rational numbers, real numbers, or complex numbers) under the operations of addition, subtraction, multiplication, and division.

It is advertised as that, and it is indeed a good platform for learning how to program.

That does not change the fact that the majority of people who buy programmable consoles don’t actually buy the console so they can learn how to program, they buy it only with the intent of playing games on it.

That’s not unique to Arduboy, that’s the general pattern for all programmable consoles. The people who actually decide to learn to program the device are the exceptional case. The same is true of desktops and tablets - most people don’t buy them so they can learn to program with them, they buy them as a utility.

I’ve read enough about it. The GBA may only have 5 modes, but it’s still reasonably common to informally refer to the GBA’s equivalent to the Super Famicom’s mode 7 as ‘mode 7’ (as can be witnessed in this article).

I know. I have actually implemented something similar for Arduboy, but I never made it public.

(If anyone wants to doubt my claim, I’ll gladly make the repo public.)

Increasing the amount of resources is not the same thing as ‘lowering the bar’.

No matter how many resources a chip has, anyone who wants to learn how to program still has to overcome a great many challenges. Whether you’ve got 2KB or 200KB, everyone has to learn about variables, functions, loops, how to draw sprites, how to print text, all those many hurdles that are innate to programming.

And as I said, the FX greatly alleviates that concern because assets can be stored on the external flash chip.

There are few examples because few people have attempted it so far, primarily due to lack of guidance and a lack of people paving the way.

I’m not going to sit here and debate terminology because it’s a subjective waste of time.

Regardless of what one chooses to refer to it as, it significantly increases the amount of available read-only memory, which means it’s possible to store lots of graphics and other assets.

Fortunately, plenty of people do.

If it’s economical then this sounds like a reasonable choice to me.

8KB would be enough for a 128x64 256-colour display mode, or larger resolutions with fewer colours, e.g. 256x128 16-colour mode.

This is true. For most people sticking with AVR isn’t a priority, though it would have the small advantage of being able to reuse old assembly (which admittedly is a very small advantage given how little exists), and perhaps more importantly the advantage of fewer new things to learn for ‘veteran’ Arduboy programmers. E.g. most of what people know about progmem should still apply as far as I’m aware.

That’s mostly right, though it’s less about wanting resource scarcity and more about the problems that come with having more resources.

  • Competition with other products
    • If people can buy a PyBadge, a PicoSystem or an Odroid Go with more or less the same spec, what’s going to make them choose “Arduboy version 2” over those similar alternatives?
  • Feature creep
    • The more scope you have for features, the easier it is to plan a game than you won’t realistically finish because you’ve planned too many features. If you know you can only include so much, you’re more likely to focus on the features that matter and ‘trim the fat’.
  • An uneven playing field
    • The more of a scope you have for art and polish, the more detailed games will be. On the face of it that seems like a good thing, but it can actually put people off making games because they’re scared that the games they make will be inferior to what other people are producing. If there’s an upper bound on how polished a game can be, the gap between ‘good’ and ‘poor’ is narrower, so the prospect of making a ‘poor quality’ game is less intimidating.
1 Like

Depends on what you mean, but the schematicc for the circuitry was released a while ago here. I’ve got it bookmarked cuz it’s a good page for DIY arduboy reference. Doesn’t seem to be any files about the actual PCB used in the production arduboy, but the full circuitry schematic of the production version is there.

1 Like

Thanks - looks like that thread has been updated (particularly last year ref some component names / values) since I looked a couple of years ago. FX schematic is perhaps the more pertinent subject for this hypothetical end of life for ATMEGA32U4-based Arduboys discussion (which I appreciate consists pretty much of me pondering a made-up future scenario in a couple of posts - not much of a discussion :grin:)


As of this time I don’t have any plans to continue production. Theoretically, unless conditions improve the 32u4 version of the Arduboy and ArduboyFX are at “end of life”.

I would say I’m hoping to try again next year to get a quote and see if prices have gone down, but that is why I think trying to design around the 32u4 is a fools errand, it will likely not go down in price as many people will use this as an opportunity to switch from this otherwise already expensive processor.

While I certainly appreciate all of the design discussions, but unless I can come up with several thousand people willing to pay $70 for an ArduboyFX and wait over a year for it, it doesn’t really matter.

I’ve mentioned before several times I’m not really super interested in doing a “next” version of the Arduboy but I mean, with the current business plan. That’s why I’m trying to find a new way to make the hardware cheaper to produce, and yeah it probably means breaking 32u4 compatibility but… it’s been 7 years now actually so it can’t last forever.


If the peripheral hardware stays the same and the GPIOs are wired in the same bit order in a byte (to not have to shuffle individual bits around) it would be reasonable to make a binary translator for 32U4 emulation on a more powerful MCU.

There’s no self-modifying code and no code execution from RAM with the 32U4 so that greatly simplifies emulation.

Most of the IO access use immediate addresses (the instructions clearly access IO so many can be translated in-line without a function call, like code for pushing SPI bytes)

Pointers are almost always accessing RAM or ROM, not IO so those memory accesses can be cheated too to bypass a check for IO vs RAM/ROM.

And on the Arduboy in particular I really doubt anyone has used cycle-exact timing to bit-bang anything in or out of the device (it should all be SPI and hardware timers) so cycle-exact emulation isn’t a real concern so long as the hardware timers are emulated with real timing. We can cheat on that too.

As long as we don’t have to translate the OLED screen, the Flash, and reorder every individual GPIO bits it should be possible to have an emulator either interpreted or translated (or both) on a 160Mhz+ ARM MCU (with TCM & cache) at fullspeed.

The larger ARM MCUs could do the translation directly right on the device, loading the .HEX file into RAM and translating common instruction sequences into faster macro-ops as it goes.

It’d be easy to intentionally break an emulator like this but should be good enough to run the existing games (without recompiling). It’d be fairly “backward compatible”.

1 Like

With a library for the new system theoretically almost everything should just “work” though, only a very minor amount of code would need to be changed to a new platform.