Self Bootloading Mod-Chip

No, I like the idea of the logo, I hate the big fat pool noodle logo and the fact it’s just sliding down like the gameboy logo. I honestly felt it had a lot more style when it was just plain text Arduboy sliding down TBH.

But, for most of your reasons you listed, yeah that’s why it’s fine and I don’t pitch too much of a fit about it.

In other news.

@mr.blinky and @mlxxxp were discussing the use of the secret EEPROM location to store the power-on menu toggle bit, and I haven’t been following along closely but it seems there may be the potential for this memory location to be susceptible to brown out corruption. Maybe it’s just a totally isolated incident but I was fiddling with an Arduboy FX prototype power switch doing some testing rapid power cycling and it wouldn’t go back into the menu.

I tried everything to get the menu going, and it was clear the bootloader was still running because holding the down button would keep it there.

Eventually I ran the activator tool and flipped the bit. And that fixed it. That was after I tried all the “normal” ways to clear the EEPROM so obviously, I don’t know how to access it within the scope of a normal sketch.

So, I’m going to do more testing, but I don’t know if we need to consider that might be why the bit is reserved is because some times it glitches out?

ALSO: I was playing super crate buino, which is a port of a gamebuino game so I don’t know… is that game doing something funky with the EEPROM bit because it’s a different target?

Just got the current Goldcart running on the Arduboy with the new [ hold up + down reset ] feature implemented, and I got to say this seems almost like a totally new device. There are so many games on here to explore and check out. And that’s saying something because I run the show here and I’m STILL finding games I haven’t played before that are pretty cool.

Thanks everyone for your games and contributions, this is awesome.

Just ordered the board… can’t wait :slight_smile:
btw, is there an option to order the FX engraved backplate only?

The logo is just a bitmap in the library. If you would like it changed to something different (preferably still 88 x 16 pixels), I’m open to it. Maybe have a contest/poll? Simply recompiling any existing sketch, using the new version of the Arduboy2 library, would then cause it to adopt the new logo.

That could be changed too, but it would be best if any new technique used no more program and RAM space than the exiting one, so as not to break any current sketches that are on the limit.

There’s also a (I suspect extremely slight) chance that a sketch or library has used the library bootLogoShell() function and thus could have problems if the scrolling down is changed to something else, depending on what the new technique is.

@Mr.Blinky and I did discuss this in comments for a GitHub PR he created. If there really is a problem, I’d like to see hard evidence that address 0 is more susceptible to it than any other EEPROM location.

The SetSystemEEPROM sketch is able to clear system EEPROM (address 0 - 15), including the FX bit, back to factory default (all 0xFF).
File > Examples > Arduboy2 > SetSystemEEPROM

@bateske has spoken (PM). When powering on with the menu or the last burned game is no longer decided by an EEPROM flag. Instead the startup method is hardcoded into the bootloader.

The activation sketch now will let you choose which startup method you want and flashes the modchip firmware accordingly.



Cool - but why? Because of an abundance of caution over byte 0 in EEPROM?
Just curious :slight_smile:

There are quite a bunch of games that corrupt the EEPROM setting. After playing one of those games Arduboy suddenly won’t power up into the menu again. This is very confusing to the user.

By hardcoding the option. It is more reliable and saves a lot of work (adapting the games and customer support for example.)

1 Like

You still have the problem with library system EEPROM settings, so it’s best not to run those sketches until they’re fixed, even with this change.

1 Like

Is that happening? I’ve given up on EEPROM management, nobody wants to take it seriously.

But the impact of of that is less severe then a non starting menu. Still it would be nice if those problematic games were adapted. I’ll leave it to other community members to look into that.

I don’t know, but until they are, I wouldn’t include any of them on the Goldcart.

I’ve tried to further dissuade people from doing this by changing the heading in the Arduboy2 library README:

Maybe we could also create a topic in this forum (in addition to the spreadsheet) with a list of all known sketches that need EEPROM fixing. If anyone wanted to tackle fixing some (licence allowing) and did so, we could mark them as fixed and either get the original updated or provide a link to the fixed version. Even if none get fixed, at least we have a reference if someone complains of symptoms that are indicative of this.


I’ll still leave address 0 as “reserved for bootloader”. Who knows, you may find it useful for flags for other not-so-critical features in the future.

:cricket: :cricket: :cricket:

Maybe the next game jam should be fix the EEPROM on your old games.

Do you have any examples?

I genuinely can’t remember the last time I saw a game that was overwriting the Arduboy2 reserved area of EEPROM.
(Not counting the one included with the Arduboy2 library that’s actually supposed to be doing it, of course.)

What about all the people who actually bother to pick a randomish offset into EEPROM to assist with wear levelling?
And those spreadsheets that @Mr.Blinky and @acedent created?
I wouldn’t call that ‘nobody’.

If there’s that many games overwriting the settings that it’s an active problem, just offer up an incentive for helping to fix the problem - nobody wants to throw themselves at a thankless menial task.

Make a badge for it or something, everyone likes badges, especially badges awarded for being helpful.

I’d give it a go myself, but like I say,
I can’t even remember the last time I saw a game overwriting the reserved part of EEPROM.
(I don’t tend to actually get around to playing that many games,
I mainly just skim the code and get back to what I was doing.)

There are quite a few listed in the spreadsheet. Many appear to be ports of Gamebuino games, which I assume must start at address 0 by default.

When not putting them on they will easily get out of sight again (these games have been around for a while) and be forgotten. Putting them on the cart keeps them in sight with a better chance they get fixed eventually.

They’re colored red in this spreadsheet

Hence my suggestion they be put in a forum topic.

Nice got linked on Hackaday! Thanks @Mr.Blinky for all your hard work and help on this!


Is it possible to upload new games to the external flash chip?

Yes you can put together your own compilation of games and flash them.