gbadev.org forum archive

After many hours, days, weeks and months of work, I have gotten the new libfat to a stage ready for testing.

To try it, get libfat-20060709.tar.bz2 from my site.

To install, extract the archive to your libnds directory, so you should have /path/to/devkitpro/libnds/include/fat.h and /path/to/devkitpro/libnds/lib/libfat.a .

To use, you'll need to #include <fat.h> in the file where the library will be initialised, and #include <stdio.h> in any source file that needs file access. In your makefile, add libfat to the list of libraries, before libnds. You'll also need to link in libnds. Eg:

Code:

LIBS := -lfat -lnds9

In your program initialisation code, add a call to fatInitialise. The first parameter specifies the size of the sector cache in pages and the second parameter determines if this is to be the default file driver. For 4 cache pages and setting this as the default I/O device, use:

Code:

if (fatInitialise(4, true)) {
// Success
} else {
// Failure
}

It needs a minimum of 2 cache pages to operate efficiently. Memory is malloc'd for this, so you'll need malloc for it to work. Each page takes about 550 bytes of memory. Use more pages for extra speed when randomly accessing files.

Once the driver is initialised, files are accessed like in normal C implementations. Use FILE* file = fopen (path, mode); to open a file, for example. If this has been set as the default I/O device, the path is simply of the form "/path/to/file". If this isn't set as the default device, you'll need to specify the device in the path, eg "fat:/path/to/file". "fat:" tells open to open files using the FAT device. There is support for using a device in both slots at once. "fat0:" is equivalent to "fat:", and uses whichever slot it finds a valid device in first (starting with slot 1). "fat1:" specifies slot 1 (the DS Card). "fat2:" specifies slot 2 (the GBA slot). "fat3:" specifies a custom device (this isn't externally visible in the library yet).

Directory listing isn't available, since DevKitPro r19a doesn't have this functionality yet.

Keep in mind that this is still in alpha stage. Functionality will be added and possibly changed in future releases. Also, it requires at least DevKitPro r19 to function.

EDIT:
Latest version comes with DevkitARM r20. Full instructions are on my libfat page.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Last edited by chishm on Thu Feb 15, 2007 1:17 am; edited 2 times in total

Great work! Which devices are supported now?
_________________
"no offense, but this is the gayest game ever"

chishm wrote:

After many hours, days, weeks and months of work, I have gotten the new libfat to a stage ready for testing.

To try it, get libfat-20060709.tar.bz2 from my site.

For those confused by "tar.bz2", that's the extension for a popular compression format on FreeBSD and Linux. Developers on Windows can use 7-Zip to extract it.

Quote:

To install, extract the archive to your libnds directory

Is the DS-only restriction just for this test version, or have you end-of-lifed the GBA version entirely?

Quote:

It needs a minimum of 2 cache pages to operate efficiently. Memory is malloc'd for this, so you'll need malloc for it to work.

If you have not EOL'd the GBA version does anyone know how to trick malloc into starting its heap from an arbitrary EWRAM address instead of from the end of the multiboot program?

Quote:

There is support for using a device in both slots at once. "fat0:" is equivalent to "fat:", and uses whichever slot it finds a valid device in first (starting with slot 1). "fat1:" specifies slot 1 (the DS Card). "fat2:" specifies slot 2 (the GBA slot).

Is fat1: compatible with Nitro FAT on a DS Game Card or compatible flash card, or only with MS-DOS FAT in the MK2/MK3 adapter? The distinction becomes important 1. for homebrew modding of games stored on DS Game Cards, and 2. once UltraFlashPass and similar cards become popular.

Quote:

"fat3:" specifies a custom device (this isn't externally visible in the library yet).

Would this be flexible enough to accommodate CIFS or HTTP?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Would the fat3 "drive" be capable of handling flat-file FAT, like a FAT GBFS?
_________________
Squak! etc.
My Blog

Can it be run without caching?

[edit] Also will we be able to determine how much disk space is available, and will you add some form of directory listing function?
_________________
I'm a PSP hacker now, but I still <3 DS.

So this is just for standard library file IO functions? Any differences between this and the gba_nds_fat library?
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

As far as I can tell, this replaces at least the nds part of gba_nds_fat in the same way that SnezziDS replaces snesDS.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Ok, I'll answer the questions in order of posting.

Supported devices: Neoflash MK2/3, GBAMP CF, M3 CF, M3 SD, SC CF, Flash Carts (search the forums for FCSR).
Unconfirmed but included: Max Media Player/Dock, EFA2
Included but not working: SC SD
Unsupported: Anything else.

The DS only restriction is only for this build, since I haven't finished getting the GBA build to work. I'll probably make it used a fixed cache size and static allocated memory.

All "fat[0-3]:" devices only support MS-DOS FAT. For other filesystems, it is better to write a new filesystem driver from scratch and implement it the same way as libfat -- using the devoptab in DevKitPro (see <sys/iosupport.h>).

"fat3" is intended for using hardware devices that haven't been incorporated into the library yet. For example, if a new cart comes out that hasn't been incorporated into the library yet then it can still be used by developers by mounting the custom device.

It can't be run without caching, since the unified disc cache replaces several caches that were in the old version. In gba_nds_fat, the FAT had it's own cache, as did each openned file. That's why at least 2 pages are needed.

This is a more efficient implementation of file I/O functions. In gba_nds_fat, I had to implement fopen, fputs, etc. Now I only have open, close, read, write and a few other functions implemented, and newlib handles the rest. This means other filesystems will use the same fputs, etc functions too. In case you didn't check, fat.h only has one function, used to initialise libfat. The rest is done through callbacks provided to newlib through the devoptab. We should be very thankful that WinterMute provided the devoptab.

File listing won't be available until it is included in the devoptab.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Wow I like the new way of doing things, Its much easier to setup than the older lib.

Also it works fine on my m3sd, nice work on the driver chishm :)

are you planning to make SC:SD support in the future?

What about the MiniSD/MicroSD Devices?

dawn2k wrote:

What about the MiniSD/MicroSD Devices?

MiniSD to my knowledge uses the same interface as the normal sized SD cards so should work using the SD drivers

thank god, maybe now more homebrew will support SD devices like the M3. Flash cart file manager anyone?

Please pardon my n00b question, but what immediate effect does this have? This library handles the reading and writing through the flashcart to the media storage, right?
*runs and hides*

Hm, sounds great, but I guess we'll have to use soft-shutdown functions now due to the caching (unmount, then power off, instead of using the power button)? Either way its usefulness is rather limited without a directory listing function.
_________________
I'm a PSP hacker now, but I still <3 DS.

D-loader:
I would if I had a SC:SD. I've tried a few times to get it working, but without hardware to test it on, it's practically impossible.

HyperHacker:
The cache is flushed when files are closed or deleted, so as long as you close files when you are finished with them (which you should be doing anyway) it will be fine.

ThetaDot:
I guess you could say that.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

thank you for your work !
does this first release support G6 linker for example !
_________________
I'm not inglish, sorry for my bad inglish :-/

At least read my answers in this thread before posting questions.

Chishm wrote:

Supported devices: Neoflash MK2/3, GBAMP CF, M3 CF, M3 SD, SC CF, Flash Carts (search the forums for FCSR).
Unconfirmed but included: Max Media Player/Dock, EFA2
Included but not working: SC SD
Unsupported: Anything else.

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

if Max Media Dock is supported by this fat library, does that mean that the Max Media Dock can/will be as homebrew capable as the gbamp?

First you'll have to implement exec() on top of this library, as MAX Media Player doesn't seem to support .nds files larger than 1 MB.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

I have added everything I wanted to, so here it is, the latest version:
Source
DS library
GBA library
As before, you need DevKitPro r19 to use this. The GBA version still uses malloc (it's unavoidable), but there is a bug in DKP r19(a) that causes malloc to fail for gba_mb specs. Therefore, the GBA version will need DKP r20 when it's out.
To compile the source, run make where you extracted the library. To install the NDS library in windows, download it to a folder and at a command line in that directory run:

Code:

bzip2 -cd libfat-nds-20060712.tar.bz2 | tar -xv -C %DEVKITPRO%/libnds

bzip2 and tar are included with DKP, so this should work.
Likewise for the GBA library run:

Code:

bzip2 -cd libfat-gba-20060712.tar.bz2 | tar -xv -C %DEVKITPRO%/libgba

Usage of the library is the same as before. This is still in alpha, as function names may change again. Make sure to backup any media that you run this on.

EDIT:
Forgot to mention that errno is now supported. Simply #include <errno.h> and use it like normal.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

There is now source code to libfat in the devkitPro CVS repository. All future source code updates will be committed to the repository.

Also, libfat is still in alpha stage, as there aren't any directory listing functions yet.

PS, I thought this news was bump worthy.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Exactly what would it take on your part and on wintermute's to get <dirent.h> and <sys/stat.h> working?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tepples wrote:

Exactly what would it take on your part and on wintermute's to get <dirent.h> and <sys/stat.h> working?

stat and fstat work already. Directory listing needs some more functions added to devoptab_t (the structure of function pointers used for each stdio device) by WinterMute. Once that is done, I need to implement the functions within libfat. The changes to devoptab_t will need a new DKP release, and a new libfat release should follow soon after.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Great work Chishm! I've been waiting unified / clean fat lib for a while and all the sudden it's here.

My two cents to the continuous "can you support this and this device" requests: Have you tried contacting flash card manufacturers asking for receiving free test adapters? To me it sounds like for example Supercard would benefit if they sent a free copy to you for testing, if that'd mean probable support for SC SD adapters. In the end lot of the flash card users are after homebrew - it'd be mutual benefit for both the card manufacturers and the homebrew community. Same goes for M3, G6... perhaps even GBAMP SD? :)

Or even making a page where people can donate money to get you to support their favorite adaptor...i know i'd throw in a few bucks

I'd be very tempted to throw in some change toward an SC SD adapter for you.. paypal or something?

Yeah just get a donations page up already, I'm sure plenty of people would throw in a few bucks to finally get full SCSD support.

Well I got a Supercard SD adapter donated yesterday, thanks to NorQue. I'll work on it as soon as I get time (busy with life, etc.).
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

New lib out. The source is in DevkitPro CVS, or you can just use the precompiled GBA version or the precompiled NDS version.

A few bugs in the FAT handling code have been fixed thanks to loopy. There is now a fatInitDefault() function to make it even easier to use. There may be a few other bugs fixed that I've forgotten about. Also, there is now full Supercard SD support.

Some of you may notice that I use ASM code in the SCSD driver. This is allowed within libfat, and is part of the reason I made it a proper library. That being said, I only used it because it was necessary for hardware timing accuracy, and I'd still prefer the drivers to be written in C.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Thank you very very much for the SuperCard SD support. I really appreciate it.
_________________
http://aaiiee.wordpress.com/

Chishm, I had couple of quirks I have when using the latest CVS version out of the box with my own project space. Nothing major though, but I decided to paste these here just because of the 'long long long' line. :)

