gbadev.org forum archive

I think it's getting fairly obvious that I'm not able to keep up with all the new adapter releases. The last time I checked, I had a backlog of about 4 devices to implement. I have about a week of free time coming up, but I won't be using it to add these particular devices. To do so would maintain the constant requirement for me to add the latest devices as they come out. So what will I do instead?

I have decided to completely change the way drivers are included. Rather than statically linking in a set of drivers at library compile time, they will be dynamically linked after the binary linking stage but (maybe just) before run-time. To do this, the existing disc_io drivers will be removed. A set amount of space (at this stage I'm thinking 32KB, but maybe more or less later on) will be reserved at compile time. To add the driver for a particular card, the user will run a patching program. I will write this program, as well as example Makefile, .specs, .ld and crt0 files needed to implement a driver. I will also convert the drivers already included into patch files. This will behave in a similar way to the patching of commercial ROMs, although different enough that a completely new patch and patcher are required. I will also add an auto-patcher to NDSMP so that it can patch files at load time, and release the code so manufacturers can do the same for their firmware.

So what benefits and downsides will this have?

I won't have to maintain all the drivers for all the cards. As soon as a driver is written by anyone, it is usable by everyone.
Cards that aren't even released yet will be supported by programs that have already been compiled. No more having to recompile to add support for a card.
Manufacturers don't have to release source code to release an easily usable driver. No more having to recompile using other libraries (I'm looking at you, G6). They don't need to make publically available their intellectual property. Of course, this means we have to disassemble whatever they do release to understand the hardware, but we already have to do this (M3, G6, GBAMP).
There is an extra step added to compile then copy to card then run a debug build. The tool will be command line based, so this can be added to the makefile.
Users will need to patch any apps that use libfat for their particular card. This should be okay, as they already do it for commercial ROMs. Alternatively, multiple builds can be released on a website, but this kinda reduces the utility of such a scheme.

If there is too much disagreement, I won't implement this, but I think it is for the common good. All comments, questions and suggestions are welcome.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

I'm all for this. Thumbs up for rethinking the FAT library.
Supporting every card will be so much easier for developpers.
Creating seperate builds for apps and games is definitely not the way to go.
_________________
AmplituDS website

Leave dynamic linking to an operating system, it only causes headaches when user programs do such things.
_________________
"We are merely sprites that dance at the beck and call of our button pressing overlord."

Dwedit wrote:

Leave dynamic linking to an operating system, it only causes headaches when user programs do such things.

It won't be run-time dynamic linking. It will be dynamic in the sense that it is changable after compilation. I will rely on either the loader to do it (so really, an OS) or a patcher. To normal developers, libfat will be used exactly the same as before, with the exception that they can only use one device (i.e. SLOT-1 or SLOT-2 but not both), which is chosen by the linker.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

No more hassle with different versions of gba_nds_fat? Sounds too good to be true :-)

But I guess the success of the idea will depend on the acceptance on the side of the card manufacturers. Imagine the worst case: No manufacturer adds this patching functionality to their firmware or adds homebrew patching to their rom patching software. Then, it would become more complicated for the user, because some homebrewers will release their software as 20 different binaries for 20 (estimated amount) different cards, while others will just release the "universal binary" and tell the user that he needs to search for a patcher to make the app run on his card. Maintaining the patchers would also be a lot of work: If there are patchers for the three major OSes and for every card, that would be 3 x N_CARDS individual programs, so about 60 at the moment.

So the question is: How likely is it that the manufacturers will support this solution?

It sounds easy enough, maybe something like:

Code:

patch-driver file.nds gbamp

I would like a card identification function in there too, something like:

Code:

const char* GetAdapterName( void );

Or maybe a function to return the amount of installed memory ( if any ) and functions to lock/unlock it.

How long will this change take? How can we help?
_________________
http://licklick.wordpress.com

I'm thinking perhaps this memory region could be passed from one patched program to another. For example, I would patch DSOrganize for use with the GBAMP. When I wish to open a program in DSOrganize, it would find the region where the said program needs to be patched, and copy its own code into the new program.

Basically, your loader application would need to be patched, and all programs compatible with this library chaining would not require a patch.

If one chooses to test their application using different devices, but using the same media storage device, he would only need a loader for each patch. Or, perhaps, a set of programs, one per device, to patch the loader, and load it. This would completely eliminate the need for patching the files manually, or picking the right binary to download. You would only need one *.patch.nds per device.
(The *.patch.nds file would be booted first, then would load, patch, and execute a specified file, similar to _BOOT_MP.NDS for the GBAMP.)

Of course, a command-line-operated piece of software may be useful to conserve space on medium which will be used for only one device. It may also be useful if your default boot program is not an application loader, or can operate as one.

One great application for this change would be WiFi-sendable games and applications. The receiver would not be limited to the sender's "version" of the fat library; it could patch the incoming image according to his media type. (Though some conflict would occur if both SLOTs were occupied, as data files (such as saves, records, info databases, etc.) might be on the card behind one device, but not the other.)

Will this have to wait for r20? And will it work on a GBAMP in GBA mode, or will it be DS-only?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

0xtob wrote:

If there are patchers for the three major OSes and for every card, that would be 3 x N_CARDS individual programs, so about 60 at the moment.

If we write it in Java or as a DS homebrew, then we could solve this problem.
_________________
Nintendo DS homebrew on Wikipedia

0xtob:
It would be one program to do the patching, and it would load a patch file specified from a command line. The end user only needs to worry about applying the right patch, but I think someone will create a GUI front end to make it simple for even the command line illiterate.

For manufacturer support, I aim to make the patch format as similar to the current driver format as possible. This makes it easy for me to modify existing drivers for the new format, and gives the manufacturers something to work from.

Lazy1:
This is purely for file system access, nothing more. The idea could be adapted for other features (unlocking memory, resetting the device) but not through libfat. Card identification will be done the same way as it is now. Hopefully the dev_t is expanded to 32 bits in DKP r20

strager:
It's a bit hard to pass the memory region around. Part of the dynamic linking is modifying an address table for a new base address. It is possible, but the current base address needs to be taken into account.

tepples:
It will work in r19. It is a change internal to libfat, so it doesn't need the file function support provided through newlib. I will ensure that the makefile targets the ARM7, so it should work for GBAMP too.

felix123:
Eww, Java ;) . I'd prefer not to force people to install a virtual machine to use the patcher, to make it as transparent as possible.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

This is a good idea but I don't like the sounds of this implementation.

chishm wrote:

Manufacturers don't have to release source code to release an easily usable driver. No more having to recompile using other libraries (I'm looking at you, G6). They don't need to make publically available their intellectual property. Of course, this means we have to disassemble whatever they do release to understand the hardware, but we already have to do this (M3, G6, GBAMP).

I thought the general idea was to try to convince them to release code, and if not, then point out to newcomers that they aren't homebrew-friendly and should be avoided? Don't we want to encourage manufacturers to release source/documentation so that things not using libfat (IE DSLinux) can benefit from them?

chishm wrote:

Users will need to patch any apps that use libfat for their particular card. This should be okay, as they already do it for commercial ROMs. Alternatively, multiple builds can be released on a website, but this kinda reduces the utility of such a scheme.

As 0xtob pointed out, this could easily degenerate into programs having 20 different versions or mentioning they need to be patched but not saying where to get the patcher (or it becoming unavailable for whatever reason), confusing people.

chishm wrote:

To normal developers, libfat will be used exactly the same as before, with the exception that they can only use one device (i.e. SLOT-1 or SLOT-2 but not both), which is chosen by the linker.

This could be a problem if you wanted to use both slots at once, or wanted to distribute your .nds file; say you meet someone with a DS and one of them cards already, but you aren't near a computer; you wouldn't be able to swap programs because they wouldn't be compatible with the card. Patching on the DS itself is possible, but let's face it, if there's already a PC program to do it is anyone going to write such an app for the DS? Not to mention, that app would need to support every card at once anyway.

I can understand it being a pain having to manage all the drivers yourself, but is there a reason others can't help by writing code for and/or figuring out various devices?
_________________
I'm a PSP hacker now, but I still <3 DS.

Can we use a compromise method: continue including all the drivers, and leave a blank space to patch in drivers for new cards?

And I also think it is a good idea to be able to access slot 1 and 2 at the same time.
_________________
Nintendo DS homebrew on Wikipedia

