Hacking Question for devs

[kaux]

Whichever one SNEEK runs better with is my choice

 

[smf]

Anyways, i think these 2 ways are complicated to write while my latest suggestion should be easier to write. And IF it would work, it would return the advantage of being able to patch the 2nd .dol in any way you want. You could do that from the cIOS too, but it would be complicated too.

You can already patch the 2nd dol with hermes fat32/ntfs. Write a patched sector to a new file on usb and for that sector give cios 222 the pointer to that block.
I was under the impression that reloading the cios will lose the current settings though.

 

[oggzee]

My vote is for separate modules, so I can add FAT/NTFS .wbfs/.iso support to it.

Or include support for fragment list which is used for FAT/NTFS support. The code is small, simple and generic. It is simpler than libwbfs but it can support WBFS too, while the performance is the same.

Or as suggested, doing both, having built-in modules but with the ability to override them with external ones, I know that's more work but I guess that would have the benefit of compatibility with older loaders that don't support module loading yet.

edit:
btw, source for fragment list can be found here: Cfg_USB_Loader_50-src.rar and cios_mload_cfg50.zip

 

[arasium]

A lot of developper won't be able to load their modules themselves (i've seen a lot of coders just doing copy/paste. They aren't good enough in coding to use external modules).

So the better way is to include plugins in the modules, but also allow the user to put his plugin (perhaps with a vector table or something like that).

I voted for the included plugins (we already have the hermes cios for external ones).

 

[oggzee]

Only proper way to fix that is blocking IOS reloading completely, and that "can" be done using both ways (builtin or no builtin modules).

Do we have an idea why hermes's ios reload blocking doesn't work for most games with this kind of problem?
I don't know what exactly his reload block does, i guess it just ignores the call. But maybe the proper thing to do is to close all ios file descriptors, since the game will re-open them after reload but since some of them are already open it might be the reason why it fails somehow? Or is the problem somewhere else?

 

[WiiPower]

A lot of developper won't be able to load their modules themselves (i've seen a lot of coders just doing copy/paste. They aren't good enough in coding to use external modules).

So the better way is to include plugins in the modules, but also allow the user to put his plugin (perhaps with a vector table or something like that).

I voted for the included plugins (we already have the hermes cios for external ones).

Well, then these developers just have to wait until somebody wrote the code that loads the modules to copy that. I don't see any problems for these developers on both options.

QUOTE(waninkoko @ Feb 10 2010, 11:35 PM) Only proper way to fix that is blocking IOS reloading completely, and that "can" be done using both ways (builtin or no builtin modules).

Do we have an idea why hermes's ios reload blocking doesn't work for most games with this kind of problem?
I don't know what exactly his reload block does, i guess it just ignores the call. But maybe the proper thing to do is to close all ios file descriptors, since the game will re-open them after reload but since some of them are already open it might be the reason why it fails somehow? Or is the problem somewhere else?

Well, correct if i'm wrong, but the IOS Reload happens because it's the way nintendo loads .dols on the ppc. The IOS is booted, looks at its state and then the IOS loads the .dol. I have absolutely no idea what Hermes IOS Reload block does, so any details would be helpful.

 

[TrapperKeeperX]

I'm no dev but I'd say release both it gives everyone to something to experiment with can they can chose one or the other and after the release then make a poll it would be easier if the users to make their opinions on it add tot he poll a 3rd option for Both Application & Built-in release both in my opinion.

IOS Reload Blocking for Metroid Prime 1 NPC,Metroid Prime 2 Dark Echoes NPC, & Metroid Prime Trilogy would be good for the Next cIOS release I wouldn't mind a delay until this it's fixed it just makes it worth waiting!

 

[oggzee]

Well, correct if i'm wrong, but the IOS Reload happens because it's the way nintendo loads .dols on the ppc. The IOS is booted, looks at its state and then the IOS loads the .dol. I have absolutely no idea what Hermes IOS Reload block does, so any details would be helpful.
Ok, now that the dip plugin is opensource, we can see what it does:
ios_mload_4.0/odip_plugin/source/es_ioctlv.c:

CODEÂÂÂÂif(dat->ioctlv.ioctl==8) { // reboot
ÂÂÂÂÂÂÂÂÂÂÂÂos_sync_before_read( (void *) dat->ioctlv.argv[0].data, dat->ioctlv.argv[0].len);
ÂÂÂÂÂÂÂÂios=*(((volatile u32 *)dat->ioctlv.argv[0].data)+1);
ÂÂÂÂÂÂÂÂversion=1;
ÂÂÂÂÂÂÂÂos_sync_before_read((void *) 0x3140,8);
ÂÂÂÂÂÂÂÂ*((volatile u32 *) 0x3140)= ((ios)

 

[cwstjdenobs]

Wouldn't closing all the IOS file descriptors also shut down the ehci module and any nand emu etc, making it a better idea to try shutting down all the ones not used exclusively by the cIOS?

 

[waninkoko]

Geez, I see there's not a clear winner option... I expected to get some conclusions today to continue developing rev18 but looks like today is gonna be a nice day to play with my console (not the wii, i mean the 360).

 

[WiiPower]

So it catches ioctl 8 on the ES module. Well, i would like to know if the return value 0 is correct and if it's always a call for an IOS to be loaded and not something else.

 

[Helwem]

The good thing of your cios is that it does everything

 

[oggzee]

So it catches ioctl 8 on the ES module. Well, i would like to know if the return value 0 is correct and if it's always a call for an IOS to be loaded and not something else.
If we check libogc sources:
CODEs32 IOS_ReloadIOS(int version)
=> ÂÂÂÂres = __IOS_LaunchNewIOS(version);
ÂÂÂÂ=> res = ES_LaunchTitle(titleID, &views[0]);
ÂÂÂÂÂÂÂÂ => res = IOS_IoctlvReboot(__es_fd,IOCTL_ES_LAUNCH,2,0,vectors);
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂ (#define IOCTL_ES_LAUNCHÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ0x08)

ÂÂÂÂif(res < 0) {
#ifdef DEBUG_IOS
ÂÂÂÂÂÂÂÂprintf(" LaunchTitle failed: %d\n",res);
#endif
ÂÂÂÂÂÂÂÂreturn res;
ÂÂÂÂ}

So return 0 seems fine...

 

[WiiPower]

Well what does it actually return? If you get past libogc's IOS Reload, that doesn't mean much on IOS Reload on games. Ok, i can check for myself what a regular IOS Reload returns. Which leads to my next question, does it return something in the output buffer? That's also something i can check for myself.

 

[tj_cool]

Geez, I see there's not a clear winner option... I expected to get some conclusions today to continue developing rev18 but looks like today is gonna be a nice day to play with my console (not the wii, i mean the 360).

I wouldn't hope for a clear outcome
Most people here don't know the difference between the 2 and just vote something...

 

[Blue-K]

Geez, I see there's not a clear winner option... I expected to get some conclusions today to continue developing rev18 but looks like today is gonna be a nice day to play with my console (not the wii, i mean the 360).

I wouldn't hope for a clear outcome
Most people here don't know the difference between the 2 and just vote something...

Jup

. But, if you look only at the answers from the Devs in this Thread (WiiPower, Oggzee), they picked Application...

So, Wanin, if you realy want an answer, I'll guess you'll have it already: External. It's also in the first place in the Poll now...

 

[WiiPower]

That's only 2 devs, there are some more. I wouldn't decide by only this.

 

[roku93]

Is there really any advantage of having them built-in? Expect maybe having to have SD on your wii to load them from..? The way I see it external modules are far superior.. :S

 

[WiiPower]

Is there really any advantage of having them built-in? Expect maybe having to have SD on your wii to load them from..? The way I see it external modules are far superior.. :S

That's not even an argument for internal modules. An application(the loader) can contain binary files(the modules) inside the .dol. A channel for a loader that doesn't need a sd card at all would be bigger then in the cIOS with external modules compared to the cIOS with internal modules, but that would be it.

 

[oggzee]

Is there really any advantage of having them built-in? Expect maybe having to have SD on your wii to load them from..? The way I see it external modules are far superior.. :S

Advantage is simplicity in using the cios for developers. And backward support for existing application that use it.

Disadvantage is more frequent re-installation of the cios, and less flexibility for new/custom stuff...

But if the new cios includes the frag-list support i'm happy with it and I have no need to make custom modules.

btw somewhat related comment ... at the moment both libwbfs and frag-list are inside ehcmodule, and duplicated inside sdhc module but a better place might be the di plugin... so that it is device independent and the same code can be used on top of both usb and sd....