Code:

c:/devkitpro/libnds/include/nds/jtypes.h:109: error: 'long long long' is too long for GCC
c:/devkitpro/libnds/include/nds/jtypes.h:109: error: declaration does not declare anything
c:/devkitpro/libnds/include/nds/jtypes.h:127: error: multiple types in one declaration
c:/devkitpro/libnds/include/nds/jtypes.h:127: error: declaration does not declare anything
c:/devkitpro/libnds/include/nds/jtypes.h:158: error: redefinition of 'struct touchPosition'
c:\devkitpro\libnds/include/nds/jtypes.h:158: error: previous definition of 'struct touchPosition'
c:/devkitpro/libnds/include/nds/jtypes.h:165: error: invalid type in declaration before ';' token
c:/devkitpro/libnds/include/nds/jtypes.h:165: error: conflicting declaration 'typedef int touchPosition'
c:\devkitpro\libnds/include/nds/jtypes.h:165: error: 'touchPosition' has a previous declaration as 'typedef struct touch Position touchPosition'

This when compiling, removing #include <nds/jtypes.h> from fat.h line 51 fixed the errors for me.

Code:

c:\devkitpro\libnds/lib\libfat.a(io_nmmc.o): In function `_Neo_SelectMMC':
c:/projects/nds/libfat/nds/../source/disc_io/io_nmmc.c:106: undefined reference to `cardWriteCommand'

This when linking. Just removed the NMMC support from disc.c as I don't need it myself right now, bypassing this problem.

There's something very very wrong with your devkitARM installation. This looks like you've somehow managed to break the header guards in jtypes.h or have something else included before which is breaking things.

What do you mean with your own project space? The CVS version is a library meant to be built on it's own and linked against, not copied into your project like the older one.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

My bad. The first one was mangled code, and the linking error was a result of passing -lfat after -lnds9 to the linker, not the other way around. Nothing wrong with the libfat.

melw wrote:

My bad. The first one was mangled code, and the linking error was a result of passing -lfat after -lnds9 to the linker, not the other way around. Nothing wrong with the libfat.

I had the same exact problem...but I didn't see your post in time to warn you :P

Personally I can never remember the order in which to link libraries, so if I get 'undefined reference to ...', and I'm pretty sure it is defined, I just twiddle with the order of the -l commands to the linker.

---

Also, in a preliminary testing of libfat, by replacing fatlib usage in my code, appears to output 0-byte files. (on SC CF). I will also test on gbamp, and also run chkdsk, perhaps my CF card is corrupted (by some other buggy homebrew).

EDIT: It appeared to be just a onetime glitch...chkdsk'd my card, then ran it again, and it seems to work fine. Loading is currently disabled, since I can't list files yet.

If anyone wants to test this on their device and report back, please go ahead. I tested with success on GBAMP and SC CF.

NDS version | .DS.GBA version | My site

Doing some testing with libfat myself, and though I can read files (on my GBAMP with DSlite) just fine, I am having trouble outputting to a subdirectory.

Here's the latest incarnation of my code (please forgive its ugliness):

Quote:

// Write to a file
FILE *ostream, *fopen();
if ( (ostream = fopen ("/data/write.txt", "w"))) { // Open file
char x[10] = "0123456789";
fwrite(x, sizeof(x[0]), sizeof(x)/sizeof(x[0]), ostream);
fclose(ostream); // close file
iprintf("\n\n\tWrote to file\n");
}

If I take out /data, it writes the file just fine. Am I doing something wrong?

EDIT: Oh, I remember seeing that libfat couldn't list directories, is this basically the issue?

- Aaron Rogers
http://www.aaronrogers.com/nintendods/

I tried that code, and I did manage to get it to fail. To do this I had to create a new directory and write the file into that. I have fixed that particular bug, so when writing to the end of a directory, the file should work. Updated code is in CVS.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Have done now some tests with M3, both CF and SD versions. With M3CF both the saving and reading the files work just as it should, but with M3SD fatInitDefault() returns false - same when trying something like fatInit(4, true). Not sure if the M3 firmware version has anything to do with the issue, I'm still using E18 due to problems reported with newer drivers.

Josath, with Draw3 test the M3CF outputs right away a blank/white .png but keeps jamming after that. With M3SD I can draw and it says it's saving when I press 'x' but no files are written on the memory card. If you could add an extra check to show on screen whether fatInit() fails that would be helpful with testing...

Quote:

Updated code is in CVS.

Works great, thanks!

Next question, what if I want to create a directory? Is that possible/easy to do?

- Aaron Rogers
http://www.aaronrogers.com/nintendods/

chishm wrote:

Some of you may notice that I use ASM code in the SCSD driver. This is allowed within libfat, and is part of the reason I made it a proper library. That being said, I only used it because it was necessary for hardware timing accuracy, and I'd still prefer the drivers to be written in C.

If it requires exact timing, how does it work on both a GBA and NDS?
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

Either separate binaries with the exact timing adjusted, or the timing depends on the speed of the GBA cart bus interface, which can be made the same in both modes.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Dwedit wrote:

If it requires exact timing, how does it work on both a GBA and NDS?

tepples wrote:

Either separate binaries with the exact timing adjusted, or the timing depends on the speed of the GBA cart bus interface, which can be made the same in both modes.

The second one. It uses stmia to transmit 4 halfwords to the GBA cart (16 bits per transfer). The first halfword contains the data to be written, and the next 3 (along with the first) provide clock signals for the Supercard's internal circuitry to break that data into 4 nibbles and transmit them to the SD card. I tried to do it in C, but I can't guarantee that the compiler will compile to stmia, and 4 lots of strh doesn't work.

arog:
Not as yet. Directories aren't fully supported within devkitPro yet, which is why libfat is still in alpha.

melw:
It may be due to your SD card. SD cards have a wider range of quality and abilities compared to CF cards, and I only have 1 type of SD card to test with.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

I'm still having problems with libfat and Mini vMac, it reads the ROM okay but when a system disk is inserted it acts like the PC version does when it's given an invalid/corrupt disk.

The problem does not exist when using the older fat library or romdiskfs.
I'm really interested in helping track this problem down.

chishm wrote:

melw:
It may be due to your SD card. SD cards have a wider range of quality and abilities compared to CF cards, and I only have 1 type of SD card to test with.

Hmm. Using Kingston 1Gb SD card over here... should be one of the better quality ones, I believe. Also, both REIN v15 and Josath's old version of Draw3 (using the same SaTa modified FAT lib?) works well with the card what comes reading and writing files.

Edit: fatInit() seems to go all the way to _M3SD_initCard() until it reaches the MAX_STARTUP_TRIES check. If I bypass that one, a moment later there's the RESPONSE_TIMEOUT failure. Couldn't find corresponding spot in SaTa's version to compare what's done differently. If you have any debugging tips on what to check next, I could do some more testing...

I though I'd post the functions being called to read from the filesystem...

Code:

#ifndef NotAfileRef
#define NotAfileRef -1
#endif

int Drives[NumDrives]; /* open disk image files */

LOCALPROC InitDrives(void)
{
si4b i;

for (i = 0; i < NumDrives; ++i) {
   Drives[i] = NotAfileRef;
}
}

GLOBALFUNC si4b vSonyRead(void *Buffer, ui4b Drive_No, ui5b Sony_Start, ui5b *Sony_Count)
{
#ifdef DiskInSRAM
if ( Drives[ Drive_No ] == ( int ) SRAM ) {
   MyMoveBytes( ( anyp ) ( SRAM + Sony_Start ), ( anyp ) Buffer, *Sony_Count );
   return 0;
}
#endif

FS.seek( Drives[ Drive_No ], Sony_Start, SEEK_SET );
FS.read( Drives[ Drive_No ], Buffer, *Sony_Count );

return 0; /*& figure out what really to return &*/
}

GLOBALFUNC si4b vSonyWrite(void *Buffer, ui4b Drive_No, ui5b Sony_Start, ui5b *Sony_Count)
{
#ifdef DiskInSRAM
if ( Drives[ Drive_No ] == ( int ) SRAM ) {
   MyMoveBytes( ( anyp ) Buffer, ( anyp ) ( SRAM + Sony_Start ), *Sony_Count );
   return 0;
}
#endif

FS.seek( Drives[ Drive_No ], Sony_Start, SEEK_SET );
FS.write( Drives[ Drive_No ], Buffer, *Sony_Count );

return 0; /*& figure out what really to return &*/
}

GLOBALFUNC si4b vSonyGetSize(ui4b Drive_No, ui5b *Sony_Count)
{
#ifdef DiskInSRAM
if ( Drives[ Drive_No ] == ( int ) SRAM ) {
   *Sony_Count = SRAMSize;
   return 0;
}
#endif

FS.seek( Drives[ Drive_No ], 0, SEEK_END );
*Sony_Count = FS.tell( Drives[ Drive_No ] );

return 0; /*& figure out what really to return &*/
}

GLOBALFUNC si4b vSonyEject(ui4b Drive_No)
{
#ifdef DiskInSRAM
if ( Drives[ Drive_No ] == ( int ) SRAM ) {
   Drives[ Drive_No ] = NotAfileRef;
   return 0x0000;
}
#endif

FS.close( Drives[ Drive_No ] );

Drives[Drive_No] = -1;
return 0x0000;
}

FS is just a wrapper for using multiple filesystems in the project, right now it supports libfat, the old fat library and romdiskfs.
The only one having problems is libfat.

TheLazy1:
I'm thinking that the problem may lie in my implementation of seek. To make it easier to track down the bug, I'll need a bit more information. Is Sony_Start always going to be a multiple of 512 (ie, it reads sectors at a time)? Does vSonyWrite get called at all before it tries to read the disc and fails? When I get back to my dev machine, I'll write an un-optimised version of seek for you to try.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Quote:

vSonyRead( Buffer=B003B1C, Drive_No=0, Sony_Start=1024, *Sony_Count=128 ); IPC->heartbeat = 509
vSonyRead( Buffer=2193730, Drive_No=0, Sony_Start=0, *Sony_Count=1024 ); IPC->heartbeat = 596
vSonyRead( Buffer=2056E02, Drive_No=0, Sony_Start=1024, *Sony_Count=512 ); IPC->heartbeat = 652
vSonyRead( Buffer=205724E, Drive_No=0, Sony_Start=7168, *Sony_Count=512 ); IPC->heartbeat = 653
vSonyRead( Buffer=B003B1C, Drive_No=1, Sony_Start=1024, *Sony_Count=128 ); IPC->heartbeat = 679

