gbadev.org forum archive

I have created this thread to try to keep all FAT library related issues together. If you have any queries or bug reports, please post them here. Thanks.

Get my version of the FAT library from here.

I will also post updates to this thread.

Mod changed the subject from "Official FAT library thread". Though the original subject was intended to be parsed as (Official ((FAT library) thread)), it could be parsed as ((Official (FAT library)) thread) meaning a library provided by Nintendo for reading Nitro-FAT filesystems on DS cards, and use of Nintendo's official libraries is generally off-topic on forum.gbadev.org.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Last edited by chishm on Tue Mar 07, 2006 1:52 am; edited 3 times in total

Speaking of updates, I have fixed the fseek bug reported by MoonLight.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

the link doesnt work....

edit: does now :)

does not...

Only a minor thing but I've noticed that theres a mistake in the readme

Quote:

insert #include "gba_nds_cf/gba_nds_cf.h" into your project where you need compact flash access. Make sure you compile the included code by adding the gba_nds_cf directory to your sources.

theres no such file as gba_nds_cf :)

Ah yes, that is meant to be "gba_nds_fat/gba_nds_fat.h".

Also, if the direct link doesn't work, try going through my web page.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Last edited by chishm on Mon Mar 20, 2006 3:30 am; edited 1 time in total

As the company behind the SC has released source code to access the CF card, you can now modify the compact_flash.h to read from the SC (CF):

It should work, alltho i didn't test it.

Edit the (single) lines and add the function shown below:

Code:

[...]

// cf host type
enum CF_HOST_TYPE {CF_HOST_NOTTESTED, CF_HOST_GBAMP, CF_HOST_M3, CF_HOST_SC} cfHost = CF_HOST_NOTTESTED;

[...]

/*-----------------------------------------------------------------
SC_Unlock
Returns true if SuperCard was unlocked, false if failed
Added by MightyMax
-----------------------------------------------------------------*/
_CODE_IN_RAM bool SC_Unlock(void)
{
*(volatile short *)0x09FFFFFE = 0xA55A ;
*(volatile short *)0x09FFFFFE = 0xA55A ;
*(volatile short *)0x09FFFFFE = 0x3 ;
*(volatile short *)0x09FFFFFE = 0x3 ;
// provoke a ready reply
*(volatile unsigned short *)0x098C0000 = 0x50 ;
// is it ready ?
return (*(volatile unsigned short *)0x098C0000==0x50) ;
}
[...]

_CODE_IN_RAM bool CF_IsInserted (void)
{

[...]

cfHost = M3_Unlock() ? CF_HOST_M3 : SC_Unlock() ? CF_HOST_SC : CF_HOST_GBAMP ;

[...]

That's if i understood it right. Some weirdness i'm ignoring atm is that the released source once reads the status from 0x098C0000 and once from 0x099C0000. I just kept our notation here.

Have fun!

:edit: Typo fixed:p

:edit^2:
whoops thanks pepsiman, was complete
wrong there :/
_________________
GBAMP Multiboot

Last edited by Mighty Max on Thu Oct 20, 2005 12:26 pm; edited 3 times in total

Mighty Max wrote:

Code:

*(volatile short *)0xF09FFFFE = 0xA55A ;

My translation of:

Code:

mvn r0,#0x0F6000000
sub r0,r0,#0x01

is:

Code:

r0 = 0x09ffffff
r0 = 0x09ffffff - 1 = 0x09fffffe

Where does 0xF09FFFFE come from?

Awesome work guys.

I keep delaying integrating this code into libnds on the promise of proper stdio file support (*pokes* wntrmute).

Plans to add support for gbfs and nds file system (automated support)?. ;) Or does it depend on FAT?

Hopefully Mk2s start shipping soon and we can get those working as well (by we, I mean people who are not me). Sure would be nice to build file based apps for any device that did not have to be recompiled for each one.
_________________
www.drunkencoders.com

dovoto wrote:

I keep delaying integrating this code into libnds on the promise of proper stdio file support (*pokes* wntrmute).

Problem that I've found is that if you bring in stdio, it appears that you bring in the floating-point version of the printf engine (printf, fprintf, sprintf) and not the integer version (iprintf, fiprintf, siprintf). This brings in the whole 40 KB floating-point emulation library, which is significant especially on GBA. At least consoleInit() from libgba has this problem, and for this reason my GBAMP compatible demos will probably use something lightweight such as AGBTTY and not the libgba/libnds built-in console code.

Quote:

Plans to add support for gbfs and nds file system (automated support)?. ;) Or does it depend on FAT?

The current GBFS uses 16-byte clusters, which doesn't mesh well with memory technologies that expect 512-byte sectors. And by "nds file system" do you mean the "Nitro FAT" file system used on most official Nintendo DS game cards? If so, what's the point of accessing that, other than for dumping proprietary DS games?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tepples wrote:

Problem that I've found is that if you bring in stdio, it appears that you bring in the floating-point version of the printf engine (printf, fprintf, sprintf) and not the integer version (iprintf, fiprintf, siprintf). This brings in the whole 40 KB floating-point emulation library, which is significant especially on GBA. At least consoleInit() from libgba has this problem, and for this reason my GBAMP compatible demos will probably use something lightweight such as AGBTTY and not the libgba/libnds built-in console code.

Good point, this was originaly why i had custom printf in libnds, but I was over-ruled...apperantly people wanted "working" code or some such sillyness ;)

The rest of this discussion was split off to this topic.

Quote:

The current GBFS uses 16-byte clusters, which doesn't mesh well with memory technologies that expect 512-byte sectors. And by "nds file system" do you mean the "Nitro FAT" file system used on most official Nintendo DS game cards? If so, what's the point of accessing that, other than for dumping proprietary DS games?

The nitro fat system is allready built into the tool chain (ie you can pass a directory to the dsbuild and it will construct the filesystem for you). Since this is the official format it would make it easier for people who plan on porting their data to the official sdk someday (even though the actual migration of such data happens very rarely). Dumping roms is simple, there are allready tools to do this and to parse the files.
_________________
www.drunkencoders.com

Hmm,

i still got problems writing to the CF (FAT32 formatted).

Code:

      FAT_FILE *f = FAT_fopen(filename,"w") ;
      FAT_fwrite(buffer,1,size,f) ;
      FAT_fseek(f,0,SEEK_SET) ;
      FAT_fclose(f) ;

Creates the file, it shows up in the folder under windows, but as soon i want to read it, i get read errors. chkdsk /F can repair about one third of the file.

(54,0kB of 134kB)

Same on a FAT16 formated.

Chkdsk outputs: (caution german)

Code:

C:\dsgba>chkdsk f: /F
Der Typ des Dateisystems ist FAT32.
Volumenummer: F405-D31E
Dateien und Ordner werden ?berpr?ft...
Der Eintrag \_BOOT_MP.nds enth?lt eine fehlerhafte Verkn?pfung.
Die Gr??e des Eintrags \_BOOT_MP.nds ist ung?ltig.
Der Eintrag \mb_data\apps\dsgba\TMP.DAT enth?lt eine fehlerhafte Verkn?pfung.
Die Gr??e des Eintrags \mb_data\apps\dsgba\TMP.DAT ist ung?ltig.
Die Datei- und Ordner?berpr?fung ist abgeschlossen.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2945 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2946 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2947 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2948 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2949 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2950 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2951 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2952 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2953 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2954 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2955 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2956 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2957 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2958 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2959 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2960 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2961 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2962 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2963 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2964 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2965 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2966 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2967 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2968 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2969 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2970 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2971 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2972 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2973 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2974 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2976 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2977 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2978 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2979 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2980 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2981 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2982 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2983 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2984 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2985 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2986 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2987 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2988 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2989 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2990 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2991 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2992 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2993 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2994 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2995 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2996 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2997 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2998 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 2999 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3000 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3001 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3002 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3003 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3004 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3005 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3006 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3007 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3008 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3009 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3010 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3011 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3012 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3013 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3014 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3015 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3016 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3017 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3018 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3019 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3020 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3021 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3022 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3023 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3024 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3025 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3026 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3027 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3028 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3029 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3030 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3031 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3032 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3033 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3034 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3035 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3036 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3037 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3038 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3039 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3040 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3041 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3042 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3043 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3044 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3045 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3046 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3047 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3048 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3049 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3050 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3051 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3052 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3053 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3054 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3055 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3056 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3057 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3058 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3059 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3060 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3061 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3062 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3063 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3064 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3065 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3066 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3067 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3068 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3069 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3070 berichtigt.
Fehlerhafte Verkn?pfungen in verlorener Kette in Cluster 3071 berichtigt.
Verlorene Ketten in Dateien umwandeln (J/N)?

It seems that the clusterlinking is not written correct.
_________________
GBAMP Multiboot

Mighty Max, there doesn't appear to be many changes to the file to support the SC, is that because it's very similar to the GBAMP?

Has anyone tested these modifications to see if they work on a real SC?

Thanks for all the great work on this, the driver has made ScummVM DS a much better port having access to a real filesystem!

