Alternate SD FS

[softdev]

An alternate FAT FS for SD Cards
----------------------------------

Recently, I've been getting into SD cards. The libOGC sdcard layer currently has
a few issues - mostly brought on by the introduction of long filenames.

For me, as an application developer, I needed something which was bullet proof.
Reliability means much more than pretty filenames! - I want the correct data now!

Enter the excellent elm-chan TinyFAT FS module.

I've ported it here to work with the libOGC sdcardio layer. So far it works well.

There is of course a downside. You can't have long filenames.

In TinyFAT FS there is only provision for unsigned short data lengths, so I've
included a wrapper to get round that, it's in src/fileio.

I've also included the original documentation for TinyFAT FS, as the site is
currently undergoing maintenance.

The demo is not perfect, but shows using a pseudo virtual memory system to play
GameBoy Advance ROMs of any size.

Setup your card as follows, remember upper case and 8.3 only!

/VBA172/ROMS - Put here GB/GBC/GBA roms. Extension determines machine.
/VBA172/BIOS - Put here BIOS.GBA, if you have one.

Notice the unix syntax - aren't you loving it already!

The demo is minimal, but shows that there are no problems seeking, reading etc.
Writing works, but isn't complete in the demo.

To get the full elm-chan fs, go to http://www.elm-chan.org
To get the VBA source code, go to http://vba.ngemu.com

For non-developers - sorry this time there is no binary - but in the future - who knows!

Enjoy!

PS: This will take some time to compile. If you have less than 2GB RAM, expect GBA.cpp to take ~45 minutes. Otherwise, it takes about ten minutes.

[emu_kidid]

Originally Posted by softdev

An alternate FAT FS for SD Cards
----------------------------------

Recently, I've been getting into SD cards. The libOGC sdcard layer currently has
a few issues - mostly brought on by the introduction of long filenames.

For me, as an application developer, I needed something which was bullet proof.
Reliability means much more than pretty filenames! - I want the correct data now!

Enter the excellent elm-chan TinyFAT FS module.

I've ported it here to work with the libOGC sdcardio layer. So far it works well.

There is of course a downside. You can't have long filenames.

In TinyFAT FS there is only provision for unsigned short data lengths, so I've
included a wrapper to get round that, it's in src/fileio.

I've also included the original documentation for TinyFAT FS, as the site is
currently undergoing maintenance.

The demo is not perfect, but shows using a pseudo virtual memory system to play
GameBoy Advance ROMs of any size.

Setup your card as follows, remember upper case and 8.3 only!

/VBA172/ROMS - Put here GB/GBC/GBA roms. Extension determines machine.
/VBA172/BIOS - Put here BIOS.GBA, if you have one.

Notice the unix syntax - aren't you loving it already!

The demo is minimal, but shows that there are no problems seeking, reading etc.
Writing works, but isn't complete in the demo.

To get the full elm-chan fs, go to http://www.elm-chan.org
To get the VBA source code, go to http://vba.ngemu.com

For non-developers - sorry this time there is no binary - but in the future - who knows!

Enjoy!

Absolutely Brilliant (The libogc one currently sucks!!)

[eke-eke]

Originally Posted by softdev

The demo is not perfect, but shows using a pseudo virtual memory system to play GameBoy Advance ROMs of any size.

this is really impressive


PS: do you know the reason of Tiny-FatFs supporting only 8.3 filenames ? could the sourcecode be modified to support LFN without major rewrite ?

And another question: I noticed that you have included in pal60.h Video Register values that have to be patched after the Video Mode has been by libogc ... what is it for ?

[softdev]

Originally Posted by eke-eke

PS: do you know the reason of Tiny-FatFs supporting only 8.3 filenames ? could the sourcecode be modified to support LFN without major rewrite ?

The reason no open embedded software supports LFN is principly that Microsoft own the patent.

Re-writing the code would be possible, if you want to do it. I'd prefer personally to stick with elm-chan's work - it's robust and in use every day in a zillion embedded devices.

[softdev]

Originally Posted by eke-eke

And another question: I noticed that you have included in pal60.h Video Register values that have to be patched after the Video Mode has been by libogc ... what is it for ?

These values are what were observed on both PAL GC and Wii for games in 60hz mode. I believe the real problem is that the Odd Field Timing register is incorrect in libogc - so this guarantees no black bar issue.

The upside for me is it keeps the screen centred - otherwise it moves up and to the left.