vSonyWrite is only called with the old fatlib and that's after the OS has started.
I also have no idea if calls to vSonyRead follow any rules, but I doubt it does.

From the looks of those reads, Sony_Start is aligned to 1024 byte boundaries, but I'll assume 512 since that is what ATA discs use.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

TheLazy1:
This is a test version with seek simplified as much as possible. Try it out and tell me if the problem is solved or not.

Everyone else:
Don't bother with the above debug version.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Problem was solved, the system boots as expected :)

Lazy1 wrote:

Problem was solved, the system boots as expected :)

Okay, that means I have work to do on seek(), since the version you tried is severely limited.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Chishm:

First of all: Congratulations for your work.

The only thing that needs this library now is the directory listing.

I hope you solve this problem soon.

WTF, who is Spelling Fairy?
_________________
http://jandujar.homelinux.com
http://www.dsrobot.com

Last edited by jandujar on Thu Aug 03, 2006 9:22 am; edited 1 time in total

Heh, thanks. File listing will be done eventually, but I have a few higher priority tasks I need to take care of.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Hi, this is REALLY cool... I had my first chance to inspect it today and it has allowed me to add open and save features to dSTAR sequencer (my MIDI program).

One thing I found, though, is that it won't work with my Sandisk 1GB SD card within my M3 Perfect. It works just fine on my 512MB Sandisk card though.

I am using the version that was included in the latest libnds update.

Thanks so much for this work.

The last DevkitPro release of libfat (2006-07-22 IIRC) had the SD timeout values set too low (I must have fast SD cards or something). This means that the startup is timing out before some cards have a chance to respond. I've fixed this about a week ago in the source in CVS. It shouldn't be too hard to checkout a copy and compile it from source.

EDIT: w00t, 713th post!
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

I hoped EZ4 would be added in this new libfat, looks like I'll have to wait a little longer... Damn it EZ team, why don't you give us the code?

Extreme Coder wrote:

I hoped EZ4 would be added in this new libfat, looks like I'll have to wait a little longer... Damn it EZ team, why don't you give us the code?

Have you asked them? Maybe if enough people request it, and include why they want it (better homebrew support, more people use the device, etc), then they might reconsider. Apparently a G6/m3minisd library was released, but without source code. I just sent them an email requesting source, they probably won't do it, but at least they know someone out there wants it.

Extreme Coder wrote:

I hoped EZ4 would be added in this new libfat, looks like I'll have to wait a little longer... Damn it EZ team, why don't you give us the code?

There is code, but read only. It isn't a simple case of changing the command to write to the SD card (as is the case for CF), so it will be harder to add write support.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

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. The functions chdir, mkdir and rename are also all there now too.

Once directory listing is supported by DevkitPro, libfat will reach beta stage. You may not be able to compile it from CVS at the moment, since the devoptab_t stucture needs to be updated first.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

That's great news Chishm, great news! Your hard work is appreciated.
_________________
http://licklick.wordpress.com

In this post, chishm wrote:

Actually, I'd recommend libfat, when DKP r20 comes out.

Is that a hint-hint about the status of opendir()?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tepples wrote:

In this post, chishm wrote:

Actually, I'd recommend libfat, when DKP r20 comes out.

Is that a hint-hint about the status of opendir()?

In this post, chishm wrote:

Directory listing is added to the library code, but it requires an update of DevkitPro that isn't released yet.

Although I haven't finished opendir() yet, I have written directory listing functions that behave similarly, but better. Implementing opendir() will be a simple case of writing a wrapper around them.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

is there any chance for ez4 support?

Much appreciated on the M3SD support indeed! Finally I can look forward to some Stella and Coleco support... pending a re-compile of course.

Aces Chishm... ACES!

chishm wrote:

You may not be able to compile it from CVS at the moment, since the devoptab_t stucture needs to be updated first.

For the anxious ones like me (willing to test that M3SD again), what exactly needs to be updated in the devoptab_t structure?

melw wrote:

chishm wrote:

You may not be able to compile it from CVS at the moment, since the devoptab_t stucture needs to be updated first.

For the anxious ones like me (willing to test that M3SD again), what exactly needs to be updated in the devoptab_t structure?

Extra entries for creating and listing contents of directories.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

fread always returns 0, although the data is read into the specified buffer. I'm using the libfat that came with the latest devkit (file date 08/13/06).
Is there a fix for this?

I haven't come across this problem before, but there are some things you can try. First, make sure you are using the latest DevkitARM. The latest is r19b. If that doesn't work, try using open / read / close instead of fopen / fread / fclose. This will bring it as close to the bare libfat routines as possible (to make sure newlib isn't doing anything to mess it up).
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

I'm using dk r19b. open/read/close don't seem to be available (not declared in this scope). I'm using fcntl.h and stdio.h

You want to #include <unistd.h>
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

thanks, reading works now.
write()ing however fails. It "correctly" returns the bytes written, but actually does not write anything, resulting in a 0-sized file. I *think* fwrite worked though

Make sure you close() the file after writing.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

I already do call close. Perhaps i need to flush it before?

Can we flush within a timer or would that require some locks?

i seem to get it to write fine, but for some reason my time stamps are always fudged up, and I do close all my files when i finish using them
_________________
http://www.myspace.com/knight0fdragonds

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

Calling close() will clean the cache. You really shouldn't be accessing the internal cache at all from outside the library, as it is all handled internally.

I'll have to look into the time stamps when I get some spare time to work on this (no joke intended). They're probably fudged by the conversion from the DS representation of time to the directory entry structure. It's one of the small things that I copied directly over from gba_nds_fat without testing.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

I just tried getting file access working, but I got stuck pretty fast. Hope you can help.

Code:

FILE* fp;
if ((fp = fopen("/test.xml", "r")) == NULL) {
iprintf("\nCannot open file.\n");
}

I had hoped not to see "Cannot open file.", but unfortunatly I do see it. What am I doing wrong? I'm using CF GBAMP, r19, the precompiled fatlib 20060722 and fatInit(4, true) returns true. Both the .nds and the file I'm trying to open is at the top level directory of the flashcard.

That code worked as expected, no problem. I'm using devkitarm r19b and libfat 20060722. I'm using fatInitDefault(); to init but that shouldn't matter.
_________________
GTAMP.com/DS

Last edited by Sektor on Fri Sep 29, 2006 1:36 pm; edited 1 time in total

FatInitDefault gives me the same error. I'm using r19b too btw.

I also tried to checkout the latest version of libfat from CVS but it didn't compile. Is there a newer precompiled version than the one I'm using?

ChronoDK wrote:

FatInitDefault gives me the same error. I'm using r19b too btw.

I also tried to checkout the latest version of libfat from CVS but it didn't compile. Is there a newer precompiled version than the one I'm using?

Perhaps you could post your full source code, as well as compiled .nds file? either:
A) your device has some problems such that libfat cannot use it or
B) your bug lies in some other part of your code.

Also: Make sure you don't do fatinit & open at the very beginning of your code. Wait a couple of vblanks before you call fatinit etc

josath wrote:

Also: Make sure you don't do fatinit & open at the very beginning of your code. Wait a couple of vblanks before you call fatinit etc

Reminds me of NES programming, where you're not supposed to read or write VRAM until after two vblanks.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tepples wrote:

josath wrote:

Also: Make sure you don't do fatinit & open at the very beginning of your code. Wait a couple of vblanks before you call fatinit etc

Reminds me of NES programming, where you're not supposed to read or write VRAM until after two vblanks.

You can call fatInit immediately, but try not to call fopen() before the first VBlank has passed. This is so the time value in the IPC struct has had a chance to be updated with the correct value. Before anyone asks, forcing a check inside the library would just slow it down on every open() / close() for something that is not likely to happen and can easily be prevented in user code. Hand-holding has to stop somewhere.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

What kind of slow-down would it be?

Sounds like just a "if (static boolean) wait for 2 vblanks" which wouldn't be at all noticable after the initial wait.

I think the extra effort inside the library is worth it to stop many people inserting 2 NDS vblank waits in otherwise generic code.

Then again, I like holding hands...
_________________
http://aaiiee.wordpress.com/

just wondering hows the g6 compatibility for this or do we know?

Thanks, I got it working. Will try not to call fopen immediately from now on.

The primary error was something else though - but it is way too embarrassing to tell about :-)

Code:

#define fatInitDefaultHoldingHands(); swiWaitForVBlank(); \
swiWaitForVBlank(); \
fatInitDefault();

LOL.

By the way, is the main focus of libfat to provide stable code for as many cards possible, or to provide perfect code (+ code design) for the popular cards? That's really a question to think about.

- Lick
_________________
http://licklick.wordpress.com

Heh, I used the exact code in that define :-)

Anyway, I'm trying to do something useful with the file system stuff now. Working with strings is nice, but I would like to load my sprites from file too.

This is what I got, and it aint working:

Code:

FILE* fp;
if ((fp = fopen("/ninja_1.raw", "rb")) == NULL) {
iprintf("\nCannot open raw file.\n");
}
else {
dmaCopy((u8*)fp, (void*)SPRITE_MEM(0), 512);
}

if ((fp = fopen("/ninja_1.pal", "rb")) == NULL) {
iprintf("\nCannot open pal file.\n");
}
else {
dmaCopy((u8*)fp, SPRITE_PAL(0), 32);
}

I'm trying to copy a 32x32 16 color sprite converted with gfx2gba (as doing the conversion in code seems way to advanced for me). Nothing shows up on the screen.

C I/O doesn't work that way. fp is NOT a charpointer to the bytebuffer of that file. It's a handle, that the I/O system works with.

1) use fread();
2) don't use dmaCopy(), use memcpy();
3) "rb" isn't necessary, libfat only does binary. ("r" = "rb")

- Lick
_________________
http://licklick.wordpress.com

I thought I would try the hand-holding approach for file times after all, but I discovered a few problems along the way. The combined ARM9 / ARM7 template provided in DKP r19 doesn't update the RTC values in the IPC struct. (No calls to rtcGetTime() are made at all.) This means the time will always be incorrect. If I attempt to wait until the time is valid, it may wait indefinitely. Therefore if the time is invalid, I'll simply set the file time to NULL rather than waiting for it to become valid.

Also, it is only close() that uses the time, so you can open() (and therefore fopen()) any time.