Yes, it looks that the used registers are exactly the same. It only adds the unlock mechnism. ( I don't got anyone to test is yet tho )

The credits still go to Chishm :p
_________________
GBAMP Multiboot

I think programs that use the CF routines should try to be multithreaded. Isn't most of the time wasted waiting for the drive to be ready with the data? Couldn't that time be better spent, maybe polling once per scanline to see if the data is ready, otherwise run the main thread?

Yes I wrote this post glaring at Scummvm, which has huge problems from IO requests bogging down everything, when it could really just start playing the digital audio immediately after the first sector is loaded.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

It looks like my FAT buffer is definitely broken. I will be completely rewritting the FAT read / write code soon anyway, to add FAT12 support. However, this probably won't be for a few weeks, since I am busy with another project and have tests coming up.

In the mean time, Dwedit suggested a temporary fix that should work. Just disable the FAT buffer.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

DwEdit, have you played the latest version? There's no noticable delays when starting the audio anymore.

Why doesn't FAT_fread use memcpy? Is it just trying to be independent of the standard C libraries?

I'm just saying because using memcpy allows you to write to GBA VRAM, if the size and all offsets are even numbers.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

Dwedit wrote:

Why doesn't FAT_fread use memcpy? Is it just trying to be independent of the standard C libraries?

I'm just saying because using memcpy allows you to write to GBA VRAM, if the size and all offsets are even numbers.

When I first wrote it, yes it was trying to be independent, as I wanted it to require as few external (space using) libraries as possible. But now that I've had more experience I will probably move to memcpy, and possibaly use some of the standard string functions too.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Can FAT_fileexists be added? Testing the existance of a file without opening it would be quite useful. Easy enough to scrounge up from bits in fopen.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

Actually, building it around fopen() wouldn't likely give you what I want out of FAT_FileExistsxists(): a way to distinguish a file from a folder in the same way that the result of FAT_FindFirstFile and FAT_FindNextFile do: 0 for not found, 1 for file, and 2 for folder.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

FAT_FileExists should be easy to add. Hopefully I will be able to add it in the next release. In fact, it should be pretty easy to do.
Here is (untested) code that I have just thought up:

Code:

int FAT_FileExists(const char* filename)
{
DIR_ENT dirEntry;
// Get the dirEntry for the path specified
dirEntry = FAT_DirEntFromPath (filename);

if (dirEntry.name[0] == FILE_FREE)
{
return DIR_END
}
else if (dirEntry.attrib & ATTRIB_DIR)
{
return DIR_DIR;
}
else
{
return DIR_FILE;
}
}

_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Supercard SD will work with this driver or just the CF version?
_________________
http://flickr.com/photos/stuffbox

Dudu.exe wrote:

Supercard SD will work with this driver or just the CF version?

Eventually SD should work, but for now not even CF will work (yet).
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

I'm using the old driver, and have problems now. After creating a few files from the GBA, when I create more files from Windows Explorer, or rename a file to a longer name, sometimes a bunch of junk directory entries suddenly appear in the folder! Anything like this been fixed in the new driver?
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

Quote:

It looks like my FAT buffer is definitely broken. I will be completely rewritting the FAT read / write code soon anyway, to add FAT12 support. However, this probably won't be for a few weeks, since I am busy with another project and have tests coming up.

In the mean time, Dwedit suggested a temporary fix that should work. Just disable the FAT buffer.

Has this issue been fixed yet? If not, how do I disable the FAT buffer?

Quote:

Eventually SD should work, but for now not even CF will work (yet).

Does that mean that the code MightyMax posted doesn't unlock the SC properly?

The SC unlock works for sure.

Pepsiman confirmed today the different modes you can switch the SC to.
Pepsiman found the following modes work:

0 = no read no write => SC disable
1 = RAM mode - read , no write
3 = CF mode - read/write
5 = RAM mode - read + write
7 = CF & RAM mode

/me is waiting for the next revision of the fat driver to include more HW drivers
_________________
GBAMP Multiboot

okay i am totally lost right now

mighty max, does ur loader come with these drivers? I mean i know it needs them but I dont get how to install them manually. Am i missing some big picture here or am i just stupid

EDIT - I found the pcx_mb.gba file and ran that and it like faded into red and froze and so I restarted my ds and the gbamp booted fine (phew, i was woried... bad experiences with rsod's and the gbamp) so now do i have the drivers installed?

Last edited by slizekalfer on Tue Nov 15, 2005 6:01 am; edited 1 time in total

You are missing the point. This is source code for programmers to use the GBAMP's compactflash interface, not drivers for a user to install.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

But would it be possible to compile the block I/O drivers as -fPIC (position independent code), so that they can be appended to the .gba file in question?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

I imagine you (chishm) already know it, but you can find some files that can help you with the supercard sd driver here

http://www.scdev.org/forum/viewtopic.php?t=1297&postdays=0&postorder=asc&start=0

Yeah, I already got that, but thanks anyway. The hard part is rewriting it in C, since the ASM won't compile properly for everyone (interworking...). I started it yesterday, but then I got Mario Kart and, well, everyone who has MK:DS will know why I haven't done anything since.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

I converted it to pseudocode on the wiki, dunno if the conversion was clean or not, since I don't have a SC to test with and I didn't really double-check it.

http://www.bottledlight.com/ds/index.php/Hardware/FlashCartridges

not converted to 'good' C, still using register names, but it should save you an hour or two at least (since it took me an hour to do ^_^)

A lot of the code is CRC computation, which I suspect you can grab pre-made, well written C for from something else that handles SD cards (maybe look for an AVR C project that interfaces to SD?)
_________________
Joat
http://www.bottledlight.com

I have decided that the next release is ready. It has many changes, including FAT12 support, SC CF support, better FAT buffering, and has FAT_fgets and FAT_fputs added.

Download gba_nds_fat_2005-11-17.zip to get the newest version.

I have spent some time testing it, however bugs can still hide in the code. If any do rear their ugly head, post here and I will try to squish them. Also note that SC SD is not supported yet. It may take a while, since I don't have one to test on.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Last edited by chishm on Mon Mar 20, 2006 3:27 am; edited 1 time in total

The one change I keep having to make is that GetFirstFile and GetNextFile return short names, and I want it to automatically return the longest name that exists.
I can see some obvious problems with making that the default behavior though, changing an API from a 13 size buffer to a 256 size buffer is a very bad idea.
I think FAT_GetLongFilename should not trash the output string if no long name exists, but that would be another API change.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

I can change the behaviour of FAT_GetLongFilename so that it leaves the string untouched, since that behaviour was never originally specified in the API, and so shouldn't have been relied upon.

Since it is requested, I can also add GetFirstFileLong and GetNextFileLong. This way the API remains the same and you get your functions :).
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Joat wrote:

I converted it to pseudocode on the wiki, dunno if the conversion was clean or not, since I don't have a SC to test with and I didn't really double-check it.

Thank you joat (and chishm) for the efforts for SC SD, it is greatly appreciated. If you need code tested just let me know and I will do my best to assist (since I cant afford to have SC SD shipped to you myself).

Quote:

Below code is translated from some whack assembly, so it might contain bugs. Credit due to the unknown author of 20051024113435206.zip

As far as I am able to tell, the code was obtained through disasm of the SC bios, possibly even the one contained in DF restore tool - but that is just because I am able to see the same sections almost identically in disasm of the bios from DF's tool. Still struggling to comprehend asm though, so the pseudo code is greatly appreciated.

One more thing: Fwrite's data should be const. That actually affects quite a bit of functions, include all the sector writers.

What's up with fclose adding an EOF character at the end of a file?
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

I'm getting corruption in files when opening them in overwrite (r+) mode and writing data!
Specifically, data from the last cluster is written to the first cluster!
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

Ok, I will look into that bug, that definitely shouldn't be happening. Did that ever occur in previous versions? I'm asking because I am pretty sure I didn't change the behaviour of fopen with regards to + mode, so the bug may lie in fwrite.

Also, I will add const to fwrite.

The EOF character is needed by windows for text files. Otherwise things like notepad will just display boxes if there is no EOF at the expected location. This is written after the last byte of the file, so it shouldn't affect binary files. If it does I think it is time to add a b/t mode option to fopen.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

chishm wrote:

The EOF character is needed by windows for text files.

No it isn't. If you set the file's logical length (bytes 0x1C-0x1F of the directory entry) correctly, Notepad will know to stop reading at the end. I just used frhed (a GPL hex editor) to look at a few .txt and .c files made in Notepad, and the last two bytes were 0d 0a ("\r\n"), not 1a (^Z, end of file under DOS) or 04 (^D, end of file under UNIX).
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tepples wrote:

chishm wrote:

The EOF character is needed by windows for text files.

No it isn't. If you set the file's logical length (bytes 0x1C-0x1F of the directory entry) correctly, Notepad will know to stop reading at the end. I just used frhed (a GPL hex editor) to look at a few .txt and .c files made in Notepad, and the last two bytes were 0d 0a ("\r\n"), not 1a (^Z, end of file under DOS) or 04 (^D, end of file under UNIX).

Yes, that is true, the last character of the file will not be ^Z. However, if you examine the physical sector on which the file resides, you should notice a ^Z as the next byte after the end of the file. Without this byte, some text programs will not know where the end of file is. This byte is not included in the file's length, and doesn't necessarily exist when the file length is a multiple of the sector size.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

chishm wrote:

if you examine the physical sector on which the file resides, you should notice a ^Z as the next byte after the end of the file. Without this byte, some text programs will not know where the end of file is.

I'm pretty sure that this problem is limited to really old programs that use the MS-DOS 1 "file control block" API that imitates CP/M, not the MS-DOS 2+ "file handle" API that (mediocrely) imitates UNIX, or the Windows APIs that imitate MS-DOS 2+. I just tested MS-DOS Editor (from Windows 95 and newer) and Notepad (from Windows 2000), and both seem to use the newer API, as closing and reopening a file containing a ^Z retains the text after the ^Z in both programs.

Quote:

This byte is not included in the file's length, and doesn't necessarily exist when the file length is a multiple of the sector size.

If this is true, that the ^Z is after the end of file and not in evenly sized files, then this is not much of an issue.

But for code that doesn't look like a bunch of ad-hockery, you could fill the end of the last sector of a file with ^Z bytes when it is closed. In the comments, say something to the effect:

Code:

/* Fill unused end of the file's last sector for security
(don't want to leave incriminating evidence in plain sight
after the file is truncated). The byte 0x1A is chosen
for compatibility with MS-DOS 1.0. */

_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

My only comment is that I would NEVER want to see something appended at the end of a file, unless I put it there! I don't want to dump 8192 bytes to disk and end up with a file of length 8193.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

Ok, I give in, I'll change the behaviour to fill the rest of the sector with null bytes, rather than just the last byte after the file.

Dwedit wrote:

My only comment is that I would NEVER want to see something appended at the end of a file, unless I put it there! I don't want to dump 8192 bytes to disk and end up with a file of length 8193.

I guess my code is more confusing than I thought. It doesn't change the file at all, it keeps it at 8192 bytes. Its just the next byte after the file in the same sector is set as NULL.

I'll change the way it works. Instead I'll NULL the sector before it is used if the file is being appended or written at the end.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Hi chishm,

I had a go this morning at integrating the new version of your fat code with ScummVM to replace the ancient version I had in there before.

I got it working, sort of. It loads the config file and I even managed to get into one of the games, but all the others crash and burn trying to load some of their resources. I'm going to keep at it to see if I can work out why, but ScummVM is huge and really hard to debug, so I wondered if you had any ideas why this might be happening? Sorry I can't yet provide much more in the way of debugging info.

I'm using a FAT16 CF card with a GBAMP.

Thanks for your fantastic work on the driver by the way!

EDIT: I tried gba_nds_fat.zip on your site as well as gba_nds_fat_2005-11-17.zip and the results are exactly the same, if that helps.

I've sorted it!

In gba_nds_fat.c, this:

Code:

// Calculate where the correct cluster is
if (position > curPos)
{
   clusCount = (position - curPos + file->curSect + file->curByte) / filesysBytePerClus;
   cluster = file->curClus;
} else {
   clusCount = position / filesysBytePerClus;
   cluster = file->firstCluster;
}

should be this:

Code:

// Calculate where the correct cluster is
if (position > curPos)
{
   clusCount = (position - curPos + (file->curSect * filesysBytePerSec) + file->curByte) / filesysBytePerClus;
   cluster = file->curClus;
} else {
   clusCount = position / filesysBytePerClus;
   cluster = file->firstCluster;
}

Everything now works as it did before. Although I did add some optimisations to the old FAT driver and although this one is much faster there's a few changes that I had made before that I'll probably do again.

Doh! Thanks for that. I should also warn you that there are a few bugs in w, w+ and r+ modes when seeking and saving. I should have a fixed version up today. I just need to test it a bit, to make sure it works.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Okay, that will be great, although my config file saving works without a hitch as far as I can tell. Not done much in the way of testing with it.

I can do a thorough test of the new version once you have it.

Ok, new version up - gba_nds_fat_2005-11-24.zip.

Removed EOF marker addition from FAT_fclose, fixed FAT_fseek, added LFN versions of FAT_FindFirstFile and FAT_FindNextFile, FAT_fwrite now takes a const void* buffer.

Please report any bugs / feature requests back to this thread.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Last edited by chishm on Mon Mar 20, 2006 3:26 am; edited 1 time in total

I know its not bugs with your driver per se, but I am hoping this testing will help integrate SD support as well.

I have managed to identify some problems with the modified for SC SD version found here:
http://www7.plala.or.jp/zap/download.html (SuperCard SD FAT Driver)
- read files, it appears to be working correctly for the non-dma functions, and Im assuming DMA is working since that is what this driver does with moonshell, but I havent tested it myself
- file delete - works great if the file was not created with this lib, but hangs in the freelinks area when the file was created with this driver
- on fclose of a written file behavior is wonky to say the least,
:fat1 contains an entry, but fat2 does not mirror it
:the entry in fat 1 seems to tell windows that the data written (even when I hex edited the fat1 entry to fat2) is exactly 1k larger than the dir entry, so checkdisk proposes that "windows has found inconsistencies in the data, this is not corruption" and on fixing it it alters the FAT entries, corrects the lack of the data in the mirror and changes one of the dir entry to +0x400 in the filesize

I think fclose/fat entry and file delete problems are directly releated, it is weird, because I can create a file, restart the DS then delete the file and it hangs, and restart again and delete the file, and it deletes.

Please tell me you know the source of the FAT1/2 thing and have dealt with it before, I am at my wits end trying to track the problem down. I have a controller/hardware version of a MMC/SD driver from circuit cellar, and as far as I can tell it recursively writes the fat entries depending on how many fats there are, but I am unable to understand what the correct data should be going to FAT entries to make the file size valid and whether the SC hardware is just simply supposed to take care of the mirror entry itself.

One other thing to note, even though the ASM looks identical in the origional asm API, the unlock routine that works in the new lib (I dont have CF to test this though) for the SC CF does not unlock the SC SD.

Last edited by cory1492 on Thu Nov 24, 2005 7:28 am; edited 2 times in total

I am sorry, but I won't support the unofficial versions of the lib for the simple fact that I don't have any control over them. That being said, I can help you with some of your queries.

The library only writes to one of the FATs. This appears to be valid behaviour, and was done for 2 reasons: 1) It is faster and 2) ChkDsk can use FAT #2 to repair FAT #1 if needed.

