It’s clear that Arduboy needs more memory, and a lot of people have asked for an SD card to be included in the next version to store games there, but…
A micro SD card may change everything.
Right now Arduboy is just a glorified Arduino Leonardo. It doesn’t have a system, just the Arduboy bootloader to load compiled games (made using Arduboy specific libraries). The bootloader allows you to put new games, but when you do it and disconnect it from the computer, it’s set there, and you can’t change it without connecting it again. To load the games you either need the Arduino IDE or one of the loaders developed by members of the community that can connect with the Arduboy and send it the files.
But if an SD card comes into play, then the paradigm needs to change.
Instead of compiling the games and sending them to Arduboy’s memory using a PC and a loader/IDE, a system needs to be developed to allow Arduboy to read the SD card file system and load the games it has there. It will need a GUI too, so at least part of the internal memory will be dedicated to this system, leaving the rest for the game. Arduboy, instead of a single game gadget, may become a full fledged portable console, similar to one of it’s big cousins, and the micro SD card will be like the cartridges used by these consoles.
Is this the ways Arduboy is going? Will we see Arduboy OS sometime in the future?
I’d love to see where everything goes from here (and if a GUI is needed, I hope I can help with it )
The boggle I see with going with the SD card solution is you can no longer just press compile/upload and instantly see your results. You’d have to plug the sd card into your computer, move over a hex file, eject the sd card from your computer, put it into the new arduboy, then select the game from the menu.
I would really hope we can find a way to get SD card and still retain the ability to flash via usb.
It still could. The extra flash space available in a processor such as the ATSAMD21G18 would allow for a larger bootloader which could contain a sketch loader menu. We’re still not talking about a full blown O/S though.
Well, there is more memory, but still the amount of size that can be dedicated to the boot loader is restricted.
The Gamebuino is based on the arduino uno, so the USB to serial is handled on a separate chip freeing up a lot of space in the bootloader for the SD transfer. At least on the 32u4 nearly the entire bootloader space of 4k is already used.
So, I guess the first step is to see how big the arduino bootloader for the SAMD21 is.
I’m having trouble reading the hex file, it looks like it might be 6k? that doesn’t seem right.
Yes, the current Arduino Zero bootloader is a bit above 6K bytes. The maximum size that can be protected for a bootloader is 32K, so plenty of space.
However, for a sketch selection menu, it may be better to put it in the library instead of the bootloader. It could work much like the “system control” (for sound muting) and “flashlight” modes that are in the Arduboy2 library. You would hold a button during boot, which would invoke the sketch selection menu. If you didn’t hold the button, it would just run the currently loaded sketch.
By putting this menu in the library instead of the bootloader, you could modify it to fix bugs or add enhancements by releasing a newer library version. If you put it in the bootloader, it’s pretty much “cast in stone” because most users wouldn’t have the ICE, or equivalent, required to burn a new bootloader. We just have to make sure that every Arduboy sketch uses the '“official” library, or one that contains equivalent sketch select/load capability.
Another advantage of putting the menu in the library is that different versions could be made available. A sketch with enough free memory could tell the library to use a fancy version with lots of bells and whistles. A sketch that needed as much flash as possible could select a “bare bones” low memory footprint menu. And, keep in mind that flash size isn’t as much a problem when a sketch itself can load maps, overlays, etc. from the SD card.
Even if the odd sketch didn’t include the selection menu, it could always be replaced by one that does using a standard USB upload via the bootloader. We could even add a minimal SD loader in the bootloader itself that just looked for a specific file and loaded it. That file would be just a loader menu sketch and could be kept on a separate “recovery” SD card.
Still think this is very short sighted. If you want put a BASIC SD loader in the bootloader that provides functionality even if you’re using whatever sketch. If there proves for be a TERRIBLE bug with that then people can just switch to using one build into the library - but at least you have it there if you need it one day.
Really the “OS” should be on the SD card… so the bootloader just needs enough code to find the “boot.hex” file on the SD card, flash that, and run that… wouldn’t this solve all issues? Now the core is easily upgradable (copy in a new boot.hex) and yet the critical functionality is also in the bootloader - you can boot to the menu no matter what sketch is uploaded.