Uzebox Bootloader V5

[Jubatian]

Another update (5.0.05, download from top post). This might be a little more tolerant with SD cards (ry755's hardware in particular, I am really determined to get it working even there!).

(...) But now I wonder something else. You are saying that we could request SD card access via an API to the bootloader. What if the bootloader could draw the screens? I figure that the bootloader is using one of your specialized video modes and would have it's own kernel. What if we could get it to play multiple frames from either SD or SPIRAM on the game's behalf and then return control back to the game?

No reflashing for this. Could that happen?

I did Video Mode 0 for this. You can even just copy it off from the bootloader's source (in "kernel"), and add it to a normal Uzebox kernel. It will work, you could play around with it. Getting the bootloader's kernel taking over for some screens is not exactly trivial, but I see it might be possible to be done, but that's again something where compatibility with old bootloader Uzeboxes would fail. It isn't very big by the way, the most significant part of the bootloader is the SD card & FAT library.

Hopefully you did not explain it and I just missed by laziness, but how is this used exactly? I think there can be some standard place where a command is sent by user code(that would be the same across different revisions of your bootloader), and then it does these things on the game's behalf. I would not feel shy in the least to lean on this as a requirement for future games using SD, as even just for SD code space saved, it is rather appreciable and helps to drive this bootloader(that I see now as a key Uzebox development) into mainstream.

Soon I will release a kernel component which can use this bootloader's API, with fallbacks to simpler routines (SDSC + FAT16) for old bootloader Uzeboxes (and of course there asking the bootloader to flash a new game is not possible). Otherwise the entry points follow standard C ABI, so you could use them natively by function pointers (see in kernel/uzeboxCore.s, the API entry points are defined there).

EDIT: I realized I made an oversight during API design, nothing game breaker, but will need a new bootloader version (piggy-backing an SD write routine onto the FAT layer is not possible in particular). I will release that likely tomorrow along with the kernel component which could interface the loader.

[ry755]

Woah, that means we can finally have huge, multi-part games! This is awesome, and quite literally a game-changing feature for the Uzebox platform. (Sorry I couldn't resist that one!)

Imagine the epic endings that games could have, and you could even switch video modes if you wanted to! Full-motion video cut scenes like Tomb Raider II between levels to advance the story line?

Advanced games might even be able to write their own .uze file on the fly, and then run it.

If one game is going to have multiple .uze files, I think the bootloader should only show the main or "master" .uze file. That way the user doesn't accidentally load the wrong file, or try to cheat in some way. Or the games could run some check to see if they were called from the main/master .uze file, and throw up an error if not.

[Artcfox]

If one game is going to have multiple .uze files, I think the bootloader should only show the main or "master" .uze file. That way the user doesn't accidentally load the wrong file, or try to cheat in some way. Or the games could run some check to see if they were called from the main/master .uze file, and throw up an error if not.

Yeah, good call. Jubatian said they could all be packed into the data file and you can just pass the offset, which would accomplish that goal, and it wouldn't count against the 255 .uze file limit, and it would meet the suggestion of having one .uze file, and one data file (to not fill up the FAT).

[Jubatian]

Another update (5.0.06, download from top post). In this I fixed many things relating to interfacing the bootloader while preparing an interface library. Also the SD card interfacing again became slightly different.

Attached is the interface library, for now without SD writes, with a demonstration program. It is set up to compile to require the bootloader (note that it demands 5.0.06, it won't use earlier bootloaders), but by commenting out the BOOTLIB_NEED_LOADER definition in the Makefile, you can compile it to include a compatibility package (about 800 bytes) which provides FAT16 support with no fragmentation (SDHC capability is still retained) when a suitable bootloader is not present (so this would be the default if it was included in the kernel). If a suitable bootloader is present (5.0.06 or above), it always uses that (so FAT32 and fragmentation capabilities are there).

When started, it displays stuff and a dump of the first sector of m74sprex.uze, then about 4 seconds later, it requests the bootloader to program this file. It would work too if the .uze file was actually part of another file.

[Jubatian]

Does anyone experience situations when the old bootloader can detect and use a card while this new one can not? (I am still trying to go after what happens on ry775's hardware). An obvious thing could be ancient MMC cards which have no ACMD41 implemented, I am looking for anything beyond that.

[Jubatian]

I did some further work on the interface library, trimming it further, and making it work on Uzem (which doesn't support SD CRC). Now the compatibility layer does a simpler MMC init (the same like the old bootloader does, so should work on hardware having that) which is smaller. It tries to enable CRC, but will mark it disabled if it finds that it is not possible to enable it (that way it works in Uzem while still has CRC checking on real hardware).

It works together with V.5.0.06 or V5.0.07 (or anything above), in V.5.0.06 there were no bugs hindering interfacing (V.5.0.07 mostly added modifications to the bootloader's init).

[uze6666]

Wow, seriously, I barely can follow cuzebox, kernel boost, fix here, fix there and now a new bootloader? Do you ever take time to sleep or eat?

I 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).

For 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?

That said, this looks awesome and is another one of your impressive piece of work done in so little time. Makes me feel ashamed about the months it took me to come up with the current one.

[ry755]

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"

Maybe there can be a special version without the game self-flashing feature, so they can still have SDHC and fragmentation support. Then if they need the self-flashing feature, they can use an ISP to flash the full bootloader. That way, if the Uzebox does somehow brick itself, you know they still have an ISP available to fix it. The "special version" could have a "B" or something after the version number, to distinguish it from the normal version.

(because now you will have games that wont run unless you have bootloader X).

Yeah, that's true. But IMHO having SDHC and fragmentation support is important.

[uze6666]

that way, if the Uzebox does somehow brick itself, you know they still have an ISP available to fix it.

Sorry, I didn't express myself well, I meant burning the chip (i.e. exceed the 10K flash limit).

Yeah, that's true. But IMHO having SDHC and fragmentation support is important.

Agreed. But think that all the regular SD games out there won't work anymore when an SDHC card is plugged in (block addressing is different if I recall). Someone will likely have to recompile games to support both SD and SDHC and hoping the code fits. Or have to maintain two sets of roms (not a nice option IHMO). No show stopper really, just things to consider.

[ry755]

that way, if the Uzebox does somehow brick itself, you know they still have an ISP available to fix it.

Sorry, I didn't express myself well, I meant burning the chip (i.e. exceed the 10K flash limit).

Oh ok. I see what you mean, a bug rewriting a section of flash over and over, making it fail eventually. I guess that's very possible.

Yeah, that's true. But IMHO having SDHC and fragmentation support is important.

Agreed. But think that all the regular SD games out there won't work anymore when an SDHC card is plugged in (block addressing is different if I recall). (...)

Oh yeah... I forgot all about that! That's the reason why I still use a small SD card. And you're right, it would be a pain to have to fix and recompile all the roms. (That is, all the roms that use the sd card)