devkitPro

Hi,

I was looking at the source of the nitroFS, now in libfilesystem. More specifically at the initialization of the filesystem. I was wondering. It contains a function to read a data block from the card (named: nitroSubReadBlock). Now if I understand this function correctly, you feed it with an offset of a file (defined in card space) and you then can read data from that file.

So the true problem with this filesystem is, the location of the nds file. Next I started to look at the __NDSHeader structure. That structure contains several offset files that, according to me, are defined in card space (e.g. arm9romOffset, arm7romOffset, filenameOffset, fatOffset).

From these values, it is possible to compute the location of the nds file, by simply substracting the header size from the arm9romOffset and you should have the offset of the nds file.

Another thing here. For the filesystem to work correctly, filenameOffset and fatOffset need to be set. However, are they not always set correctly if you have embedded files?

I'd appreciate if any one likes to clarify the working a bit more.

Thx.

I'm really not sure exactly what you're asking here, this stuff is all internal to the library and not intended for general use.

The procedure for using nitroFS in homebrew is to add files using ndstool, call nitroFSInit() and use normal stdio functions. See the nitrodir example provided.

WinterMute wrote:I'm really not sure exactly what you're asking here, this stuff is all internal to the library and not intended for general use.

The procedure for using nitroFS in homebrew is to add files using ndstool, call nitroFSInit() and use normal stdio functions. See the nitrodir example provided.

Well. I guess I was a bit unclear here. I tried the nitroFS using the above procedure. It works on emulators, but it doesn't work on my R4i. I can run a program but whenever it tries to access files using the nitroFS, it fails. If I use libfat, it works. But I'd like to have a single nds file holding everything. Now that was why I started to inspect the internals of the nitroFS.

My guess is that the initialization somehow fails. And that's why I wanted to know a bit more of the internal details to get a more general understanding of how the Nintendo actually interacts with the ROM device.

It fails because your card launcher doesn't support argv. See http://devkitpro.org/wiki/Homebrew_Menu

WinterMute wrote:It fails because your card launcher doesn't support argv. See http://devkitpro.org/wiki/Homebrew_Menu

I agree. The card launcher doesn't support argv protocol. I tested that some time ago. The point is, when using the devkitPro tools, libfat works out of the box and, as far as I can tell, any card supports it.

On the other side, if a developer chooses for the nitroFS, then the supporting library libfilesystem doesn't work out of the box. It depends on wether the card launcher supports the argv protocol. So I started to look at the code to see if it somehow could be improved so that it works out of the box.

The only solution I can think of is, in case no argv protocol is supported, to search for the nds file using the fat library. I've seen this code posted somewhere in the forum. It could be an improvement in the initialization of the nitroFS. Of course, the preferred method is argv. Anyway, it would allow for a more intuitive use of the libfilesystem library.

No, the only supported method is through argv. Many card menus now support this, more will follow.

Searching for the file using libfat is stupid, short sighted, prone to error and incredibly slow if the user has a lot of files on the card. Please do not provide incentives for card makers to not support argv.

WinterMute wrote: Searching for the file using libfat is stupid, short sighted, prone to error and incredibly slow if the user has a lot of files on the card. Please do not provide incentives for card makers to not support argv.

But MeRAMAN's softwares use that method since before you provided argv scheme...

Then MeRAMAN's software is wrong and should be avoided at all costs.

Having homebrew implement workarounds for defects in card menus creates problems for everyone. If the card manufacturers want to claim that they support homebrew then they need to be providing the support that homebrew requires, end of. And actually the argv scheme was provided long before homebrew had nitrofs support.

WinterMute wrote:Then MeRAMAN's software is wrong and should be avoided at all costs. Having homebrew implement workarounds for defects in card menus creates problems for everyone. If the card manufacturers want to claim that they support homebrew then they need to be providing the support that homebrew requires, end of. And actually the argv scheme was provided long before homebrew had nitrofs support.

Mmmhh.. I can see some logic in this argument. But I never said the card supports homebrew software. As far as I can see it, many cards only support dldi. I see no reason assuming card manufacturers will eventually support the argv protocol. They simply don't benefit from it. They did benefit from dldi, that's why it is adopted.

Still, the issue comes down to this: there is a need for an extension to the libfilesystem initialization to search for the current nds-file in case all other initializations fail! You could make it argument driven with the default being not to fall back on a search if you like.

No, it's selfish, stupid and short sighted.

All card manufacturers claim they support homebrew - if they don't then they're just another device intended solely for piracy and thus illegal.

All the recent "big name" cards support argv, others have argv support from 3rd party menus like akaio and woodRPG, hbmenu can be enticed to support pretty much any card without much fuss.

Searching the card DOES NOT work. There's no conceivable way to guarantee that it will find the file or, even if it does, that it's the correct file. Compound that with the prevalence of large capacity cards where some users store 100s if not 1000s of nds files.

Please use the energy you obviously have spare to argue with me to encourage your card manufacturer to support homebrew properly instead.