devkitPro

Hello, there.

I'm investigating a bug in my code that could be due to diropen() 's behaviour to have changed over the last few years. I used to provided it with a relative path, e.g. diropen(".") for reading the root directory of the default FAT device -- typically my microSD card in a R4 linker. I had a look at the implementation of diropen in libfat, which contains a 'curious' And _FAT_partition_getPartitionFromPath() actually delegating the job to GetDeviceOpTab(char*) function, to my best understanding. I lack some documentation on the argument, whether some "device:/path..." must be used, and which are the possible "device:" values.

Any hint ?

FAT1 and FAT2 for slot1 and slot2 ? anything else ?

See examples/filesystem/libfat/libfatdir.

Never, ever use explicit device names in your paths and using a relative path to get the root directory is unlikely to work. If your card loader implements the argv protoocol correctly then the default working directory is the path where the nds file resides. If your card loader doesn't then consider using hbmenu

WinterMute wrote:See examples/filesystem/libfat/libfatdir.

Hmmm ... should have thought about it, but it looks like it doesn't tell me much. The buggy code is the media exploration in EFSlib by noda, which was working properly with an older version of the libfat, and that seems to make use of diropen and dirnext in a way it should work e.g. on Unix.

Never, ever use explicit device names in your paths and using a relative path to get the root directory is unlikely to work.

Hmm ... Well, I suppose indeed using fat1:highscore would be a bad idea if the .nds file is placed on a SLOT2 linker.

If your card loader implements the argv protoocol correctly then the default working directory is the path where the nds file resides. If your card loader doesn't then consider using hbmenu

It is not. Regardless of whether I'd be willing to install and use hbemu on my DS, I cannot force other people to do so, and people would take for granted that their linker would be able to run a homebrew game without the help of an additional tool.
Sorry. I don't want to sound rude or discard the efforts that people have put into hbemu and the argv protocol, but I aim for user friendliness before anything else, here. I cannot afford a chicken-and-egg issue.

So, is there something like dldi:/data/highscore ? is there a function that adds entries in the "device_optab" that I could look for to better understand how things are working and how I can make an informed choice ?

Should there be anything else but fatInitDefault() to be called so that e.g. opendir("/data") uses the DLDI-powered partition if DLDI is used and that the common "fallback to SCSD/SCCF/..." works if no DLDI driver has been linked like in the old days ?

PypeBros wrote:

WinterMute wrote:See examples/filesystem/libfat/libfatdir.

Hmmm ... should have thought about it, but it looks like it doesn't tell me much. The buggy code is the media exploration in EFSlib by noda, which was working properly with an older version of the libfat, and that seems to make use of diropen and dirnext in a way it should work e.g. on Unix.

Noda's EFSlib is not supported. Use libfilesystem.

If your card loader implements the argv protoocol correctly then the default working directory is the path where the nds file resides. If your card loader doesn't then consider using hbmenu

It is not. Regardless of whether I'd be willing to install and use hbemu on my DS, I cannot force other people to do so, and people would take for granted that their linker would be able to run a homebrew game without the help of an additional tool.
Sorry. I don't want to sound rude or discard the efforts that people have put into hbemu and the argv protocol, but I aim for user friendliness before anything else, here. I cannot afford a chicken-and-egg issue.

That's precisely the kind of attitude which prevents user friendliness and creates huge problems for everyone. If you create workarounds for the fact that your chosen card doesn't support argv then you're preventing the protocol being widely supported. When we introduced DLDI everyone had to patch their nds files for a particular card, all cards now support DLDI. If everyone had insisted on keeping workarounds for particular cards in their homebrew creations then we'd still be manually patching ...

Noda's EFSlib is not supported. Use libfilesystem.

I don't expect anybody @devkitpro to ensure that EFSlib keeps working with new releases of the relevant devkit parts, since it's clearly a 3rd-party library. I'm here to better understand why it's no longer working and what would work instead. I gave a look to libfilesystem, but it looks like it would only work with a nitrofs-compatible emulator or a argv-compatible loader.

If you create workarounds for the fact that your chosen card doesn't support argv then you're preventing the protocol being widely supported

I'm quite surprised you think so. Increasing support of the ARGV protocol is imho in the hands of linker vendors through an upgrade of their firmware. I'm afraid the R4 is the most common device around here, and as far as I understood, the company that produced them has dismissed, keeping their trade secrets closed. The fact that I'd produce a piece of software that works only with hbmenu is unlikely to make it more widely accepted. Afaik, the EFSlib enables the ARGV protocol to bypass the media scanning, meaning that the scan can be relegated to a backward-compatibility thing. You'll note that libfat included SCSD drivers even past the introduction of DLDI, and imho, it was part of the success of the approach.

WoodR4 provides argv support.
AKAIO provides argv support.
hbmenu can be used as a replacement menu for R4.
CyclodDS and EDGE both released updated, argv supporting firmwares after I started insisting that people make the manufacturers aware of the issue.

If you want to implement workarounds that help prevent the widespread support of the argv protocol then kindly refrain from asking for support. Any workarounds you post here will be removed and if you insist on being a part of the problem then your posting privileges will be revoked.

We need to inform users of why their card doesn't work with homebrew that uses nitrofs and ask them to request that the feature be added. Hiding the problem fixes nothing.

WinterMute wrote:WoodR4 provides argv support.

That sounds like good news. You might want to update the wiki page, then, as it gives the impression that hbmenu is the only available option for R4 users.

You have some objection to hbmenu?

I'm reluctant to link to or recommend piracy tools.

WinterMute wrote:You have some objection to hbmenu?

I think if you're fair to yourself and compare it to existing loaders, the drawback of hbmenu are clear. It has a non-appealing interface, and it doesn't run commercial games. I can perfectly understand that from a developer point of view, and I will likely invest some time understanding its source. From an adult point of view, I wouldn't like to replace my linker firmware with hbmenu, first because I'm reluctant at touching my devices' firmware, and second because that means I'd have to carry my complete games collection with me everyday in the case my bus was late.

The direct users of my software (those I meet in real life) are kids <= 10 who received a "pre-installed" linker with many games. That's their parent's choice. I frown upon that, but I can't change it. Showing the kids (and sometimes even the parents) that "homebrew" exists and that piracy isn't required for affordable entertainment is already challenging. For them, hbmenu as an additional step would be annoying at best and possibly confusing to the point they can't run games without help of their parents.

I'm reluctant to link to or recommend piracy tools.

Which I can understand very well. If they're can offer alternative to somebody, though, it would be honest to have information about it.

I think hbmenu has potential, though, if we augment it to become something as a homebrew channel, that can e.g. read my selected board RSS feed, download URL content, etc. The ability to return to main especially makes such use appealing. You mentioned overlays in a previous post, and I can easily see such "additional features" programmed as overlays using one screen while the core of hbmenu remains in control of the other screen.

Personally, I think coding a game that will be unable to work without ARGV is a bit extreme, esp. without any "sorry screen" to tell the user "your loader lacks the ARGV protocol. See http://wherever.org/argv to find out how to load it". I understand that pretending that everything's fine doesn't help either, and that you might easily got upset at me if I'm the 1001'th person you need to convince. Since EFS requires scanning of the media card, I think it would be fair to
1) ensure it only does the scan when no ARGV has been found
2) use the scanning time as an educational advertisement stating "disk scan in progress, you can avoid this using an ARGV-compliant loader. See http://wherever.org/argv to learn more about it." Insisting on a button press to dismiss this message can even be envisioned.