Evolution of the SD card API
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Evolution of the SD card API
Ill change them all to say sdCard at the start and rename the whole thing sdCardBase and do another push later today.
Do you want me to add write support to this?
Should we make it do some checking for fragmentation and files size before writing is allowed or should that be up to the full fatfs only ?
Should I add support for "read to buffer" for the full FatFs
Do you want me to add write support to this?
Should we make it do some checking for fragmentation and files size before writing is allowed or should that be up to the full fatfs only ?
Should I add support for "read to buffer" for the full FatFs
Re: Evolution of the SD card API
Good question. Fact is we have lived happilly all those years without write function. And I think it's more things like tools and other novelty programs that will require it. So I'd say, for now, let's have that covered by FatFs and PFF. They also deal with fragmentation so all the hard work is done.Do you want me to add write support to this?
I was thinking in fact that a fragmentation check for reading would be very nice for the user experience. Many people still don't know their card should not be fragmented and I heard many time peoples don't understanding some wonky behavior because of it. A quick function like sdCardCheckFileFragmentation(File) should return 1 if the file is fragmented. The game could then simply display a message to instruct the user to defrag his card before playing.Should we make it do some checking for fragmentation and files size before writing is allowed or should that be up to the full fatfs only ?
Eh, defragmenting it on the fly would be the cream of the crop. But that's another story.
I always expected FatFS to be used for slower things like tools and such, so not sure there would be a benefit so far. (just my 2 cents though)Should I add support for "read to buffer" for the full FatFs
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Evolution of the SD card API
OK - Artcfox helped me make the SD code a little cleaner, closer to spec and more adaptable to extend to SDHC in the future.
I have also changed the name of the functions to all start sdCard and changed the filename to sdBase.s / sdBase.h
https://github.com/andrewm1973/uzebox/t ... ter/kernel
I have also changed the name of the functions to all start sdCard and changed the filename to sdBase.s / sdBase.h
https://github.com/andrewm1973/uzebox/t ... ter/kernel
Re: Evolution of the SD card API
Great! I'll review that and merge it.
Re: Evolution of the SD card API
It seems there are conflicts and I can't merge from Github. I will have to check that tommorow unless you can synchronize with the master branch first and repush a clean PR.
Another thing I noticed, in the videomode14 files, you replaced lots of defines with videmode6 ?
Another thing I noticed, in the videomode14 files, you replaced lots of defines with videmode6 ?
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Evolution of the SD card API
OK - I must have messed up something - I didnt intend for there to be any VideoMode14 stuff or Tornado stuff in that push.
I'll try clean it up
I'll try clean it up
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Evolution of the SD card API
Ok _ think I have pushed a clean version now.
-
- Posts: 1445
- Joined: Mon Feb 11, 2013 8:08 am
- Location: Brisbane, Australia
Re: Evolution of the SD card API
Has anyone started using this SD code yet?
Any feedback / Feature requests ?
Any feedback / Feature requests ?
Re: Evolution of the SD card API
I am working on a scrolling game that might lean on this heavily if I can figure out how to get maps arranged in an efficient way(duplicated horizontal and vertical to avoid seeking around the SD). SD music might be done before that, but it seems what you have is already enough for that one. It is definitely the ticket to the big games that I still think are coming; PFF could did not allow for these things realistically.
Re: Evolution of the SD card API
Noticed that Artcfox had had a problem that games would not start always. There was a similar behaviour on my Euzebox after compiling bootloader from source. After disabling interrupts in flashgame() by removing all sei() statements that problem was fixed. Side effect was that progress bar would not display anymore but that doesn't matter so much as games load so fast anyways