I cannot help you with the FAT problems, as I have completely rewritten the FAT handling code in the newest versions of the lib.

I do have atheory about the 1K size difference. FAT_fwrite allocates a cluster as soon as it has reached the end of the last cluster of a file. If you write an exact multiple of the cluster size to the file, it will allocate a new cluster, but not actually use it. Since windows sees more clusters are allocated than are needed to hold the file, it complains.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

I have my doubts as to the asms ability to write properly, especially since the SC software only uses it to overwrite existing files without modified FAT values and dir entries...

Here is the source you posted above, with some changes to use SCSD as well but with the asm API for readSector and such. Read and write is working, but still the same problem with the FAT1/2 as above as well as the extra space used and complained about under windows.
buildtest_newSD.zip

How does the MP correspond to the FAT problems I am seeing, from what I see FAT1 is written to, not FAT2, which as you say windows should be able to handle if there is any problem - but it still really doesnt explain to me why deleting a file links is crashing things, even if the dir ent/fat entry is incorrect(perhaps some error handling is needed for corrupt/noncorrosponding FAT entries?).

edit:/ you are 100% correct about the 1k thing, I was previously writing a test file of 1024x10 bytes, I changed it to 1023x10 bytes and now windows has no complaints and FAT_remove works perfectly (I just noticed that it now returns 0 if successful instead of 1...) - will this extra cluster be corrected in a later version?

just to note, I was actually trying to bring somthing to the driver for you, since you dont have a device to test with. I have not started trying to integrate the pseudocode till I got this other stuff worked out, and with the answers you provided I should be able to test basic functions from the pseudocode and fix up the io_scsd in the next few days, time permitting.

Does the new version of FAT_remove work for you now? I'm interested to know, because I can see no reason why it shouldn't work, even if the file does have extra clusters.

Also, I appreciate that you are trying to add SC SD support. However, I have one request. If you do use the asm, either inline it in the C file, or get it to work with interworking. This is just to make sure it can be compiled and linked into other projects correctly.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Sata's
http://www.pat.hi-ho.ne.jp/~sata68/nds/ndsiotest.lzh

supports SC SD,too.

devmani, you are right, he used the same method (essentially) that I did to add that support

chishm, I am going to attempt to convert it into C, but since I dont know very much asm it will be a large task for me to do, even with the psudocode from the past post. As I said, the SC unlock code for CF appears the same in ASM, but seems to not work at all with SC SD. Confounding. Is there any guide to inlining ASM around? I have found some examples, but little explanation -and C code for the ldrh seems to not work for me as its a 1/2 size of what C can handle with ARM...?

I formatted and tested again, and it is indeed deleteing the file OK now when I use 1024x10 bytes for the size. Excellent, aside from one thing, on a freshly formatted disk, I create test.bin - windows reports 2 errors (Im assuming its overwriting the old partially deleted clusters/dir info) inconsistent data as before, and invalid date/time stamp. Neither should be fatal though to any DS app, but... I corrected this with code in fclose in the older driver, checking to see if create date or time is 00, and if so fill it with current data - it seems somewhat random that this occurs though.

PS: just to add in, I really like the looks of how this FAT lib is shaping up, thanks for your work once again chishm.

cory1492:
The invalid date / time will occur if you don't allow enough VBlanks for the IPC to be updated with the correct time. This causes it to be filled with random data, which is picked up as invalid by windows. Having a value of 0 for all date and time fields will be ignored by windows, and is in fact the method used when the lib is run on a GBA.

Joat has some C code up on NDSTech Wiki that he converted from the ASM. Oh and ldrh is basicly like reading into a short int (u16 or s16). This is used because the GBA cart data bus is only 16 bits wide.

