#114229 - cheapo - Fri Jan 05, 2007 4:45 pm
Hello all!
I'm sorry if this is a dumb question, I'm fairly new to the DS development. Been playing with PALib for a while, now I decided to learn more about the DS hardware and start developing only using DKP/libnds.
It's known that NDS commercial ROMs have an internal filesystem, and that we're able to create/extract files from this filesystem via ndstool, right?
So why isn't there a lib to read/write to this filesystem using libnds? Is that because no one did it yet or is there something more, like something commercial ROMs can do that homebrew can't?
I've been asking myself this for quite a while, so I decided to ask you guys hoping I can understand the reason.
Thanks a lot!
_________________
There's no place like 127.0.0.1
#114235 - Sausage Boy - Fri Jan 05, 2007 5:47 pm
Most pirate rom patching tools rely on finding exact Nintendo code, so they wouldn't be able to patch homebrew even if we made a library. That means the program would run on very few devices. Also, you can't write to that filesystem from games.
Why use a filesystem with less features that works on less devices than what we already have (libfat)?
_________________
"no offense, but this is the gayest game ever"
#114236 - cheapo - Fri Jan 05, 2007 5:58 pm
| Sausage Boy wrote: |
| Most pirate rom patching tools rely on finding exact Nintendo code, so they wouldn't be able to patch homebrew even if we made a library. That means the program would run on very few devices. Also, you can't write to that filesystem from games. |
Well, that's something I didn't know. So if there was a library to read this kind of filesystem the NDS would need to be patched to work on flashcarts?
| Sausage Boy wrote: |
| Why use a filesystem with less features that works on less devices than what we already have (libfat)? |
The idea would be to have all files my game needs to read (like images, sounds, etc) inside the NDS itself (no need to manually copy files to your card, much like a commercial ROM), but without using the 4MB memory we use for code. I know I could do this with GBFS for example, but it wouldn't work on carts without 32MB GBA RAM and Slot-1, right?
_________________
There's no place like 127.0.0.1
#114239 - josath - Fri Jan 05, 2007 6:19 pm
| cheapo wrote: |
| The idea would be to have all files my game needs to read (like images, sounds, etc) inside the NDS itself (no need to manually copy files to your card, much like a commercial ROM), but without using the 4MB memory we use for code. I know I could do this with GBFS for example, but it wouldn't work on carts without 32MB GBA RAM and Slot-1, right? |
There is currently no good way to do this. Even if you were to write homebrew code to access the NITRO FAT, which can be embedded in a .nds, it most likely wouldn't work on most flashcarts, because as mentioned above, the pirate patchers look for very specific nintendo code, instead of actually emulating a DS cart.
One possibility I've toyed with is this:
1. Attach appended GBFS
2. If cart has GBAROM space, simply use it as normal
3. If not, use libfat and fopen("mygame.nds"), and use fread(), fseek(), etc to read from the appended GBFS
There is only one downside to step 3: There is no way AFAIK to find out what .nds file you are running. Thus there are two options:
A. Make sure the user never renames your .NDS file, and force them to place it on the root of the card. DOWNSIDE: Some people like to rename their files, or place them in directories.
B. Scan through their entire cart, looking at the header of each .NDS file until you find the correct one. DOWNSIDE: Slow if many files on the cart, possibly some extra work / problems, if they have multiple versions of your NDS on their cart
Sidenote: Everywhere you see GBFS mentioned, you can also use romfs (aka romdiskfs). It is slightly more complex, but a more flexible. (longer filenames, directory support, etc).
Here's a quick overview of various filesystems
#114241 - Lynx - Fri Jan 05, 2007 7:06 pm
I think what you are getting at is the same as THIS TOPIC which is reguarding dynamically loading data into the 4MB RAM space. and then some how turned into an OS at which case I lost interest as we already have DSLinux if I wanted an OS..
Anyway, as I posted in that thread, I believe there are two ways to directly do what you are speaking of. One, the hard way, would be to hard code addresses into your .nds file that keeps a specific range saved for managing data, and then the "rest" of the 4MB space for loading your data in and out. And then the second way, easy cause it uses magic, is to have a library that would create the address pointers for you when you compiled your code.
_________________
NDS Homebrew Roms & Reviews
#114251 - josath - Fri Jan 05, 2007 9:13 pm
| Lynx wrote: |
| I think what you are getting at is the same as THIS TOPIC which is reguarding dynamically loading data into the 4MB RAM space. and then some how turned into an OS at which case I lost interest as we already have DSLinux if I wanted an OS.. |
That is not quite what cheapo was asking, I think he is only worried about data assets, non-executable stuff. For these you don't need any linker trickery or fancy OS coding or anything. Just the ability to do stuff like loadSprite("gfx/playerman.pcx");
Basically, the case where you want a NDS > 4MB, but still works on GBAMP and Slot-1 devices. (and also don't want to have the files cluttering up the card, but instead all embedded in the .nds)
#114610 - Payk - Tue Jan 09, 2007 2:57 pm
I realy can understand that thing. Its just handy to have one rom, just as we all know it from handhelds/consoles. It has advantages too.
-I got a 7.5MB folder with lots of textures. If i use fat for my game, and want to update datas it loads about 50 files to sd card. That takes about 2-3 minutes! If i use KOSFS instead, i just copy a 7.5MB rom to SD card within 20 sec.
-It doesnt matter in which folder or subfolder the rom with attached datas are, it doesnt change internal paths or something. Its much more flexible and easier to archivate
-And most important is of course, that it isnt THAT easy to change/rip content. I guess that ?ersons who can do that, also could write their own games. So ppl wpuld feel more secure when releasing roms with textures/music.
But yeah that all doesnt work on slot1 solucions. Thats why i still prefer slot2. That manufactures could have made a homebrew patcher which redirects each GBA-ROMACCES to their EEPROM....But no one did that.
Libfat looks cool too, but i got (like i said) 50 files and a folderstructure which i want to keep alive. Its pretty s...y that only fatlib and kos are usable for my game in a handy way. I hope we will see another solution soon.
#114644 - Sunray - Tue Jan 09, 2007 7:02 pm
Well, I use GBFS to create a data file which is stored as a regular fat file. So I have project.nds and project.data. Internally I just open the data file and search using the GBFS header. If the file wasnt found I try to open it as an external fat file.
#114846 - cheapo - Thu Jan 11, 2007 1:48 am
Probably silly question: if I make a homebrew and generate a NDS using ndstool with some files together (using ndstool ability to create Nitro-FAT) and put it inside some slot-1 device (no patching), is there a memory address I can access the (read-only) FAT, in raw mode?
_________________
There's no place like 127.0.0.1
#114852 - Lynx - Thu Jan 11, 2007 3:50 am
Nope, Slot-1 isn't directly addressable. You'll have to swap RAM like official games.
_________________
NDS Homebrew Roms & Reviews
#114895 - cheapo - Thu Jan 11, 2007 11:21 am
Can you point me to any information about swapping RAM, so I can understand what does it mean?
_________________
There's no place like 127.0.0.1
#114898 - Payk - Thu Jan 11, 2007 12:04 pm
Sunray:
Quite cool idea but still no folder structure. I am thinking about adding a file for a pseudo folder structure, and add a lib which then access it with stdio functions. But thats much work. There is already a KOSFS. It would be cool to make it working with FAT. I watched the source and i am sure that dont wanna do that :D
Anyone likes to do that?
#115021 - Lynx - Fri Jan 12, 2007 7:20 am
Cheapo, that's the problem. Currently nobody is doing it, which is why we have this topic and the topic I linked to earlier. I still believe everyone wants the same results overall.
_________________
NDS Homebrew Roms & Reviews
#115023 - tepples - Fri Jan 12, 2007 8:00 am
"swapping RAM": First you load the GBFS file's header and directory from disk into RAM. Then whenever you want to load an object from GBFS, you read the offset and size from the directory, malloc() that much space, seek in the file, and load it in. Should I make a wrapper to load GBFS from stdio as a proof of concept of how GBFS could fit into a program that uses libfat?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#115042 - Payk - Fri Jan 12, 2007 1:49 pm
Yeah that would be very cool. Best would be with dirrectorys and encryption (xor or something...very simple save)
And yeah that "ram swapping" isnt not any problem in anykind. As you said you just load the adresses of files which should be 32bit per file into ram. The rest is just load what you need. You would do same with fat, too.
But GBFS in the GBA-ROMSPACE has a great advantage. You can dirrectly point to it. If you point to it, the entiry file doesnt have to be in RAM, too.
Thats what makes cardridge so unique :D
#115048 - cheapo - Fri Jan 12, 2007 2:36 pm
Okay, so commercial GBA games can store up to 32 MB in ROM and read it directly, with no swapping, right?
But NDS commercial games do RAM swapping in order to read the contents below the program (which is limited to 4MB and placed in RAM). So, how do commercial games read these contents (the files inside Nitro-FAT) to put it in RAM and use it?
Is homebrew able to do something similar, for example, inside an emulator (where no patch is applied to the NDS ROM)? Even as a proof-of-concept, is there a way to reach the contents of the NDS file below program data inside an emulator?
_________________
There's no place like 127.0.0.1
#115102 - josath - Sat Jan 13, 2007 12:28 am
| tepples wrote: |
| "swapping RAM": First you load the GBFS file's header and directory from disk into RAM. Then whenever you want to load an object from GBFS, you read the offset and size from the directory, malloc() that much space, seek in the file, and load it in. Should I make a wrapper to load GBFS from stdio as a proof of concept of how GBFS could fit into a program that uses libfat? |
Yes please, I know of a couple people that would use it. I tried hacking something similar, but it was a bit buggy.
Now if only we had a solution to the problem of knowing where to load the GBFS file from -- currently there is no easy way of knowing which .NDS file was launched from the media card.
#115125 - HyperHacker - Sat Jan 13, 2007 4:07 am
Well the easiest way would be for launchers to just leave the path in memory somewhere. I was thinking too it might be possible to pass parameters to the app's Main(), which would allow a standard argc/argv system to be used.
_________________
I'm a PSP hacker now, but I still <3 DS.
#115135 - josath - Sat Jan 13, 2007 5:04 am
| HyperHacker wrote: |
| Well the easiest way would be for launchers to just leave the path in memory somewhere. I was thinking too it might be possible to pass parameters to the app's Main(), which would allow a standard argc/argv system to be used. |
There are soo many launchers though (almost every flashcart has it's own). That means we'd have to get them all to agree on where to put it, then get the users to use the new launchers.
#115138 - amphoterous - Sat Jan 13, 2007 5:19 am
| josath wrote: |
| There are soo many launchers though (almost every flashcart has it's own). That means we'd have to get them all to agree on where to put it, then get the users to use the new launchers. |
Better now than never? I believe that homebrew is all about collaboration and I hope that something on this scale could be done.
#115139 - tepples - Sat Jan 13, 2007 5:28 am
If you build it, they will come. Or at least Chishm thinks so with DLDI.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#115241 - Lynx - Sun Jan 14, 2007 2:41 am
Well, I think it worked with the FATlib.. :) I'm sure if someone put together something like this, people would definatly use it.
_________________
NDS Homebrew Roms & Reviews
#115246 - josath - Sun Jan 14, 2007 3:59 am
The difference being that DLDI / fatlib changes, do not require changes to the firmware of the flashcarts. Using the new DLDI makes your homebrew more compatible, using a feature not supported by all flashcarts would make it less compatible (though perhaps it would pressure the flashcart makers into complying with the standard)
#115306 - Lynx - Sun Jan 14, 2007 10:50 pm
You lost me.. What feature is not available from all fashcarts? If you think commercial card providers will add a "feature" to their software, you'll be waiting a LONG TIME! They don't give a crap about homebrew compatibility. But, if there was a "universal" launcher (code, I mean) that all homebrewers could easily use, or it was added to DevkitPro, then it would work, as people compliling their homebrew would have the "feature" anyway.
Of course, the downside would be that when your supercard (insert any commercial loader here) menu comes up, you'd have to launch a homebrew app for launching everything else. So, would people be willing to double "launch" to be able to play their favorite homebrew with the capabilities we are talking about? Dunno.
_________________
NDS Homebrew Roms & Reviews