Bootloader API library with SDHC and FAT32

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Bootloader API library with SDHC and FAT32

Post by Artcfox »

Jubatian wrote: Tue Apr 10, 2018 6:52 pm By the way you could even build your .uze file to include game data and saves. Neither the old or the new bootloader checks actual file size anyhow, they flash the game by the information in the first sector. So you can add extra data beyond the game which you could access directly by filesystem functions.
Very interesting idea!
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Bootloader API library with SDHC and FAT32

Post by CunningFellow »

Can I please say don't do this unless some standard is agreed upon that will allow the Uze format to grow.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Bootloader API library with SDHC and FAT32

Post by Artcfox »

CunningFellow wrote: Tue Apr 10, 2018 10:40 pm Can I please say don't do this unless some standard is agreed upon that will allow the Uze format to grow.
Oh. I didn't think about that. Especially if we can get the bigger AVR chip working that has double the flash space. We'd still want the games to be source backwards compatible.
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Bootloader API library with SDHC and FAT32

Post by D3thAdd3r »

Maybe 64k of padding after the rom, if one is trying to be 1284 compatible and have extra data. Would be a lot cleaner to have it all in 1 file either way.
User avatar
Artcfox
Posts: 1382
Joined: Thu Jun 04, 2015 5:35 pm
Contact:

Re: Bootloader API library with SDHC and FAT32

Post by Artcfox »

Artcfox wrote: Tue Apr 10, 2018 12:33 pm I just made a one-off to test write support, and from what I tested in the emulator (writing, moving to the next sector, writing again) it works great! :D This will definitely come in handy for saving states that are too large for the EEPROM.

Hopefully I get a chance to test it on real hardware tonight, but my vote is to merge it into the master branch.
I just tested write support on real hardware, and it works great! Thanks Jubatian!
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Bootloader API library with SDHC and FAT32

Post by Jubatian »

CunningFellow wrote: Tue Apr 10, 2018 10:40 pmCan I please say don't do this unless some standard is agreed upon that will allow the Uze format to grow.
I don't think there is any need for standardization here. The only thing to note is that whoever does this must not add stuff to the first sector (which is, and needs to remain wholly standardized). Otherwise it is your own problem if you package your game so you can't expand it later (I mean it can't affect anyone else).

From the point of bootloaders it is indifferent as they can't accept any significant new feature (there is no room to add any), much less anything which could make any use of data beyond the game binary. Standardized descriptors could be added in the first sector, but the technique could be used without any, and those descriptors would be only available to the game anyway.

If you could think about some useful kernel support for accessing such extra game data, then standardizing related elements added to the first sector could be useful. But I think that would only be really useful for SPI RAM games as you keep trying to bypass even the bootloader API to get things done faster with the card (eh, 4K RAM is 4K RAM, true ...). The point is that since SD access itself tends to be brewed for the particular game, I don't predict significant uses for such a filesystem access library.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Bootloader API library with SDHC and FAT32

Post by CunningFellow »

I am not advocating standardized custom data area for games, but standardize how the start of that custom data is located.

Have just after the binary a pointer to where custom data starts. This would be the next 512 byte sector if nothing can ever be added. If however the Uze format does gain extra features in the future then that pointer can point to the next 512 bytes after the new data.

Adding the pointer to the "User data area" wont break anything in the future. Not having something like that means it is not future proof.

Its a fairly standard/common way for file formats to do things. TIFF, MP3, FLAC all do something similar.

BTW - My idea is to have 32x32 pixel animated images of the games play (possibly with sound on the loop) on the screen as each game is selected.

I think it might be possible with a few code size optimizing runs to get that to fit into the bootloader.
User avatar
Jubatian
Posts: 1561
Joined: Thu Oct 01, 2015 9:44 pm
Location: Hungary
Contact:

Re: Bootloader API library with SDHC and FAT32

Post by Jubatian »

CunningFellow wrote: Wed Apr 11, 2018 9:53 amI think it might be possible with a few code size optimizing runs to get that to fit into the bootloader.
Sure. :lol: (Even the video mode isn't quite fitting for this, I would say such a feature could take at least some 500 bytes)

Anyway the idea is sound, I think I will propose some header extensions then for data pointers. I don't think it even has any documentation anywhere except within comments in the old bootloader. Still, if such a feature is added (animation), that is which needs standardizing, existing games adding extra data to the UZE file would keep being functional as they were before (if you add such a feature, you must add it so existing UZEs are still OK. The extra data could only break compatibility if the new feature depended on the UZE file's actual size, which is a bad practice anyway). What a "nonstandard" extra data could make difficult is modifying such a game to be able to use the newer UZE features which required additional data (unless that additional data could be located at the end of the extra data).
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Bootloader API library with SDHC and FAT32

Post by CunningFellow »

Jubatian wrote: Wed Apr 11, 2018 10:43 am
CunningFellow wrote: Wed Apr 11, 2018 9:53 amI think it might be possible with a few code size optimizing runs to get that to fit into the bootloader.
Sure. :lol: (Even the video mode isn't quite fitting for this,
I was assuming there would need to be video mode changes to allow SD loaded RAMTiles
Jubatian wrote: Wed Apr 11, 2018 10:43 amI would say such a feature could take at least some 500 bytes)
I am always up for a good challenge :)
User avatar
nicksen782
Posts: 714
Joined: Wed Feb 01, 2012 8:23 pm
Location: Detroit, United States
Contact:

Re: Bootloader API library with SDHC and FAT32

Post by nicksen782 »

I used this with SD Simple:

Code: Select all

	sdCardCueSectorAddress( (SPIRAMSR) + i );
	sdCardDirectRead(ram_tiles, 512UL, 0, 0);
	sdCardStopTransmission();
The data returned assumed no fragmentation. I would then write the data to SPIRAM. So, I would only need to read from the SD Card one time. However, I would like read from SD multiple times to replace data already in SPIRAM and I would need to pull certain parts of my SD datafile into SPIRAM.

Let's say that the file started at a position such as 0x0000 and whatever data I wanted was at 0x0100 (on a sector boundary.) I would organize my data to always start on a multiple of 512 for each main section but what about sub-sections? Perhaps the data for a screen takes up 100 bytes and I want to read the data for screen 3. With SD Simple I would cue the sector closest to the address that I want and then I would skip bytes up until the data that I actually want.

How to do this with the new bootlib api? I read the example code what I'm not certain if I should be working with sectors, clusters, or actual byte addresses within a file (or within the entire SD itself.) I'm not certain.
Post Reply