Chishm, your idea make a lot of sense. For the implementation I think that making a win/*nix/mac... program is a bad idea, It will just confuse the user even more.
I rather prefer a .nds patcher that you put in your card with the homebrew you want to play. The user launch the patcher which detect the card, select the right IO driver and patch the homebrew.
This way there is only one patcher (different version number of course as the number of device supported increase). Also if you want to transfer an homebrew via wifi users send the patcher along with and that's it.

HyperHacker:
Trying to convince the manufacturers to release code isn't working. At best they release a half-arsed driver which only works with their card and assumes that no other card exists. I hope to include the patcher in DevkitPro much like dsbuild and ndstool are now, along with a download on my website.

I included the ability to use two slots at once in libfat due to a few requests for it. Now that it's there, I have not seen a single app use it. It's as simple as accessing "fat1:/" (slot 1) or "fat2:/" (slot 2), yet no one does.

People have tried to write drivers in the past, and they've been a great help. However, I still have to clean up the code to match the naming and style conventions of libfat, then test it in combination with various other devices to make sure it doesn't cause compatibility issues. Also, with the growing number of new devices, it is becoming more and more wasteful to support them all at once. Then there is the need for finished apps to be recompiled everytime a new device is released.

felix123:
I was also thinking about that. In fact, the only reason I haven't mentioned it is because I will need to reserve so much space for new drivers that I would remove the old ones to make room. From the general concensus, I think it is better that I leave them in there.

viruseb:
Even idiotic pirates manage to patch their commercial ROMs using a PC program, so I doubt that this is too confusing for the end user.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Having a scmhbp style patcher designed for each piece of hardware would be a good way to handle it.

Having a single compiled homebrew NDS and a single patcher designed for your cart.
GBAMPPatcher.exe whatever.nds spits out whatever.dkp.nds with support

GBAMPLoader.NDS lists the raw NDS homebrews on the cart. selecting it loads the nds into ram and patches it before booting. *obviously not optimal*

Its going to be a little messy having the current style homebrew and new style.. but should be easy enough to handle.

Do you want to leave this patcher in the hands of the hardware supplier and/or hardware hackers? the framework idea is fine if we can "guarantee" support for the hardware you can support already.. and if handled by the hardware groups themselves should make life easier for most people with new hardware.. if they choose not to support the community, they are going to have pissed off customers and lack of support from us.

Dropping a file onto an exe is easy as pie.
_________________
MrShlee.com
Projects
Dev-Scene
MyTechpedia

Mrshlee wrote:

GBAMPLoader.NDS lists the raw NDS homebrews on the cart. selecting it loads the nds into ram and patches it before booting. *obviously not optimal*

My idea is more that the .nds patch the homebrews once for all (ie rewriting the patched homebrews in the cart).
Let the hardware supplier do the patcher is a double edged sword. They can make without revelating to many "secrets". They can even add it to their own patcher they supply. But of course they can choose not to.

Hmmmmm, this is an interesting idea, but I'm not totally sure what to make of it.

Chishm has made quite a few good points, but so has HyperHacker...

I personally don't like the idea of having to patch homebrew to run it. It just seems a little...tiresome :-)

Also, whether or not the manufacturers would pay any attention is a good point. They've been pretty slack for the most part. The flood of new SLOT-1 devices has seen every one appearing claiming to support with homebrew, but with very little actual meat to back up such claims...

I don't know, maybe it's just a knee-jerk response but I don't think libfat should worry about supporting SLOT-1 devices unless full source is released (I guess we can thank the SC team in this regard, since they did release source for their new card promptly...)

However, the underlying idea chishm has is a good one. Allowing various people to contribute drivers as required is a good thing...

My personal preferene would be for FAT access to be handled as an OS module, but that relies on a feature-complete DS OS (Other than DSLinux) being released. Either that or we start working of drivers for DSLinux to give it as much access to the DS's HW as possible...

Like I said, though, the OS idea is not quite pertinent just yet for general homebrew (Porting current homebrew apps to DSLinux would be a long and code-filled path...)

Changes to libfat are a good idea, but I think the patching thing is possibly a little problematic...

Hmmmmmm....

Modular is good, patching is a pain. What to do?
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

Just do patching. It pushes some of our work to the end-user, but I don't think they mind at all.
(Plus, when doing tests, the developer can simply use the makefile to generate a patched nds for his device, so it doesn't slow down development, only distribution.)
_________________
http://licklick.wordpress.com

While testing I've added a temporary IO_INTERFACE to libfat (private source, not in CVS) that basically reserves space for the patches. If people prefer it this way, I may keep it. It does, however, take up 32KiB of space.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

If this method saves me a few kilobytes of memory (as only the one driver has to be loaded) then I'm all for it! Although you'd have to allocate a chunk of memory large enough for the largest driver...
I also like the idea of the gbamp firmware patching all executables run on it - could this be done with other cards?
_________________
Big thanks to everyone who donated for Quake2

I would imagine it to be viable for all cards with a firmware...

Of course, it depends on the manufacturers playing with their firmware...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

Here is how I thought of how the driver would be implemented:
Somewhere (possibly near the beginning of the file) there is a function look-up table. Functions include FAT_init, FAT_fopen, and other essential pieces to the library. Then, somewhere in the file, there is a large chunk of memory (chishm say 32KiB), which is ZERO'd out (or packed with garbage or something...). The patcher would need some way to locate this memory region.
The patcher would write in this chunk of memory the function code (for FAT_init, FAT_fopen, etc.) for the certain card. Then, it would write the start addresses (offset by the ROM start address) to the function look-up table.
The user's code (programmer of the .nds) would call the functions from the LUT. This is done by reading the needed function pointer from the LUT, and calling the function. (Wrapper functions should be provided kindly by a header or such.) By default, before the ROM is patched, perhaps the LUT could contain pointers to a function to print an error message ("Please PatchMe (tm)!") as a dummy.
(I think that the program should support both ARM and THUMB code, and should do proper switching or such...)
Is this how libfat is intending to work things out?

My idea, expanded from this one, is to instead of allocating a large chunk of nasty ROM space, simply append the data to the end of the target binary (the .arm[79], not the .nds). This could allow any size of patching, as long as it's kept under the 4MB size limit (minus the IPC structures used in libnds).

To transfer the patch from one software to another, simply copy the loader, with the patch and patch LUT. Copy the ROM image using the patching functions. Then update the loaded ROM's FAT table, while adjusting function offsets to make it work at the end of the binary.
(This method may require a "size" parameter per function, or, if all patching code were forced to be in one block, a "size" paramater for the entire patch (minus the LUT). Or something.)
In theory, this patching method would not take very long; it's a simple memory-to-memory copy, with a little offset handling.

I have managed to write the patch part (Makfile, .ld, crt0.s and .spec files) and it seems okay. I even wrote the stub interface for libfat. I haven't written the actual patcher yet, so I had a lot of manual address recalculations to perform.

A lookup table is generated when code is compiled as -fPIC (Global Offset Table). This gets rewritten with the correct addresses. Unfortunately, there is a bug in GCC where it doesn't reference the GOT for interworking stubs, meaning I need to patch a second section. Externally accessed functions are the same as the IO_INTERFACE functions. In fact, my patch file header contains a section that is used as the IO_INTERFACE. This makes the code relatively easy to port backwards to the normal libfat way of doing things.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Will it be possible to re-patch a .nds ?

i.e. if you get a homebrew, and don't know if it is an unpatched version or not, just patch it again with your card drivers. This will reduce confusion between unpatched and patched version of homebrews.

Lord Raptor wrote:

Will it be possible to re-patch a .nds ?

i.e. if you get a homebrew, and don't know if it is an unpatched version or not, just patch it again with your card drivers. This will reduce confusion between unpatched and patched version of homebrews.

To do that, he'd probably need to put a little magic number thing before the driver space.

chuckstudios wrote:

To do that, he'd probably need to put a little magic number thing before the driver space.

Good idea. I think there should be an easy way to figure out what devices a particular binary supports.
_________________
Nintendo DS homebrew on Wikipedia

chishm wrote:

I included the ability to use two slots at once in libfat due to a few requests for it. Now that it's there, I have not seen a single app use it. It's as simple as accessing "fat1:/" (slot 1) or "fat2:/" (slot 2), yet no one does.

I'm guessing this is because there's no way to list a directory. I was considering a simple file manager that could move/copy/etc files around between cards, but you can't write a file manager without a directory listing.

[edit] fixed quote <_<
_________________
I'm a PSP hacker now, but I still <3 DS.

Last edited by HyperHacker on Tue Dec 26, 2006 4:58 pm; edited 1 time in total

Lord Raptor & chuckstudios & felix123:
Yes it is possible to repatch an NDS. The patching already works based on a magic string to singnify the start of designated block, and this string is left there by the patches. The patch header also has space for a 15 character string that can be used to put a friendly device name in.

HyperHacker and others:
The general concensus is people don't like change :p . I'll keep the old IO_INTERFACEs in the library and simply add this as another one. This means cards that already work will work exactly the same as before. Currently unsupported cards will need to use this patch, but it's better than no support at all.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

chishm wrote:

The patch header also has space for a 15 character string that can be used to put a friendly device name in.

It's a tight squeeze:

Code:

012345678901234
SuperCardMiniSD

Quote:

HyperHacker and others:
The general concensus is people don't like change :p .

Does the "change" you're talking about mean switching from the r19b Windows installer to compiling pre-r20 from CVS?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

I'll up the friendly name to 47 characters. The change does not require a new DKP. It just needs people to patch apps for their device as opposed to having an interface for every device built in.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Thanks for the Christmas present Chishm...

In case none of you have noticed it yet, here it is :-)

EDIT: Been taking a look through the source. Very nice chishm. It's lean, mean and very clean. In fact, I'm playing with the idea of mucking about with making a RAM device driver just for fun using this. Not really useful as a permanent storage device, but just interesting to see if it would work. Are there any plans to allow two drivers to be patched in at once to allow FAT access to both SLOT-1 and a SLOT-2 device?
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

Is there a new build for libfat? And yeah chishm, it's the best christmas gift ever! =D Wonderful idea, wonderfully written!

Perhaps a moderator could rename (DLDI) + sticky this topic?
_________________
http://licklick.wordpress.com

I have everything sorted now (that explains the delay between the Christmas post and this -- compiling a few card's drivers).

I have completed the DLDI IO_INTERFACE for libfat (and gba_nds_fat). It is implemented as just another card interface, so all existing interfaces are left as they are. Only one new interface can be patched in at a time (as OOPMan mentioned), so to use two cards at once, you'll still need to have one of the currently supported cards. Also, malloc is not supported within DLDIs for various reasons, so don't try to use it. As with the provided code, DLDIs should be lean. There is currently an arbitrary limit of 32KiB, however no DLDI has even reached 16KiB so far.

Oh, and you'll need a new version of libfat to use it. The code is already in CVS.

I think the web page explains it pretty well, so I won't ramble on too much. As before, post any comments, questions, suggestions and criticisms here.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Only a big thank you from me.

Working G6 Flash driver (read-only):
@ Get the g6fl.dldi and a patched test file (.nds/.ds.gba) here.
@ Get the source here

The FAT code is totally written by viruseb, I only did the job of building it into a .dldi patchfile. The driver should be read-only.

G6 Flash owners, please run the tests and post the results here!
- Lick

[updated]
_________________
http://licklick.wordpress.com

Last edited by Lick on Tue Dec 26, 2006 2:26 am; edited 3 times in total

Working Supercard DS (Slot-1) driver:
@ Get the scds.dldi and a patched test file (.nds/.ds.gba) here.
@ Get the source here

'Ported' the SCDS driver, released by the SuperCard team. It should be able to read and write.

Supercard DS owners, please run the tests and post the results here!
- Lick

[updated]
_________________
http://licklick.wordpress.com

Last edited by Lick on Tue Dec 26, 2006 11:57 pm; edited 3 times in total

Nice work lick. Too bad I don't own either of those or I'd test for sure. Anyway, nice work ;-)
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

G6 works fine. Hmm, why`s the app so big?
Thanks, Lick!

Magical homebrew Patcher! Yay. Good work, chishm!
So now there is no reason to keep any interfaces in fat lib, except DLDI, right?

Not quite Puyo. If one wishes to do I/O with both a SLOT-1 and a SLOT-2 device at the same time then keeping the older stuff is a good idea.

I believe chishm plans to release a version at some point that removes the old stuff for those who want a lighter version with support for only one device at a time...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

Ok, tested everything with PicoDrive 0.1.6. First of all patching app didn`t worked for me, it said something like "The app must be configured to work" in windows text box & quit. Had to recompile it to work.
Then for testing purposes removed all of the drivers, about 7-8 devices, and left only DLDI interface. Compiled it and compared sizes: 684-665 = 19KiB.
Not much, but anyways.
Trying patching with default driver gave me error: "dldi file is invalid".

Well, that`s for bug report, anyway the system works as expected & I hope shouldn`t be hard for users. Thank you, Chishm.

Made a Windows GUI version of the patcher. You can find the .exe and source (needs Visual C++ 6.0 or better) at

http://home.clara.net/adamhodson/dldi32-001.zip

There may be bugs in my GUI code - I have been drinking wine.

Merry Christmas

Adam

Puyo wrote:

Ok, tested everything with PicoDrive 0.1.6. First of all patching app didn`t worked for me, it said something like "The app must be configured to work" in windows text box & quit. Had to recompile it to work.

This is normal. The DLDI requires that your app be compiled with the new version of libfat that supports it. The DLDI patcher will not work on homebrew compiled against older libfat releases.

Quote:

Then for testing purposes removed all of the drivers, about 7-8 devices, and left only DLDI interface. Compiled it and compared sizes: 684-665 = 19KiB.
Not much, but anyways.
Trying patching with default driver gave me error: "dldi file is invalid".

This is not such a surprise either, given the way libfat + DLDI works. If you look back through the thread you can find more info but I believe it works as follows: The new libfat has an pre-included DLDI code area 32 kib in size. When you patch your DLDI enabled homebrew it inserts the code from the DLDI file into this DLDI code area. This is probably a simplification...

By removing the drivers without adjusting the position of the DLDI code area in the link file I *think* you've invalidated the patching mechanism. The patching fails because libfat is smaller than it should be.

I may be wrong on this, though, so we'll have to wait and see what chishm has to say...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

chishm wrote:

I have everything sorted now (that explains the delay between the Christmas post and this -- compiling a few card's drivers).

Also, malloc is not supported within DLDIs for various reasons, so don't try to use it. As with the provided code, DLDIs should be lean. There is currently an arbitrary limit of 32KiB, however no DLDI has even reached 16KiB so far.

No malloc... mmh the g6 driver have a 16ko lookuptable to translate logical adresses. If I have a malloc handy the driver will be 16ko less.
For now I don't think it will break the 32ko limit so there is no hurry.
Anyway good work everybody.

OOPMan wrote:

Puyo wrote:

...

This is normal. The DLDI requires that your app be compiled with the new version of libfat that supports it. The DLDI patcher will not work on homebrew compiled against older libfat releases.

What I meant was, that the dos patcher provided on chishm`s site didn`t even start for me, it just produced windows error when I ran it.

Quote:

This is not such a surprise either, given the way libfat + DLDI works. If you look back through the thread you can find more info but I believe it works as follows: The new libfat has an pre-included DLDI code area 32 kib in size. When you patch your DLDI enabled homebrew it inserts the code from the DLDI file into this DLDI code area. This is probably a simplification...

By removing the drivers without adjusting the position of the DLDI code area in the link file I *think* you've invalidated the patching mechanism. The patching fails because libfat is smaller than it should be.

Well, first of all I was doing it with gba_nds_fat, sorry for not mentioning it. But even if it was libfat it shouldn`t be a problem, because patching software simply searches for magic string & appends the driver just after. It`s not dependant of libfat size.
While the problem with default.dldi is that the header is 64 bytes further from it should be.

Puyo wrote:

What I meant was, that the dos patcher provided on chishm`s site didn`t even start for me, it just produced windows error when I ran it.

Same here on Windows 2000. I think it needs a later version of the Visual C++ runtime .dll (Visual Studio 2005?).

Adam

Yeah, the G6 Flash driver only compiles when the memory is 32K. Even 16K did not compile. (Because the lookuptable is 16K itself.)
SuperCard DS however is only 8K. Not that it matters much, since it's still all < 32K.

bob_fossil: nice GUI. If only you could:
- Load DLDI's into a list. (Like, scan the same directory for .dldi files.. etc.)
- Make a drag-and-drop list for to-be-patched binaries.
That would seriously own.
_________________
http://licklick.wordpress.com

Last edited by Lick on Tue Dec 26, 2006 2:45 am; edited 2 times in total

Untested DSLink (microSD Card) driver:
@ Get the untested dlms.dldi and a patched test file (.nds/.ds.gba) here.
@ Get the source here

Taken from 20061204_ndskybkm03.zip, the original code is written by Rudolph. 'Ported' to dldi, 8K in size. Should be able to read and write.

DSLink owners, please run the tests and post the results here!
- Lick
_________________
http://licklick.wordpress.com

Interesting, does this still use the same initialization functions like fatInitDefault? Will it return failure if no device is found?

Lick:
I added the G6FL, SCDS, and DLMS interfaces to my page. If you don't want this, I can remove them.

Puyo:
When using gba_nds_fat, you'll need to add the driver as the first in the initialisation list for both GBA and NDS (it should be fairly obvious of how to do this). The small reduction in size is because the original interfaces share a lot of code (in libfat, all the CF based cards differ only in their startup routines and registers, for example). They can also link against libnds and newlib that is already used in other parts of libfat, rather than having to compile it in separately for the driver (as in DLDI).

I also fixed the default.dldi file. The problem was caused by me not putting the code in the ".init" section, so the linker added it's own init code at the start of the file.

The win32 exe was compiled using VC++ 2005. If people want to compile it for other OSes (Linux, MacOS X, etc) or even recompile it for Windows without the dependencies, then feel free to.

OOPMan:
DLDI doesn't rely on the other drivers being there at all. The reserved space is empty when no interface is patched in.

viruseb:
In my opinion, good hardware and drivers shouldn't need to take up 100's of KiBs of room. I think that the hardware should be doing most of the work, not the CPU and software. Other people think differently, I suppose, including device manufacturers (where it's cheaper to burden the host system).

Don't worry too much about using the smallest space as possible, as long as it's under 32KiB. It will take up the same amount of space in the binary as was originally reserved for it. The only reason to aim for smaller drivers is when the host binary is running low on space and the author decides to reduce the reserved space.

That being said, the DLDI specifications are flexible enough that a V2 could be made with malloc allowable.

Lazy1:
To libfat, it looks like any other IO_INTERFACE. The default DLDI is simply there to reserve space, and returns false for any function call. The DLDI file header has a section that is exactly the same as an IO_INTERFACE struct, and this is used by libfat. So to the programmer, it behaves exactly the same as before.

If a patch is written correctly, it will return false if the desired device is not found. However, I'm not sure all patches are written correctly, which is why you can patch back to default if you want to. I'm not sure if I mentioned it before, but you can patch from any device to any device.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Puyo wrote:

What I meant was, that the dos patcher provided on chishm`s site didn`t even start for me, it just produced windows error when I ran it.

Aaaah, well, bit of confusion there :-)

Puyo wrote:

Well, first of all I was doing it with gba_nds_fat, sorry for not mentioning it. But even if it was libfat it shouldn`t be a problem, because patching software simply searches for magic string & appends the driver just after. It`s not dependant of libfat size.
While the problem with default.dldi is that the header is 64 bytes further from it should be.

Which version of gba_nds_fat? The one that supports DLDI, or not?

Anyway, if it is a bug I'm sure chishm will fix it soon enough :-)
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

Lick wrote:

bob_fossil: nice GUI. If only you could:
- Load DLDI's into a list. (Like, scan the same directory for .dldi files.. etc.)
- Make a drag-and-drop list for to-be-patched binaries.
That would seriously own.

http://home.clara.net/adamhodson/dldi32-002.zip

OK, the program now looks in the folder you ran it from for .dldi files and creates a combo list from the available files. You can browse to another folder and use that if you wish.

You can now add binaries to the list to do basic batch processing. You can also drag and drop files onto the list. They will then be processed in order when you hit the 'Patch' button. The log window will show the results.

Adam

Awesome, Adam! ;D
_________________
http://licklick.wordpress.com

Lick wrote:

Working G6 Flash driver (read-only):
@ Get the g6fl.dldi and a patched test file (.nds/.ds.gba) here.
@ Get the source here

The FAT code is totally written by viruseb, I only did the job of building it into a .dldi patchfile. The driver should be read-only.

G6 Flash owners, please run the tests and post the results here!
- Lick

[updated]

On my G6, the tests list the contents of the root of my card, and finishes with :
done error: 30 Read-only file system
-- stop --

Is it normal ?

Anyway, awesome job !

That's normal, because the G6 Flash driver is still read-only. (And the code is written by viruseb!)

chishm: the device table is bugged. The 'author' text of SCCF should be swapped with the 'author' text of SCDS (Slot-1). Thanks for adding the drivers! ;D
_________________
http://licklick.wordpress.com

Thanks a lot Chishm for all the hard work
Thanks to your library, I'll be able to add FAT support to Comic Book DS 2.0

I've got two questions :

- I'm using PAlib and it creates 2 files : ".nds" ".sc.nds" "ds.gba"
Is the patcher able to take 'only' the .nds file and create the correct file for each particular adapter ?

- I plan to persist (saving in a file) the viewed page of the comic book each time the page is changed. Could this frequent save damage the memory (SD card) ?
Is there a known way to be notified just before the DS is shut down ?

I hope to see soon the r20 of DevKitPro :)

PS: Thank you too Lick. i can see that you are quite active. Moreover, i 'borrowed' your brightness handling code :)
_________________
http://Gnese.free.fr/NDS/

Lick wrote:

That's normal, because the G6 Flash driver is still read-only. (And the code is written by viruseb!)

chishm: the device table is bugged. The 'author' text of SCCF should be swapped with the 'author' text of SCDS (Slot-1). Thanks for adding the drivers! ;D

OK.

So, add me in the working list for the G6 :)

Thank you for your answer (I wondered if my G6 was corrupted)

SuperCard DS (Slot-1) driver works. Read here.

Paco: perhaps you can do it every minute? And make it an option, so people can turn it off to 'save' on their cards.
_________________
http://licklick.wordpress.com

Okay, SCDS author is fixed and listed as working. Thanks Lick and sWampy.

Paco_777:
You won't be able to use the current PAlib FAT library with this driver. Either wait until they upgrade it or use libfat. ".sc.nds" and ".ds.gba" are ".nds" files with a loader prefixed. You can patch either the ".ds.gba" or ".nds" files with dlditool. Use dsbuild to turn a ".nds" into a ".ds.gba" file.

bob_fossil:
That's a great tool. It'll make it a lot easier for end-users. Just one very minor niggle. You should be including the GPL license with the download, as dlditool was released under the GNU GPL.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

So will ndstool, dlditool, and dsbuild for all major platforms (Windows x86, Mac OS X x86/PowerPC, and Linux x86) be available from a central location?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Paco_777 wrote:

- I plan to persist (saving in a file) the viewed page of the comic book each time the page is changed. Could this frequent save damage the memory (SD card) ?

Flash memory can handle generally between 100,000 and 1,000,000 writes. At 100,000, writing to it a whopping 50 times a day would get you just over 5.4 years of usage. Of course, one operation may be a few dozen writes, but then there's sure to be days where you do pretty much nothing that involves writing, so it should even out nicely.

Quote:

Is there a known way to be notified just before the DS is shut down ?

Unfortunately I don't believe so.

BTW, you might want to re-check your math. ;-)
_________________
I'm a PSP hacker now, but I still <3 DS.

You shouldn't do that much writing to the SD card. Your application won't be the only one writing to the card.
Is it really that hard for the user to just go to the page again if they turned the DS off or something?
You could also offer a shutdown option which would save the page.

chishm wrote:

bob_fossil:
That's a great tool. It'll make it a lot easier for end-users. Just one very minor niggle. You should be including the GPL license with the download, as dlditool was released under the GNU GPL.

OK, I've added the license with the download, plus the relevant bits of boilerplate to my source.

http://home.clara.net/adamhodson/dldi32-0021.zip

Adam

Thanks all,
I guess i will add manual save feature, event if it have a few chances to damage the card, i don't want the user to take that risk (and my program to be responsible of the troubles)

Chishm, yes I was using the 'first' version of the new fatlib (the one from this thread : http://forum.gbadev.org/viewtopic.php?t=10289) and it was working correctly. Even if i'm using PAlib, replacing the lib.h and libfat.a in the libnds directory (and adding -lfat in the makefile) is ok.

However, I have problems using the last version (libfat-nds-20061225.tar.bz2) with the patcher. When i launch the patcher, it tells me that the .nds file does not have a DLDI section.
I'm almost sure to use the correct library and header. Is there something specific to do in the makefile ?

(for information, the libfat link in your dldi page does not work as it is forbidden)
_________________
http://Gnese.free.fr/NDS/

tepples:
AFAIK ndstool and dsbuild are included as part of DevkitPro. If WinterMute says it's okay, I'll add dlditool too.

bob_fossil:
Thanks for fixing the licenses. I can call off my crack-team of blood-thirsty lawyers now. :p

Paco_777:
Make sure you extract the newest libfat over the top of the old version, and rebuild your app (make clean && make) to use it.

The libfat link is broken because I haven't actually made that page yet. It's a bit like a wiki -- I added a link I later intend to fill.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

chishm wrote:

tepples:
AFAIK ndstool and dsbuild are included as part of DevkitPro.

True, but end users tend not to have a devkitPro installation, which appears to be targeted at developers.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

For end-users, ndstool is not needed if they are only downloading *.nds files. dlditool is available in the same place as all the DLDI files, so they are likely to find it. dsbuild can be found using a quick FWSE search. dlditool should handle *.ds.gba files fine too, so they can patch those if they really wish.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

chishm wrote:

dlditool is available in the same place as all the DLDI files

But does it run on a Macintosh computer?

Quote:

dsbuild can be found using a quick FWSE search.

Fast Wide Single Ended? If you refer to Favorite Web Search Engine (Yahoo/MSN/Google), does it run on a Macintosh computer?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Perhaps somebody should put together an "end users tool pack", or something along those lines. A big old pack of tools required for various homebrew roms, compiled against all the different major platforms...
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI

You can find my NDS homebrew projects here...

If someone builds dlditool for Mac, I'll add it to the page. The source is a single .c file and uses standard POSIX functions (except stricmp, I'll have to change that to strcasecmp).

I do agree that we need a page with tools for end-users. Unfortunately, I only have access to a PCs (not Macs) so I can't build any tools for MacOS. Source for both ndstool and dsbuild is in DevkitPro CVS, maybe I'll add dlditool too.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Hi,
I just joined this forum and the DS homebrew community. First of all, I'd like to say "Thank you" for DevkitPro and libfat, as they are all great pieces of software and work like a charm.

Then, a question: can I use libfat to do low-level access to the SD card? I need to read raw sectors, just like dd does.

Thanks again!
_________________
Nintendo DS Lite (White) + Supercard Lite + R4 + Sandisk 1 GB MicroSD
Sony PSP + Firmware 3.03 OE-A2

Hi all!

Good job for all these drivers!

i'm currently working on VGMDS (http://perso.wanadoo.fr/Globoeil/VGMDS/VGMDS.htm), and I need more than ever SD-compatible drivers.
So I've heard something about libfat, but... How can I use it?

My context:
-I already have a LOT of code written with "FAT_fread, FAT_chdir", etc functions (Using gba_nds_fat_2006-03-03) , and I just want to know if I have to rewrite my entire source to use libfat?
If I don't have to rewrite all the code, what should I do?

Sorry, an older lifat.a (that was in another directory) was used instead of the new one.
Now i can patch correctly my files :)

i have to say that i'm a bit lost between those 3 files (".sc.nds" and ".ds.gba" are ".nds") produced by default with PAlib.
On my supercard SD, both the .sc.nds and a .ds.gba (renamed as .nds) extensions works.

I was used to use the .sc.nds file but, even if the dldi patch report no errors, the resulting file does not work.
However that's ok because the patched .ds.gba renamed into .nds works correctly on my supercard (well, in fact the patch is not necessary because the card is supported with the default driver)

It may be quite hard for some (new) end users to :
- find which one of the 3 files they have to get (sometimes trying the 3 of them)
- know if they have to rename the file or not
- test the file which may work without the patch
- apply the patch
- perhaps apply another specific patch for their card.

This procedure could be explained somewhere (perhaps it is already, but I've never found it)

The easiest thing would be for the developer to distribute the .nds file only
The end user would then apply a 'homebrew' patcher with the dldi dedicated to his card.
With the dldi, some information could be bundled like the correct extension, and the necessity to add a loader (which may also be bundled) of not.
_________________
http://Gnese.free.fr/NDS/

There's an EZ5 driver out now. I would make into a DLDI, but it's beyond my skills.

Nobody can explain it to me?

http://forum.gbadev.org/viewtopic.php?t=10289 has every info on moving from old to new fat lib you need.
_________________
GBAMP Multiboot

I'm going to port the EZ5 driver. After I farted.

Okay, ready to port!
_________________
http://licklick.wordpress.com

SukkoPera:
You can't directly read/write raw sectors using libfat. However, you could just make use of the stuff in the disc_io source directory. You'll only need common.h from the top level source directory. Alternatively, just use libfat and call the disc_io functions directly. Be careful doing this, since they are internal functions (not normally exposed outside the library) and as such are subject to change without notice.

Globoeil:
You don't have to rewrite all of your code. You'll need to get the backported DLDI interface for gba_nds_fat (available on the DLDI page). Edit disc_io.c and:

#include io_dldi.h
Add a DLDI initialisation step to both GBA and NDS interface checking functions

After doing this, you should be able to use DLDI patches.

Paco_777:
*.sc.nds is basically the same as *.ds.gba, but with a different extension. dlditool detects the file type based on the extension, and I have programmed it to detect *.ds.gba and *.nds, but not *.sc.nds. You can force the type by using the -t switch, like:

Code:

dlditool -tdsgba sccf.dldi libfat_tests.sc.nds

The reason dlditool reported no errors is because it managed to find the DLDI section, but then patched it for the wrong file type (*.nds, not *.sc.nds).

chuckstudios:
It's fairly easy to make a driver into a DLDI file. Instructions are on the DLDI page. If you have a working driver to begin with, it usually takes no more than 5 minutes to create and test the DLDI file.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Tested to fail EZ Flash 5 (microSD Card) driver:
@ Get the failing ezf5.dldi and a patched test file (.nds/.ds.gba) here.
@ Get the source here

This is the ported version of EZ Flash 5's official FAT code, released by EZteam. I am not sure if the readSector code will work (their code doesn't contain such a function with the same parameters), but it probably works.
Ow, and it's 16K.

EZ Flash 5 owners, please run the tests and post the results here!
- Lick

[update] looks like the FAT lib doesn't work. Lame, EZteam.
_________________
http://licklick.wordpress.com

Last edited by Lick on Fri Dec 29, 2006 5:26 pm; edited 1 time in total

chishm: what is the difference for patching between the filetypes? Isn't it the same 32K that is being replaced?
_________________
http://licklick.wordpress.com

Paco_777 wrote:

i have to say that i'm a bit lost between those 3 files (".sc.nds" and ".ds.gba" are ".nds") produced by default with PAlib.
On my supercard SD, both the .sc.nds and a .ds.gba (renamed as .nds) extensions works.

Explanation, with latest info on m3/sc included:

ds.gba: "PassMe format". A DS program designed for use with traditional GBA flash cards and PassMe/NoPass style devices. Generally consists of a short loader program followed by a .nds file.
sc.nds: Byte-identical to ds.gba, but renamed for use with SuperCard's menu, which needs files in ds.gba format to have the .nds suffix.
.nds: New versions of ndstool put a mini-loader on these so that they work more smoothly with SuperCard, but software for traditional GBA flash cards that tries to repair the header for GBA-mode software may screw this up.

Quote:

It may be quite hard for some (new) end users to :
- find which one of the 3 files they have to get (sometimes trying the 3 of them)

As I understand it:

Traditional GBA flash cards can use ds.gba
GBAMP (aka M2), M3, and SLOT-1 cards can use .nds
SuperCard and M3 can use sc.nds (renamed ds.gba)
Drop .nds onto dsbuild to get ds.gba

Quote:

The easiest thing would be for the developer to distribute the .nds file only
The end user would then apply a 'homebrew' patcher with the dldi dedicated to his card.

I agree.

chishm wrote:

You'll need to get the backported DLDI interface for gba_nds_fat

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

I don't think it's -really- necessary. BTW, SuperCard and M3 use normal NDS.

Only thing that has to change is the order in which ".sc.nds" and ".nds" are checked in the patcher. The first should be checked first.
_________________
http://licklick.wordpress.com

chishm wrote:

SukkoPera:
You can't directly read/write raw sectors using libfat. However, you could just make use of the stuff in the disc_io source directory. You'll only need common.h from the top level source directory. Alternatively, just use libfat and call the disc_io functions directly. Be careful doing this, since they are internal functions (not normally exposed outside the library) and as such are subject to change without notice.

I've spent quite a bit today looking at libfat's sources, and I had reached the same conclusions. Therefore I took the libfat sources, deleted all the functions dealing with FAT, and renamed the whole thing libblockdev. Now I need to implement raw open(), seek() and close(), which sounds reasonable, and I hope to be able to mantain the DLDI structure, which I think is great. I'm happy to have joined the NDS homebrew community now that this sort of things is almost sorted out ;).

Anyway I'll keep you posted, maybe we can merge back the code, one day :).

Congratulations for the libfat code, it looks very well structured and easy enough to understand.

PS: BTW, today's CVS won't compile :). dir_iter_t is undeclared, but it didn't affect me, as it was one of the things I removed.
_________________
Nintendo DS Lite (White) + Supercard Lite + R4 + Sandisk 1 GB MicroSD
Sony PSP + Firmware 3.03 OE-A2

SukkoPera wrote:

I've spent quite a bit today looking at libfat's sources, and I had reached the same conclusions. Therefore I took the libfat sources, deleted all the functions dealing with FAT, and renamed the whole thing libblockdev.

Good job. Is it for both GBA and DS? And once the block device drivers get factored out completely, how hard would it be to adapt FreeBSD's (presumably more widely tested) FAT library on top of it, or to adapt one of the gba_nds_fat forks on top of it?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tepples wrote:

SukkoPera wrote:

I've spent quite a bit today looking at libfat's sources, and I had reached the same conclusions. Therefore I took the libfat sources, deleted all the functions dealing with FAT, and renamed the whole thing libblockdev.

Good job. Is it for both GBA and DS? And once the block device drivers get factored out completely, how hard would it be to adapt FreeBSD's (presumably more widely tested) FAT library on top of it, or to adapt one of the gba_nds_fat forks on top of it?

The disc_io stuff was always a separate layer from gba_nds_fat or libfat. The only reason interfaces weren't back-ported to gba_nds_fat more often is because I considered that set of code (not really a library) to be rather limited in its design, with many bugs (lack of any reentrancy, support for only one slot at a time, re-writing of fread when it was already available in newlib) that were simply not fixable by modifying that code base in any sane way. I wanted to encourage the use of libfat (which has all those problems fixed and is much more maintainable), so I did this using the carrot (more device support) and stick (no bug fixes in gba_nds_fat) approach. Unfortunately, the lack of directory listing functions hindered that plan.

Many of the gba_nds_fat forks really only differ in the devices they support. I back-ported DLDI to try to unify the device support amongst all of the different libraries in the wild. In fact, the only difference between gba_nds_fat and libfat's IO_INTERFACE model is gba_nds_fat gets the interface pointer via a function call (a mere wrapper) compared to libfat's approach of exposing the IO_INTERFACE reference directly.

SukkoPera wrote:

Congratulations for the libfat code, it looks very well structured and easy enough to understand.

PS: BTW, today's CVS won't compile :). dir_iter_t is undeclared, but it didn't affect me, as it was one of the things I removed.

Thanks, that was yet another reason I rewrote gba_nds_fat into libfat. The old code was a mess.

dir_iter_t is from the up-coming directory support which is yet to be added to DevkitPro's newlib patches. It's unfortunate that those two parts of the DKP CVS went out of sync (a few months back) but it can't be helped.

Lick wrote:

what is the difference for patching between the filetypes? Isn't it the same 32K that is being replaced?

It is, but the patcher needs to calculate the correct memory offsets for all the functions and global variables. It does this by examining the NDS header to find the RAM address it is loaded to. *.ds.gba files have an extra 512 bytes before the header, hence they have to be treated differently. *.gba files are assumed to be loaded to 0x08000000 and *.mb.gba (*.mb) are assumed to be loaded to 0x02000000
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

tepples wrote:

SukkoPera wrote:

I've spent quite a bit today looking at libfat's sources, and I had reached the same conclusions. Therefore I took the libfat sources, deleted all the functions dealing with FAT, and renamed the whole thing libblockdev.

Good job. Is it for both GBA and DS? And once the block device drivers get factored out completely, how hard would it be to adapt FreeBSD's (presumably more widely tested) FAT library on top of it, or to adapt one of the gba_nds_fat forks on top of it?

Well, I'm trying to change Chishm's code as little as I can (which basically means not changing it at all, but adding above it), so it should still work on GBA, too. I'll try do some tests, if I ever end up with anything usable.

About using FreeBSD's FAT implementation, I think it can already be done in current libfat, because the raw access functionality is clearly separated from partition access. It's just that raw access is limited to reading a certain range of sectors, while I need to be able to read() an arbitrary amount of data and seek() here and there, that's why I'm modifying it.

Actually I thought the FAT code was taken from somewhere else, and not written from scratch. Anyway it seems already quite stable, so I think the current code is good enough, unless big problems show up.
_________________
Nintendo DS Lite (White) + Supercard Lite + R4 + Sandisk 1 GB MicroSD
Sony PSP + Firmware 3.03 OE-A2

Quote:

Globoeil:
You don't have to rewrite all of your code. You'll need to get the backported DLDI interface for gba_nds_fat (available on the DLDI page). Edit disc_io.c and:

1. #include io_dldi.h
2. Add a DLDI initialisation step to both GBA and NDS interface checking functions

After doing this, you should be able to use DLDI patches.

Thank you VERY much! But there is just on thing that I don't understand ...

Quote:

Add a DLDI initialisation step to both GBA and NDS interface checking functions

Maybe I must add a line at the beginning of my program?What line?
Sorry for my ignorance...

Mmmh, it seems that my read function:

Code:

int _RAWIO_read_r (struct _reent *r, int fd, char *ptr, int len);

always gets called with len = 1024, is this normal? Maybe some kind of wrapping done by newlib? What happens if the program did a 512 byte - for instance - read, allocating only 512 for the buffer?

It all seems rather odd :).
_________________
Nintendo DS Lite (White) + Supercard Lite + R4 + Sandisk 1 GB MicroSD
Sony PSP + Firmware 3.03 OE-A2

newlib uses buffered I/O by default, it may be 1024 bytes at a time but I'm not 100% sure offhand.

You should be able to use setvbuf to change the buffering behaviour.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

chishm, tepples :
thanks for those clarifications and help. :)

chishm :
that's not an issue for me but patching this way makes dlditool crash :
>dlditool -tdsgba scsd.dldi myfile.sc.nds
(i can send you my sc.nds file if it can help)
_________________
http://Gnese.free.fr/NDS/

I had a look at the fileformat, and i think i gonna use DLDI for loading blockdevice drivers into my current project dynamically.

The drivers only manipulate the devices and their given xkB of memory, right? So i can switch between several DLDI by just shutting down the interface, free the memory and laod/prepare the next? Or do you export a way to malloc from main memory in any way?
_________________
GBAMP Multiboot

Lick wrote:

Untested DSLink (microSD Card) driver:
@ Get the untested dlms.dldi and a patched test file (.nds/.ds.gba) here.
@ Get the source here

Taken from 20061204_ndskybkm03.zip, the original code is written by Rudolph. 'Ported' to dldi, 8K in size. Should be able to read and write.

DSLink owners, please run the tests and post the results here!
- Lick

Tested, Failed DSLink (microSD Card) driver

"Initing FAT...fail"

Ppfffft.. Thanks for testing, too bad it's negative! =(
_________________
http://licklick.wordpress.com

Globoeil:
You need to edit the disc_io.h file which is part of gba_nds_fat. First, add the line

Code:

#include "io_dldi.h"

under the comment

Code:

// Include known io-interfaces:

Next, look for the function disc_setGbaSlotInterface, and just before line that says #ifdef SUPPORT_M3CF, add:

Code:

active_interface = DLDI_GetInterface() ;
if (active_interface->fn_StartUp())
{
return true ;
} ;

Add the same code to disc_setDsSlotInterface, just before the #ifdef SUPPORT_NMMC line.

Paco_777:
Whoops, that was a bug. Fixed it now.

MightyMax:
Correct, the drivers only have access to their allocated 32KiB of memory.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

d3tr0it: Moonlight has also attempted to port the DSlink driver to DLDI. Please test it.
http://mdxonlinemirror.dyndns.org/resources/20061230_dldi_dlms_ver10_20061230.zip

I patched Lick's test NDS with the driver. http://www.zshare.net/download/dslink_v2-7z.html

Firon wrote:

d3tr0it: Moonlight has also attempted to port the DSlink driver to DLDI. Please test it.
http://mdxonlinemirror.dyndns.org/resources/20061230_dldi_dlms_ver10_20061230.zip

I patched Lick's test NDS with the driver. http://www.zshare.net/download/dslink_v2-7z.html

hmm.. same error.
I tried the NDSKYBKM03_DLMS_DSLink_SD.nds with integrated support just to see if something was wrong with my hardware, but it works like a charm

Well, can you try Moonshell? It's using DLDI now.
At least this way you can rule out it being a problem with Lick's test file.
http://mdxonlinemirror.dyndns.org/resources/20061230_moonshell16beta5.zip

Quote:

Globoeil:
You don't have to rewrite all of your code. You'll need to get the backported DLDI interface for gba_nds_fat (available on the DLDI page). Edit disc_io.c and:

1. #include io_dldi.h
2. Add a DLDI initialisation step to both GBA and NDS interface checking functions

After doing this, you should be able to use DLDI patches.

Okay I've done all of these instructions.
But when I try to use a patch (using "dlditoo.exe scsd.dldi vgrds.nds") it always says me: "VGRDS.NDS does not have a DLDI section".
Why? I've put what you said exactly where you said

Quote:

You need to edit the disc_io.h file which is part of gba_nds_fat. First, add the line
Code:
#include "io_dldi.h"
under the comment
Code:
// Include known io-interfaces:

Next, look for the function disc_setGbaSlotInterface, and just before line that says #ifdef SUPPORT_M3CF, add:
Code:

active_interface = DLDI_GetInterface() ;
if (active_interface->fn_StartUp())
{
return true ;
} ;

Add the same code to disc_setDsSlotInterface, just before the #ifdef SUPPORT_NMMC line.

Except that I modify disc_io.C because you said disc_io.h but there was not trhese function in this file.

wintermute wrote:

newlib uses buffered I/O by default, it may be 1024 bytes at a time but I'm not 100% sure offhand.

You should be able to use setvbuf to change the buffering behaviour.

Thanks a lot, this worked:

Code:

setvbuf (fd, NULL, _IONBF, 0);

_________________
Nintendo DS Lite (White) + Supercard Lite + R4 + Sandisk 1 GB MicroSD
Sony PSP + Firmware 3.03 OE-A2

Firon wrote:

Well, can you try Moonshell? It's using DLDI now.
At least this way you can rule out it being a problem with Lick's test file.
http://mdxonlinemirror.dyndns.org/resources/20061230_moonshell16beta5.zip

Moonshell with the 20061230_dldi_dlms_ver10_20061230.zip dldi file works on my dslink..

Update: Licks DLDI seems to work with moonshell also

Last edited by d3tr0it on Sat Dec 30, 2006 2:37 pm; edited 1 time in total

Excuse me, if I'm stupid. But what is DLDI (in plain olde English)?
A library that allows the compiled library to be patched with a new FAT driver? In this case, it's ingenious. :0
_________________
[ Crimson and Black Nintendo DS Lite | CycloDS Evolution | EZ-Flash 3-in-1 | 1 GB Transcend microSD ]

d3tr0it: interesting. Perhaps it really is a problem with Lick's test file, and not his driver. :P

MaHe: essentially, it allows you to patch an NDS file with a new/different FAT driver without needing to recompile the NDS.
Basically, a developer would never need to do anything to support new adapters. All you'd have to do is patch the NDS with a driver for the new adapter, and bam, you've got full support.

DLDI is a great idea, and it actually seems to be working in practice. Good job chishm. :P I hope every homebrew developer makes use of it.

chishm wrote:

chuckstudios:
It's fairly easy to make a driver into a DLDI file. Instructions are on the DLDI page. If you have a working driver to begin with, it usually takes no more than 5 minutes to create and test the DLDI file.

According to Lick, it didn't work. The EZTeam's driver was in a weird structure compared to other drivers.

ok, just a little update on dslink.
I just tried the moonshell dldi with the recently released ndsmail and it failed to access the sd card.

So far only moonshell works with the dslink dldis. How does the dldi implementation in moonshell differ from other apps? (ndsmail and licks test app so far)

And btw are there any more apps with dldi support. Maybe a test app with lots of debug output?

My testfile was provided by chishm and it has been patched multiple times. (Not that that should mather.) The difference compared to Moonshell, and the likeness compared to NDSMail, would probably be the use of libfat. Moonshell, I think, uses a modification of gba_nds_fat..
_________________
http://licklick.wordpress.com

Yes, you're right, Moonshell uses gba_nds_fat. Strange though, why would the driver work with gba_nds_fat and not libfat?

I have made a new testing app that should give more thorough results. It is available on the DLDI page. If you have a card that is listed as not tested, can you try it and report back here. Thanks. I'm also interested in cards that should work but fail for whatever reason.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

chishm wrote:

I have made a new testing app that should give more thorough results. It is available on the DLDI page. If you have a card that is listed as not tested, can you try it and report back here. Thanks. I'm also interested in cards that should work but fail for whatever reason.

The new test app doesnt work with the DSLink DLDIs. Same error as before.
"Initing FAT...fail"

Chishm, do you know (or have an idea) why the DLDI implementation in moonshell works with these DLDIs?

windirt (EZ-Flash Representative)

Quote:

if you want run homebrew program with ez5,you need change you makefile file like this.

$(TARGET).nds : $(TARGET).arm7 $(TARGET).arm9
ndstool -c homebrew.nds -7 arm7/arm7.bin -9 arm9/arm9.bin -g "PASS" "01" "EZ5NDS_LDR" -b arm9/logo32.bmp "MoonShell.nds;_;By Moonlight"
then the homebrew.nds file can run in ez5.
you also can change our ez5 151 makefile file for run homebrew mode in ez5

Note : the -g parameter "PASS" is necessary.. We used it to distinguish cleanrom or homebrew.

I suppose "EZ5NDS_LDR" is needed as well?

[upd] try this please!
_________________
http://licklick.wordpress.com

I would so much rather see a dynamic linking version than one that you had to patch each app. You would just need a folder in the root of your card with the .so for your card(s) and you could keep drivers for all cards somewhere if you wanted to trade files with a friend that uses a different card. elf dynamic linking isn't hard at all. I wrote my own PE exe loader that handles dynamic linking and it took me very little time to do so.
If you are looking for a source for a pre-existing elf loader then look no further than KallistiOS, I wrote a full gui OS for it with multiple apps working fine on the dreamcast.

GrizzlyAdams wrote:

I would so much rather see a dynamic linking version than one that you had to patch each app. You would just need a folder in the root of your card with the .so for your card(s) and you could keep drivers for all cards somewhere if you wanted to trade files with a friend that uses a different card. elf dynamic linking isn't hard at all. I wrote my own PE exe loader that handles dynamic linking and it took me very little time to do so.
If you are looking for a source for a pre-existing elf loader then look no further than KallistiOS, I wrote a full gui OS for it with multiple apps working fine on the dreamcast.

That's all very well when you can actually read the device in the first place.

How do you read from the device when the driver has not yet been installed?

This approach would require all the detection and read code from every driver linked with the application which kind of makes loading the driver from the media a bit pointless.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

wintermute wrote:

How do you read from the device when the driver has not yet been installed?

You load your card's specific _boot_mp.nds, which loads the driver into RAM and then loads moonshell.nds.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Almost all of the newer cards don't support auto-booting. Only GBAMP does. =/
But wintermute is right, it's a bit of a struggle in practice. End-users should just quit being lazy and patch their homebrew themselves. It's nothing hard or time taking.
_________________
http://licklick.wordpress.com

Lick wrote:

But wintermute is right, it's a bit of a struggle in practice. End-users should just quit being lazy and patch their homebrew themselves.

If no one comes through with an implementation of this suggestion, does this include buying a PC that runs Microsoft Windows with which to do so?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

tepples wrote:

Lick wrote:

But wintermute is right, it's a bit of a struggle in practice. End-users should just quit being lazy and patch their homebrew themselves.

If no one comes through with an implementation of this suggestion, does this include buying a PC that runs Microsoft Windows with which to do so?

source is provided, along with linux and windows binaries.

I'm intending to provide this tool with devkitARM r20 which should hopefully be released by the end of January. Assuming my OSX colleagues are available then everyone should be pretty happy.

I now have newlib 1.15.0 built with the psuedo device API updated for the directory listing functions. There are also several fixes in the base rules for arm/itcm/iwram code as noted in other places by gmiller.

I'm also hoping to include git and several examples using this marvellous image processor.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

tepples wrote:

wintermute wrote:

How do you read from the device when the driver has not yet been installed?

You load your card's specific _boot_mp.nds, which loads the driver into RAM and then loads moonshell.nds.

This system requires the nds to be patched with the appropriate driver. Ideally this can and should be done by the card's bootloader but I wouldn't hold my breath waiting for such a bootloader for cards where we don't have access to the firmware.
_________________
devkitPro - professional toolchains at amateur prices
devkitPro IRC support
Personal Blog

It appears that the G6 driver only works on the normal G6, and not the G6 Lite.

Firon wrote:

It appears that the G6 driver only works on the normal G6, and not the G6 Lite.

i own G6 lite and it works for me in moonshell

wintermute wrote:

I'm intending to provide this tool with devkitARM r20 which should hopefully be released by the end of January. Assuming my OSX colleagues are available then everyone should be pretty happy.

I now have newlib 1.15.0 built with the psuedo device API updated for the directory listing functions. There are also several fixes in the base rules for arm/itcm/iwram code as noted in other places by gmiller.

Nice to see a solid update on r20!

Great work man,
_________________
MrShlee.com
Projects
Dev-Scene
MyTechpedia

theli: is that with the DLDI test I posted, or with the official 1.6 finalbeta 2? 'Cause I asked some people to try it on a G6 Lite and they had no such luck.

it's the DLDI from the chishm website (one ported by lick)
adn with the first DLDI test build you posted

ok quickly put together an fcsr image dldi patcher based on gba_nds_fat fcsr driver, tested it in desmume-0.5.0 so hopefully works on hardware also.

http://gpf.dcemu.co.uk/fcsrDLDI.zip includes precompiled bins and source

here is davr's fcsr linux source and scripts and my win32 version and bat files for creating fcsr images.
http://gpf.dcemu.co.uk/fcsrimage.zip

to use create fcsr.img and then
padbin 512 file.ds.gba
cat file.ds.gba fcsr.img > out.ds.gba

then patch for dldi
dlditool.exe fcsr.dldi out.ds.gba

Troy(GPF)
http://gpf.dcemu.co.uk

Lick wrote:

Untested DSLink (microSD Card) driver:
@ Get the untested dlms.dldi and a patched test file (.nds/.ds.gba) here.
@ Get the source here

Taken from 20061204_ndskybkm03.zip, the original code is written by Rudolph. 'Ported' to dldi, 8K in size. Should be able to read and write.

DSLink owners, please run the tests and post the results here!
- Lick

Just tested on my DS-Link. I get INIT FAT: Failed

Guess it does not work :(

EDIT: One of the mods over at SCDev also tested his, same result.

GPFerror wrote:

ok quickly put together an fcsr image dldi patcher based on gba_nds_fat fcsr driver, tested it in desmume-0.5.0 so hopefully works on hardware also.

http://gpf.dcemu.co.uk/fcsrDLDI.zip includes precompiled bins and source

here is davr's fcsr linux source and scripts and my win32 version and bat files for creating fcsr images.
http://gpf.dcemu.co.uk/fcsrimage.zip

to use create fcsr.img and then
padbin 512 file.ds.gba
cat file.ds.gba fcsr.img > out.ds.gba

then patch for dldi
dlditool.exe fcsr.dldi out.ds.gba

Troy(GPF)
http://gpf.dcemu.co.uk

OK received a report that it does work on hardware for at least 1 person :)

Troy

I should probably hurry up and finish the second FCSR driver. The disc images used should be almost the same, except it'll handle writing without having to predefine the regions used.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

minor dlditool fix -- changed _stricmp to stricmp, and added checking for .sc.nds filetypes. (my system doesn't have stricmp, so i had to uncomment the #define earlier in the .c file, but it was for stricmp, not _stricmp)

Code:

--- dlditool.c 2006-12-30 17:54:22.000000000 -0800
+++ dlditool.c.fixed 2007-01-04 11:05:12.000000000 -0800
@@ -125,7 +125,7 @@
return false;
}
strEnd = &str[strlen (str) - strlen(end)];
- return (_stricmp (strEnd, end) == 0);
+ return (stricmp (strEnd, end) == 0);
}

int quickFind (const char* data, const char* search, size_t dataLen, size_t searchLen) {
@@ -150,7 +150,9 @@

enum FileType detectFileType (const char* appFileName) {
enum FileType fileType;
- if (stringEndsWith(appFileName, ".nds")) {
+ if (stringEndsWith(appFileName, ".sc.nds")) {
+ fileType = FT_DSGBA;
+ } else if (stringEndsWith(appFileName, ".nds")) {
fileType = FT_NDS;
} else if (stringEndsWith(appFileName, ".nds.gba") || stringEndsWith(appFileName, ".ds.gba")) {
fileType = FT_DSGBA;

Looks like the patcher has serious endian issues that will have to be addressed before a PPC Mac port is possible. Thankfully, I'm doing my dev on an Intel Mac, so it works great. =]

My current workflow involves loading arm9 ELF files over wifi into the delightful DS debug monitor stub using GDB, so I spent an hour or so last night hacking dlditool to support patching ELF files. Seems to work for me -- you can grab the source here.

josath & ApM:
Yeah, DLDI tool needs a bit of work. When I get enough time I'll add sc.nds patching and fix _stricmp (I forgot that I'd renamed it to make MS VC++ happy). I also need to remove any assumptions about endianess or integer length. However, removing assumptions about 8 bit chars is going a bit too far I think ;) .
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

zektor wrote:

Just tested on my DS-Link. I get INIT FAT: Failed

Correct, doesn't work on my DSlink.

But you could simply access DSlink Fat system by using this moonshell sources (v1.5). I have implemented this piece of source from moonshell into DSdoom and it run fine on my DSlink.

It looks like I'm the only one around here with a Max Media Dock, so I thought I'd join and share my experiences with DLDI.

Unfortunately it's not working on my device at all. I've tried dldi_tester.nds and DSDoom 1.1.0 rev1. Both patched successfully with mmcf.dldi according to the patcher, but when run on my DS, I never get any kind of message indicating failure, they actually freeze while trying to init FAT.

Has anyone tested the R4 lib on a M3 DS Simply? From what I understand they are basically the same device, possibly with different firmware.

josath wrote:

Has anyone tested the R4 lib on a M3 DS Simply? From what I understand they are basically the same device, possibly with different firmware.

I get my M3simply next week. but I got this driver source from M3 and the filenames have R4 in it. so I think it's the same ...

Just for kicks, I thought I'd try out the mmcf_moon.dldi driver that comes along with the most recent Moonshell. Interestingly enough the test program immediately fails when patched with it, but DSDoom works perfectly (though it needs to be run as bootme.nds, but that's a completely unrelated problem, I'm told).

Globoeil wrote:

Quote:

Globoeil:
You don't have to rewrite all of your code. You'll need to get the backported DLDI interface for gba_nds_fat (available on the DLDI page). Edit disc_io.c and:

1. #include io_dldi.h
2. Add a DLDI initialisation step to both GBA and NDS interface checking functions

After doing this, you should be able to use DLDI patches.

Okay I've done all of these instructions.
But when I try to use a patch (using "dlditoo.exe scsd.dldi vgrds.nds") it always says me: "VGRDS.NDS does not have a DLDI section".
Why? I've put what you said exactly where you said

Quote:

You need to edit the disc_io.h file which is part of gba_nds_fat. First, add the line
Code:
#include "io_dldi.h"
under the comment
Code:
// Include known io-interfaces:

Next, look for the function disc_setGbaSlotInterface, and just before line that says #ifdef SUPPORT_M3CF, add:
Code:

active_interface = DLDI_GetInterface() ;
if (active_interface->fn_StartUp())
{
return true ;
} ;

Add the same code to disc_setDsSlotInterface, just before the #ifdef SUPPORT_NMMC line.

Except that I modify disc_io.C because you said disc_io.h but there was not trhese function in this file.

what I've done wrong?

Globoeil:
Sorry if I didn't respond last time, I must've missed it. You need to make sure that io_dldi.s is compiled. It should produce an io_dldi.o file in your build directory when you make it, if it actually is compiling. If you know how to hex-edit files, try searching your executible for the following byte string:

Code:

ED A5 8D BF 20 43 68 69 73 68 6D 00

Which should produce the ascii string "???? Chishm" (where ? are strange looking symbols). If you cannot find it, then it is still missing the DLDI section.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

Hi chishm,

I've been integrating the DLDI interface into ScummVM, and have had some success.

GBAMP CF: Worked!
NinjaDS: Worked!
M3 Lite: Failed
Max Media Dock: Failed

However, I managed to get the Max Media Dock to work fine after rebuilding the DLDI removing the -i option to the linker

Change:
LDFLAGS = -specs=$(CURDIR)/../$(SPECS)/dldi.specs -T $(CURDIR)/../$(SPECS)/dldi.ld -g $(ARCH) -mno-fpu -Wl,-i,-Map,$(TARGET).map

I've no idea what this actually does, just that the makefiles on the other DLDIs don't have this option. Looking at the resulting DLDI with a hex editor, it seems to prevent the function addresses from being insterted in the table in the header.

I can build a driver for the M3 Lite out of the one I have in ScummVM if it will be useful. Although normally I would expect any M3 driver to work on the M3 lite so I'm not sure why the existing one doesn't work.

Great work on the DLDI stuff by the way, it's ace!

I can confirm that after compiling the MMCF code with the -i option removed, both the tester and DSDoom work. I can read from and write to my device with no problems.

Hey guys!

I know it doesn't look extra good when I start my first post with a request, but I'd really like to know your opinion about integrating R4/M3 Simply DLDI interface into homebrew apps. I've been following this thread but I'm afraid I don't really have what it takes to try it out myself (one of the reasons being the fact that I don't have a flashcard). I know that some stuff already works on R4 (like Beup and DS Doom) but I'd really like to see the working versions of ScummVM, DSOrganize, PicoDriveDS or HexenDS. It would be great if someone could try this out or at least throw in some ideas about getting this stuff to work (since if I understand this correctly, the apps using the "old" fatlib can't be patched this way).

Thanks for reading this and keep up the great work. Cheers.

agentq wrote:

Hi chishm,

I've been integrating the DLDI interface into ScummVM, and have had some success.

GBAMP CF: Worked!
NinjaDS: Worked!
M3 Lite: Failed
Max Media Dock: Failed

However, I managed to get the Max Media Dock to work fine after rebuilding the DLDI removing the -i option to the linker

Change:
LDFLAGS = -specs=$(CURDIR)/../$(SPECS)/dldi.specs -T $(CURDIR)/../$(SPECS)/dldi.ld -g $(ARCH) -mno-fpu -Wl,-i,-Map,$(TARGET).map

I've no idea what this actually does, just that the makefiles on the other DLDIs don't have this option. Looking at the resulting DLDI with a hex editor, it seems to prevent the function addresses from being insterted in the table in the header.

Oh, whoops. *embarrassed*
That is from when I was playing with linker options while designing the DLDI stuff. It is meant to force the linker to generate relocatable code (like -fPIC for the compiler), but it didn't work the way I thought so I removed it from the template. It seems I copied the MMCF DLDI from the template before this. Thanks for the heads-up, it's fixed now.

agentq wrote:

I can build a driver for the M3 Lite out of the one I have in ScummVM if it will be useful. Although normally I would expect any M3 driver to work on the M3 lite so I'm not sure why the existing one doesn't work.

Yeah, that'd be good, especially if you have the hardware to test it on.

agentq wrote:

Great work on the DLDI stuff by the way, it's ace!

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

Diddl wrote:

josath wrote:

Has anyone tested the R4 lib on a M3 DS Simply? From what I understand they are basically the same device, possibly with different firmware.

I get my M3simply next week. but I got this driver source from M3 and the filenames have R4 in it. so I think it's the same ...

I got my M3 Simply today and can confirm that the R4 dldi driver does in fact work with the M3 Simply.

Shtroodle:
Here's what you have to do
1. Recompile the programs with the new libfat
2. Patch the new programs with the R4 dldi driver
3. Play
_________________
Nintendo DS homebrew on Wikipedia

Pipian wrote:

Diddl wrote:

josath wrote:

Has anyone tested the R4 lib on a M3 DS Simply? From what I understand they are basically the same device, possibly with different firmware.

I get my M3simply next week. but I got this driver source from M3 and the filenames have R4 in it. so I think it's the same ...

I got my M3 Simply today and can confirm that the R4 dldi driver does in fact work with the M3 Simply.

Thanks for the info. I wonder who copied who.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

chishm wrote:

Pipian wrote:

Diddl wrote:

josath wrote:

Has anyone tested the R4 lib on a M3 DS Simply? From what I understand they are basically the same device, possibly with different firmware.

I get my M3simply next week. but I got this driver source from M3 and the filenames have R4 in it. so I think it's the same ...

I got my M3 Simply today and can confirm that the R4 dldi driver does in fact work with the M3 Simply.

Thanks for the info. I wonder who copied who.

M3 Team has explained this mystery to gbarl.it community (open the spoiler to read it):

Quote:

M3 DS simply & R4 is same our produts .
We sell the M3 DS simply .
And our Factory sell the R4 .

We will release the M3 DS real & G6 DS later .
Any information , we will inform you .

Best Regards

So it's the same product ;)
_________________
My homepage!

Hey,

chishm, first of all, I think this is great stuff. Finally a way to cleanly support all current and future flash cards without having to re-up new builds... which was a bit of a pain for me with DSFTP, at least.

I can't get it to run, though. :-) "It" being DSFTP using gba_nds_fat, with your compatibility backport from your home page. Symptom:

Code:

Dynamically Linked Disk Interface patch tool v1.01 by Michael Chisholm (Chishm)

Old driver: Default (No interface)
New driver: SuperCard (Compact Flash)

Position in file: 0x0000FDC0
Position in memory: 0x00000002
Patch base address: 0x000080BF
Relocation offset: 0xFFFE7D03

Segmentation fault

I've debugged into it, and the culprit is the memset() line at dlditool.c:89. Looks like __bss_start and __bss_end aren't initialized correctly. I've put up the .nds binary at http://giesler.biz/~bjoern/downloads/dsftp/DSFTP-DLDI-broken.nds, if you want to give it a try. Any idea what might cause this?

I'd love to upgrade to libfat, but DSFTP needs directory management...
_________________
DSFTP homepage

This was determined to be an endianess issue. The current version of dlditool (v1.01) is written with the assumption that it is running on a little-endian architecture, which a PowerPC Mac isn't. I'll release a new version once I have tested it a bit more (probably tomorrow).
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

I have released a new dlditool version (v1.10). It now supports *.sc.nds, *.gba.nds and is usable on big-endian architectures (PowerPC based Macs, for example). It is available in the usual place.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

I've finally released my hack of libfat which allows for raw I/O. It's available here:
- Source
- NDS binaries
- GBA binaries (untested)

I tried to isolate my changes/additions, so if Chishm wants to add them back to libfat, it should be fairly easy, even though some things probably need some cleaning. Anyway it works enough for my project, see this post for further info.
_________________
Nintendo DS Lite (White) + Supercard Lite + R4 + Sandisk 1 GB MicroSD
Sony PSP + Firmware 3.03 OE-A2

GPFerror wrote:

ok quickly put together an fcsr image dldi

chishm, can this be listed on DLDI page?
or why not?

and by the way ... what are drivers included with libfat except DLDI IO_INTERFACE ?

theli wrote:

GPFerror wrote:

ok quickly put together an fcsr image dldi

chishm, can this be listed on DLDI page?
or why not?

I am working on an FCSR version 2 driver that doesn't need explicit SRAM overlays, but rather just allocates sectors as they are needed. It should also be backwards compatible with FCSR version 1 images. I intend to put this up on the DLDI page, but it isn't finished yet.

theli wrote:

and by the way ... what are drivers included with libfat except DLDI IO_INTERFACE ?

Drivers in order of initialisation: DLDI, NJSD, NMMC, MPCF, M3CF, SCCF, SCSD, M3SD.

SukkoPera:
The modifications are good, but I won't be adding them back to libfat, since it is intended to be a high-level filesystem library. The raw disc I/O functions are best distributed as a separate library for people to use if they want to.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

I haven't tried DLDI yet but I have a basic understanding of what it is about. I have a question about programming for it. Can you detect if your program hasn't been patched? Such as running a function that when not patched returns a false but when patched returns a true?

No, to any host application, it appears exactly the same as a standard disc interface. If it hasn't been patched, the default DLDI just returns false on initialisation and the library tries the next available interface.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

@chishm: Ok, it's fine to keep mine as a separate library.

Anyway, a user of my program on a SCLite says that it fails to initialise the I/O driver. Actually, I only have a SCLite myself, so I'm pretty sure my program works on such cart. Someone then commented he "heard someone say it's hit or miss with the SC Lite because of an apparent hardware revision that doesn't work with the SCSD driver".

Any hints on that?
_________________
Nintendo DS Lite (White) + Supercard Lite + R4 + Sandisk 1 GB MicroSD
Sony PSP + Firmware 3.03 OE-A2

SukkoPera wrote:

Anyway, a user of my program on a SCLite says that it fails to initialise the I/O driver.

The problem is the order of the driver initialization.

My Fat library now supports all known devices (also DSlink, R4, M3simply). I loop in a driver table and each driver init tests for it's card.

Some driver init functions 'hang' if a wrong card is present. For example I have a M3 with micro SD and by calling this movie player init function my DS hang (forever - I waited for 15 minutes).

So this Movieplayer init function must called after the M3 init function ...

Maybe this Problem appears with other combinations ...

Diddl wrote:

SukkoPera wrote:

Anyway, a user of my program on a SCLite says that it fails to initialise the I/O driver.

The problem is the order of the driver initialization.

My Fat library now supports all known devices (also DSlink, R4, M3simply). I loop in a driver table and each driver init tests for it's card.

Some driver init functions 'hang' if a wrong card is present. For example I have a M3 with micro SD and by calling this movie player init function my DS hang (forever - I waited for 15 minutes).

So this Movieplayer init function must called after the M3 init function ...

Maybe this Problem appears with other combinations ...

DIDL should prevent that problem, because the patched in DIDL is the first one tested. So if a user adds the M3 microSD patch, then it will always be the first one with init() called

josath wrote:

Diddl wrote:

stuff

DIDL should prevent that problem, because the patched in DIDL is the first one tested. So if a user adds the M3 microSD patch, then it will always be the first one with init() called

Now it's getting confusing: Diddl, DLDI, what you called "DIDL"...
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

Just rename it "dildo" and be done with it.

</kidding>
_________________
http://aaiiee.wordpress.com/

Or is "DILDO" the name for drivers if they finally get Wii homebrew working?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.

I have been patching any and all homebrew apps that are utilizing dldi with the dldi DSLink driver included with the latest moonshell. Everything I have patched is working perfectly on my DSLink (DSFtp, DSO, NitroTracker). I just wanted to express my thanks for your work chishm. I for one am extremely grateful. This was a genius of an idea!

I have a request: could the Win32 frontent that bob_fossil developed be hosted on the main DLDI page? I've already encountered a user on another forum who does not understand the command-line, so I redirected him to the Win32 frontend. Placing the download link on the main site could help this situation.

Unfortunately though, I think that the frontend is already out of date, as I think I remember reading about additional support for sc.nds and other filetypes in the console program.

dantheman:
If bob_fossil updates it to version 1.10, I'll put it on my site (with his permission of course).
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

chishm, last (posted on your site) dlditool doesn't work for me.... nor linux nor windows (under wine) ...

example:
patch moonshell with last dlditool (g6fl.dldi) ... error on start
repatch with backuped dlditool ... all fine

EDIT: it seems it just doesn't deals nice with dsgba ...
DSOrganize.nds patched and then appended gba loader works fine

Just a quick bug report: Precompiled .sc.nds and .ds.gba files won't work if patched with DLDITool. You have to patch the .nds file and apply the ndsloader.bin afterwards. :/
_________________
[ Crimson and Black Nintendo DS Lite | CycloDS Evolution | EZ-Flash 3-in-1 | 1 GB Transcend microSD ]

After having problems with the new DSOrganize I downloaded the testing app from Chishm's site. I patched it and ran it, but it fails at the first test (init).

I'm using a SC lite, just got at Christmas time. I saw mentioned on another thread that there are multiple hardware revisions...? Maybe the new/old one doesn't work with the current SC DLDI?

Then again I could just be using it wrong:
1. Copied the test files to the card.
2. Run the dlditool on them, it reports success.
3. Boot the .nds.

Hopefully I'm not getting that wrong. :)

chishm wrote:

dantheman:
If bob_fossil updates it to version 1.10, I'll put it on my site (with his permission of course).

OK, I've updated dldipatch32to v0.3. You can get it from:

http://home.clara.net/adamhodson/dldi32-0030.zip

New in this version:

- Updated to latest source 1.10.
- Added 'clear' button to the patch list.
- Added version info.
- Added XP theme support.

If people could try this and it's OK, then I don't see any problem with chishm including it on his site.

Thanks,

Adam

Does DLDI not support SRAM or something, because I've noticed that both the new beta of Moonshell and DSOrganize don't boot homebrew properly anymore on my M3miniSDv1 with DLDI patches. Moonshell says the media card isn't compatible, and DSOrganize freezes on a black screen with white text saying Initializing FAT... Is this a problem with the DLDI or is this just a coincedence?

If you want to boot homebrew with DSO you need to patch the exec_stub.bin as well. Read the faq. dlditool -tbin -r0x06020000 <dldi file> exec_stub.bin
_________________
Nintendo DS homebrew on Wikipedia

I have a problem.

DsOrganize in G6Lite.

didi32-0030 or diditool-win32 1.10 version dont work for me, with the last dldi of viruseb, and patching the DSOrganize.ds.gba (the same with .nds and .sc.nds). Dont pass of Trying patched driver...

didi32-0021 with last dldi for g6 and patching DSOrganize.ds.gba..., it works perfect, read and write.

Any clue?

Thawin wrote:

I have a problem.

DsOrganize in G6Lite.

didi32-0030 or diditool-win32 1.10 version dont work for me, with the last dldi of viruseb, and patching the DSOrganize.ds.gba (the same with .nds and .sc.nds). Dont pass of Trying patched driver...

didi32-0021 with last dldi for g6 and patching DSOrganize.ds.gba..., it works perfect, read and write.

Any clue?

Same problem than Theli. The 1.20 dlditool should solve this issue.

Thawin wrote:

I have a problem.

DsOrganize in G6Lite.

didi32-0030 or diditool-win32 1.10 version dont work for me, with the last dldi of viruseb, and patching the DSOrganize.ds.gba (the same with .nds and .sc.nds). Dont pass of Trying patched driver...

didi32-0021 with last dldi for g6 and patching DSOrganize.ds.gba..., it works perfect, read and write.

Any clue?

v0.3

Old driver: Default (No interface)
New driver: G6 Lite DLDI V0.15

Position in file: 0x000CF3C0
Position in memory: 0x02000000
Patch base address: 0xBF800000
Relocation offset: 0x428CF1C0

Patched successfully

v0.21

Old driver: Default (No interface)
New driver: G6 Lite DLDI V0.15

Position in file: 0x000CF3C0
Position in memory: 0x02000000
Patch base address: 0xBF800000
Relocation offset: 0x428CEFC0

Patched successfully

----

Looks like relocation offset may be wrong? Perhaps line 351 in dlditool.c

fileOffset = readAddr(appFileData, dsHeaderOffset + DHO_Arm9Src);

should be

fileOffset = readAddr(appFileData, dsHeaderOffset + DHO_Arm9Src) + dsHeaderOffset;

I made a test version at:

http://home.clara.net/adamhodson/dlditool32-test.zip

Adam

Yes, there is a bug in v1.10 that caused the relocation offset to be miscalculated for DSGBA type files. The next version (v1.20) uses a completely different calculation method that should work on all file types without depending on the extension. I just need to test it a bit more first before release -- I don't want something like this happening again.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

I uploaded dlditool v1.21 to the usual place. It should be able to patch any file without relying on the extension. It uses a new offset calculation method, which won't work if you've modified the Default DLDI included as part of libfat. The updated IO_INTERFACE has already been included in libfat in the DevkitPro CVS, and should be usable when DevkitARM r20 is released. The patcher will still work with the original, unmodified DLDI IO_INTERFACE, so don't worry about upgrading libfat until DevkitARM r20 comes out.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

So is the problem with some SC lites not working because of a difference in hardware revisions? Does the scsd.dldi need to be modified? I'm not trying to pester, I'm trying to figure out why none of the dldi stuff works on my DS. :)

Heh, it seems so. I have many problem reports. Chishm, any input on that?

Also, where can I get the sources of the DLDI tester? It seems to corrupt my media card.
_________________
Nintendo DS Lite (White) + Supercard Lite + R4 + Sandisk 1 GB MicroSD
Sony PSP + Firmware 3.03 OE-A2

Wouldn't it be nice if card manufacturers took advantage of DLDI and built in patching support to their firmware, to automatically patch supporting homebrew at execution?

Yeah, I guess that would be nice.

@Chishm: You forgot to update the version number of the dldi patcher, it's still 1.20 in the 1.21 release.
_________________
Nintendo DS Lite (White) + Supercard Lite + R4 + Sandisk 1 GB MicroSD
Sony PSP + Firmware 3.03 OE-A2

Is there any kind of documentation, tutorial or example on implementing libfat with/without DLDI?

I've never used libfat before, and I'm trying to write a simple program that reads a text file from FAT and displays its content on screen, just to learn how to use libfat, but I don't know where to start.

Is there anything simple available or do I have to dig trough some other program that uses libfat and look how it's implemented?

Thanks!
_________________
There's no place like 127.0.0.1

Using libfat is a matter of calling an init function and then using regular fopen etc calls.
_________________
"no offense, but this is the gayest game ever"

Quote:

Using libfat is a matter of calling an init function and then using regular fopen etc calls.

Okay, I'll try to find out the init function syntax in some howebrew already using it. Thanks!
_________________
There's no place like 127.0.0.1

It's fatInitDefault ();, if you don't have to do anything too fancy.
_________________
Nintendo DS Lite (White) + Supercard Lite + R4 + Sandisk 1 GB MicroSD
Sony PSP + Firmware 3.03 OE-A2

New version of the Windows patcher at:

http://home.clara.net/adamhodson/dldi32-0031.zip

It uses chishm's latest source so it should fix the problems with ds.gba files.

Adam

cheapo wrote:

Quote:

Using libfat is a matter of calling an init function and then using regular fopen etc calls.

Okay, I'll try to find out the init function syntax in some howebrew already using it. Thanks!

Don't forget that the .h include files are also a valuble source of info, as well as looking at examples.

tyraen:
I've heard there may be multiple SC Lite (not rumble) hardware revisions, but I'm not entirely sure. I will be getting a SC Lite soon so I should be able to test it some more.

SukkoPera:
I haven't made the tester sources public. It is just a simple program that uses libfat to open/read/write/close 2 files on the card. Since it uses a normal build of libfat, I have to use a hex editor to remove the built in IO_INTERFACES (so it doesn't give false positives). Fixed version number now too.

cheapo:
You'll need to #include <fat.h> and call fatInitDefault(); somewhere, and add -lfat before -lnds9 in the list of libraries in your ARM9 makefile. Once this is done you can access files like any POSIX system (fopen, fread, etc.).

bob_fossil:
Thanks for the GUI version, I'll add it to the DLDI page.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

chishm wrote:

tyraen:
I've heard there may be multiple SC Lite (not rumble) hardware revisions, but I'm not entirely sure. I will be getting a SC Lite soon so I should be able to test it some more.

You heard correct. In the process of helping cory1492 get his unpatcher software working with the "new" Supercards (SD/Mini/SC Lite) we discovered some differences. Spansion chips are now used, and the firmware is written quite differently. He managed to get his unpatcher to actually work on the newer SD and miniSD, but no luck on that SC Lite.

Seems strange that some FAT interfaces work with the new ones work and some don't. I can run older versions of Moonshell and DS Organize just fine.

Actually, the latest moonshell ships with two DLDI drivers for SCSD: one is the same as on Chishm's page, the other one seems a DLDIsation of the SCSD driver integrated in previous versions of Moonshell.

Now, it seems that the former driver has the abovementioned problems, while the latter does not. Anyone can confirm this?

EDIT: I had a guy (thanks juvinious) try the latter driver on a failing SCLite. He reported that reading works fine on the tester app, while writing hangs. The "normal" SCSD driver fails all together.
_________________
Nintendo DS Lite (White) + Supercard Lite + R4 + Sandisk 1 GB MicroSD
Sony PSP + Firmware 3.03 OE-A2

Well, source is open for all DLDIs in Moonshell, so if they work and an official one doesn't, you're free to add them to the page chishm.

http://mdxonlinemirror.dyndns.org/resources/20070101_dldi_scsd_ver10_20070101.zip

He also made an EZ5 DLDI, but there's two conditions (unrelated to the DLDI) for it to work. Firmware version must be 1.1 or greater (though only 1.31 has been tested and confirmed working, I believe), and the GAMEID must be set to PASS.

I ran the dldi_tester patched with the Moonshell dldi you linked, it works except that the Write test fails at "Writing...", I'm not sure why, but it seems to have gone off into a loop, or just crashed or something. But a step up anyways. :)

Today I compared Moonlights DS-Link dldi source and my own DS-Link dldi source, and it seems that the only difference is that I linked it to be a SLOT-1 device (which it is) and he linked it to be a SLOT-2 device.

This world is weird.
_________________
http://licklick.wordpress.com

Lick wrote:

Today I compared Moonlights DS-Link dldi source and my own DS-Link dldi source, and it seems that the only difference is that I linked it to be a SLOT-1 device (which it is) and he linked it to be a SLOT-2 device.

This world is weird.

I'm too lazy to look back thru the thread now, but I thought chishm said there was some bug/typo in the makefile or spec file or something.

Edit: nevermind.

Diddl wrote:

zektor wrote:

Just tested on my DS-Link. I get INIT FAT: Failed

Correct, doesn't work on my DSlink.

But you could simply access DSlink Fat system by using this moonshell sources (v1.5). I have implemented this piece of source from moonshell into DSdoom and it run fine on my DSlink.

BTW, a belated thanks for this info. Would you be able to share that version of DSDoom?

yes of course I will share this version of DSdoom. here isn't possible (for me) to upload a file, so you will find it here: NDS Toolz

if anyone want the source code, I will send/upload it. the difference to this DSdoom v1.1 is:

replaced the fat code in /fat directory
added mini menu to choose one of four WAD files (doom, doom2, tnt ..)
added different savefile directorys on different WAD files.

So, just saw the new version of the Moonshell beta and the release notes mentioned SC Lite fixes, so I tested it out and it worked. I took the DLDI from the archive and patched it against the dldi_tester from chishm's site and all tests passed successfully. :)

Here's a link to the DLDI: sclt.dldi

Is that one different than the one Firon posted earlier on this page? Any new changes for it, like write support?

It's different from the one I posted; it's made explicitly for the Supercard Lite, probably to fix the write problems with the different variations.

Like I said, I tested it with the dldi_tester which does read and write tests. :)

To support this all I need is a new version of libfat right?

Diddl wrote:

yes of course I will share this version of DSdoom. here isn't possible (for me) to upload a file, so you will find it here: NDS Toolz

if anyone want the source code, I will send/upload it. the difference to this DSdoom v1.1 is:

replaced the fat code in /fat directory
added mini menu to choose one of four WAD files (doom, doom2, tnt ..)
added different savefile directorys on different WAD files.

I *really* appreciate this! I just had a few good rounds in Doom II thanks to your update. Again, thank you!

Hi chishm,

As promised (a while ago) I've made a DLDI out of the M3 driver I was using in ScummVM. This should work on every Slot-2 M3 card. Tested and works perfectly on my M3 lite.

It would be great if you could put it up as an alternate M3 SD driver or something. I'm planning to point ScummVM DS users to your page for all the latest DLDIs, you see! The code is based on the code that M3 released, and I fixed a misaligned data issue and ported it to the DLDI structure.

http://scummvm.drunkencoders.com/m3sd.zip

Thanks again for your work on this.

Updated DLDI page for M3SD, SC Lite and EZ5.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com

gbadev.org forum archive

DS development > DLDI: loadable block device drivers for libfat

#112959 - chishm - Thu Dec 21, 2006 11:52 pm

#112961 - Dark Knight ez - Fri Dec 22, 2006 12:07 am

#112962 - Dwedit - Fri Dec 22, 2006 12:10 am

#112970 - chishm - Fri Dec 22, 2006 1:22 am

#112971 - 0xtob - Fri Dec 22, 2006 1:29 am

#112974 - Lazy1 - Fri Dec 22, 2006 2:01 am

#112976 - Lick - Fri Dec 22, 2006 2:13 am

#112978 - strager - Fri Dec 22, 2006 2:34 am

#112986 - tepples - Fri Dec 22, 2006 4:30 am

#112989 - felix123 - Fri Dec 22, 2006 6:07 am

#112991 - chishm - Fri Dec 22, 2006 6:20 am

#112994 - HyperHacker - Fri Dec 22, 2006 6:49 am

#112998 - felix123 - Fri Dec 22, 2006 7:16 am

#113002 - viruseb - Fri Dec 22, 2006 8:22 am

#113006 - chishm - Fri Dec 22, 2006 9:31 am

#113011 - Mrshlee - Fri Dec 22, 2006 10:17 am

#113015 - viruseb - Fri Dec 22, 2006 10:58 am

#113022 - OOPMan - Fri Dec 22, 2006 12:52 pm

#113024 - Lick - Fri Dec 22, 2006 1:05 pm

#113032 - chishm - Fri Dec 22, 2006 1:47 pm

#113037 - simonjhall - Fri Dec 22, 2006 2:11 pm

#113049 - OOPMan - Fri Dec 22, 2006 3:15 pm

#113055 - strager - Fri Dec 22, 2006 3:29 pm

#113061 - chishm - Fri Dec 22, 2006 5:03 pm

#113067 - Lord Raptor - Fri Dec 22, 2006 6:45 pm

#113074 - chuckstudios - Fri Dec 22, 2006 7:50 pm

#113087 - felix123 - Fri Dec 22, 2006 10:05 pm

#113098 - HyperHacker - Sat Dec 23, 2006 12:52 am

#113104 - chishm - Sat Dec 23, 2006 2:24 am

#113111 - tepples - Sat Dec 23, 2006 5:57 am

#113114 - chishm - Sat Dec 23, 2006 7:16 am

#113256 - OOPMan - Mon Dec 25, 2006 11:38 am

#113260 - Lick - Mon Dec 25, 2006 1:37 pm

#113261 - chishm - Mon Dec 25, 2006 1:52 pm

#113262 - Dark Knight ez - Mon Dec 25, 2006 2:49 pm

#113263 - Lick - Mon Dec 25, 2006 3:18 pm

#113265 - Lick - Mon Dec 25, 2006 4:18 pm

#113266 - OOPMan - Mon Dec 25, 2006 5:21 pm

#113268 - Puyo - Mon Dec 25, 2006 6:41 pm

#113270 - OOPMan - Mon Dec 25, 2006 7:10 pm

#113274 - Puyo - Mon Dec 25, 2006 7:39 pm

#113275 - bob_fossil - Mon Dec 25, 2006 7:42 pm

#113277 - OOPMan - Mon Dec 25, 2006 8:00 pm

#113278 - viruseb - Mon Dec 25, 2006 8:01 pm

#113279 - Puyo - Mon Dec 25, 2006 9:20 pm

#113280 - bob_fossil - Mon Dec 25, 2006 10:11 pm

#113286 - Lick - Tue Dec 26, 2006 1:46 am

#113287 - Lick - Tue Dec 26, 2006 2:24 am

#113295 - Lazy1 - Tue Dec 26, 2006 5:45 am

#113299 - chishm - Tue Dec 26, 2006 8:31 am

#113300 - OOPMan - Tue Dec 26, 2006 8:33 am

#113315 - bob_fossil - Tue Dec 26, 2006 2:19 pm

#113317 - Lick - Tue Dec 26, 2006 3:03 pm

#113332 - Lord Raptor - Tue Dec 26, 2006 8:21 pm

#113336 - Lick - Tue Dec 26, 2006 9:14 pm

#113352 - Paco_777 - Tue Dec 26, 2006 11:30 pm

#113354 - Lord Raptor - Tue Dec 26, 2006 11:47 pm

#113355 - Lick - Tue Dec 26, 2006 11:55 pm

#113378 - chishm - Wed Dec 27, 2006 4:38 am

#113380 - tepples - Wed Dec 27, 2006 5:15 am

#113382 - HyperHacker - Wed Dec 27, 2006 6:30 am

#113395 - Firon - Wed Dec 27, 2006 9:25 am

#113419 - bob_fossil - Wed Dec 27, 2006 6:38 pm

#113422 - Paco_777 - Wed Dec 27, 2006 7:33 pm

#113468 - chishm - Thu Dec 28, 2006 12:00 am

#113471 - tepples - Thu Dec 28, 2006 1:11 am

#113478 - chishm - Thu Dec 28, 2006 2:38 am

#113485 - tepples - Thu Dec 28, 2006 5:08 am

#113500 - OOPMan - Thu Dec 28, 2006 9:14 am

#113502 - chishm - Thu Dec 28, 2006 9:30 am

#113523 - SukkoPera - Thu Dec 28, 2006 3:25 pm

#113537 - Globoeil - Thu Dec 28, 2006 5:16 pm

#113539 - Paco_777 - Thu Dec 28, 2006 5:49 pm

#113546 - chuckstudios - Thu Dec 28, 2006 9:18 pm

#113564 - Globoeil - Thu Dec 28, 2006 11:33 pm

#113567 - Mighty Max - Thu Dec 28, 2006 11:55 pm

#113568 - Lick - Thu Dec 28, 2006 11:57 pm

#113571 - chishm - Fri Dec 29, 2006 12:49 am