So really, you can use them or ignore them - what best suits you.

[eke-eke]

The reason no open embedded software supports LFN is principly that Microsoft own the patent.

Re-writing the code would be possible, if you want to do it. I'd prefer personally to stick with elm-chan's work - it's robust and in use every day in a zillion embedded devices.

I'm not very aware of patent issues: does this mean that we legally shouldn't release code supporting LFN ?

These values are what were observed on both PAL GC and Wii for games in 60hz mode. I believe the real problem is that the Odd Field Timing register is incorrect in libogc - so this guarantees no black bar issue.

The upside for me is it keeps the screen centred - otherwise it moves up and to the left.

So really, you can use them or ignore them - what best suits you.

thanks for the precision
the weird thing is that this "black bar" problem only happened when using TVMpal480IntDf timings, they completely disappear if mode is set to TVNtsc480IntDf, regardless of the console region



I'm curious about the Virtual Memory system used to play roms that can't fit into RAM, have you coded it yourself or was it already a feature of VBA ?
Anyway, this would for sure be a great inspiration for all future emulator porting job

[softdev]

Originally Posted by eke-eke

I'm curious about the Virtual Memory system used to play roms that can't fit into RAM, have you coded it yourself or was it already a feature of VBA ?

No, it's not a feature of VBA. It's also not the best method, but it demonstrates the reliability of the FS quite well.

[the byter]

This may be explained if I look at the source.. but is this a solid FAT16 (or FAT12) implementation, or something independent? Can I plug an SD card formatted this way into a PC and read/write to it?

LFNs were implemented on FAT file systems by using a number of file records which would then be strung together. It was a hack done with Windows 95 on an old file system.

[softdev]

Originally Posted by the byter

This may be explained if I look at the source.. but is this a solid FAT16 (or FAT12) implementation, or something independent? Can I plug an SD card formatted this way into a PC and read/write to it?

YES - It supports FAT12/16/32. Interestingly, this is on PAGE ONE of the documentation.

Originally Posted by the byter

LFNs were implemented on FAT file systems by using a number of file records which would then be strung together. It was a hack done with Windows 95 on an old file system.

Again! - a link to the full MS specification is also on - OMFG! PAGE ONE!

C'mon, how lazy can ya get?

[the byter]

Originally Posted by softdev

C'mon, how lazy can ya get?

I'd say quite a bit. Haven't downloaded the package yet.

[columdrum]

hi first of all , great job!!

I had a problem while compiling this:

Compiling ... GB.cpp
../src/gb/GB.cpp:23:20: warning: memory.h: No such file or directory
Compiling ... gbCheats.cpp
Compiling ... gbDis.cpp
Compiling ... gbGfx.cpp
../src/gb/gbGfx.cpp:19:20: warning: memory.h: No such file or directory
Compiling ... gbGlobals.cpp
Compiling ... gbMemory.cpp
Compiling ... gbPrinter.cpp
../src/gb/gbPrinter.cpp:20:20: warning:memory.h: No such file or directory
../src/gb/gbPrinter.cpp: In function `void gbPrinterReceiveData()':
../src/gb/gbPrinter.cpp:121: error: `memset' was not declared in this scope
../src/gb/gbPrinter.cpp:121: warning: unused variable 'memset'
../src/gb/gbPrinter.cpp:128: error: `memcpy' was not declared in this scope
../src/gb/gbPrinter.cpp:128: warning: unused variable 'memcpy'
../src/gb/gbPrinter.cpp:139: error: `memcpy' was not declared in this scope
../src/gb/gbPrinter.cpp:139: warning: unused variable 'memcpy'
make[1]: *** [gbPrinter.o] Error 1
make: *** [build] Error 2

(i have remoded the paths for better reading)
You forgot the memory.h or i am doing something wrong?

[softdev]

Sorry, I develop on linux where the full C includes are always available. Cross platform development would be damn slow without it

If you're on Windows, grab the full mingw C compiler from Mame downloads. You'll find any other includes you need in there.

[PeterM]

Thanks very much for posting this - I was using the old library and the corrupted data was driving me (and my game) crazy!

[PrimaMimo]

alternate Eb fingering i.e. the "fork" Eb ýòî âðîäå áûëà êàêàÿ-òî êîíñòðóêòèâíàÿ îñîáåííîñòü ñòàðûõ ñàêñîâ, êîòîðóþ ïîòîì óïðàçäíèëè.???