The main focus is to provide stable, correct code for as many cards as possible. Correctness means it cannot give false positives for the card detection function, it has to support reading, and it should (but doesn't have to) support writing. It also has to be fail safe, so if a function cannot access the card, it should give up and return an indication that an error occured.

ChronoDK:
Care to share what the problem was? Other people can learn from your mistakes too.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Using "rb" is a good habit, even if it's not necessary in this case. Who knows what future fat versions will add? Even if a text version is very unlikely, using "r" is just stupid. Don't change it.
_________________
"no offense, but this is the gayest game ever"

Lick wrote:

"rb" isn't necessary, libfat only does binary. ("r" = "rb")

Actually, it's newlib that deals with fopen(), libfat just provides open() (which newlib calls). Therefore, if newlib gets updated to support text mode verses binary mode then so will whatever uses it. Sausage Boy is right though, leave it in just in case. It especially helps for ports.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Whew.. man information is changing fast. Last time I asked it was still 'r is enough'.
_________________
http://licklick.wordpress.com

Lick wrote:

Whew.. man information is changing fast. Last time I asked it was still 'r is enough'.

"r" is indeed enough. However, "rb" is better if you plan on reusing code at a later date or on another platform.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Hi,

I want to report a little bug present in libfat, in the function FAT_mkdir()

To initialize the entries the functions ends so:

Code:

// Write entry to disc
disc_WriteSector(FAT_ClustToSect(newDirCluster), entries);

// Flush any sectors in disc cache
disc_CacheFlush();

So, it only write one sector of the cluster!!! (and the rest sectors has bad datas)

Replace by:

Code:

// Write entry to disc
for(i=0;i<filesysSecPerClus;i++) /* to write all the cluster correctly*/
{
disc_WriteSector(FAT_ClustToSect(newDirCluster)+i, entries);
memset(entries, FILE_LAST, BYTE_PER_READ); /* set to 0 the rest of the sectors */
}

// Flush any sectors in disc cache
disc_CacheFlush();

And problem solved ;)

Well that is actually a function from gba_nds_fat, not libfat. However, the libfat version does operate in the same way. It shouldn't have affected anything, since the end of directory marker is moved when new entries are created.

After testing, it appears that not clearing the cluster will cause problems for other OSes when they try to add entries to the directory. This has now been fixed in libfat (despite mkdir not actually being usable at the moment).
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Yay - happy! I got sprite loading from file working now. If you want to see, here it is:

Code:

void cSprite::copyFile(cGameWorld* gameworld_, const char* strname_, bool newsprite_) {
FILE* fp;

//copy sprite data from file
char filename[32];
strcpy(filename, "/data/sprites/");
strcat(filename, strname_);
strcat(filename, ".raw");

if ((fp = fopen(filename, "rb")) != NULL) {
   fseek(fp, 0, SEEK_END);
   u16 size = ftell(fp);
   iprintf("Bytes: %i\n", size);
   rewind(fp);
   u8* buffer;
      if ((buffer = (u8*)malloc(size)) != NULL) {
      fread(buffer, 1, size/sizeof(u8), fp);
      memcpy((void*)SPRITE_MEM(gfx), buffer, size/sizeof(u8));
      //dmaCopy(buffer, (void*)SPRITE_MEM(gfx), size);
      if (newsprite_)
         gameworld_->sprite_control->next_gfx = gameworld_->sprite_control->next_gfx + size/32;
      }
   fclose(fp);
   free(buffer);
   }
   else
   iprintf("\nCannot open raw file.\n");

//copy sprite palette from file
strcpy(filename, "/data/sprites/");
strcat(filename, strname_);
strcat(filename, ".pal");

if ((fp = fopen(filename, "rb")) != NULL) {
   fseek(fp, 0, SEEK_END);
   u16 size = ftell(fp);
   iprintf("Bytes: %i\n", size);
   rewind(fp);
   u8* buffer;
      if ((buffer = (u8*)malloc(size)) != NULL) {
      fread(buffer, 1, size/sizeof(u8), fp);
      memcpy(SPRITE_PAL(pal), buffer, size/sizeof(u8));
      //dmaCopy(buffer, SPRITE_PAL(pal), size);
      }
   fclose(fp);
   free(buffer);
   }
   else
   iprintf("\nCannot open pal file.\n");
}

Sorry for posting all that. But perhaps someone can use it sometime. Could I have done it in a better way? An why is memcpy better than dmaCopy? They both work, but I did as you told me and used memcpy.

chism: I dont think anyone can learn from the embarrassing part of the last error - I called the file "text" but tried to open "test" :-)

You'd be surprised how common that mistake is. At least to me. >_>
_________________
I'm a PSP hacker now, but I still <3 DS.

ChronoDK wrote:

chism: I dont think anyone can learn from the embarrassing part of the last error - I called the file "text" but tried to open "test" :-)

Don't worry, I've done that too.

Also, memcpy is better than dmaCopy since dmaCopy can't access the DTCM region of the ARM9, which is where the stack is placed.

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

Hello,

Since devkitpro r19b does not have directory listing support yet, the latest CVS of libfat will not compile under it. In order to get it to work, simply apply this patch

This is just a stopgap, to let you use the latest libfat, without having to wait for a devkitpro update (basically it comments out all the directory related functions)

Alternatively, you could just ask for the latest compiled version. This is compiled without the patch, but due to the way the device table in DevkitPro works, the extra functions will simply be ignored.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Good news. Checked out the latest CVS version, and compared to the previously released pre-compiled package also all the SD adapters worked flawlessly.

A test batch with writing and reading succeeding on each adapter included:

- GBAMP CF (256Mb Kingston)
- M3 CF (256Mb Kingston)
- M3 SD (1Gb Kingston)
- M3 Lite SD (512Mb Sandisk)

I can also check how the Chinese M3 Mini SD works in the near future.. Looking forward for the official beta release of libfat!

Keep up the good work chishm! Can we expect the new dewvkitpro anytime soon or is it still some ways off yet?

El Hobito wrote:

Keep up the good work chishm! Can we expect the new dewvkitpro anytime soon or is it still some ways off yet?

devkitpro = wintermute, not chishm. donate at devkitpro.org to get it out sooner!

josath wrote:

El Hobito wrote:

Keep up the good work chishm! Can we expect the new dewvkitpro anytime soon or is it still some ways off yet?

devkitpro = wintermute, not chishm. donate at devkitpro.org to get it out sooner!

yeah i know that! that was just a generic cop compliment!

If anyones interested i have little tester program with a list for know working cards starting. If anyone can run it and test it that would be great.

http://teamnnc.free.fr/phpBB2/viewtopic.php?p=10581#10581

hi, the new fatlib is great :)

now write / read works on my SC SD card .

but i have a small problem now .
i must RENAME a file name , but it doesnt work :(

isnt it implemented until now ?

must i make a work around ?

tnx .
cya

rename() won't appear until the rest of the directory level functions appear, with the next version of DevkitPro.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Have you guys seen this? It is supposed to be the source code for accessing the SCCF, SCSD and SCSD mini. It also includes the rumble code.

http://scdev.org/forum/viewtopic.php?t=6896

felix123 wrote:

Have you guys seen this? It is supposed to be the source code for accessing the SCCF, SCSD and SCSD mini. It also includes the rumble code.

http://scdev.org/forum/viewtopic.php?t=6896

It seems to include code for writing to SC Rumble, but not any code for actually making it vibrate. (Though I may have missed it). Otherwise, it appears to be all ARM ASM, with most functions having comments describing what it does in C

Using the WIP-build of libfat, is it possible to check which device is inserted? Like Supercard, M3..
_________________
http://licklick.wordpress.com

it doesn't seem there is any easy way. I think you could do:

Code:

// make sure the libfat source directory is searched for includes,
// but not for source
#include "partition.h"

extern PARTITION *_partitions;

for(int i=0; i<MAXIMUM_PARTITIONS; i++) {
if(_partitions[i] != NULL) {
iprintf("Partition %d type = %X\n", i, _partitions[i].disc->ioType);
}
}

Then you can compare the 'partition type' with the magic numbers in the various io_*.h files in the disc_io dir:

Code:

io_efa2.h:#define DEVICE_TYPE_EFA2 0x32414645
io_fcsr.h:#define DEVICE_TYPE_FCSR 0x52534346
io_m3cf.h:#define DEVICE_TYPE_M3CF 0x4643334D
io_m3sd.h:#define DEVICE_TYPE_M3SD 0x4453334D
io_mmcf.h:#define DEVICE_TYPE_MMCF 0x46434D4D
io_mpcf.h:#define DEVICE_TYPE_MPCF 0x4643504D
io_njsd.h:#define DEVICE_TYPE_NJSD 0x44534A4E
io_nmmc.h:#define DEVICE_TYPE_NMMC 0x434D4D4E
io_sccf.h:#define DEVICE_TYPE_SCCF 0x46434353
io_scsd.h:#define DEVICE_TYPE_SCSD 0x44534353

I think they actually are 4 character strungs (not \0 terminated), so you could print them out as well.

I tried it, but I couldn't get it to compile. Guess I'm releasing two binaries. =/
_________________
http://licklick.wordpress.com

Well, my code wasn't right, it wasn't tested like I said. They were just simple problems though (like a missing [], using a . instead of a ->, etc)

source + compiled .nds --> http://davr.org/ds2/fattest.tgz

Would have been nice, but I already released LoveLite, without SC-detection. Thanks for your effort though, josath! Love you!

- Lick
_________________
http://licklick.wordpress.com

josath wrote:

I think they actually are 4 character strungs (not \0 terminated), so you could print them out as well.

Yes, they are the 4 characters of the name of the device. For instance, the supercard SD will be SCSD. The characters are ASCII encoded and the highest byte corresponds to the last letter in the name (little-endian architecture).
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

josath wrote:

Well, my code wasn't right, it wasn't tested like I said. They were just simple problems though (like a missing [], using a . instead of a ->, etc)

source + compiled .nds --> http://davr.org/ds2/fattest.tgz

Thanks! I'm using this and it's workig like a charm! ;)
_________________
http://licklick.wordpress.com

I'm trying to do a "FAT_GetFileCluster()" in the DevKitPro libfat. I copied the necessary structs from the libfat source and then access access the FILE* I get from fopen() like this:

Code:

typedef struct {
u32 cluster;
u32 sector;
s32 byte;
} FILE_POSITION;
typedef struct {
u32 cluster;
u32 sector;
s32 offset;
} DIR_ENTRY_POSITION;
typedef struct {
u32 filesize;
u32 startCluster;
u32 currentPosition;
FILE_POSITION rwPosition;
FILE_POSITION appendPosition;
bool read;
bool write;
bool append;
bool inUse;
PARTITION* partition;
DIR_ENTRY_POSITION dirEntryStart; // Points to the start of the LFN entries of a file, or the alias for no LFN
DIR_ENTRY_POSITION dirEntryEnd; // Always points to the file's alias entry
} FILE_STRUCT;

