The game is a great game i’ll admit that but for me it gave me a huge bug that was a pain to fix. Basically once the game is flashed onto the arduboy, it cause the arduboy not to be recognized by any computer what so ever, No matter if it was linux or windows. My work around was hitting the reset button and flashing a new game while the screen was black and it was being detected by the computer. Overall great game but a few bugs need to be fixed
Did you read the note about that in the original post in this topic?
Oh no I didn’t see that at all, sorry this is my first day with the Arduboy. Thanks so much for the info that helps alot!
There’s a few other games like this that had to strip out the USB library for space.
Holding up seems to be the defacto-standard way to force bootloader mode.
I think the new bootloader is fixing that.
No, holding the DOWN button is the defacto standard if the sketch removes the USB code.
The UP button is used to enter “flashlight” mode, which can be used to fix a bootloader problem if the USB stack is left included in the sketch.
Can you post the source code so I can run this game on my homemade Arduboy with a custom screen?
I believe this is a closed source game.
I was looking at your (reversed) game code for EEPROM usage and found that Starduino uses 13 bytes starting at EEPROM location 16.
I also noticed that at some point you write to EEPROM location 12. I presume you intended to write to EEPROM location 16+12 ?
Could be. I’ll check when I get home.
Found it in the audio on/off setting in the menu.
DAAAAAMN YOU LINE 904!!
. * shakes fist angrily *
whee! 871 sources…
Going to repackage the game as soon as I can with the fix, probably this weekend.
Great. Do you think you could also add the pressing UP + DOWN for 2 seconds to enter bootloader feature ?
I will try to find space for it.
Might have to ugly-hack it a bit and borrow the space for the main function’s return address on the stack or an unused IO register to store a byte to count 120 frames of holding the keys.
Also would need permission to include in the FX cart per the license.
I’ve added the hold up+down for reset.
While I’m in there before I go through the work of repackaging the update do we want to move the savegame area elsewhere?
I can do a separate FX build but it’d be confusing so I’ll just make the official package use whatever EEPROM range works best for the FX cart.
@bateske Alternatively, if we had some way to tell the tool how to patch the PGM ROM to change the EEPROM range so people can pick a bunch of .hex and let the tool relocate the EEPROMs without having to go through the trouble of recompiling all the games to build a custom set without conflicts every time they want to change their set.
We just need a few bytes of PGM ROM to tag a struct with the size needed, and the base-offset, and a checksum just to avoid false hits.
Or some metadata INI/XML/whatever file to tell the tool where to patch that PGM variable that could be automatically generated from the map file.
@Mr.Blinky is the genius behind all of this I don’t know much of anything other than it works and it’s awesome.
11 posts were merged into an existing topic: Shared EEPROM storage management across multiple apps
The best I can think of is a small EEPROM library where save function is in (or has some) assemly. so it isn’t ‘optimized’ by the compiler and the assembly could also be the signature.