Sure, but if the reset occurs outside that window, the magic number could still end up being clobbered.
I’m not sure about detecting the interrupt. It may be possible but I haven’t looked into it.
You might be able to check if the magic number has been set before starting each frame render and if it has then do:
It may be that the best you can do is add a menu item for “upload mode” that would put the game into the “safe” state above.
Otherwise, you could just document the fact that this game may require flashlight mode. Since it’s more or less unpredictable which games will require it, it’s pretty much an Arduboy fact of life. We should resign to striving to educate everyone about it.
Having to use flashlight mode is really not much different than having to hold Down for games that have the USB code removed.
And if you wanted, you could start shipping Arduboys with a modified bootloader that fixes the problem. You could also offer this bootloader for people to install on existing Arduboys if they have the equipment and skills to do it.
It’s a good suggestion, but… there are a lot of particles.
Once I post the game you can help me try to squeeze it if you want to laugh at my garbage coding skills. I’m certain there is a lot of room for improvement. I’m actually pretty pleased with how fast this game came together, it only took me 3 days!
Can someone explain why using too much RAM causes this situation and what the magic number is all about? I just sort of accepted it as part of developing for Arduboy but like to understand what the issue is
The PC triggers a reset to bootloader by turning off and on the serial port for a certain amount of time (500ms I think).
This is done by a interrupt routine that is watching the serial port, and what it does is set a value in ram at location 0x0800 to 0x7777 (30583 in decimal). And then resets.
The bootloader checks memory location 0x0800 for 0x7777 (the magic number) and if it is found, then it triggers the upload, otherwise it just loads the program.
So if you have a game that is using location 0x0800 for something else, and changes the value between the time the interrupt is triggered and the reset actually occurs, then the boot loader does not see the value and it won’t upload.
This should have been at the end of memory space… if you had only 2k of memory. Whoever wrote the catarina bootloader wasn’t paying attention (or had ulterior motives) to the fact you actually have 2.5k of memory so this ends up being like 82% (I think) of memory which is when you get this warning from arduino:
(It didn’t use to give this warning, this is an admission of the problem)
Actually, arduino even called out the Arduboy in a patch to the software, to move the magic number all the way out to the end of memory, but never actually implemented it in the bootloader. This “New Bootloader” that is mentioned in their blog post is vaporware. (Or we were intended to make it on our own, I assumed they meant the most recent one included in the package at the time, so I used that without reading the code)
Actually, if this is still valid, we could solve the problem for every game except for those using the very last 4 bytes of ram.
Actually I fixed this very early when I started working on my custom bootloader. But recently I removed the magic key check and a WDT reset will always trigger the bootloader menu. The lufa signature is still present so the USB code will store the magic key at end of ram preventing corrupted variables or stack at 0x800 in case of a false positive.