When will the next Arduboy drop?

I would say SD card will be quite difficult.
It starts with emory blocks I assume. The architecture of the two things are different.
I don’t know :sweat_smile: It is a good thing but if you have enough storage
But I was thinking about memory blocks, 32-bit, 64-bit and 8-bit architecture and the fact that it is NOT EEPROM and issues with read and write-solid state storage is very difficult to tackle with.

And what are you going to do with that card? You CANNOT put source code or even HEX files onto it. The data may not be even a file, as our current Arduboy suggests, and are just a loose collection of data.

A advanced bootloader with double maybe tripled storage sounds good to me, as then you can pick which games to play (unless you own more than one arduboys, you WILL have to bootComputer-plugArduboyIn-OpenArduinoIDE-selectFile-CompileFile-UploadFile-TurnOff-Computer to change things, and that is impossible when, say, you are on the metro.
OR, just make your own. I got my credit-card-size Arduboy last month and now I want a home brew Arduboy on a customized PCB with beefed up buttons and switches, bigger screen (I am good with the resolution, just make the pixels bigger))
But then the board will be different and…man.

No, but you can put level data on it.

If games could load levels from an SD card instead of progmem then certain games would be able to do a lot more (Dark & Under, Circuit Dude, Rogue Boy).


Yes sure you can put DATA onto it…
And yes, that enables level packs.
I thought you are going to ditch the entire on-board storage…
So now it is a fixed drive (like a harddrive on a laptop) with mobile storage like SD cards acting like (USB sticks)
That is cool.
But again, you DO NOT need 8 GB (even the entire Windows XP do not have 8 GB)
Am I seeing things or does Arduino Leonardo ETH come with a micro SD card slot?image

The EEPROM? Or the progmem?

AVR chips are Harvard architecture based, so I don’t think it would be possible to load code from an SD card.

An SD card could be used to save games, but getting rid of EEPROM entirely would be a backwards-compatibility issue.

It does, but it’s “retired”, which I assume means they don’t make them anymore.

It would probably be suitable for an Arduboy clone though (if you managed to find one).

1 Like

Arduino Leonardo ETH:
Sells for the same price as a ready-to-use Arduboy.
Ah. Online junky market. (Chinese market seems to have lots of old stuff. They even have working Atari 2600 s out somewhere)

The main idea is to add SD card support to the bootloader so hex files can be loaded from it and be flashed. as a bonus a sketch could load (level) data or graphics of it. This can be done.

But the flash chip idea is currently my favorite now. which I’ll discuss further in the custom bootloader topic


I Disagree that the Atari 2600 is “Online Junk”


What I want is a transition to a larger, color display like this one:

Or this one if we want to be more reasonable:

I think having a better processor and more storage to drive this more vibrant display would be nice, and SD card support should not be too hard if you just need to read bytes from the pins.

A lot of people have voiced opposition to a colour display.
I don’t know what the official line is.

(I think the answer is probably no because a lot of those features would require making the Arduboy larger than a credit card, which goes against the original idea.)

There was a vote ages ago on this old thread.
(A chunk of the people who said colour actually wanted greyscale.)


Grayscale also seems nice too.

I think a lot of people who ask for colour haven’t realized just how much RAM it would take up. Same for SD card support. :confused:


darn, the bane of any computer nerds existence, ram.

Let’s put some figures on the table:
The 32u4 in the Arduboy has 2560 bytes (2.5KB) of RAM.

Here’s how much RAM you’d need for different screen modes at the same resolution:

  • 128x64@2bpp (4 colours) = 16384 bits (2048 bytes, 2KB)
  • 128x64@4bpp (16 colours) = 32768 bits (4096 bytes, 4KB)
  • 128x64@8bpp (256 colours) = 65536 bits (8192 bytes, 8KB)
  • 128x64@16bpp (65536 colours) = 131072 bits (16384 bytes, 16KB)

To tackle those adafruit screens specifically:

  • 1.27": 128x96@16bpp (65536 colours) = 196608 bits (24576 bytes, 24KB)
  • 1.5": 128x128@16bpp (65536 colours) = 262144 bits (32768 bytes, 32KB)

yeah, thats insane amounts of ram. I think we should use a grayscale display (although still thats ~2kb) Sadly I cannot find one anywhere.

1 Like

Personally, I’m happy with the current monocrome display. A bigger screen would be nice though.

1 Like

After writing a few demos, I find the monochrome display easy to understand. Grey scale or colors is going to make it less minimalist. Being able to select a single color at a time for the entire the display would be nice.

I have no idea what you mean by this.

I think what @jesse means is, using a display like this one but sticking with a monochrome screen buffer, and just being able to choose which two colours represent the mono palette?

Could slow things down though, because you would need to send a lot more data over SPI anyway for a colour display… unless you found one with a parallel interface, and tied a lot of the pins together - enough to give a choice of just a few colours…

In other words 1-bit paletted mode?

Plausible if the screen supports it.
I don’t expect a modern screen would though.


Isn’t coloured film an option for pallets?

In my experience “when” is when the existing product is no longer profitable.