devmani:
SaTa showed me that last night. I made pretty much the same comment as I did to cory1492, ie, it should be interworking compatible. Thanks for bringing it up anyway. (I too have tried doing it with external asm, and that's when I realised interworking fails.)
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

New release. Get gba_nds_fat_2005-11-26.zip from my site.

I have changed the way clusters are allocated. Instead of being allocted as soon as the last cluster is filled, they are allocated when they are needed. I have tested it to make sure it works, but some bugs may exist. I also fixed seeking in append mode.

Finally, I added support for standard GBA flash carts. This includes saving to SRAM transparently to the host app. Unfotunately, small SRAM sizes limits the size of writable files to approximately 60KB. I still have to write the file system builder for it, but the support is there.

How it works:
A complete FAT file system is made into a binary image, and appended to the 256 byte paddded ROM. In the MBR or BS of the disc image, at offset $100, is the null terminated string "FCSR Chishm FAT" (16 bytes long). This is searched for in 256 byte steps. Following this string is the start sectors of up to 4 SRAM overlays. Then then 4 overlay sizes are defined. If an overlay is not used, its size is set to 0.

Regions of the file system that are in ROM are set to read only. Clusters are set as occupied. Files are marked read only. Directories are padded with invalid long file name entries, which get ignored.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Last edited by chishm on Mon Mar 20, 2006 3:25 am; edited 1 time in total

The biggest problem I am having so far is "provoke ready reply" so that the test to see if its running on SC SD doesnt always need to reply true, Im willing to bet that SATA will have something working long before I can though.

I will test the cluster against my buildtest right now to see if windows still gripes about inconsistencies.

Have you made concessions for carts that have both media and SRAM present, or is one only type of a deal? Heh, heres a new one I have never seen before: "io_fcsr.c:196: warning: pointer targets in assignment differ in signedness"

edit/ perfect, no inconsistencies and its not hanging on the delete (of course 1 in 5 times I get the invalid timestamp, but since I did not use the interrupt at all that goes very well with your explanation)

edit/ I had hoped for some insight from SATA's code, but the memorycard is inserted function returns true regardless of whether the SC SD is unlocked

cory1492 wrote:

Have you made concessions for carts that have both media and SRAM present, or is one only type of a deal? Heh, heres a new one I have never seen before: "io_fcsr.c:196: warning: pointer targets in assignment differ in signedness"

Flash cart + SRAM mode is pretty much a last resort. Standard flash cart SRAM only offers 64KiB of writable space, which is not a lot when a whole 512MB CF card can be written to. The worst part it, the file system has to be built by a PC side program, which hasn't been written yet :P.

That error is because I had a u8* being assigned to a char*. chars are signed, but u8s aren't.

For the IsInserted function, I generally (ab)use the memory mapped registers of the inserted media. For instance, compact flash has 4 LBA sector registers that can be read and written in the cart address space. Since flash carts can't be written be simply writing data to the desired memory address, it can be safely assumed that it is not ROM that is being dealt with. Since the registers are accessible, the interface is usable and the function returns true.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Hi chishm,

I'm having save trouble with the driver. In the gba_nds_fat_2005-11-17.zip version, config file saved ok, but game saves didn't. They don't try to seek within the save file, just write it from beginning to end.

24th and 26th November versions don't save games and the config file saving doesn't work on those ones either.

In all cases, I get a file of the right name and roughly the right size, but the contents are corrupted.

I haven't looked into why yet, but I thought I'd give you a heads up. :-(

Edit: It seems the save games do work on the 17th version. They just take nearly 30 seconds to load up again! I'm looking into this...[/i]

I have a request :) : Is it possible to implement a rename file or move file command? Would be great!

Greetings
FloFri

(P.s.: You are doing a great work chishm (also with the GBAMP firmware), keep it up!)

Ok, sorted the slowness.

It seems you weren't checking whether there were any bytes remaining before you read in a whole cluster. You also weren't checking whether you needed to update the read buffer. I'm still using the 17th Nov version. Now the 30 second load takes 1 second!

I haven't looked why the later versions don't work.

Here's my updated fread function:

Code:

u32 FAT_fread (void* buffer, u32 size, u32 count, FAT_FILE* file)
{
int curByte;
int curSect;
u32 curClus;

int tempVar;

char* data = (char*)buffer;

u32 length = size * count;
u32 remain;

bool flagNoError = true;

// Can't read non-existant files
if ((file == NULL) || (file->inUse == false) || size == 0 || count == 0 || buffer == NULL)
   return 0;

// Can only read files openned for reading
if (!file->read)
   return 0;

// Don't read past end of file
if (length + file->curPos > file->length)
   length = file->length - file->curPos;

remain = length;

curByte = file->curByte;
curSect = file->curSect;
curClus = file->curClus;

// Align to sector
tempVar = BYTE_PER_READ - curByte;
if (tempVar > remain)
   tempVar = remain;

if ((tempVar < BYTE_PER_READ) && flagNoError)
{
   memcpy(data, &(file->readBuffer[curByte]), tempVar);
   remain -= tempVar;
   data += tempVar;

   curByte += tempVar;
   if (curByte >= BYTE_PER_READ)
   {
      curByte = 0;
      curSect++;
   }

   if (curSect >= filesysSecPerClus)
   {
      curSect = 0;
      curClus = FAT_NextCluster (curClus);
   }
}

// align to cluster
// tempVar is number of sectors to read
if (remain > (filesysSecPerClus - curSect) * BYTE_PER_READ)
{
   tempVar = filesysSecPerClus - curSect;
} else {
   tempVar = remain / BYTE_PER_READ;
}

if ((remain > 0) && (tempVar > 0) && flagNoError)
{
   disc_ReadSectors ( curSect + FAT_ClustToSect(curClus), tempVar, data);
   data += tempVar * BYTE_PER_READ;
   remain -= tempVar * BYTE_PER_READ;

   curSect += tempVar;
   if (curSect >= filesysSecPerClus)
   {
      curSect = 0;
      curClus = FAT_NextCluster (curClus);
      if (curClus == CLUSTER_FREE)
      {
         flagNoError = false;
      }
   }
}

// Read in whole clusters
while ((remain >= filesysBytePerClus) && flagNoError)
{
   disc_ReadSectors (FAT_ClustToSect(curClus), filesysSecPerClus, data);
   data += filesysBytePerClus;
   remain -= filesysBytePerClus;
   curClus = FAT_NextCluster (curClus);
   if (curClus == CLUSTER_FREE)
   {
      flagNoError = false;
   }
}

// Read remaining sectors
tempVar = remain / BYTE_PER_READ; // Number of sectors left
if ((tempVar > 0) && flagNoError)
{
   disc_ReadSectors (FAT_ClustToSect(curClus), tempVar, data);
   data += tempVar * BYTE_PER_READ;
   remain -= tempVar * BYTE_PER_READ;
   curSect += tempVar;

   if (curSect >= filesysSecPerClus)
   {
      curSect = 0;
      curClus = FAT_NextCluster (curClus);
      if (curClus == CLUSTER_FREE)
      {
         flagNoError = false;
      }
   }
}

// Last remaining sector
if ( ((remain > 0) || (file->curSect != curSect) || (file->curClus != curClus)) && (flagNoError))
{
   disc_ReadSector( curSect + FAT_ClustToSect( curClus), file->readBuffer);
   if (remain > 0)
   {
      memcpy(data, file->readBuffer, remain);
      curByte += remain;
      remain = 0;
   }
}

// Length read is the wanted length minus the stuff not read
length = length - remain;

// Update file information
file->curByte = curByte;
file->curSect = curSect;
file->curClus = curClus;
file->curPos = file->curPos + length;
return length;
}

Thanks for the heads up, AgentQ. I have gone and made the changes to last sector loading, using a slightly different algorithm. However, the check for remain > 0 on the align to cluster code shouldn't be needed. This is because tempVar = 0 if remain = 0.

New version is gba_nds_fat_2005-11-27.zip.

I also found a bug that caused it to incorrectly zero sectors when writing, this probably caused the config file save problem. This bug was related to the sector loading in FAT_fread bug. Hopefully I have also fixed the game saving. If not, can you post the saving code (just the sequence of FAT_fopen, FAT_fwrite, FAT_fseek, FAT_fclose, etc used for saving).
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Great news!

It all works perfectly with the 27th Nov version. I've saved and loaded quite a few games and it seems just fine now.

Yep, you're right about the extra check on the cluster read, that isn't needed. I was being a bit too careful.

Thanks for all your help, I'm sure many people will be grateful that they can play ScummVM on the M3 and Supercard.

Its working most excellently chishm.

A question though, I have a test app that uses fwrite to write 1k 256 times, it does so very slowly until it gets to around the 160'th time, then it flies through the last bit in about the same time it takes to do 1 of the first bunch - is there something I am really missing?

one thought: I made a small change in the loop (a printf location) and did the build again without making it from clean, and the whole 256k wrote as fast as about 2 of the slow ones... this leads me to beleive there is something wrong in my app (a wait CR, or not using VBLANK at all... or some other obscure thing that Im not taking into account) - any thoughts would be appreciated though.

No bugs, just slow CF cards.

When writing to a file it has to allocate clusters when they are needed. To do this it has to search the FAT for a free cluster. This can take a bit time. If you have a highly fragmented filesystem, it can cause this sort of problem. Most OSs cache the FAT for this reason, but the NDS doesn't have enough memory to make it worth it.

If you write over a file in R+ mode, the clusters are already allocated, and won't cause a slow down.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Just to be clearer, for the purposes of my tests the card is formatted every time (although I realize windows usually leaves most of the data intact), and the .nds file is put on alone, although I am using the W mode, I will try the R+ one to see what happens in the case of overwrite.

Thanks chishm.

- first note, if the file doesnt exist and its opened in R+ mode, it fails to write and fclose returns failed - but a 0k file is created? (Im assuming this is why there is a W+ mode)
- all I can say is wow, that is dead on - in R+ mode, if the file size is not exceeded it is FAST. Now I understand fully why SuperCard/M3 makers use pre-written save files instead of doing file management from the boot menus.

Two last (kinda dumb) question, does the linking system in the FAT allow fragmentation (I assume it does, but I'd prefer the definite answer, of course) - and could a DS based defrag app be made that does cache the FAT (just wondering if the DS has enough memory to do that, not sure how big the biggest FAT can be)

Is there a good way to determine which directory or path a multiboot GBA file was launched from? Could CF_LastSector be used to find the last sector read, then brute force traversal to find which file path was last read?
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

Dwedit wrote:

Is there a good way to determine which directory or path a multiboot GBA file was launched from? Could CF_LastSector be used to find the last sector read, then brute force traversal to find which file path was last read?

I was originally going to implement this functionality (hence CF_LastSector), but I never bothered. You will need to call CF_LastSector before any other CF access, and make sure to remove the highest 4 bits (these will be 0xe). Then initiate the CF card, convert the sector to a cluster, brute force through the FAT until you find the start cluster of a chain that points to the cluster found, then brute force through the directory tree until you find the correct directory enry that uses that start cluster. Now you know why I never bothered.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

This code fails! I had to bring in code from an eariler version to fix it. It stopped any long file names from appearing.

Code:

/*       if (lfn.ordinal & LFN_DEL)
      {
         lfnExists = false;
      }
      else if (lfn.ordinal & LFN_END) // Last part of LFN, make sure it isn't deleted (Thanks MoonLight)
      {
         lfnExists = true;
         lfnName[(lfn.ordinal & ~LFN_END) * 13] = '\0'; // Set end of lfn to null character
         lfnChkSum = lfn.checkSum;
      }
      */

_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

Can you please post the exact code you had to replace it with. This is odd, since I am able to view long filenames when doing directory listings, and no one else has reported a problem.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Thread bumped because I released a bug fix.
Version 2006-01-04:
* Fixed FAT_fwrite when writing in cluster aligned chunks

Get it from my website.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

I had some issue too, but I have not explored it further. It was when opening a file for appending ("a"). It went corrupt somehow.
I resolved it by opening the file as updateable ("r+") and then seeking towards the end.
Perhaps this bugfix helps. It's still too bad every app needs to be recompiled each time.

Another month, another release, another recompilation for you. :D

2006-02-09
* Fixed file and directory names starting with a dot ("."), or containing more than one dot
* Added Neoflash MK2 / MK3 support, thanks to www.neoflash.com
* Modified CF access routines to mask of the high byte of the status register, hopefully improving compatibility
* Added disc caching, thanks to www.neoflash.com . It can only be enabled on the DS (not GBA) since it will consume 128KB of memory on the default setting. It is advisable to call FAT_FreeFiles() before shut down if caching is enabled, to flush any writes to disc
* Added Supercard SD test code. It unfortunately doesn't work, and is disabled by default
* Added FAT total size and type functions
* Added file creation and modification functions. Disabled by default, see gba_nds_fat.h for more info
* Fixed AddDirEntry bugs:
* should no longer corrupt a directory when adding a new file
* no longer puts garbage into a short file name's extension, thanks to 0xtob
* long file names with less than 12 characters now work, thanks to DragonMinded for pointing it out
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Any word on the GBA Movie Player SD? I've gotten an email asking for support for that card.

Also here's a big size optimization by rolling up a couple loops:
Put this in somewhere:

Code:

const char lfn_offset_table[13]={0x01,0x03,0x05,0x07,0x09,0x0E,0x10,0x12,0x14,0x16,0x18,0x1C,0x1E};

replace this:

Code:

         lfnPos = ((lfn.ordinal & ~LFN_END) - 1) * 13;
         lfnName[lfnPos + 0] = lfn.char0 & 0xFF;
         lfnName[lfnPos + 1] = lfn.char1 & 0xFF;
         lfnName[lfnPos + 2] = lfn.char2 & 0xFF;
         lfnName[lfnPos + 3] = lfn.char3 & 0xFF;
         lfnName[lfnPos + 4] = lfn.char4 & 0xFF;
         lfnName[lfnPos + 5] = lfn.char5 & 0xFF;
         lfnName[lfnPos + 6] = lfn.char6 & 0xFF;
         lfnName[lfnPos + 7] = lfn.char7 & 0xFF;
         lfnName[lfnPos + 8] = lfn.char8 & 0xFF;
         lfnName[lfnPos + 9] = lfn.char9 & 0xFF;
         lfnName[lfnPos + 10] = lfn.char10 & 0xFF;
         lfnName[lfnPos + 11] = lfn.char11 & 0xFF;
         lfnName[lfnPos + 12] = lfn.char12 & 0xFF;

with this:

Code:

         int ii,jj;
         u8 *lfn_str = (u8*)lfnName + ((lfn.ordinal & ~LFN_END) - 1) * 13;
         //new code
         for (ii=0;ii<13;ii++)
         {
            jj=lfn_offset_table[ii];
            lfn_str[ii]=((u8*)&lfn)[jj];
         }

and again, replace this:

Code:

      lfnEntry.ordinal = (lfnPos + 1) | (dirEntryRemain == dirEntryLength ? LFN_END : 0);
      lfnEntry.char0 = filename [lfnPos * 13 + 0];
      lfnEntry.char1 = (filename [lfnPos * 13 + 1] == 0x01 ? 0xFFFF : filename [lfnPos * 13 + 1]);
      lfnEntry.char2 = (filename [lfnPos * 13 + 2] == 0x01 ? 0xFFFF : filename [lfnPos * 13 + 2]);
      lfnEntry.char3 = (filename [lfnPos * 13 + 3] == 0x01 ? 0xFFFF : filename [lfnPos * 13 + 3]);
      lfnEntry.char4 = (filename [lfnPos * 13 + 4] == 0x01 ? 0xFFFF : filename [lfnPos * 13 + 4]);
      lfnEntry.char5 = (filename [lfnPos * 13 + 5] == 0x01 ? 0xFFFF : filename [lfnPos * 13 + 5]);
      lfnEntry.char6 = (filename [lfnPos * 13 + 6] == 0x01 ? 0xFFFF : filename [lfnPos * 13 + 6]);
      lfnEntry.char7 = (filename [lfnPos * 13 + 7] == 0x01 ? 0xFFFF : filename [lfnPos * 13 + 7]);
      lfnEntry.char8 = (filename [lfnPos * 13 + 8] == 0x01 ? 0xFFFF : filename [lfnPos * 13 + 8]);
      lfnEntry.char9 = (filename [lfnPos * 13 + 9] == 0x01 ? 0xFFFF : filename [lfnPos * 13 + 9]);
      lfnEntry.char10 = (filename [lfnPos * 13 + 10] == 0x01 ? 0xFFFF : filename [lfnPos * 13 + 10]);
      lfnEntry.char11 = (filename [lfnPos * 13 + 11] == 0x01 ? 0xFFFF : filename [lfnPos * 13 + 11]);
      lfnEntry.char12 = (filename [lfnPos * 13 + 12] == 0x01 ? 0xFFFF : filename [lfnPos * 13 + 12]);

with this:

Code:

      int ii,jj;
      u8*filename_pos=(u8*)filename+lfnPos*13;
      u8*lfn_str=(u8*)&lfnEntry;
      lfnEntry.ordinal = (lfnPos + 1) | (dirEntryRemain == dirEntryLength ? LFN_END : 0);

      for (ii=0;ii<13;ii++)
      {
         jj=lfn_offset_table[ii];
         if (filename_pos[ii]==0x01)
         {
            lfn_str[jj]=0xFF;
            lfn_str[jj+1]=0xFF;
         }
         else
         {
            lfn_str[jj]=filename_pos[ii];
            lfn_str[jj+1]=0x00;
         }
      }

_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

I haven't got an GBAMP SD, and there hasn't been any code posted, so support is not happening.

That optimisation is great, thanks.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

I just ordered an M3 and have a question. Why would I use Chism's driver over the one that comes with the M3? What benifit does it give me of the OEM drivers?

It is for developers only. You don't really need it.

SCSD: a bit of code that I tested as returning the same value as the crc7 function (for command CRC's) (note that the value returned by the function seems 'trimmed')

Code:

////////////////////////////////////////////////////////////
// standard CRC7 used in MMC/SD SPI mode access
// tested as working fine to obtain low 8 bits for commands
uint8 SCSD_CRC7(uint8* data, int cnt)
{
int i, a;
uint8 crc, temp;

crc = 0;
for (a = 0; a < cnt; a++)
{
temp = data[a];
for (i = 0; i < 8; i++)
{
crc <<= 1;
if ((temp & 0x80) ^ (crc & 0x80)) crc ^= 0x09;
temp <<= 1;
}
}
crc = (crc << 1) | 1;
return(crc);
}

Possible to use the DS's built in crc16? Not certain it generates the same crc though...

I am also thinking that sending the command to turn off CRC's entirely (as M3 and MK do) could be another way of doing it...

[/quote]

I imagine that would make it more susceptible to corruption, though.

cory1492, feel free to hack around with the SC SD driver as much as you want. I haven't been able to get it working (not having a supercard to test with), so it would be great if you made it work. As you can see, I converted all the ASM to C, but I may have made a mistake somewhere.

Also, the SC SD uses bit banging to communicate on the SD command line, so it is safer to use CRCs. If it was a hardware SPI interface, I would disable them.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Your web page seems to be dead. All I see in the source code is some popunder code and a redirect to itself.

Apparently that's true of all sites hosted at geocities.com. Which browser are you using?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Firefox. I've never seen any other site do it, even on Geocities.

chishm's site works fine here using firefox 1.5

Ok, new version.
Changes:
2006-03-03
* Improved NMMC (MK2 / MK3) driver
* Optimised LFNs into loops, thanks to dwedit
* Optimised SuperCard SD CFC7, thanks to Cory1492
* Added file attribute support
* Added read only M3 SD support, thanks to SaTa and Moonlight. Disabled by default due to incompleteness
* Fixed SuperCard SD reading, thanks to Loopy
* Added EFA2 support, thanks to CyteX

The M3 SD, SC SD and EFA2 drivers only support reading at this stage, so they are disabled by default.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Awesome chishm.

I just replaced this into ScummVM, reenabled the M3SD files and recompiled and it didn't work although it tells me that it detected the card (it doesn't show any directories when I browse).

Can anyone else confirm or deny compatibility of this latest version? Previously I had been using the modified version found in moonshell, with minimal changes by me.

chishm wrote:

Ok, new version.
Changes:
2006-03-03
* Improved NMMC (MK2 / MK3) driver
* Optimised LFNs into loops, thanks to dwedit
* Optimised SuperCard SD CFC7, thanks to Cory1492
* Added file attribute support
* Added read only M3 SD support, thanks to SaTa and Moonlight. Disabled by default due to incompleteness
* Fixed SuperCard SD reading, thanks to Loopy
* Added EFA2 support, thanks to CyteX

The M3 SD, SC SD and EFA2 drivers only support reading at this stage, so they are disabled by default.

Gr8! :)
now we have to wait untill you guys got the write function to get it work :)

