Uzebox Forums

I would like to improve Uzesynth so that patches could be loaded from SD card and transferred onto the UB via UART.

I thought I would attempt adding the SD card support first so my plan was to borrow the SD card code from the Bootloader. Bootloader5 seems to be written entirely in AVR asm which I don't understand so I thought I'd try the original bootloader which is mainly written in C but I've not been able to get it to run under cuzebox or uzem. When I run the old Bootloader I just get a black screen. Is this a known bug? It hasn't been reported on github. The new Bootloader runs fine including emulated SD card support.

I realise the old bootloader only supports non SDHC SD cards. Are there any other working open source Uzebox projects with SD card access code written (mainly) in C that I could borrow instead of the old bootloader?

If I'm successful in adding these features to Uzesynth, is it likely they can be merged into the Uzebox repo or is this going to have to be a new demo project (still within the main UB repo) or would it have to be an entirely separate project?

IIRC, the new bootloader provides a compatibility library that gets built with applications so they at least get FAT16 support built-in, if they are run on hardware that doesn't have the new bootloader on it, or if they are run on hardware with the new bootloader, they will have both FAT16 and FAT32 support, and files won't have to be contiguous.

It doesn't have to be written in C to call it from C. My suggestion (the easiest way) would be to use it like it was intended to, include the header file of the compatibility library in your application, and call the functions through that API and it will automatically handle whether it has FAT32 support if running the new bootloader, or fall back to just FAT16 support if running on a Uzebox with the old bootloader. There should be examples provided, but make sure you are looking at the new way to do it. You may have to wade through a bunch of "old ways" to do SD access that aren't this new way. There have been many different versions of SD libraries over the years, but having written FAT12/16/32 code from scratch before, I definitely just recommend you to use the bootlib.h version in your application code, rather than reinvent the wheel yet again.

Ah right! I had no idea about bootlib.h providing FAT support.

I'd be grateful if someone could point me towards some example code.

It should be in your demos directory already.

You can run the command: to find all files that #include bootlib.h, but the project you probably want is in demos/BootDemo/

There is also a forum post about it: https://uzebox.org/forums/viewtopic.php?f=3&t=9521

It is documented on the wiki, both a guide and API reference:
http://uzebox.org/wiki/Bootloader_API_guide
http://uzebox.org/wiki/API_Functions#Bo ... _Functions

You can also look at the code for that project directly on GitHub:
https://github.com/Uzebox/uzebox/blob/m ... BootDemo.c

Another option, if you don't want to depend on the bootloader, is to use the FatFS/PetitFatFS libraries included under the kernel. They support fat 12/16/32 with fragmentation too. For my next project, I couldn't use that feature due to the fact that Cuzebox only supports sector read/write and I didn't have 512 bytes of RAM to spend (PetitFatFS uses streaming and doesn't need a buffer).

That said, if you don't have this limitations, using Jubatian's API is the best way to go since the bootloader is always present in the end. And you'll save some precious flash for your game.

In T2K I am using Jubatians bootloader to do all the housekeeping stuff like

Init the SD card, Do the FAT stuff to find the first sector of a given file name.

Then I just using my only short bit of code to stream the bytes.

That saved me a lot of flash over including all the FAT stuff in the user code. PLUS it supports SDHC which was my main reason for using it.

IIRC, using bootlib.h shouldn't force a dependency on the bootloader. It will always include the code for FAT16 directly in your application, but if the new bootloader is also present, it will automatically and transparently allow the code you wrote against bootlib.h to work with both FAT16 (SDSC cards) and FAT32 (SDHC cards). It is getting harder and harder to even find SDSC cards, so if you don't use FAT32/SDHC aware code, your game may not run if people try to use it with an SDHC card.

The 512 bytes of RAM might be an issue though if you don't have it and aren't able to reuse the space allocated for RAM tiles. At least with Mode 3, the RAM tile memory doesn't get used until ProcessSprites is called, so up until then a game is free to use it for whatever. There are now kernel options you can set so ProcessSprites has to be manually called by the user, so you can know for sure when the RAM tile memory is still available to use.

Artcfox wrote: ↑Sat Feb 04, 2023 7:02 am IIRC, using bootlib.h shouldn't force a dependency on the bootloader. It will always include the code for FAT16 directly in your application, but if the new bootloader is also present, it will automatically and transparently allow the code you wrote against bootlib.h to work with both FAT16 (SDSC cards) and FAT32 (SDHC cards).

Quite interesting and clever then, I did not know this.