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.nicksen782 wrote: ↑Fri Oct 13, 2017 3:29 pm(...) 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?
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).D3thAdd3r wrote: ↑Fri Oct 13, 2017 6:17 pmHopefully 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.
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.