TNX! :)

keep up the good work! :)

What do you suspect are the problems are with writing the SD? I know you dont have one so its hard to tell but if theres anything you think i should try im willing, ive had a look over the code but its still above my head. I understand it, but just dont really have any ideas about what to do.

linus, it's probably more silly little mistakes on my part when I did the conversion.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

I'm still not seeing any content on that page... :-(

Quote:

Apparently that's true of all sites hosted at geocities.com. Which browser are you using?

I don't think so, but it may be true of any site on geocites.com. :)
http://www.geocities.com/chishm1/gbamp/

-Rich

I finally got the time to start looking through the code. As I said im pretty much learning it as I go so at this point I just have questions :)

in: bool SCSD_WriteSectors (u32 sector, u8 numSecs, void* buffer)

sector = sector * BYTE_PER_READ;

the variable sector isnt used again, i would have thought that the function calls in the loop would use that at as starting point like:

SCSD_CRC16(((u8*)buffer) + (sector+ (curSector * BYTE_PER_READ)), BYTE_PER_READ, (u8*)crc16);

but instead it just uses curSector which is initialised to 0. But then the comments in the asm looks to be doing something similar

@ sectno<<=9;

then sectno isnt used again so whats the point, im really sorry if this is something stupid.

The other question was whats this divide about...

SCSD_WriteData(((u16*)buffer) + (curSector * (BYTE_PER_READ/2)), crc16);

As far as I can tell there is a problem in this function (I dont know if theres more) because when I call fopen with a + or w it doesnt return i assume because it cant write the sector.

Sector is used again in the very next line:

Code:

SCSD_Command(25,0,sector);

The divide is because it is going to an offset in the buffer, but the buffer is a u16* and so adding an int to the base address will go 2 * offset into the buffer.

EDIT: This was my 512th post \o/. 512 is a very special number for FAT and disks.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

just found a quick few hours to get back into this, my writetest was getting stuck in WriteData at the first loop

while (SD_DATAADD & SD_STS_BUSY);

i figured it should be

while ((SD_DATAADD & SD_STS_BUSY) == 0);

it doesnt get stuck here now, instead it deletes the text file i try to write and deletes the write test binary - i think it may just be deleting them from the fat record though because the SuperCard menu system still sees the files but windows doesnt.

At the moment I have no idea why this is so ill keep guessing away, but if anyone has any ideas or something to test let me know.

Cheers

PS one last thing i put some debug stuff in the io_scsd.c functions to find where the error was, would they mess up the timing or something to cause it to not work?

chishm:

First of all: Great work with the FATlib so far, I'm impressed by the increasing compatibility of this lib. I'm using it in NitroTracker and it works very well for most cards. Thank you very much for the effort you're putting into this!

