Atm the kernel has only access to the usb device OR sd-card, not both at the same time. All files needed by the kernel to do its job has to be on the device the game is readed from (nincfg.bin, controller.ini, ninmem.raw and ndebug.log).
It would be better to make the loader accept arguments and or use a specific spot in memory to load/write the configuration but thats up to the dev team.
I agree with this. I'd say keep the first argument as the calling location, as that seems to be the standard. Then, either combine all the config settings into the second argument comma separated or each setting into its own argument. I'd lean to the second one. Something like:
argv[0] = "sd:/apps/Nintendont/boot.dol"
argv[1] = "CONFIG_CFG_AUTO_BOOT=1"
argv[2] = "CONFIG_GAME_PATH=/games/Zelda/game.iso"
argv[3] = "CONFIG_CFG_USB=1"
I like using strings so that if settings change, old code would still work.
You'd want these to override the settings in the config file, so it would processed after the ConfigReset, but before asking the user for USB/SD.
I would also like to point the kernel to a location in memory where it can read the config, rather than from a file. Maybe near 0x[1|9]0004100, as we're already using that area to communicate between the loader and the kernel. The loader could write the config structure to memory there, and the kernel could read it, rather than using file access.
In a related a note, a common header file with all global memory locations in it would be nice, rather than having hard-coded values like the 90004100/10004100 in loader/main.c and kernel/common.c.
While I'm making wishes, at some point I think we're going to need to replace the ARAM DMA patches with code that does the memcopy in the kernel, rather than in the PowerPC where it's being done now. ARQPostRequest and ARStartDMA accept requests to copy memory from the main RAM to the ARAM on a gamecube which are normally handed off to other hardware, with a callback function for when its done. This mode isn't supported by the Wii, according to
http://wiibrew.org/wiki/Hardware/DSP. The patches just immediately do the copies instead and immediately call the callback. This method appears to work in most cases, but it will likely cause stuttering in game, during the copy. It would probably work better to have the ARM do these copies instead. Maybe using a method similar to the way the Disk interface patches work? (see dip.cpp/h, DI.c/h). It would probably need to have a max size to process at one time, breaking the copy into multiple chunks in the while loop in main(), so that controller information is still updated at a reasonable rate.
Glad to see some new committers and others working on this. If anyone else wants to start working on these, feel free. I don't have time myself right now, but I'll probably start looking at some of them myself eventually if no one else does.