Evolution of the SD card API

Topics related to the API, programming discussions & questions, coding tips, bugs, etc. should go here.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Evolution of the SD card API

Post by CunningFellow »

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
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Evolution of the SD card API

Post by uze6666 »

Do you want me to add write support to this?
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.
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 ?
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.

Eh, defragmenting it on the fly would be the cream of the crop. But that's another story. :P
Should I add support for "read to buffer" for the full FatFs
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)
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Evolution of the SD card API

Post by CunningFellow »

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
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Evolution of the SD card API

Post by uze6666 »

Great! I'll review that and merge it.
User avatar
uze6666
Site Admin
Posts: 4801
Joined: Tue Aug 12, 2008 9:13 pm
Location: Montreal, Canada
Contact:

Re: Evolution of the SD card API

Post by uze6666 »

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 ?
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Evolution of the SD card API

Post by CunningFellow »

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
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Evolution of the SD card API

Post by CunningFellow »

Ok _ think I have pushed a clean version now.
CunningFellow
Posts: 1445
Joined: Mon Feb 11, 2013 8:08 am
Location: Brisbane, Australia

Re: Evolution of the SD card API

Post by CunningFellow »

Has anyone started using this SD code yet?

Any feedback / Feature requests ?
User avatar
D3thAdd3r
Posts: 3221
Joined: Wed Apr 29, 2009 10:00 am
Location: Minneapolis, United States

Re: Evolution of the SD card API

Post by D3thAdd3r »

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.
xiaolong
Posts: 12
Joined: Thu Nov 19, 2015 7:40 am

Re: Evolution of the SD card API

Post by xiaolong »

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 :)
Post Reply