Alternative Screen and CPU Arrangements

Here is a picture of a ‘bit modded’ FX … note the visible chip in the centre of the machine.

I’ve never seen something like this.

However, I know that every Arduboy can become a Arduboy FX by soldering up a small piece of PCB at the back
that add-on PCB is actually a award from Arduboy(Inc) for the “crazy popcorn time” on the DIY Arduboy Contest
However from the look of Arduboy – FX it seem like they indeed make new PCBs for it. Maybe there are enough orders to produce a batch of Arduboy FX PCBs, and maybe after the FX production had began (and ceased) there weren’t enough orders to roll another batch of FX PCB (which is why they are sold out)

It’s also because a program written for the original Arduboy will work on the FX, while a different screen size may need changes.

I chose “color screen” and now I totally regret it. Resolution is more important.

1 Like

That was supposed to say ‘not modded’ - fat fingers.

That’s a fair point too. Even if a 128x96 screen followed the exact same protocol, any game code would still need to be recompiled to account for the 32 extra rows of pixels.

1 Like

I think recompile is going to be needed for anything that is worth producing at this point. The 32u4 is too expensive.

Thinking a lot about the samd21, and going vertical screen.


Honestly would love to see it, samd21 seems like a great option for an Arduboy 2: Electric Boogaloo


A different screen format would be nice for creativity – having enough resolution to support easily porting 128x64 games, but allowing taller programs would be neat, and the vertical orientation tends towards some neat arcade tropes.

SAMD is reasonable, but I’m not sure a vertical screen is a good idea.
It’s fine for Tetris and maybe 1942/1943, but it’s probably going to be awkward for a lot of other things. Especially platformers.
RPGs could possibly manage by using the vertical space for a HUD.


I’ve got to agree, and it would be awkward to play recompiled arduboy games. Maybe a better option would be to go for a screen with double the resolution of the arduboy? from what I’ve seen, SAMD21 is pretty good with screens that have a larger framebuffer, and if it was a multiple of the 128x64 resolution, recompile would be pretty easy to port 32u4 arduboy games over to the new system in a way that’s not too unfamiliar (as with the vertical screens)

1 Like

Did someone mention 1943?


It’s $4.93 on digikey.

Samd21 is a lot more powerful. ARM32 too.
If you want the highest spec (ATSAMD21J18A, 256KB PROGMEM, 32K “data memory”, 64 pin), it will cost you …
$4.28. Or $3.97. Around $4.1.
If you want comparable spec (ATSAMD21G15A, 32KB PROGMEM, 4K “data memory”, 48 pin), it will cost you …
I can’t get a listing.
But if you go with ATSAMD21G15B, it will only cost you $2.1.
It’s unknown why the 15A is unavailable. The stats are identical.

You know, I’ll be in the SAMD21 boat. But I’ll be asking questions about bootloader (unless we are using the ATSAMD21G18, which is on the Arduino Zero).
And also, remember that those chips typically don’t have EEPROM. And also, we need to toss in a 3v3 converter (which, indirectly means that we will have no way of knowing the current battery voltage via software)

But it have massive storage and massive ram.

1 Like

Prices are crazy right now for components so that’s why I’m waiting to do any more production.


IMHO, after solving the biggest problem that the Arduboy had (i.e. storing only one game), and all the positive feedback for the FX variant (Input Mag, Hackaday, user comments), it might be a good idea to try to support the original Arduboy for as long as possible – this little handheld still has got lots of potential, and it looked like it was gaining steam again. Is the price hike of the 32u4 connected with the global chip shortage? Maybe it could be waited out, or the chip could be emulated/replicated in some form? If there is a new Arduboy, I would love to see a device that is fully compatible with the original Arduboy (like the Game Boy Color is with the original GB).

And when it comes to a completely new homebrew handheld, I would like to see a PICO-8 device made with custom hardware the most. Some people say it might be possible to implement PICO-8 on FPGA (and someone is even looking into this brownphoton comments on How would you run a fantasy console on FPGA?). I wonder what Lexaloffle would say about a crowdfunding campaign for a PICO-8 console…


You have to realize that we had maxed it out with Evade2, which used 100% of PROGMEM and 100% of RAM.

