Okay tweaked the bootloader a bit more. more stable reset for the OLED display, the hardware also gets initialized pretty much the same as in bootPins bootSPI bootOLED and added build support for the official DevKit. The batch make spits out 7 different bootloaders (Arduboy,DevKit and 5 clone variants) Unfortunately I don’t have an original DevKit to test it on.
Anyone with an official DevKit who wan’t to be a guinea pig?
I’ve updated my Arduboy variant package with the bootloader and extra 1K board support.
You can select the Arduboy +1K board that gives you the extra 1K of application space.
You can also burn the new bootloader using the Arduino IDE it also burns the right fuse settings.
Besides Arduboy and clone variants. I’ve also include +1K versions for Leonardo, Micro and Esplora.
In the below image I’ve Burned the Arduboy +1K, ProMicro SH1106 Version using the Arduino IDE on a test ProMicro.
I’m pleased with the end result.
Ohoh old idea is back. Before I had the idea of adding an 64Mbit SPI flash chip (for 256 in 1 games) to an Arduboy (clone) but dropped it because it would require a loader app to download the contents through USB and flash it through a loader app which I find too awkward (and wearsinternal flash faster).
Now I realize I could add support to the bootloader to program the flash chip and add a little loader menu too without using up too much code. But I’m not sure if I should persue this idea or start looking at SD Card support (and definetly loose that 1K freed space) any thoughts?
If it’s for the masses adding additional writes to flash is a no no and the space can be used better for single games not to mention the amount of users unable or unwilling to modify their hardware.
If it’s a personal project then whatever floats your boat but then you might as well be giving clones a thrashing to preserve your Arduboy but once you’ve moved away from actual hardware you might as well go for something completely different like @MLXXXp did with his Arduboy Zero.
I lack the technical knowledge but I’m assuming that SPI Flash would be more practical to implement than cram and cut SD into the existing shell and possibly remove some headaches and bloat dealing with bulky file systems, but would it be possible to redirect the 32u4 to read the spi flash instead of internal flash? removing the need to constantly rewrite internal flash.
If so I would be looking to:
1 Use the 32u4 to give me access to the spi flash from PC over USB and also handle the required redirects when in use.
2 write a PC app that’s capable of building a multi game with menu from existing code if possible and transfer the raw data to the newly installed flash.
From what I have read on other posts most methods suggest using an external storage method to flash the internal flash thus doubling the amount of writes and if any of that above were possible your internal flash would only require an initial flash then everything else would be run on the fly from the external.
Apologies bit of a ramble I’m typing aloud rather than thinking first and posted it…
Exactly, I don’t want to waste a flash cycle for burning a loader. That’s why I added the streaming feature in the bootloader already so a dock doesn’t need to flash a loader.
I’m doing it for my personal enjoyment. But I’m keeping the community in mind because that makes it it much more fun.
It will be tricky to add Arduboy but the case doesn’t need to be modified when using an flash chip in a WSON package. But it will be easy for clones to add.
I like to stick with the atmega32u4. When moving on to a more powerful chip new arduboy sketches won’t work on older Arduboys and you’re basically moving on to a new handheld. I also think there still a lot of potential in the current Arduboy.
unfortunately not. There is no support external memory.
The idea is to extent the read/write block commands in bootloader mode as I did for the OLED display support. The contents of the atmega32u4 isn’t changed in the process.
Yes the idea is to manage the content on a PC/Pi. Each game would get a title screen or one is created by the tool (gamename) and games could be grouped for easier selecting. In the bootloader menu would just step through these screens and when you make your choice it burns the game.
That is correct. However if you want to preserve the contents of the EEPROM after chip erase then you should use 0xD2. I’m going to use that as default in my board package update.
I’m using the feature quite a lot while experimentiong with the USB core and library optimalisations. and it’s a delight to have it.
I’m also so used to the flashing RGB LED in bootloader mode now that at one time I though my Arduboy froze up when the RGB LED didn’t flash before realizing I had just flashed the oldbootloader back for testing
I’m finding that I am having issues uploading a sketch more than once with this build
Sketch uses 29020 bytes (97%) of program storage space. Maximum is 29696 bytes.
Global variables use 1834 bytes (71%) of dynamic memory, leaving 726 bytes for local variables. Maximum is 2560 bytes.
Found programmer: Id = "ARDUBOY"; type = S
Software Version = 1.1; Hardware Version = 1.A
Managed to sueeze out more space of the bootloader. The Arduboy Homebrew bootloader takes currently ~2.63K with read and write flash sector commands added to the bootloader protocol. It’s pretty easy now to burn and dump an 8/16 Mbyte image to the SPI flash chip.
Need to work on a game select/flasher menu now. Basically the idea is to browse through a list of splash/title screens using D pad and flash upon pressing the A button.
Just to let you know, the main post doesn’t have any external links.
You might want to put a link to the repo up so people don’t have to read through the thread to find one.
(And maybe an “I take no responsibility if this thing bricks your unit” just to be safe.)
A few more suggestions while I’m thinking of it:
May I suggest adding a list of the commands that your bootloader supports?
(I originally came here looking to find out if your bootloader supports EEPROM save/restore. It’s probably going to turn out that the original cathy does, but when I think of “cool features” your bootloader comes to mind first :P.)
However, one of the advantages of this bootloader is that it frees up an extra 1K for sketches. If someone wrote an Arduboy game that took advantage of the extra space, it would be too big to fit in an Arduboy with the standard bootloader.
A person who wasn’t informed, could specify that their Arduboy, with the standard bootloader, had the Cathy3K bootloader. If this happened to be one of the ones that was manufactured without the proper bootloader protection fuses set, an oversized sketch could overwrite the bootloader and “brick” the unit.
I realise this isn’t a problem with the actual custom bootloader and package itself, but it’s something that someone should make an effort to prevent.
Just a bit of extra warning to remind people to take precautions and not to go trying it if they aren’t completely sure about the process.
I know most people here aren’t likely to try to blame you but it happens and we do get younger visitors too.
It’s a good project, making sure that people can access the information about it easily will help it get the recognition that it deserves.