True, I also had this concern when developing it and deciding on what to expose to the user. I am open for some discussion on it, and maybe I will drop it. Personally I don't really like the idea and wouldn't use it myself.uze6666 wrote: ↑Wed Nov 01, 2017 3:45 amI don't want to tone down the overall excellent work, but I'm not fond about the part about allowing a game to flash sectors (if I've read correctly).This makes me quite nervous that a bug in a game (or even on purpose) could brick a chip in no time. As a kit seller, what will I do if peoples ran into such a problematic game? Put a disclaimer to run games at your own perils? Take the hit and send them new chips? It's a risk I was never willing to take. If this is allowed, sadly, I won't be able to use that new bootloader on my kits (and include any games that requires it obviously). My two cents would be to drop this feature for the greater good and avoid "market fragmentation" (because now you will have games that wont run unless you have bootloader X).
My end decision was the following API which is currently tested and works:
The game can request the bootloader to program a new game image. This can be a .uze file as-is, or the complete image of a .uze file within another file. So if the game calls this, the game ends, actually doing a "soft-reboot" into the bootloader, which programs a complete new game. So this isn't as versatile as a page program interface, thus because of its limitations (you can't normally take state across unless you save it somewhere and restore), it needs more consideration for using right. It also makes it a bit more difficult for a single game to goof up and perpetually ask programming stuff (if it keeps asking programming itself, the bootloader will happily do nothing and restart the game, otherwise what it programs is a different game, so it is not very trivial to set up a "ROM killer chain" in this manner).
The API library example I posted above has an appropriate compatibility layer, so the compiled game using it works fine with all the emulators and existing bootloaders (or no bootloader). If it can't detect the new bootloader (it has a signature and version info embedded in its binary), it uses the same MMC code which I found in the original bootloader to interface the card, using a simple no fragmentation FAT-16 layer on top of it (this is smaller than a stand-alone SDHC + FAT32 + fragmentation capable library). The only plus it has is CRC checking if it can turn it on (but it can accept it not being available to keep working on Uzem). So games using this SD library would work fine on all existing Uzeboxes and emulators.uze6666 wrote: ↑Wed Nov 01, 2017 3:45 amFor the SD API part, the fallback code is essential. To keep all games backward compatible with all existing kits that runs the 'old' bootloader. Btw, how is it going to work with the emulators? How do they know what bootloader to use? Yiou would not have choice? Could it be a better idea to link the dependency bootloader at the end of game so it's self contained and could "just run" in the emulators?
Sadly I can't do anything with old games coded to use SDSC + FAT16, of course they won't work if you have the new bootloader and put them on an SDHC card or one with FAT32. Of course you are free to use a FAT16 formatted SDSC card with the new bootloader.
Thanks for feedback on this by the way!