For my question: Recently, I recieved some reports from Supercard CF owners for whom NitroTracker froze when trying to access the file system. I sent a version with debug output to one of them and it turned out that the call to FAT_Initfiles causes the freeze. I'm using version 2006-03-03 with Sata's M3SD patch. I then compiled my program with version 2006-01-04 and it turned out that there are no crashes on Supercard CF with this version.

What could be the problem with the new FATlib?

Thanks in advance!
Tob

There are a few things that could be wrong, however the most likely is that it is detecting the wrong type of card being inserted. If this happens, when it tries to read a sector it will freeze forever, waiting for a response (if it misdetected it as an SD card), or it will freeze until a timeout occurs (if it misdetected it as a CF card).
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

chishm: Thanks, fixed it by switching the checks for SC SF and SC SD in disc_io.c . I had people test it on SC SD and SC CF and it seems to work fine on both. Well, exceot for saving to SC SD or course :-)

Bye, Tob

linus wrote:

just found a quick few hours to get back into this, my writetest was getting stuck in WriteData at the first loop

while (SD_DATAADD & SD_STS_BUSY);

i figured it should be

while ((SD_DATAADD & SD_STS_BUSY) == 0);

it doesnt get stuck here now, instead it deletes the text file i try to write and deletes the write test binary - i think it may just be deleting them from the fat record though because the SuperCard menu system still sees the files but windows doesnt.

At the moment I have no idea why this is so ill keep guessing away, but if anyone has any ideas or something to test let me know.

Cheers

PS one last thing i put some debug stuff in the io_scsd.c functions to find where the error was, would they mess up the timing or something to cause it to not work?

Im still having problems with this, has anyone got passed this stage? cory? I dont really know where to go from here so if any one has any suggestions or anything i should try id appreciate that.

Sorry linus, havent had much time to fiddle with it in the last few weeks... Just a note, the current version of Rain by sata can write both SCSD and M3SD (although it will not work on the new/smaller M3SD) using assembly files for the write routines.

Yeah its all asm :( ive patched it into the latest C version anyway but i cant test at the mo.

I was wondering though, if the SCSD card reads u16 at a time (correct me if im wrong) why is:

void SCSD_WriteData (u32 *buff, u16* crc16buff)

declared with u32 *buff surely everytime its ++ (later on) it screws it over. Im still learning the mechanics of everything but if u inc like this you would miss every second 16bits?

Anyway just looking through sorry if the questions have been covered - i know if the solution was a simple of switching a u32 to a u16 someone would have done it, im just trying to learn whats going on.

Hey there. I have a problem with my M3 SD, none of the programs that use this driver seem to be able to load data from my m3 SD card, while others can use m3 SD's :/. Some programs crash and some just dont display any files on the card, like nitrotracker.

I've tried different SD cards, and formatting them FAT or FAT32 but it doesnt seem to help.

Do you have any idea what else i could try ? Or maybe some sort of test program that would show where my M3 SD actually errors ?. I really want to use nitrotracker, but like this i cant load any samples :[

It might be working in one version and not another. Some people might have used an older version where it worked, while others used a version where it didn't, not knowing there was a problem or just not wanting to risk finding bugs.

HyperHacker wrote:

It might be working in one version and not another. Some people might have used an older version where it worked, while others used a version where it didn't, not knowing there was a problem or just not wanting to risk finding bugs.

Thats not it. Using the same build of nitrotracker (1.2), another m3 SD user could access the SD card, and i could not. He is using the same first version of the M3 just like me to, not a different version (and yes i've tried version 1.3 to, makes no difference)

I think that either there's something wrong with my M3 SD, or there's something wrong with the driver. But the thing is that using the extend mode of the m3 i can access the SD card. Thats as good as homebrew software, but well just written by the m3 guys, and using a driver of there own probably. So im guessing theres something weird with the driver.

Is there some kind of diagnostic program i could run? Some sort of program that shows exactly where things go wrong could be a big help.

Could be the SD card itself, some cheaper brands are known to have problems.

I've tried a kingston 1 GB and a sandisk 128mb. Especially the sandisk one should work on anything.

i dont know if anyone is experiencing this, but when I FAT_fopen(..."r") then close it, then FAT_fopen(..."w") dualis seems to crash when i want to write to the file

on the DS, i believe that it just freezes on the DS, but that may just be because its having the issues with the writing to begin with,

just something that should be looked into perhaps ??? thanks for ur time
_________________
http://www.myspace.com/knight0fdragonds

MK DS FC: Dragon 330772 075464
AC WW FC: Anthony SamsClub 1933-3433-9458
MPFH: Dragon 0215 4231 1206

I'm using the FAT library and what-not from the Moonshell download (one of, if not -the- latest. the first one implementing ezflash4 support).
I've run into a couple of problems compiling it though... see screenshot.

http://www.few.vu.nl/~ssstolk/temp/some_errors.PNG

The purple colour is just me masking what project I'm working on, as to surprise you all with my crappy coding. :) If all goes well, it should be released this month, maybe next, I don't know.
Anyway, most of these warnings I can probably get rid of (like the no-casting warnings), but I'd like to know about the other warnings and how to get rid of them.
I'm assuming I need a "_console.h" which also contains a function called "_consolePrintOne" and I also need something with the function EZSD_GetInterface. Any suggestions/help here?

Thanks in advance.

_console.h is probably a file included with MoonShell that contains the debugging functions. You can safely comment out all references to _console.h and _consolePrintOne without any problems.

EZSD_GetInterface should be included from a file most likely with the name "io_ezsd.h". If that file is not included, try including it. Please note that this is an unofficial version of the library, so I can't help you much further with EZflash support.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Thank you for the quick response. Got it to build properly without any errors or warnings.

The file "io_ezsd.h" was already included, but did not contain a declaration of the function EZSD_GetInterface, even though "io_ezsd.c" did contain that function. Putting that in there got rid of that.

How is the support for M3 SD? In chishm's site that it's partialy supported (read only). That this mean that the reading part si working correctly, but not writing? Or that reading is still in beta and there is just no code for writing?
What happens if you try to write something?

Thanks, and sorry for my english.

Turambar wrote:

How is the support for M3 SD? In chishm's site that it's partialy supported (read only). That this mean that the reading part si working correctly, but not writing? Or that reading is still in beta and there is just no code for writing?
What happens if you try to write something?

Thanks, and sorry for my english.

The supplied version is read only, and doesn't always correctly detect that an M3SD is inserted (false positives / negatives). For this reason, it is disabled by default.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Ok, thanks. Do you think you'll be able to make it work?

Turambar wrote:

Ok, thanks. Do you think you'll be able to make it work?

Actually, that's my current project, and I just made a little bit of progress on it. I won't go into the details here though.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

I've implemented the latest _official_ FAT library, and it interferes with my music playback. My music is decoded by arm9, put into a shared buffer, and read out by arm7. arm7 lets know when it needs new music via IPC communication.

The music played back now has a slight form of crackling. After some debugging, the cause appears to be FAT_InitFiles. After having called that function, the crackling appears. The inclusion of the FAT library itself forms no problem. The crackling only occurs after calling FAT_InitFiles, and it matters not if I did or did not call IO functions of the library after FAT_InitFiles.

I've been looking through the code of FAT_InitFiles and the functions it calls, but I can not find a piece of code which seems threatening in one way or the other.
I know these things though:
- the crackling is not caused by having a too busy CPU (tested for that)
- the crackling is not caused by inclusion of the FAT library
(meaning that it's not caused by global variables memory consumption, unless maybe dynamicly allocated)

So, I thought I'd ask here before trying to rip out functionality to determine what exactly causes this interference with my music. Does FAT_InitFiles somewhere mess with (or use) IPC, interrupts, or malloc-ing of memory? (I could not find these things myself though.) Is there something else you could suggest that might be causing it?

gba_nds_fat does not use malloc, nor does it use interrupts. The IPC struct is accessed only when closing a file, to get the current time and date.

FAT_InitFiles gets an appropriate disc interface, then finds the first valid partition (prefering the active partition). It then gets the information about the file system and readies all available file pointers.

After FAT_InitFiles has completed, nothing will still be running in the background. The only possible exception that I can think of is that both cart / card slots are accessed during the function, and the hardware may be setting off interupts (as an unintended side-effect that I haven't seen before).
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

I have only a flashcard in the GBA slot, no media based card. I let FAT_InitFiles be called nevertheless, to accomplish better compatibility with all types of cards. At my card it returns false, obviously. But with other cards it provides extra functionality.
This means I can not fathom the card itself setting of interrupts. Perhaps (one of) the slots do though, I do not know that as of yet.

I shall try to debug the library further and will let you know the outcome. I thank you for the quick response.

What happens if you try calling FAT_InitFiles() before setting up your sound playback?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Genious in its simplicity, but it failed to work. Thanks anyway. :)

edit:
I've tracked it down to:
WAIT_CR &= ~(0x8080);
The effect is only caused by disc_setGbaSlotInterface. Other statements in that function could also be causing it, but this is the first statement in that function which already has that effect.

I myself have been using
WAIT_CR &= ~0x80;
for use with SRAM, which did not cause any trouble with the music.

Would that suffice in the FAT lib? Or does it really need to be &= ~(0x8080)?
Or alternatively, would it be okay to modify things so that WAIT_CR only has that value when FAT functionality is called?

Dark Knight ez:
You just sent me on a half hour trail, with the conclusion that NDSTek was wrong and libnds is wrong about WAIT_CR. After testing it myself, I've discovered that bit 15 controls main RAM priority, not GBA cart SRAM ownership.

This will be fixed in the next version of the FAT library, but in the meantime you can modify the WAIT_CR setting to not modify the RAM priority bit.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Good thing it was discovered, in that case. ;)
Changing it solves the issues I've had with the music, which now makes sense considering a shared buffer in RAM is used for it.

Hello,

I've not tried to use the library yet, but was wondering if it supports the SuperCard SD? I've read that it's disabled by default since the author doesn't have one of these cards.

I have one, so is there anything I can do to help with SC SD support?

Is the latest version of the lib only available at http://chishm.drunkencoders.com/gba_nds_fat/index.html ? The last release was 03/03/06, but Chishm's progress reports in this thread are newer.

Thanks for your help,
Pete
_________________
http://aaiiee.wordpress.com/

It doesn't support SC SD saving, and the card detection returns false positives when an SC CF is inserted. You can try enabling it if you want.

That is the address with the latest updates. I haven't made any releases since then, since I am completely rewriting the library, which takes time.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Two questions:

1) Are there any tutorials/examples/up-to-date documentation about how to start using this? Do you include fat.h (that comes with libnds) or gba_nds_fat.h? Which is the most up to date?

2) Are there emulators that support Chishm's FAT? If not, is there any way for me to write code on PC implementing file IO that will work on DS right away? I guess maybe the GBFS?

Thanks.

EDIT: I have looked around but anything I've found seems to be out of date with the latest lib...

you obviously didn't look hard enough i mean chishm released a new lib about 10 posts below this one which uses standard stdio and you only need to #include <fat.h> the instructions are in the thread/zip

Great, thanks. I had found that thread before... whatever. Thanks!

There were huge problems with a 4MB FAT32 disk image I created with linux, it got misdetected as FAT16. However, I wouldn't expect the code to be patched up for some case this obscure.

I encountered it because I was working on a little extension, making it load disk images stored in rom, and saving up to 63.5k of altered sectors into SRAM, making it look like it's writing to the read-only filesystem. Mainly so I can test out programs that use the filesystem in emulators which do not emulate the GBAMP. I was testing it out on that 4MB FAT32 disk image, and kaboom, big problems. Maybe FAT16 is more suitable for that disk size :)
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

Dwedit wrote:

There were huge problems with a 4MB FAT32 disk image I created with linux, it got misdetected as FAT16.

The official MS-FAT subtype detection algorithm depends entirely on the number of clusters. Disks with fewer than about 65,500, such as any disk below 32 MB, will be detected as FAT16. Disks with fewer than about 4,000 will be detected as FAT12.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tepples wrote:

Dwedit wrote:

There were huge problems with a 4MB FAT32 disk image I created with linux, it got misdetected as FAT16.

The official MS-FAT subtype detection algorithm depends entirely on the number of clusters. Disks with fewer than about 65,500, such as any disk below 32 MB, will be detected as FAT16. Disks with fewer than about 4,000 will be detected as FAT12.

In fact, MS-FAT lists as a requirement that disks with fewer than 65525 clusters be considered FAT16 (or FAT12 if it has fewer than 4085 clusters). So the bug lies in whatever program allowed you to create a non-conforming MS-FAT partition.

For the ROM extension I suggest you take a look at FCSR.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

chishm wrote:

For the ROM extension I suggest you take a look at FCSR.

Google doesn't help:

Family Care Safety Registry?
Foundation for Corporate Social Responsibility?
Florida Center for Science and Religion?
Football Club Sportif Rumilly?
Futbol Club Santa Rosa?
Florida Child Support Resources?
Fayette County Search & Rescue?
For Scotland's children report?
Feedback with carry shift register?
Florida Citizens for Social Reform?
Floating Point Condition and Status Register?

Not everybody can find "flash cart static random [access memory]". It'd be better if you expanded the acronym in the supported devices section of FAT Library Classic web page so that people have an idea of what you're talking about.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

regarding fread i was thinking it is possible to optimise the process by getting a certain portion of the data in the file (like memcpy) rather than the whole thing

this would greatly increase data retrieval speed (especially if users use memcpy after that [using only part of that data and not using the rest at all])
and if so , even reduces the strain on the ds internal memory as getting a portion of the data does not require that much space as compared to the whole chunk

hope this would increase the speed of future homebrew to come

lets make homebrew better!

What is the current status of the FAT driver? Have any bugs been squashed in the current ndslib version that have not yet been backported to the classic driver?
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

dh2050:
That's pretty much how fread works already. However, disks have to be read/written in 512 octet chunks known as "sectors". That is why it reads at least this amount of data at least once. Sectors are cached for consecutive reads.

Dwedit:
libfat is reentrant, which the lack of can be considered a bug in gba_nds_fat. It also has rewritten filename creation / deletion code that hasn't caused any trouble so far.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Quote:

That's pretty much how fread works already. However, disks have to be read/written in 512 octet chunks known as "sectors". That is why it reads at least this amount of data at least once. Sectors are cached for consecutive reads.

well since fread reads in chunks, is it possible to read a certain selected chunk rather than all the chunks together?

im intending to get a small portion out of a sea of data (eg: 2mb)
and display it on the screen

Use fseek to select what you want to read, then fread to read it. The driver will only read the sectors necessary to get that data.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

I hope you've signifigantly improved the writing code in this version. Two different CF cards, using a GBAMP, have become corrupted nearly every time I save something in a DS app. It makes a lot of homebrew - especially emulators - quite useless when your data keeps getting wiped out! >8^(

[edit] OK, either it or Windows just ruined my 4GB CF card, which is now an unformattable 2GB card. Windows hasn't done this sort of thing before, so... :-/ No low-level format programs can even write to it. Any ideas?
_________________
I'm a PSP hacker now, but I still <3 DS.

I usually just overwrite the first sector of the disc with all 0s. This causes Windows to see it as unformatted and then formats it.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

I've been trying that, but I can't write to sector 0.

[edit] To be specific, I open it in Hex Workshop and can see a bunch of garbage data. Any attempts to write to this sector show errors saying the drive is locked or not ready. Upon opening it I get an error as well:

Quote:

This drive contains a layout irregularity- the partition (4048380 sectors) appears to be larger then volume (4061232 sectors). This is likely a corrupt drive or some form of copy protection.

I've tried just about everything I can think of. Windows-based low-level format tools, DOS-based, Linux based, "cat /dev/zero > /dev/hda1" in DSLinux booted from another CF card, backing up a save file in Rein (also booted from another card; I heard this helps, but it fails to write). All of these low-level format tools fail to write to nearly every sector and have no effect. It blank-screens (doesn't even boot to GBA mode) if I try to boot with it in DS mode, and the GBAMP complains it's not formatted in GBA mode.
Rein booted from WMB does the same as booted from another card (CF not ready), and DSLinux booted from WMB shows a number of FAT errors then "init: /usr/bin/agetty exec failed" and "init: /usr/bin/agetty respawning too fast" over and over. So I'm officially out of ideas.