Using a SAMD21 will allow advanced user to push it further, although, if we really are going SAMD21, I urge for a bigger display so we can extend the 32KB of RAM and 256KB of ROM (as well as the inherent 32 bit advantage and blistering fast speed) further.

1 Like

By potential I meant that with the release of the FX, there are new users interested in the device. The SAMD21 is obviously more powerful.


Unfortunately this is going off topic a bit, but…

I very much agree. We haven’t even begun to make full use of the FX yet.

I think later on I’ll have a go at trying to calculate what kind of power/throughput an emulator would require in order to emulate an AVR chip.

Speed is usually the biggest issue with any emulator.

Another alternative is to write a transpiler that can convert AVR machine code to another platform’s machine code, but the thing would complicate that is the code that controls the hardware.

This is one of the reasons I think it’s important that Arduboy games are open source - reimplementing Arduboy2 and recompiling games from source is by far the simplest and easiest method for running the games on other devices.

As someone who knows a thing or two about virtual machines, I’m inclined to believe this is possible, but not necessarily practical.

It’s been done for Java bytecode with Jazelle, though admittedly not with FPGA as far as I’m aware.

“Only if I’m profiting from it” if he has any business sense.
“Sure, no problem” if he cares more about people’s enjoyment than money.

Unfortunately the biggest issues with PICO-8 will always be its licensing. It’s not licensed in an open way, so you’re at the whims of its creator. If you do anything the creator doesn’t like, you could be sued for copyright infringement.

Although as of the resolution of Google vs Oracle, in which they finally ruled that it’s possible for another implementation of an API to be considered ‘fair use’, so it may be more complicated than that.

But while that’s definitely relevant for someone reimplementing the PICO-8 API, an FGPA implementation of the bytecode might fall under different rulings because bytecode most likely isn’t judged the same as an API (though I would argue that bytecode is a protocol which must be implemented, and thus shares important characteristics with an API).

If it weren’t for the legal issues, I’d be perfectly happy to reverse engineer PICO-8 and provide alternative implementations, despite not actually being all that fond of PICO-8.

The problem with that though is that with those specs you start to compete with devices like the Pokitto. (Gamebuino is no longer an issue since they went bust.)

I think you’d need something more unique to set it out from the crowd, like an infrared transmitter or link cable to enable multiplayer games.

By the way, I just found out about FPSLIC, which is an AVR chip with FGPA capabilities and the capability to run machine code from RAM. I’ve not seen a device with that sort of arrangement before, so the possibilities are interesting.

If that were to be combined with the FX chip, it would make it possible to load functions from the FX chip into RAM and execute them, which opens up a lot of possibilities for game scripting.


Not quite … they are alive again.


Then make that two competators, and no doubt others that I’m unaware of.

Maybe we need to create a new thread with titles like “future arduboy planning” among other things.
Maybe like “[Poll] New Arduboy: AVR or ARM32?”
But from Bateske’s saying, I feel like that he don’t want to be disturbed until the price for these electronics goods return to normal prices (and availability returns to normal)

1 Like

I think Arduboy’s “killer feature” is the monochrome display. I realise many people see it as detrimental to game experience and, as I am not a gamer, I concede that may be so. But we all know that the display is only part of the experience. Otherwise there would be no demand for retro gaming of any kind, with the display technology of today. So if you want to make the screen bigger, either in pixels count or area, that does not seem like a departure from what I perceive to be the key traits of an Arduboy. And for that reason, I would consider pokitto and gamebuino meta less like direct competition.

The flash cart/multi-game part seems to be a very popular feature that should probably remain in any future Arduboy.

I have had the hardware for an IR link in GAMOO since first conceived, as I think it could make Arduboy more fun and also give a real motivation boost to anyone developing their first few games in an educational setting to progress to a wireless multiplayer mode.

Anyway, back to the screen - monochrome (Edit-colours are fine as long as monochrome is the default option is in the libraries to simplify game development for beginners) and fast enough refresh rate without ghosting are my top suggestions. Size that could accommodate 128*64, even if you want a larger playing field or different orientation options is next suggested priority. Below those priorities, daylight readable would be nice but I think the OLEDS do remarkably well, all told.