#144741 - thegamefreak0134 - Tue Nov 06, 2007 11:21 am
A friend of mine and I are working on a firmware replacement for the DS, and although development is way early for you to get excited over anything, we think we've got the basics of Cart detection and booting, and he's working on setting up the personal settings right now. It's an ugly mess of testing, but it's on it's way to glory.
Anyway, we figured since this is going to be a homebrew replacement, it should have a filebrowser built in. It would be much too tedious to actually go out and learn how to interface with every different kind of card, and that would make the image for the firmware way too large. So, we figured we would make it compatible with DLDI, and let people patch it for their own cards.
Here's my issue. Since this is firmware, it needs to be able to potentially read from both slot1 and slot2 cards. The way I see it, it should allow patching for up to 6 different card types, three for each slot. (That way people with multiple cards can swap in any order and it will still work fine.) I have a couple of issues with this approach however, in that I do not know how to actually handle multiple DLDI patches. It's still a bit of a mystery to the both of us, and as I'm the only one with a FAT compatible card, I'll be doing the filesystem. ^_^
My initial idea was to write a loader program that would patch the 6 individual object files, and then link them together and let the program choose. I don't quite know how to get this to work, but I imagine it wouldn't be terribly difficult. If someone could shed some light on just how DLDI actually works on a binary level, I think it would help me out tremendously.
The main reason I have for doing it this way is so that people can browse both filesystems on their slot cards at once, and even perform basic copy operations between the two if needed. Likewise, it would be just peachy if the firmware could browse the filesystem and load files on it's own, in addition to being able to boot the cart. We would need to patch on the fly most likely to make this feature most useful, so I really need to know how it works to a very fine degree.
Anyone who can point me in the right direction (are there standard DLDI specs somewhere?) would be greatly appreciated.
-thegamefreak
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#144762 - HyperHacker - Tue Nov 06, 2007 8:23 pm
You know firmware is 256K right? 6 DLDI patches is going to eat up 192K already, and then you have user settings and wifi data to worry about. Why do you need file management functions in firmware anyway?
_________________
I'm a PSP hacker now, but I still <3 DS.
#144775 - thegamefreak0134 - Wed Nov 07, 2007 2:13 am
Wow... I didn't know that DLDI was that big. OK, then I might limit it to two, one for each slot.
I just figured that the firmware should allow you to manage both cards effectively. That way, if desired, you could use the firmware to boot your homebrew and use it to copy between cards and such. Or it could even search for "default.nds" and run that automatically, things like that.
Are there any major similarities between the DLDI patches that I might be able to account for, and thus save space by only patching for the differences between them? Or are they a set size? It seems to me that a DLDI patch ought to be something a simple as a memory address change or two, but I don't know how they work. Any info on that would help tremendously. ^_^
-gamefreak
PS: Yes I know about the firmware size limits, we are planning our code around this. ^_^
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#144778 - tepples - Wed Nov 07, 2007 2:35 am
Most DLDIs for CF/SD adapters that I've seen are less than 5 KiB. The maximum size was set at 32 KiB only because an interface to raw NAND memory needs some fairly big constant tables for error correction. Examples of raw NAND memory include SmartMedia, xD-Picture Card, and (most importantly) the memory soldered inside a G6 card. I believe there's a compile-time option somewhere in libfat to make the DLDI section only 8 KiB or 16 KiB in size rather than 32 KiB.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#144784 - thegamefreak0134 - Wed Nov 07, 2007 2:48 am
So is a DLDI "patch" basically just a read/write function for the FAT area of the card?
-gamefreak
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#144791 - tepples - Wed Nov 07, 2007 4:27 am
| thegamefreak0134 wrote: |
| So is a DLDI "patch" basically just a read/write function for the FAT area of the card? |
Yes. Each DLDI file is a driver that exports six methods: isInserted(), startup(), clearStatus(), readSectors(sector, count, buf), writeSectors(sector, count, buf), and shutdown().
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#144801 - thegamefreak0134 - Wed Nov 07, 2007 9:47 am
OK, that makes sense. I'll worry myself later about how the compiled binary handles the different sizes of these functions.
OK, so I know that a DLDI is a specific size. It makes sense to me, then, to have up to a certain size, and 64k seems like the most reasonable because in a worst-case scenario, that will allow for at least 2 maximum size drivers. I suppose I could also release a tool that would allow you to update your drivers without having to re-flash your DS. Heck, if I made sure the failsafe code was there, you could update the entire firmware that way.
OK, I have a few more questions on the subject, since I will have the joy of implementing this somehow. I assume that the patcher programs look for a DLDI signature of some kind, and copy the patch to that location. The problem with this approach is that I will need to potentially have more than one DLDI signature in my program, or possibly have one signature and then place a new signature on the end of the old patch. It's complicated. Is this how it's done, or is there a different method to the madness? If it is this way, what is the magic byte arrangement I'm searching for?
Oohh... kk I think I've got it, but I need to know something. Since the patcher works on a pre-compiled binary, does the patch need to keep the function entry-points the same? (Can I count on the functions being at the same memory location within each patch?) If so, this could become really easy to actually do, by making sure that those functions are not actually used, but a pointer to those functions is used instead, so I could simply offset the pointer by the location at which the second patch was located. Easy fixes make me happy. Hmm... do you know where I could get my hands on the source of a DLDI driver, so I could test this theory?
-thegamefreak
PS: Yes, I know I'm asking a lot of weird questions, but this is one of the more major features of the firmware, so I really want to see it implemented. ^_^
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#144802 - OOPMan - Wed Nov 07, 2007 10:24 am
Er...
Let me se...
At the moment, the standard link-script for DLDI-enabled programs only allows one DLDI driver. Programs that allow access to SLOT1 and SLOT2 at the same time presently rely on the fact that libfat contains a lot of legacy driver coder for SLOT2 devices.
There has been interested in multiple-DLDIs before, though, and I believe Chishm has been looking into it. I'm not sure what kind of progress he's had, though...
With regards to DLDI source, checks Chishm`s site at DrunkenCoders. It's linked to in the libfat thread stickied at the top of this forum. There's source for DLDI's there and the source for libfar is also available.
_________________
"My boot, your face..." - Attributed to OOPMan, Emperor of Eroticon VI
You can find my NDS homebrew projects here...
#144803 - chishm - Wed Nov 07, 2007 11:56 am
The signature is {0xED, 0xA5, 0x8D, 0xBF, ' ', 'C', 'h', 'i', 's', 'h', 'm', 0x00}. The current patchers only work with one driver at a time. You'll also have trouble when trying to use more than one driver per slot, as they are written with the assumption that no other driver will be initialised before them. Most drivers won't have this problem, but you may run into it with a few.
You'll also have issues specific to using the drivers as part of the firmware. Some drivers expect the flash card firmware/menu to initialise the inserted media. Running the drivers as part of the DS firmware will bypass this initialisation.
If you can work around these issues, then one way of implementing multiple DLDIs is to append them to the end of the binary and have (a heavily modified) libfat load them and adjust required offsets as needed.
To save space, I suggest you create a custom build of libfat with all unnecessary functions (such as file writing and directory creating) removed, and use open/read/close directly, instead of going through fopen/fread/fclose.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#144841 - thegamefreak0134 - Thu Nov 08, 2007 5:10 am
OK, I'm relatively certain this is enough information to get started with my stuff. I really only have one question. You mentioned that the drivers expect no other driver to be initialized before them, which I suppose makes sense. Ideally, I would only initialize a particular driver if the cart for it was present. It occured to me though, is it possible to ID every card on the market based on just information you can gather without the driver? I would assume that there is something in the header that can be used as an ID..
OK, I'm going th get the latest version from my friend sometime this week and give this all a whirl. I'll let you know if I have any progress.
-gamefreak
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]
#144842 - chishm - Thu Nov 08, 2007 6:23 am
I'm not sure about identifying cards based on their headers, since I don't have every card on the market. If you use this option, you'll have to be wary of headers that change when the card gets a firmware update (if any cards do this).
Slightly off-topic: May I ask why you are looking to do this as a firmware replacement? Most cards allow you to auto-boot a certain NDS file from the inserted media. This gives you more space and is less prone to difficulties with DLDIs than modifying the DS firmware.
_________________
http://chishm.drunkencoders.com
http://dldi.drunkencoders.com
#144844 - thegamefreak0134 - Thu Nov 08, 2007 6:37 am
We're not doing the firmware replacement strictly as this, I just thought this would be a great feature to actually implement in firmware, as that seems like the most logical place to manage cards. It's a complicated matter, I know, and I don't expect the solution to be a simple one, especially since we by no means plan to use console text for the firmware menus, but plan to go with a more sleek design. (I'm not telling, it's intended as a bit of a surprise if it works.) We figured that the firmware should be able to effectively do everything that the original DS firmware could do, along with providing options to boot and browse homebrew cards. If the browse doesn't work, it doesn't work, I just think that it should be there if it can.
For normal homebrew, we will identify cards based on the standard headers that FlashMe already uses, so figuring out how to boot the cards properly should not be a problem at all. Of course, if desired, it will allow you to boot a card using any method, in the event that the detection fails. I figured that the firmware would also be a handy place to manage your cards, so that you could arrange your files without having to boot into a shell like DSOrganize, which is especially handy if you don't happen to have a shell on the card at all. Since the main function of firmware is to boot other code, the card-handling will be given the most effort.
-gamefreak
_________________
What if the hokey-pokey really is what it's all about?
[url=http:/www.darknovagames.com/index.php?action=recruit&clanid=1]Support Zeta on DarkNova![/url]