..
FILE *_boot_mp = fopen("_BOOT_MP.NDS", "r");
u32 cluster = *((FILE_STRUCT*)(_boot_mp->_file)).startCluster;
fclose(_boot_mp);
return cluster;
..

Will this work?

- Lick
_________________
http://licklick.wordpress.com

Use fstat. It will return a struct describing the file. The inode number (st_ino) is the file's start cluster. Also, don't use any variables or functions starting with an underscore (eg _partitions). They are meant to be hidden from the host application and may change between versions.

The latest CVS version of libfat will return the hostType (ioType) in the device field of the stat struct (st_dev). So to get the type of disc inserted, try this (untested, should work):

Code:

#include <sys/stat.h>

/* To get the inserted device type */
struct stat st;
stat ("/.", &st); /* Get the file stat for the root directory */
u32 partitionType = st.st_dev; /* Get the disc that the root directory is on */

/* To get the start cluster of a file */
int _boot_mp = open("_BOOT_MP.NDS", "r");
fstat (_boot_mp, st);
close(_boot_mp);
u32 cluster = st.st_ino;

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

Thanks for clearing it up! Perhaps a list of implemented standard functions should be put up, as it's hard to track what is implemented and what not. (Don't know what libnds' coding standards are, but I dislike the idea in general to use standard functions, unless you implement them ALL.)

chishm wrote:

The latest CVS version of libfat will return the hostType (ioType) in the device field of the stat struct (st_dev). So to get the type of disc inserted, try this (untested, should work) ..

chishm wrote:

Alternatively, you could just ask for the latest compiled version. This is compiled without the patch, but due to the way the device table in DevkitPro works, the extra functions will simply be ignored.

I will try that code, but it works with the quoted libfat version right?
You're the man!

- Lick
_________________
http://licklick.wordpress.com

No, I only added the code to CVS 5 minutes before making that last post.

EDIT: I did, however, compile the the latest version for you
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Yay! .. .. Yay! Yay!

Edit: I tested the paritionType detection and.. Sigh.. It works! ;D

Will there be ezsd support? AFAIK, that code is already released, or at least known.
_________________
http://licklick.wordpress.com

It doesn't work. I only get 0x4353 ("SC"), a 16-bit value. How do I get the whole 32-bit value? ("SCSD")

Edit: Upon investigation I found that this define causes the compiler to make dev_t a short value.
/DevKitARM/arm-eabi/include/sys/types.h

Code:

#if defined(__rtems__)
/* device numbers are 32-bit major and and 32-bit minor */
typedef unsigned long long dev_t; // This is skipped
#else
#ifndef __CYGWIN__
typedef short dev_t; // This is parsed
#endif
#endif

I simply brutely modified sys/types.h, but it still doesn't work. I think it's still 16-bit in libfat.a (or in my devkitpro version).

- Lick
_________________
http://licklick.wordpress.com

Getting the partition type and boot file cluster can be greatly simplified from the above example:

Code:

#include <sys/stat.h>