Also, Windows already sees it as unformatted but fails to format it.
_________________
I'm a PSP hacker now, but I still <3 DS.

According to the website TestDisk can recover partitions and might help with the issue of being able to format again and even getting the data you lost off. I used it on a disk with NTFS and it worked somewhat. The drive was failing so the recovery could not write the fixed data back. It can be found here and it's free.

http://www.cgsecurity.org/wiki/TestDisk

Like all the other tools it detects the card as 2GB (which, according to the documentation, basically means it won't be able to help) and gives write errors if I try to do anything to it.
_________________
I'm a PSP hacker now, but I still <3 DS.

I'd say your partition table is corrupt. Instead of editting the logical disk, you'll need to edit the physical disk.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

That's what I've been doing... at least in programs like Hex Workshop, I choose physical disk and it still says 2GB and can't write.
_________________
I'm a PSP hacker now, but I still <3 DS.

I found this on the internet and thought it might thow some more information on the SD issue.

http://www.luminous-landscape.com/reviews/accessories/4gb-sd.shtml

I know you said hex edit was complaining but here is something someone else did to get the drive so the OS would reformat:

Quote:

At first, you need a HexEditor. http://www.sweetscape.com/010editor/

Put your card in the cardreader and run the Programm.

Choose "Open Drive" from the Menu and select the Physical Drive of your SD-Card.

Choose "Edit" -> "Select Range" from menu.

Start Address: 0
Size: 512

Press OK

Select "Edit" -> "Fill Bytes" from menu

Start Address: 0
Size: 512
Hex: 0
Decimal: 0

Press OK

Save.

After this the author got the system to reformat the SD card. But there are many complaints that certain reader were having problems with the 4GB format cards. I assume since you already had stuff on it that you were using it before and this is a new issue.

There is also this approach which might help:

Quote:

ust incase anyone is still having trouble formatting in XP, u can try loading a live linux CD like Ubuntu or Knoppix and running these commands to format your sd card;

0. insert SD card + reader into USB slot. boot PC from live linux cd.
1. find out about your SD card ' dmesg |grep sd '. this will tell you your device location. (/dev/sda in my case)
2. ' cfdisk /dev/sda ' to partition it. create a new primary partition, change type to ' 0C '.
3. ' mkfs.vfat -F 32 /dev/sda1 '

4. Done.

It's a CF actually. I found someone else who had the same problem, and they were told to delete any existing partitions with Ranish Partition Manager. I tried that but there's only the Master Boot Record; I can do whatever I want and it says the changes have been saved, but nothing actually changes (all other software gives write errors so I imagine it's just ignoring them and assuming nothing went wrong), plus even it reports 2GB. It shows other odd things like a cluster size of 77K and 1007 cylinders, but I can't edit any of it.
Given that the card is completely unwriteable I'm going to just try to have it replaced and file this under coincidence, but it wouldn't be the first time by a long shot that DS homebrew using gba_nds_fat has corrupted my CF card.
_________________
I'm a PSP hacker now, but I still <3 DS.

The last one using the linux could work for both unless the media itself is flaky. The advantage of using the linux is that it can "usually" do rw reads and writes with no problems. I wonder if these cars use CRC's or something like it to record data and that data is corrupt so it refuses to write sonething less than one of it's "sectors". Sorry, I do not know much of the underlying technology.

If your card is that beyond repair, I wouldn't be so hasty to blame gba_nds_fat. The only commands it issues to the CF card are read sectors (ATA command 0x20) and write sectors (ATA command 0x30). Even if the card format is completely screwed, you should still be able to raw read/write the card and recover it that way.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Yeah, I suspect one of the flash chips just pooped out or something. gba_nds_fat has corrupted data a number of times on that and another card though.
_________________
I'm a PSP hacker now, but I still <3 DS.

Quick question, chishm, based on what you said in another thread awhile back:

Quote:

I thought I might post a progress update. It turns out that the M3SD driver I wrote works so well even the new micro is supported (well, that's what I've been told). I have also updated the SCSD driver to support the SC Lite. Directory listing is added to the library code, but it requires an update of DevkitPro that isn't released yet.

Does that mean M3Lite MicroSD support (I assume that's what you meant by 'the new micro') is working in the CVS version but also requires the unreleased devkitpro update?

Thanks!

There has been a report that 1GB microSD cards don't work, however, 512MB did work. SCLites in both cases.
_________________
http://licklick.wordpress.com

I wonder if some flash card companies are reluctant to release their hardware info for fear of commercial games deleting the ROMs on the card? Has that ever happened? The only other real reason I can think of not to release it is that they don't want someone to make third-party flashing software, but that's rather silly when you still need to buy the card to use it. Makes some sense for those cards that have a separate flashing device you have to hook up to your computer, but I haven't seen one of those in a while.
_________________
I'm a PSP hacker now, but I still <3 DS.

Hm, I did a bit more research and it just seems to be deleting that causes problems. Pretty much every time I delete something in DSOrganize, something else goes boom. Which I suppose could be a DSO bug, but it's probably worth checking out. It's getting to where any delete operation (except in Windows) obliterates the entire filesystem and only an error check followed by a format - if anything at all - will restore the card to a useable state. (Specifically, a Transcend 120x 4GB.)

[edit] Judging by the card's corruption every time I write to it in Windows now, I'd say the problem isn't gba_nds_fat so much as Transcend. >_>
_________________
I'm a PSP hacker now, but I still <3 DS.

Could I make a request for a feature to add to the FAT library?

I'd really like to be able to set a flag that automatically flushes every write to the card. Yes, I understand that this will negatively impact the lifetime of the card.

However, when debugging, I often write debug statements to flash as well as the screen so that I can record what is flying past. If the system crashes, the file is "empty" since it never wrote the used sector metadata to the directory entries.

I can submit a patch, if desired. Basically, I refactored the close() code into flush() and close() and made write() call flush() every time through.

Yeah, performance sucks, but it's sometimes the only way to debug a really thorny problem.

Alternatively, a command to manually flush the cache would work, too.

Thanks.

I'm having problems with the latest libfat (libfat-nds-20061028.tar.bz2) as well with older libfats. I'm trying to read binary files into memory but the bytes with value 0x0a which is "\n" (carriage return) cause problems. Some lib code tries to interpret this byte as a text byte. I haven't found out yet where this happens.

Once libfat reads this byte all following read bytes have different values compared to the file displayed in my hex viewer. I'm opening my files with file = fopen("book.bin", "rb") but the "rb" flag makes no difference to "r" only.

Example snippet from my bin file:

00000060h: 00 00 FF FF 5A 8A 01 A2 0A 63 38 AA 07 00 00 60

And in my array after i used the fget function:

00000060h: 00 00 FF FF 5A 8A 01 A2 0A 00 FF FF 20 A4 74 27

all bytes following after "0A" are incorrect and do not exist in my bin file. Once i send a new fget the bytes are ok again until i reach 0A again.

any ideas?

'\n' is new-line, 'r' is carriage-return. When using fgets(), '\n' is interpreted as the end of a string. It will stop reading the file when a new-line character is encountered. Those garbage values in the array are not actually read from the disc. They are simply values that were already in memory.

To read a block of data of a certain length, use fread().

EDIT: I might as well add that gba_nds_fat is no longer being worked on. If you have any bugs/requests that aren't in libfat, post them to the current libfat thread.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

chishm wrote:

I might as well add that gba_nds_fat is no longer being worked on.

Fixed subject.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Well, i'm a kinda noob on this stuffs but is there anyway to make it work on a M3 Adapter SD?

Easy. Just send money to wintermute and hope he gets devkitPro r20 out soon.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

what is the code you have to do in GBA_NDS_FAT to support DLDI?

What do you put in disc_io.c?

Ex.

#ifdef SUPPORT_M3CF
// check if we have a M3 perfect CF plugged in
active_interface = M3CF_GetInterface() ;
if (active_interface->fn_StartUp())
{
// set M3 CF as default IO
return true ;
} ;
#endif

Pretty much just copy that code, but change it to reference DLDI_* instead. Place this as the first disc tested for both Slot-1 and Slot-2. Also make sure to #include "io_dldi.h".
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

chishm wrote:

Pretty much just copy that code, but change it to reference DLDI_* instead. Place this as the first disc tested for both Slot-1 and Slot-2. Also make sure to #include "io_dldi.h".

so put "DLDI_interface" instead of "Active_interface"

No. Copy one of the interface checks and put

Code:

active_interface = DLDI_GetInterface() ;

instead of

Code:

active_interface = MCF_GetInterface() ;

_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

[DELETED] to be honest I was just testing the quick reply in a sticky as it is not working in a sticky on another site; but forgot that deleting was removed.

Given that I can't think of any developers other than DragonMinded who are still using this library, I'm going to let it fall off the sticky section.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

probably for the best

I was actually thinking of asking for this to be unstickied a few months back, but I never got around to asking.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

gbadev.org forum archive

DS development > Chishm's gba_nds_fat (legacy)

#57612 - chishm - Mon Oct 17, 2005 11:52 am

#57613 - chishm - Mon Oct 17, 2005 11:53 am

#57620 - Lukaso - Mon Oct 17, 2005 12:27 pm

#57626 - sasq - Mon Oct 17, 2005 1:03 pm

#57627 - El Hobito - Mon Oct 17, 2005 1:10 pm

#57760 - chishm - Tue Oct 18, 2005 8:11 am

#58033 - Mighty Max - Thu Oct 20, 2005 10:34 am

#58042 - pepsiman - Thu Oct 20, 2005 12:06 pm

#58075 - dovoto - Thu Oct 20, 2005 5:32 pm

#58077 - tepples - Thu Oct 20, 2005 5:41 pm

#58084 - dovoto - Thu Oct 20, 2005 6:45 pm

#58366 - Mighty Max - Sat Oct 22, 2005 11:00 pm

#58367 - agentq - Sat Oct 22, 2005 11:02 pm

#58368 - Mighty Max - Sat Oct 22, 2005 11:05 pm

#58388 - Dwedit - Sun Oct 23, 2005 2:43 am

#58392 - chishm - Sun Oct 23, 2005 3:59 am

#58419 - agentq - Sun Oct 23, 2005 2:06 pm

#58642 - Dwedit - Tue Oct 25, 2005 12:56 am

#58655 - chishm - Tue Oct 25, 2005 2:24 am

#59380 - Dwedit - Tue Nov 01, 2005 4:29 am

#59381 - tepples - Tue Nov 01, 2005 4:55 am

#59383 - chishm - Tue Nov 01, 2005 6:31 am

#59608 - Dudu.exe - Wed Nov 02, 2005 9:42 pm

#59622 - chishm - Wed Nov 02, 2005 10:29 pm

#59862 - Dwedit - Fri Nov 04, 2005 6:40 pm

#59879 - agentq - Fri Nov 04, 2005 10:30 pm

#59883 - Mighty Max - Fri Nov 04, 2005 10:51 pm

#60834 - slizekalfer - Tue Nov 15, 2005 5:57 am

#60835 - Dwedit - Tue Nov 15, 2005 5:59 am

#60919 - tepples - Wed Nov 16, 2005 2:45 am

#60959 - amiga - Wed Nov 16, 2005 9:39 am

#60972 - chishm - Wed Nov 16, 2005 11:13 am

#61015 - Joat - Wed Nov 16, 2005 7:25 pm

#61109 - chishm - Thu Nov 17, 2005 10:03 am

#61243 - Dwedit - Fri Nov 18, 2005 11:53 am

#61248 - chishm - Fri Nov 18, 2005 1:22 pm

#61255 - cory1492 - Fri Nov 18, 2005 2:16 pm

#61288 - Dwedit - Fri Nov 18, 2005 8:08 pm

#61292 - Dwedit - Fri Nov 18, 2005 8:43 pm

#61333 - chishm - Sat Nov 19, 2005 12:46 am

#61351 - tepples - Sat Nov 19, 2005 3:48 am

#61362 - chishm - Sat Nov 19, 2005 7:26 am

#61386 - tepples - Sat Nov 19, 2005 6:21 pm

#61397 - Dwedit - Sat Nov 19, 2005 7:50 pm

#61433 - chishm - Sun Nov 20, 2005 3:22 am

#61782 - agentq - Wed Nov 23, 2005 1:09 pm

#61811 - agentq - Wed Nov 23, 2005 9:50 pm

#61817 - chishm - Wed Nov 23, 2005 10:53 pm

#61820 - agentq - Thu Nov 24, 2005 12:01 am

#61828 - chishm - Thu Nov 24, 2005 2:15 am

#61842 - cory1492 - Thu Nov 24, 2005 6:44 am

#61844 - chishm - Thu Nov 24, 2005 7:04 am

#61845 - cory1492 - Thu Nov 24, 2005 7:29 am

#61856 - chishm - Thu Nov 24, 2005 8:42 am

#61858 - devmani - Thu Nov 24, 2005 8:51 am

#61861 - cory1492 - Thu Nov 24, 2005 9:14 am

#61863 - chishm - Thu Nov 24, 2005 9:39 am

#61974 - chishm - Sat Nov 26, 2005 2:02 am

#61995 - cory1492 - Sat Nov 26, 2005 8:57 am

#62011 - chishm - Sat Nov 26, 2005 1:13 pm

#62045 - agentq - Sat Nov 26, 2005 8:13 pm

#62050 - FloFri - Sat Nov 26, 2005 9:49 pm

#62051 - agentq - Sat Nov 26, 2005 10:24 pm

#62071 - chishm - Sun Nov 27, 2005 4:31 am

#62112 - agentq - Sun Nov 27, 2005 3:24 pm

#62738 - cory1492 - Mon Dec 05, 2005 6:32 am

#62740 - chishm - Mon Dec 05, 2005 6:52 am

#62831 - cory1492 - Tue Dec 06, 2005 8:15 am

#64080 - Dwedit - Mon Dec 19, 2005 6:37 am

#64101 - chishm - Mon Dec 19, 2005 11:14 am

#64537 - Dwedit - Fri Dec 23, 2005 9:28 am

#64618 - chishm - Sat Dec 24, 2005 9:07 am

#65601 - chishm - Wed Jan 04, 2006 9:09 am

#65611 - darkfader - Wed Jan 04, 2006 11:11 am

#71076 - chishm - Fri Feb 10, 2006 6:42 am

#71083 - Dwedit - Fri Feb 10, 2006 7:10 am

#71085 - chishm - Fri Feb 10, 2006 7:58 am

#71124 - hoagie - Fri Feb 10, 2006 2:54 pm