Future Arduboy


@uXe I don’t think stepping down from full speed hardware USB to software low speed USB is the way to go.

That means no more 8-bit gaming sniff :cry:

Rather than jumping on the bandwagon for a more beefed up version how about an Arduboy keychain, XXL version or have anotherlook at the micro card ?

(Scott R) #42

Not what everyone wants to hear but…

If it sells why fix it? I would be building a larger user base rather than new hardware if it’s still selling. Bells and whistles are an endless pit and it’s easier to lose a user base by deprecating their hardware than it is to encourage further investment.


Isn’t the Arduboy 1 bit gaming ? : D
Wait no i’m probably wrong since i’m an electronic pleb and i was only thinking about the display part.
So do we consider Arduboy 8 bit with 1 bit graphics ?

(Pharap) #44

It’s an 8-bit processor with 16-bit memory addressing using 1 bit graphics.
But actually there’s nothing to stop the processor calculating 16, 32 and 64 bit values,
it just takes more instructions and processing power.

Interestingly, the 32u4’s clock speed is nearly 4 times faster than the chip the Gameboy used (16MHz vs 4.19MHz).

CPUs are complicated and hard to compare.


You could actually say 16 times faster as the fastest instructions on the Gameboy take 4 clock cycles vs 1 clock cycle per instruction on atmega32u4.

(Pharap) #46

Yup, and I suspect if you ran tests based on data processing, the 32u4 would process the same data even more than 16 times faster.

As I say, CPUs are complicated.
‘8-bit’ is about as useful for gauging processor power as ‘16Mhz’ is.
You really need the whole picture to make a decent comparison.


Getting back on this. To resolve the missing hardware USB, an ATMEGA32U4 could be added :smiley: basically it would be a micro card (the 1st design with multi MCU) but with the ATMEGA328P replaced by that ATMEGA4809


Seems like that is exactly what Arduino themselves are doing - take a closer look at that board and there is a 32u4! (and an RGB LED?)

After reading a little further seems like the 4809 has the complication of needing to be programmed via ‘UPDI’ rather than good ol’ ICSP… :frowning: So it will be interesting to actually get more details on that new board and how they tackle this…

There is someone already selling their own solution for a 4809 dev board (using an FT2232D Dual USB-UART interface and an ATmega88PA for the UPDI interface):


Looks like somebody already tackled the problem:

(Reltkaine) #52

mightycore 644 based arduboy https://youtu.be/KAAXIuZdp7k

Arduboy2 library
atmega 644 16 MHz(or 20 MHz)
sh1106 (or ssd1306)
6 button tact switch(+2 or more)

(Micah Silverman) #54

I’d love to see a realtime clock that persists even when the unit is off - or, to have that option.

While battery life would take a hit, it would open the possibility to other types of applications.

I recently turned an ArduBoy into a 2fa security token and the only thing that holds it back from being practical is that you have to set the correct date and time each time you turn the ArduBoy on:

(Josh Goebel) #55

Yeah, that’s what everyone forgets about. For one, you lose 512 bytes just to buffer writes to the SD card. That’s not counting the other RAM expenses of the SDFat library, etc. You probably could make a slower library that only did reads for actual app usage - but best bet might be the games don’t try and touch the SD - that it’s only used for reflashing new games. Luckily the “app switcher” would be it’s own ROM… so the real question is whether you can fit the code to reflash the “app switcher” in the bootloader.

Of course you could also do magic such as only allowing IO in-between frames and using the “VRAM” as your disk buffer. That helps with the RAM situation, but not the code space situation.

Worse case if it came down to it I think you could require a specially formatted SD card - that had the app switcher binary in hard-coded sectors (allocated properly in FAT)… so that the bootloader could just do straight IO off the SD card to reflash the app switcher (which would have fuller SD/FAT support for reading the filesystem). Then you only have to squeeze the SDCard IO code into the bootloader.