struct stat st;
stat ("_BOOT_MP.NDS", &st); /* Get the file stat for the root directory */
u32 partitionType = st.st_dev; /* Get the disc that the root directory is on u32 cluster = st.st_ino;

It's rather unfortunate about the st_dev type being 16 bit. I can't do much about that without modifying the DevkitPro installation. Maybe WinterMute won't mind, but if he does, I'll need to find another (standardised) way.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

chishm wrote:

It's rather unfortunate about the st_dev type being 16 bit. I can't do much about that without modifying the DevkitPro installation. Maybe WinterMute won't mind, but if he does, I'll need to find another (standardised) way.

Another option is to use non-ascii representations of device types. like SCSD = 100, SCCF = 101, SCLite = 102, M3CF = 200, M3SD=201, gbamp=50, and so on. It's not like we will ever have more than 2^16 device types. You can then just provide an id->string lookup table in the fat.h headers for example.

chishm wrote:

Maybe WinterMute won't mind, but if he does, ..

Why would he mind? It's actually a FIX rather than a plain modification. ARM is 32-bit, y'know.

chishm wrote:

..but if he does, I'll need to find another (standardised) way.

What about using the first 8bit for brand identification, and the second 8bit for the type identification? Josath is completely right that a 16-bit value is more than enough. (Oh, and 32-bit is actually waaaay too much. Although you can use it as a non-zeroed string..)

I still think a simple fix in stat.h will do and should be allowed. (Chishm, could you be kind, for the millionth time, and build a version with a 32-bit st_dev? I really appreciate the immediate help you've given!)

- Lick
_________________
http://licklick.wordpress.com

I would go with a change along the lines described by josath. Although the change of dev_t to a 32bit value is simple it is a change to the base source of newlib - maintenance hassle for the devkitARM team when/if a new version of newlib is used.

< continued from http://forum.gbadev.org/viewtopic.php?t=7195&start=155 >

When using fread '\n' is also interpreted as the end of a string and libfat stops reading.

So what i have to do as a workaround is to read my data char after char and stop reading when it finds '\n'. Then the program must fseek to the next position after the '\n' and continue reading. This is the only way to avoid garbage in memory when reading binary files. This does not happen when i use gcc for win32. binary data is read without any problems using fget or fread.

code snippet for non working read method. This will stop reading after '\n':

Code:

fread(book_buffer, 20, cluster, book_file);

here is my example code for the workaround:

Code:

char tmp[20];

   // Binary Read Hack for NDS, 0x0a=\n causes corrupt reads

for (j = 0; j < cluster; j++) {

   for (i = 0; i < 20; i++) {
      tmp[i] = fgetc(book_file);
      key++;
      if (tmp[i] == 0x0a) {
         myprintf("Found 0x0a at pos %d\n",key);
//          use seek to read correct bytes after \n
         fseek(book_file, key, SEEK_SET);
      }
   }

   for (i = 0; i < 20; i++) {
         myprintf("%02X",(unsigned char) tmp[i]);
   }

   memcpy(&book_buffer[j],tmp,20);
}

Last edited by diggla on Sun Oct 29, 2006 5:57 pm; edited 1 time in total

diggla wrote:

< continued from http://forum.gbadev.org/viewtopic.php?t=7195&start=155 >

When using fread '\n' is also interpreted as the end of a string and libfat stops reading.

You must be doing something else wrong, I've used fread and never needed to use fseek to skip \n, even when reading in a text file with many \n's in it

josath wrote:

You must be doing something else wrong, I've used fread and never needed to use fseek to skip \n, even when reading in a text file with many \n's in it

ok i found the flaw. i must stuff the disk data to a temp buffer first and then memcopy the data to my custom structures. loading directly to my structures didnt work.

chishm: does _BOOT_MP.NDS' startCluster always equal 0?

Also, besides st_dev there is another 16-bit variable that should be 32-bit: st_ino. =/
_________________
http://licklick.wordpress.com

Lick wrote:

chishm: does _BOOT_MP.NDS' startCluster always equal 0?

Also, besides st_dev there is another 16-bit variable that should be 32-bit: st_ino. =/

The start cluster should never be 0, unless it is the root directory. I can work around the 16 bit st_dev field, but inodes really should be at least 32 bit. Imagine a modern operating system only being able to store a maximum of 65536 files.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

But if I simply enter 0 (for *(vu16*)0x027FFFFC, that is), will GBAMP's hacked firmware do the job of locating _BOOT_MP.NDS for me?

Edit: yes.
_________________
http://licklick.wordpress.com

Apologies for the noob question, can libfat write to DS-Link? It's a slot-1 device. I didn't see the name mentioned in the thread but I may have missed it.

It's time for me to stop complaining and start contributing. If I wanted to download a suitable version of libfat source code and customize it by making, say, fopen("/", "r") return a newline-delimited list of files within the root directory, how would I go about this?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Purrrhaps you shouuuld look at the other fatlibs that DO have directory functions and see what they do? Afterwards, just find a way to implement it into the standard C functions (but I think standard C doesn't include directory functions, so you should check out the Posix functions.)
_________________
http://licklick.wordpress.com

DS-link doesn't work yet. The company claims it will in the future.

tepples wrote:

It's time for me to stop complaining and start contributing. If I wanted to download a suitable version of libfat source code and customize it by making, say, fopen("/", "r") return a newline-delimited list of files within the root directory, how would I go about this?

You can checkout the code from DevkitPro CVS. If you just want to look at a couple of files, you can browse the repository.

To commit back to the source tree you'll need to get access rights from Wintermute, the project administrator. If you are going to make such a major change as this, it is best to discuss it with me or Wintermute before commiting.

For your example, I'd suggest creating a fork instead of adding this to the main code base. This is because the proposed changes will be extraneous when DevkitPro r20 is finally released.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Hi,

I made a simple piece of code to test libfat on my Supercard. I found out that the code did not work (fatInit() failed) on my 512 MB DaneElec SD card.
Then I tried a 16MB SD card (SDC-16M Canon) and the code worked like a charm!

I have no problem running Beup and DSlinux which both do not use libfat.

Anyway, if there is an update I would be happy to test it!

I'm about to buy a 2 GB SD card. Can anyone let me know which brand and type SD works with libfat & supercard?

Here is some info:
NDS lite
SuperKey
Supercard (firmware 1.7, also tried firmware 1.63)
libfat-nds-20061028.tar.bz2
devkitpro 19b

The code:

Code:

iprintf("fatInit()..");
if (fatInit(4, true)) {
iprintf("\tSuccess\n");
} else {
iprintf("\tFailure\n");
}

// Write to a file
FILE *ostream, *fopen();
if ((ostream = fopen("/test.txt", "w")) == NULL) {
iprintf("Cannot open file\n");
}else{
   iprintf("File opened.\n");
   char x[10] = "0123456789";
   fwrite(x, sizeof(x[0]), sizeof(x)/sizeof(x[0]), ostream);
   fclose(ostream); // close file
   iprintf("Wrote to file\n");
}

// Read the same file
FILE *handle;
if ((handle = fopen("/test.txt", "r")) == NULL) {
iprintf("Cannot open file\n");
}else{
   iprintf("File opened\n");
fseek(handle, 0, SEEK_END); // Go to end of file
u32 size = ftell(handle); // Get current position in file, because it is the end it will be the size
char* text = (char*) malloc (size); // Allocate memory for file
fseek(handle, 0, SEEK_SET); // Go to begining of file
fread((void*)text, size, 1, handle); // Read all of file into memory
fclose(handle); // Close file
}

while(1) {

   touchXY=touchReadXY();
   iprintf("\x1b[10;0HTouch x = %04X, %04X\n", touchXY.x, touchXY.px);
   iprintf("Touch y = %04X, %04X\n", touchXY.y, touchXY.py);

}

fattest.zip
_________________
CircuitDB - Free electronics circuits & schematics!

I read through this topic in its entirety and figured I'd try using libfat in a NDS app I've written to allow me to remotely control XBMC using the NDS (e.g. edit/create play list, see album art, switch songs, ff/rw, etc). The app works great except that it currently uses the GBA SRAM to save its settings (i.e. wifi settings, XBOX hostname/ip addresses, etc). This is annoying with flash carts because saving is a two step process:

1. Save in app/game.
2. Restart NDS and save SRAM to flash cart.

I figured using libfat in the app would be nice because then the app can just write its settings directly. Also, I'm currently using gbfs for some data files used by the app. This works fine with the SuperCard Lite but doesn't seem to work with the SuperCard Lite Rumble (probably because it doesn't support GBA). I figured libfat should be able to help with this as well.

I decided to test out if libfat works in my app... so I wrote some code just to stat some files on the flash cart. I started out by using fatInitDefault() and it seemed to be successful. However, as soon as stat() was called, the program appeared to hang. I tried using open() to read a file and to write a file but same problem. So then based on the posts in this topic, I figured maybe my flash carts aren't supported properly or maybe I need to wait for a newer version of DevKitPro.

Instead of giving up, I decided to grab fattest source/binary linked on this topic to see if it would work. The binary seemed to work fine printing out mounted partitions but I wasn't sure if stat or open would work since fattest didn't do any of these operations. I managed to get the code to compile (after fiddling with the source a little) and I added in stat, open, read, write calls. Everything worked fine.

Hmm... I checked my build env to make sure I'm using same options in Makefile, including same header files, linking to same library, etc. Everything seemed to check out. While I was checking this stuff out, I left the NDS running after it froze on a stat() call. I noticed that the call eventually returned with an error. I assume the call eventually timed out but failed... I moved my libfat test code around and tried commenting some code out to see if it would have any effect. It turns out that my config loading code that accesses SRAM was causing problems for libfat. I'm guessing the reason was that after loading config details, I was doing a WAIT_CR that gave ownership of the cart/rom back to the ARM7 CPU. After fixing this, libfat worked fine...

Anyway, I just thought I'd share this with the forum in case someone else hits this problem and doesn't feel like banging their head against a wall.

devkitPro 19b
libfat-nds-20061116 (with directory functions commented out)
NDS lite (flashmev7lite)
SuperCard SD (firmware 1.63)
SuperCard Lite (firmware 1.7)
SuperCard Lite Rumble (firmware 1.7)

I've just tried libfat with dualis and it doesn't appear to work (it actually crashes dualis).

Maybe I'm doing something wrong. gba_nds_fat worked.

Any ideas?

I'm having trouble seeking then reading data from within a big file. I'm 99% sure that the file on the PC is the same as the file being used by the DS, but when I read data I don't get the same results. The data that gets read is from several hundred bytes later on in the file.

Here's a quick snippet of code which I can put near the beginning of my program which will replicate the problem. I call fatInitialise(4, true) before this.

Code:

char buf[9];

FILE *fp = fopen("fat0:/baseq2/pak0.pak", "rb");

fseek(fp, 183786082, SEEK_SET);
fread(&buf, 1, 9, fp);

fclose(fp);

printf("buf is %s\n", buf);

The DS returns data from slightly further into the file and I get the string "textures/". The PC (under Linux) gives "env/unit".

I'd like to check which version is correct with a hex editor or something - could anyone suggest anything easy to use? Although as the PC runs fine and the DS gives whack results I'd like to think the PC's doing it right!

And does anyone have any suggestions as to what the problem could be? I'm using a gbamp with a 512 meg CF card.

Ta guys.

At what offset do you see env/unit when reading the file on a PC?

You could find a hex editor (on Windows, I use Notepad++). Scroll to offset 0AF45A60, which corresponds to decimal 183786080.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

On the PC reading 183786082 gives env/unit<and the rest of the filename>
On the DS reading 183786082 gives textures/e1u1/hint.wal

If I examine the pak file (on the CF card) myself with a hex editor the textures string actually lives at 183794274. So the DS is really reading 8192 bytes further into the file than where it really should do...

I would try the old fat driver just to see what's going on, but I really don't want to replace all the FILE * pointers in Q2 with plain integers...

EDIT: I just formatted the CF card and copied back on just the files I needed (as that pak file was fragmented), so now there are no fragmented files. I'm still getting the same problem though :-(

I'm going to guess that the cluster size of that disc is 8192 bytes. It's probably a seek() bug. If you can tell me the true cluster size, as well as try this test only 8200 bytes into the file, that'd be helpful for tracking it down.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

I was gonna try that this evening but I left my card reader on my desk at work!
Is it likely that the error will be shown at 8200 bytes in? I could just imagine myself searching through a 175 meg file, 8k at a time (by hand) until I detect a difference...
I'll do it tomorrow night :-p

It might be an off-by-one error in the cluster determination formula, in which case it should show up 8200 bytes into the file.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Right, I've just spent a while checking what's going on and no, I don't get an error at 8192 or 8200 bytes in. I've only managed to get an error at the address that I gave (175.271k in). I don't get an error at 175k and I don't get an error at 176k, only at that specific address. I could keep homing in until I figure out the exact address it fails on if you like. What would you like me to do?

If you've got pak0.pak from Quake 2 and a gbamp you could always test this yourself...

Can you tell me what the cluster size of the disc is. Also, make sure that there really is no error at 175k or 176k by checking to see you aren't simply seeing data that really is 8192 bytes ahead but is the exact same as you were expecting. What is the size of the file (in bytes)? Unfortunately I don't have Q2 to try this on. Perhaps try reading from 183777890 and see if you get the data you expected at 183786082.

Just to get the simple stuff out of the way, you are opening the file in "rb" mode on both the PC and DS right?

You can also cast the FILE* handle to a FILE_STRUCT* (see fatfile.h) then extract the position information directly. This way you can tell what cluster, sector and byte it thinks it the data is at (after seeking) and compare it to the actual data position. It helps if the file is not fragmented when doing this.

Finally, try opening the file using

Code:

int fp = open (file_name, O_RDONLY);

to bypass newlib, then use seek and read instead of fseek and fread. This is only a test and I don't expect it to be a permanent solution.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Ok, I've been testing more...
The file size is 183,997,730 bytes. Diskeeper tells me that the file is not fragmented.

This broken region seems to start somewhere between 0xaf44f46 and 0xaf450c2 and seems to finish at 0xaf46022 to 0xaf45fe6 ish. So it's about 4000 bytes in size... Reads in this area appear to take data from 8k further into the file.
Sorry I can't be more specific, but there's a lot of empty and repeated data.

This is what *fp is just after opening:

Code:

(gdb) print *fp
$9 = {_p = 0x0, _r = 0, _w = 0, _flags = 4, _file = 36930704, _bf = {_base = 0x0, _size = 0}, _lbfsize = 0, _cookie = 0x233830c,
_read = 0x20a8018 <__sread>, _write = 0x20a7fac <__swrite>, _seek = 0x20a7f60 <__sseek>, _close = 0x20a7f38 <__sclose>, _ub = {_base = 0x0,
_size = 0}, _up = 0x0, _ur = 0, _ubuf = "\000\000", _nbuf = "", _lb = {_base = 0x0, _size = 0}, _blksize = 0, _offset = 0, _data = 0x0,
_lock = 0}

after the a seek (to an address which I know works fine, 0xaf44f6c)

Code:

$11 = {_p = 0x2338854 ']' <repeats 32 times>, '\177' <repeats 86 times>, "\215\215\215\215\215UUUU\177\177\177\177PP\\\\\\]]]]]][[[[[[", _r = 148,
_w = 0, _flags = 5252, _file = 36930704, _bf = {
_base = 0x23384e8 ']' <repeats 20 times>, '\177' <repeats 82 times>, "Y\216\215\215\215\215\215YYUUUUU]]]]\\\\]]]]]]]]", '[' <repeats 35 times>, "
U", '\177' <repeats 34 times>..., _size = 1024}, _lbfsize = 0, _cookie = 0x233830c, _read = 0x20a8018 <__sread>, _write = 0x20a7fac <__swrite>,
_seek = 0x20a7f60 <__sseek>, _close = 0x20a7f38 <__sclose>, _ub = {_base = 0x0, _size = 0}, _up = 0x0, _ur = 0, _ubuf = "\000\000", _nbuf = "",
_lb = {_base = 0x0, _size = 0}, _blksize = 1024, _offset = 183783424, _data = 0x0, _lock = 0}

after the read:

Code:

(gdb) print *fp
$13 = {_p = 0x2338868 ']' <repeats 12 times>, '\177' <repeats 86 times>, "\215\215\215\215\215UUUU\177\177\177\177PP\\\\\\]]]]]][[[[[[", _r = 128,
_w = 0, _flags = 5252, _file = 36930704, _bf = {
_base = 0x23384e8 ']' <repeats 20 times>, '\177' <repeats 82 times>, "Y\216\215\215\215\215\215YYUUUUU]]]]\\\\]]]]]]]]", '[' <repeats 35 times>, "
U", '\177' <repeats 34 times>..., _size = 1024}, _lbfsize = 0, _cookie = 0x233830c, _read = 0x20a8018 <__sread>, _write = 0x20a7fac <__swrite>,
_seek = 0x20a7f60 <__sseek>, _close = 0x20a7f38 <__sclose>, _ub = {_base = 0x0, _size = 0}, _up = 0x0, _ur = 0, _ubuf = "\000\000", _nbuf = "",
_lb = {_base = 0x0, _size = 0}, _blksize = 1024, _offset = 183783424, _data = 0x0, _lock = 0}

Dunno if that's any use!

I don't know what the cluster size of the disk is - I just chose default. Is there an easy way of finding out?

Thanks for the help btw :-)

EDIT: I forgot to say, yes I'm using 'rb' and I tried to use open/seek/read, but I didn't know what the prototypes were. I'll try your other fat driver later to see if I get the same read problems.

Yo, I just tested this with your gba_nds_fat library and it reads the data just as it should... Looks like I'm just gonna have to use that then instead!

Unfortunately those structs aren't any help. I really needed the data pointed to by _file within that struct, but I suppose it isn't too important. I mistakenly asked for the wrong data. That doesn't really matter now, if you don't want to spend any more time debugging it.

However, if you do want to debug further, the prototypes are in <sys/unistd.h>. It would also really help if you could find out the cluster size.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Right! This is with libfat again. I've got 8192-byte clusters.

Here's me opening, seeking and reading from that funny bit of disk. I've basically printed *(FAT_FILE *)fp->_file here. Is that right? Sorry for the whack characters...
after opening:

Code:

$15 = {firstCluster = 3, length = 36953500, curPos = 183997730, curClus = 54, curSect = 0, curByte = 54,
readBuffer = "\000\000\000\000\000\000\000\000‗W\000\000\n\000\000\000\"\001\000\000\001\000\000\001h?3\002\002\000\000\000\001\000\000\000\b\000\00
0\000\002\000\000\000\001\000\000\000\b", '\0' <repeats 11 times>, "▒\000\000\000\003\000\000\000\234?3\002\"\225?\n6\000\000\000\000\000\000\0006", '
\0' <repeats 11 times>, "‗W\000\000\n\000\000\000\"\001\000\000\001\000\000\001h?3\002\002\000\000\000\001\000\000\000\b\000\000\000\002\000\000\000\0
01\000\000\000\b\000\000\000\000\000\000\000\034\000\000\000\001\000\000\000@?3\002?", '\0' <repeats 79 times>, "i!", '\0' <repeats 190 times>, "█\000
\000\000&YA1? ", '\0' <repeats 14 times>, "z▀3"..., appClus = 1, appSect = 8273, appByte = 2, read = true, write = false, append = false,
inUse = false, dirEntSector = 8, dirEntOffset = 0}

after seeking:

Code:

$19 = {firstCluster = 3, length = 36953500, curPos = 183997730, curClus = 54, curSect = 183786496, curByte = 22489,
readBuffer = "\016\000\000\000\000\000\000\000‗W\000\000\n\000\000\000\"\001\000\000\001\000\000\001h?3\002\002\000\000\000\001\000\000\000\b\000\00
0\000\002\000\000\000\001\000\000\000\b", '\0' <repeats 11 times>, "\t\004", '\0' <repeats 28 times>, "\n?┬\000\212\003\001\000env/space1dn.tga", '\0'
<repeats 40 times>, "\224?├\000\022\000\003\000maps/base1.bsp", '\0' <repeats 42 times>, "???\000pc\036\000textures/e1u1/metal2_1.wal", '\0' <repeats
30 times>, "\026K?\000?*\000\000textures/e1"..., appClus = 0, appSect = 0, appByte = 0, read = false, write = false, append = false,
inUse = false, dirEntSector = 0, dirEntOffset = 0}

after reading:

Code:

$21 = {firstCluster = 3, length = 36953500, curPos = 183997730, curClus = 54, curSect = 183786496, curByte = 22489,
readBuffer = "\016\000\000\000\000\000\000\000‗W\000\000\n\000\000\000\"\001\000\000\001\000\000\001h?3\002\002\000\000\000\001\000\000\000\b\000\00
0\000\002\000\000\000\001\000\000\000\b", '\0' <repeats 11 times>, "\t\004", '\0' <repeats 28 times>, "\n?┬\000\212\003\001\000env/space1dn.tga", '\0'
<repeats 40 times>, "\224?├\000\022\000\003\000maps/base1.bsp", '\0' <repeats 42 times>, "???\000pc\036\000textures/e1u1/metal2_1.wal", '\0' <repeats
30 times>, "\026K?\000?*\000\000textures/e1"..., appClus = 0, appSect = 0, appByte = 0, read = false, write = false, append = false,
inUse = false, dirEntSector = 0, dirEntOffset = 0}

...and the data in my buffer is the data from 8192 bytes further into the file.
Hope this can be some use.

I've not yet tried using open()/seek() etc btw.

After tracing through all the pointers, you should be using

Code:

*(FAT_FILE *)(*(__handle *)fp->_file)->fileStruct

You'll need to #include <sys/iosupport.h> for __handle. This is all assuming DKP r19b.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Do I need to be using r19b? I'm still using r19a. Is this likely to be the problem? I've been putting off upgrading as I'm sure everything will just suddenly break! Y'know, don't fix what ain't broken etc ;-)

Um, yeah, you need r19b for libfat to work correctly. r19a had a small bug that caused the fileStruct data to become corrupted. This may be the root of your problem.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Doh :-( That's kinda funny, in a not so funny way...

Maybe devkitPro should try and version check and then cry bloody murder if it's not up to date :-)
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

Right...I didn't know that you required a certain version in order for it to work. I thought they were, like, two separate things...

I'll get back to you when I get round to updating!
_________________
Big thanks to everyone who donated for Quake2

If anybody has encountered problems with chism's fat lib using DS-X, I've discovered this may be related to the auto-boot option in DS-X. If your DS-X settings allow for your program to be loaded without loading the DS-X operating system first, the fat lib will not function properly, and both read & write operations may fail.

That's no surprise, since the DS-X is not officially supported by fatlib and won't be until to DS-X developers actually release some info about how their fat system works...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

About the EFA2 support - I don't think it works.

I've tried using both init and initDefault, but both of which return false unfortunatly.

Is there anything different or special I could try to get it to work for the EFAII?

[EDIT]
ie, do I have to enable something in the source, and re-compile?
[/EDIT]

Cheers,
Jess.
_________________
Nintendo DS & Dominos :: DS Dominos
http://jt0.org

That's unfortunate. EFA2 is placed as the very last device in the list, as an experimental card. Either another driver is returning true incorrectly or the EFA2 driver is faulty. I don't have an EFA2 to test with, so I can't really fix it, but feel free to play with the source.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Ok, I rearranged the order and made the efa2 first, and it still failed. So it's definatly the driver.

Next, I have put in a number of debug strings throughout the efa2 io code, and narrowed the issue down to the fact that the returned NAND ID is wrong (getting 0x41000000 instead of 0xEC79A5C0).

I have absolutlely no idea where to go from here, so I've emailed CyteX, but in the mean-time, do you know much about the EFA2 hardware and its registers?

Cheers,
Jess.
_________________
Nintendo DS & Dominos :: DS Dominos
http://jt0.org

I know next to nothing about the EFA2, so your best bet is CyteX.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

No worries.

Thanks for the great library, though, without it, I'd still be stuck not knowing what to do :P

If I ever do get the EFA2 code working, I'll most definatly give you the updated source to include into the repository so others can benefit from it.

Cheers,
Jess.
_________________
Nintendo DS & Dominos :: DS Dominos
http://jt0.org

Is there an emulator that supports libfat for testing?

I think Dualis does. I know it gets past basic init...

*checks quickly*

Hmmmm, Dualis can pretend that a GBAMP v2 is plugged in, but it doesn't actually allow you to specify and image for use with it, so I guess the real answer is: Not really...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

OOPMan wrote:

I think Dualis does. I know it gets past basic init...

*checks quickly*

Hmmmm, Dualis can pretend that a GBAMP v2 is plugged in, but it doesn't actually allow you to specify and image for use with it, so I guess the real answer is: Not really...

Reading documentation might have been helpful. Dualis emulates a GBAMP, and the root of the CF card should be taken as the same directory that the NDS is in. However, I've had problems with it with newer versions of libfat, don't know if this has been fixed.

DeSmMuUEme (or whatever it's called), supposedly has GBAMP emulation as well in newest version. I haven't tried this, so can't comment on it.

Good point :-(

No noddy badge for me :-(
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

Noddy badge? What's that?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Supercard released the driver for SC DS ONE. It's good to see manufacturer release drivers on launch day.
_________________
Nintendo DS homebrew on Wikipedia

That is good news. I may consider getting a SC-DS at some point. I've disinterested in the DS-X mainly because the creators have yet to release any of their actual homebrew support...

EDIT: Crap, no USB port or anything on it :-(
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

Well, I rather have only auto FAT integration (which works perfectly for me) than only a FAT lib (sucks to recompile every app out there). gba_nds_fat and fatlib works fine in my apps, without a driver. Hopefully DS-Xtreme will have both soon.

I'd rather not have closed-source auto-integration, thanks.

At least with an open-source fatlib and open source drivers for devices
you have some way of dealing with problems.

At present people using a DS-X can only rely on the DS-X team to
fix homebrew compataibility problems. Not optimal, as the homebrew
community has demonstrated itself quite capable of fixing stuff itself.
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

FYI, the new R4 slot 1 device released it's I/O interface.
http://www.r4ds.com/soft/3-other-en.htm

There is a new version of libfat that should hopefully solve device interface problems forever. See this post in this thread for details.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

I wonder if there are plans for integrating EZ-Flash 5?
(I'm on the virge of buying a cartridge and the EZ5 is cheaper than the M3-SD one, while the EZ5 doesn't need a flashed DS)
_________________
[project website] [personal website]

Vich wrote:

I wonder if there are plans for integrating EZ-Flash 5?
(I'm on the virge of buying a cartridge and the EZ5 is cheaper than the M3-SD one, while the EZ5 doesn't need a flashed DS)

The shop I looked at (not supposed to mention its name, but it starts with "kick") had both of them for $45, and neither one requires flashed DS. I'd say go with the M3 Simply.

josath wrote:

Vich wrote:

I wonder if there are plans for integrating EZ-Flash 5?
(I'm on the virge of buying a cartridge and the EZ5 is cheaper than the M3-SD one, while the EZ5 doesn't need a flashed DS)

The shop I looked at (not supposed to mention its name, but it starts with "kick") had both of them for $45, and neither one requires flashed DS. I'd say go with the M3 Simply.

Add shipping costs(to the Netherlands) and taxes and it'll be very close to what the shops are asking here (65? at the lowst ... to 100?+ :X)
But almost all of them get delivered with a passme device, so I presume it doesn't work without one?
Although I have a flashed DS, I might buy a DS light later, so it would be nice if I don't have to flash it(for warranty).

(sorry for taking this thread offtopic)
_________________
[project website] [personal website]

So... I don't see a download link anywhere on the site for libfat.
_________________
I'm a PSP hacker now, but I still <3 DS.

HyperHacker wrote:

So... I don't see a download link anywhere on the site for libfat.

Third page of that topic. I agree that the libfat build should be linked on the DLDI page, even just temporarily.
_________________
http://licklick.wordpress.com

How about looking 6 posts earlier in this topic? But indeed should be added to DLDI page.

Ah, I didn't see the link there. They're almost the same colour as the text; when I'm up that late they start to blend right in. Thanks. (Though still, why no link on the page? I checked the source, so I doubt I missed it.)
_________________
I'm a PSP hacker now, but I still <3 DS.

If anyone else is getting "undefined reference to irqDisable" in libfat.a, the solution is so trivial it's almost funny.
_________________
I'm a PSP hacker now, but I still <3 DS.

Can we update the startpost with the latest version of libfat and the drivers? It's a real pain to browse to 15-page topics for stuff that could be the right link...
Why don't the developpers always keep a zip file named like "MyDriver-Latest.zip"? This way, we don't have to change the topic start continuously!
_________________
[project website] [personal website]

Vich wrote:

Why don't the developpers always keep a zip file named like "MyDriver-Latest.zip"?

There are only two ways to do it: filenames with the version number and filenames without the version number. If the version number is included, you complain. If the version number is omitted, people who keep an archive of multiple previous versions of software would complain about having to go in and rename each version after downloading it, as I have seen when figuring out the distribution for LOCKJAW.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

So I suppose the simple solution is to update the first post to link to the latest version with each new release.
_________________
I'm a PSP hacker now, but I still <3 DS.

tepples wrote:

Vich wrote:

Why don't the developpers always keep a zip file named like "MyDriver-Latest.zip"?

There are only two ways to do it: filenames with the version number and filenames without the version number. If the version number is included, you complain. If the version number is omitted, people who keep an archive of multiple previous versions of software would complain about having to go in and rename each version after downloading it, as I have seen when figuring out the distribution for LOCKJAW.

And what about uploading the file that has the version number in it ?nd uploading it as MyDriver-Latest.zip
If they put a changelog or version.txt or an empty [version x].txt in it, it would be easily identifyable. Of course that's more work for the developpers, but it's not as much work as constantly updating the startpost.
_________________
[project website] [personal website]

Feeling kinda dumb here...
Which DLDI driver do I need to use for a Supercard which takes miniSD? The regular 'scsd' one doesn't wanna know when using the dldi tester.
The card worked fine when using the SCSD stuff from gba_nds_fat...

PS: I realise there's a search function, but searching for Supercard, DLDI or FAT is gonna turn up like a million hits...
_________________
Big thanks to everyone who donated for Quake2

simon, using the regular SC SD patch file for my miniSD works fine, though I sometimes have to apply it to the .ds.gba instead of the .nds. I haven't used the DLDI tester myself though.

Seems that I can't get the dldi tester to work on my SC no matter what (there's gotta be something obv that I'm missing), but Quake runs 'fine' with DLDI. It also works when I patch it with the R4 driver too, which I find a bit suspicious!
On the other hand, the M3 Simply works first time with DLDI, but after one frame of gameplay it locks up. O...k!
_________________
Big thanks to everyone who donated for Quake2

chishm, can you update G6 driver on your DLDI page?
http://forum.gbadev.org/viewtopic.php?p=120549#120549

and could you update the DLDI driver for DS Link card?

http://forum.gbadev.org/viewtopic.php?p=120281#120281

hi!

this may be a rather dumb question, but: i have a neoflash mk4 mini and a neoflash slot 2 card - can someone point me to a solution how to get my files and directories onto it? do i need to make some sort of disk image? i don't have the possibility (read: software) to create directories on the flash card. just... how? couldn't find a forum for this (may be that i'm blind or something or it just doesn't exist) and i don't have the time to read through *all* post. (sorry.)

thanks for any help!

silent_code wrote:

hi!

this may be a rather dumb question, but: i have a neoflash mk4 mini and a neoflash slot 2 card - can someone point me to a solution how to get my files and directories onto it? do i need to make some sort of disk image? i don't have the possibility (read: software) to create directories on the flash card. just... how? couldn't find a forum for this (may be that i'm blind or something or it just doesn't exist) and i don't have the time to read through *all* post. (sorry.)

thanks for any help!

What you want is called 'FCSR', GPF has a tool for fcsr images under windows, you can find it on his website. Also search for it on the forums, it should come up.

thanks, i'll have a look at it.

Hi,
I may be wrong but it seems that there is a memory leak in the fopen/fclose code
(on Supercard SD, at least)

To reproduce the problem I performed the following code:

Code:

int allocsize=1000;
void* before = malloc(allocsize);
free(before);

FILE *handle = fopen("/my.file", "r");
fclose(handle);

void* after = malloc(allocsize);
free(after);

As a result, I get different values for 'before' and 'after'.

Has anyone else having this problem ?

(I cannot really confirm that, but I think that the libfat I used before the directory listing was available, did not have this problem)
_________________
http://Gnese.free.fr/NDS/

I think this is no memory leak. it is cause of the buffer allocation of libfat.

Updated DLDIs for DS Link and G6 flash cart.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Diddl wrote:

I think this is no memory leak. it is cause of the buffer allocation of libfat.

You might be right.
I checked on XP and the result is the same (the addresses are different).
I was not aware of that behaviour.

So i guess that there is one memory allocation performed with the first fopen method call (which is kept during all the program execution).
Is it possible that some new memory allocation (not deleted by a fclose()) are done in the next fopen calls (or is the first one, the only one) ?

For information, i need to know what is happening in order to avoid memory fragmentation.
_________________
http://Gnese.free.fr/NDS/

Here's a DLDI for N-Card. I think it is written by the manufacturer.
http://www.superdslink.com/download/file/NC_DLDI.rar
originally from
http://www.superdslink.com/download/download.html
_________________
Nintendo DS homebrew on Wikipedia

felix123 wrote:

Here's a DLDI for N-Card. I think it is written by the manufacturer.

we have this since many weeks from other companies (Neo MK5, DS Linker ...) it is same and has READ SUPPORT ONLY. (write functions are only for SRAM).

gbadev.org forum archive

DS development > Chishm's libfat (superior to GBA_NDS_FAT)

#91774 - chishm - Sun Jul 09, 2006 1:39 pm

#91782 - Sausage Boy - Sun Jul 09, 2006 3:16 pm

#91784 - tepples - Sun Jul 09, 2006 3:56 pm

#91792 - parrot_ - Sun Jul 09, 2006 5:18 pm

#91800 - HyperHacker - Sun Jul 09, 2006 8:03 pm

#91804 - Dwedit - Sun Jul 09, 2006 8:34 pm

#91811 - tepples - Sun Jul 09, 2006 9:50 pm

#91869 - chishm - Mon Jul 10, 2006 9:21 am

#91878 - Normmatt - Mon Jul 10, 2006 10:40 am

#91897 - D-loader - Mon Jul 10, 2006 2:20 pm

#91899 - dawn2k - Mon Jul 10, 2006 2:28 pm

#91906 - Normmatt - Mon Jul 10, 2006 3:14 pm

#91992 - bugmenot! - Tue Jul 11, 2006 12:00 am

#91993 - ThetaDot - Tue Jul 11, 2006 12:09 am

#92019 - HyperHacker - Tue Jul 11, 2006 4:38 am

#92022 - chishm - Tue Jul 11, 2006 4:45 am

#92051 - dem1980 - Tue Jul 11, 2006 9:48 am

#92060 - chishm - Tue Jul 11, 2006 11:06 am

#92068 - quadomatic - Tue Jul 11, 2006 11:51 am

#92074 - tepples - Tue Jul 11, 2006 1:18 pm

#92263 - chishm - Wed Jul 12, 2006 12:11 pm

#92632 - chishm - Fri Jul 14, 2006 7:44 am

#93233 - tepples - Mon Jul 17, 2006 11:31 pm

#93248 - chishm - Tue Jul 18, 2006 1:41 am

#93282 - melw - Tue Jul 18, 2006 8:42 am

#93316 - josath - Tue Jul 18, 2006 4:25 pm

#93340 - nukomod - Tue Jul 18, 2006 6:52 pm

#93353 - Sintax - Tue Jul 18, 2006 7:33 pm

#93467 - chishm - Wed Jul 19, 2006 10:26 am

#94008 - chishm - Sat Jul 22, 2006 1:34 pm

#94014 - PeterM - Sat Jul 22, 2006 2:53 pm

#94332 - melw - Mon Jul 24, 2006 1:14 pm

#94355 - wintermute - Mon Jul 24, 2006 3:26 pm

#94394 - melw - Mon Jul 24, 2006 6:46 pm

#94395 - josath - Mon Jul 24, 2006 6:55 pm

#94711 - arog - Tue Jul 25, 2006 9:58 pm

#94843 - chishm - Wed Jul 26, 2006 12:16 pm

#94852 - melw - Wed Jul 26, 2006 1:00 pm

#94923 - arog - Wed Jul 26, 2006 10:05 pm

#94927 - Dwedit - Wed Jul 26, 2006 10:21 pm

#94932 - tepples - Wed Jul 26, 2006 10:38 pm

#95007 - chishm - Thu Jul 27, 2006 9:17 am

#95029 - Lazy1 - Thu Jul 27, 2006 12:49 pm

#95033 - melw - Thu Jul 27, 2006 1:22 pm

#95079 - Lazy1 - Thu Jul 27, 2006 7:18 pm

#95377 - chishm - Sat Jul 29, 2006 2:44 am

#95388 - Lazy1 - Sat Jul 29, 2006 3:48 am

#95403 - chishm - Sat Jul 29, 2006 6:50 am

#95570 - chishm - Sun Jul 30, 2006 9:18 am

#95631 - Lazy1 - Sun Jul 30, 2006 5:02 pm

#95888 - chishm - Mon Jul 31, 2006 12:35 pm

#96361 - jandujar - Wed Aug 02, 2006 9:42 pm

#96424 - chishm - Thu Aug 03, 2006 9:14 am

#98056 - TheRain - Sat Aug 12, 2006 11:02 pm

#98076 - chishm - Sun Aug 13, 2006 2:23 am

#98491 - Extreme Coder - Tue Aug 15, 2006 4:21 pm

#98494 - josath - Tue Aug 15, 2006 4:54 pm

#98601 - chishm - Wed Aug 16, 2006 9:52 am

#99078 - chishm - Sat Aug 19, 2006 1:44 pm

#99082 - Lick - Sat Aug 19, 2006 2:09 pm

#99237 - tepples - Sun Aug 20, 2006 5:50 am

#99250 - chishm - Sun Aug 20, 2006 8:38 am

#99294 - Frz - Sun Aug 20, 2006 3:08 pm

#100062 - Twibber - Fri Aug 25, 2006 9:49 pm

#100661 - melw - Tue Aug 29, 2006 11:51 am

#100667 - chishm - Tue Aug 29, 2006 1:12 pm

#101941 - Bronto - Sat Sep 09, 2006 2:29 am

#101957 - chishm - Sat Sep 09, 2006 6:05 am

#101988 - Bronto - Sat Sep 09, 2006 3:54 pm

#102057 - chishm - Sun Sep 10, 2006 9:17 am

#102071 - Bronto - Sun Sep 10, 2006 3:35 pm

#102123 - chishm - Mon Sep 11, 2006 1:01 am

#102124 - Bronto - Mon Sep 11, 2006 1:09 am

#102132 - darkfader - Mon Sep 11, 2006 3:11 am

#102139 - knight0fdragon - Mon Sep 11, 2006 5:37 am

#102141 - chishm - Mon Sep 11, 2006 5:58 am

#104410 - ChronoDK - Thu Sep 28, 2006 8:03 pm

#104457 - Sektor - Fri Sep 29, 2006 8:33 am