Hacking NeoGamma R9 beta

[WiiPower]

Right now NeoGamma does this to fix 002 error:
*(u32 *)0x80003188 = *(u32 *)0x80003140;

I guess
*(u32 *)0x80003140 = *(u32 *)0x80003188 ;

would be better, because 0x80003188 would always contain the info which IOS is requested by the game and the cIOS could do
*(u32 *)0x80003140 = *(u32 *)0x80003188 ;

as well to fix the 002 error. And it should be more resistant to copy protection mechanisms as right now the game could do a 002 check with the IOS requested by the tmd. If this 002 fix was always done, even ourselves would have problems to find out if a cIOS is running or not. If you don't consider this a problem, you could even set 002 fixing to always on and it wouldn't need any config.

If you write to /sys and the wii crashes at the wrong time, you got a big problem: A "noob" tries to load a disc with IOS Reload block, the wii crashes, and days later he installs a wad, returns to HBC and gets "weird" issues in some other app. The cIOS would be stuck in block IOS Reload everytime it gets loaded, until you launch a game with explicitly turned off blocker. Hmm, how about writing to /sys + a magic word at 0x80003188 and the old value of 0x80003188 in the config file?

About the return to system menu/HBC issue i meant:
Right now the cIOS gets loaded instead of the system menu IOS if you return to the wii menu, or does it not? That the launch title still launches anything that's not an IOS was clear to me already.(while i know that this behaviour is not self-evident)

 

[davebaol]

Right now NeoGamma does this to fix 002 error:
*(u32 *)0x80003188 = *(u32 *)0x80003140;

I guess
*(u32 *)0x80003140 = *(u32 *)0x80003188 ;

would be better, because 0x80003188 would always contain the info which IOS is requested by the game and the cIOS could do
*(u32 *)0x80003140 = *(u32 *)0x80003188 ;

as well to fix the 002 error. And it should be more resistant to copy protection mechanisms as right now the game could do a 002 check with the IOS requested by the tmd. If this 002 fix was always done, even ourselves would have problems to find out if a cIOS is running or not. If you don't consider this a problem, you could even set 002 fixing to always on and it wouldn't need any config.
Well, soon after d2x v4beta3 has been reloaded 0x80003140 contains the word representing 249v21004 and 0x80003188 contains the ios expected by the game, so
*(u32 *)0x80003140 = *(u32 *)0x80003188 ;
is exactly what I already do to fix the error 002.
And I believe it's better to do that only after the cios has been reloaded by a ios reload block.

If you write to /sys and the wii crashes at the wrong time, you got a big problem: A "noob" tries to load a disc with IOS Reload block, the wii crashes, and days later he installs a wad, returns to HBC and gets "weird" issues in some other app. The cIOS would be stuck in block IOS Reload everytime it gets loaded, until you launch a game with explicitly turned off blocker.
I think I can prevent this by saving the title_id of the running game in the config right before the cios is reloaded.
As soon as the cios is reloaded it loads the config and checks the title_id of the running app with the one in the config.
If they are different then the blocker is turned off.
Anyway the config file is deleted every time the cios is reloaded.
So if the wii crashes during the fake ios reloading, in the worst case /sys/esconfig.cfg remains stored in the nand until the cios is loaded the next time.

Hmm, how about writing to /sys + a magic word at 0x80003188 and the old value of 0x80003188 in the config file?

Sorry, I can't understand your point here. Can you explain?

QUOTE(WiiPower @ Apr 22 2011, 09:00 PM)

About the return to system menu/HBC issue i meant:
Right now the cIOS gets loaded instead of the system menu IOS if you return to the wii menu, or does it not? That the launch title still launches anything that's not an IOS was clear to me already.(while i know that this behaviour is not self-evident)

Hmm, I'll investigate about that and let you know.

 

[WiiPower]

Ok, the title id check is way better than everything i come up with yet. If you let the system menu IOS correctly loaded no matter if the block is enabled or not, then i'm happy. Great job with the whole project btw, when i update NeoGamma next time, i have to update the recommend cIOS too, it's overdue.

 

[davebaol]

Ok, I'm almost ready to release d2x v4beta3.
The title id check seems to work great. Now it should be pretty much impossible to encounter a blocker loop.
Also the system ios doesn't seem to be a problem.

Oh, does Neogamma support a slot other than 249?

I've added to the "fake launch" ioctl an optional argument for method 2 representing the slot to reload instead of the requested one. If this argument is missing the default value 249 is used to preserve backward compatibility.

 

[WiiPower]

If you give me the code i need, i'll make NeoGamma use that command. There's the possibiltiy to change the used IOS in the config file manually, so it would be useful for some (experienced) users.

 

[davebaol]

You should modify few lines of the block_ios_reload function in apploader.c like that:

ÂÂÂÂstatic int mode ATTRIBUTE_ALIGN(32);
ÂÂÂÂstatic int ios ATTRIBUTE_ALIGN(32);

ÂÂÂÂmode = blockiosreloadselect;
ÂÂÂÂvector[0].data = &mode;
ÂÂÂÂvector[0].len = 4;

ÂÂÂÂint inlen = 1;
ÂÂÂÂif (mode == 2) {
ÂÂÂÂÂÂÂÂinlen = 2;
ÂÂÂÂÂÂÂÂios = 249; // ios to reload instead of the requested one
ÂÂÂÂÂÂÂÂvector[1].data = &ios;
ÂÂÂÂÂÂÂÂvector[1].len = 4;
ÂÂÂÂ}

ÂÂÂÂIOS_Ioctlv(es_fd, 0xA0, inlen, 0, vector);

This code is not tested but should work.
Note that waninkoko's cios and d2x cios lower than v4beta3 ignore the second argument.
On the other hand the second argument is optional for cios d2x v4beta3 or higher.

Tomorrow I'll release the new beta.

 

[davebaol]

cIOSx d2x v4beta3 has been released: http://gbatemp.net/t277659-ciosx-rev21d2x-...p;#entry3609914

 

[IceIceBird]

davebaol: maybe an easy function for saving savegames to SD/USB instead of the limited real nand could be added in the future, so the usb loaders could implement it easier. Sure it already can be done by using the nand emulation, but as said most of the usb loaders don't want to look in to it. So if there was an easy function for this in the cIOS maybe they will add it then

The only one I know of is uLoader that suport it at the moment.

Hmmm, at first glance it seems not very hard to implement since it's a small subset of emunand, but I could be wrong.
However I'm not sure that usb loader developers are interested in integrating this feature.
And I wouldn't spend my spare time to implement features whose nobody cares about.
Maybe a poll could tell us more about that. I'll let upon you.

The poll

 

[Levente]

I have 007 Everything or nothing, what's to test with it?

 

[Levente]

I have 007 Everything or nothing, what's to test with it?

This game is not loading, only keeps restarting. (Neogamma R9 beta47, cIOSrev21 d2x v4beta3, Wiigators 0.2 cMIOS)
I get this with internal mode:
Game ID: GEND69, dvd read function 2. reloader activated
Warning: could not patch seek
Warning: could not patch read audio
Warning: could not patch audio config
Warning: could not patch audio status
Audio stream bit set, but no audio streams found
Waiting...
Lauching game...
Then the wii just restarts.

Backup disc is loading with a softmodded GC with SD media launcher and GCoS 1.x.

 

[WiiPower]

I think it moves its own main.dol or parts of it from one memory location to another. This results in garbage executed instead of the read replacement function right now. It could be partly fixed by using fixed jumps, but then calling the original read function(yes it's used/required by NeoGamma's plugin) would execute garbage.

I've been trying to fix this, but it's still too early to tell if it will work or not. If it will work, then it will also fix 007 Agent under Fire that currently works with the .elf fix option. The .elf fix option checks loaded .elf files and patches them according to where the parts of the .elf file belong in the memory, instead of where they are loaded to.

Hmm, i gotta check if there's an easy fix and the main.dol is loaded to a wrong memory location. Hmm, or maybe it's a .dol that has the read .dol included in itself. If that's the case, i hope it's not compressed, but it seem unlikely as NeoGamma finds some dvd read function in the .dol...

Anyways thanks for bumping the problem!

 

[Levente]

Anyways thanks for bumping the problem!

You are welcome.
And what's the status of PSO games?

 

[tagzard]

When i launch Installer for WiiGator's cMios which ios do i choose to load? When it first opens.

 

[davebaol]

@WiiPower
FYI cIOS d2x v4beta4 implements a "return to channel" feature fully compatible with all games.

 

[WiiPower]

@WiiPower
FYI cIOS d2x v4beta4 implements a "return to channel" feature fully compatible with all games.

Nice, but:
"FAT - Added support for sector size up to 4K (typically needed for HDD greater than 2T)."
sounds more intesting to me.

You achieved the return to channel feature with the IOS Reload block code? Instead of launching the system menu/its IOS, it boots the desired channel? And let me further guess, it works without configuration?

 

[davebaol]

Nice, but:
"FAT - Added support for sector size up to 4K (typically needed for HDD greater than 2T)."
sounds more intesting to me.
Yeah and I believe it's even more interesting than you can imagine.
I'm studying the dip module and it seems fat is supported directly by the cios just like wbfs.
Basically it means you can load wii games from a fat formatted hdd (or sd card) with few changes to the loader.
Obviously the loader should use the fat module to retrieve the game list.
Also it seems that splitted wbfs files (needed for the games bigger than 4GB) are not supported, but it should be quite easy to implement.
Does it sound still interesting to you?

QUOTE(WiiPower @ May 9 2011, 05:41 PM) You achieved the return to channel feature with the IOS Reload block code? Instead of launching the system menu/its IOS, it boots the desired channel? And let me further guess, it works without configuration?

Yep, but if the ios reload block is enabled then the channel id is saved in the config file so that after reloading the cios you can still return to that channel in place of the system menu.

EDIT:
Oh, forgot to say I'm studying the dip module because I'm investigating ios reload and usb support.
I would be happy to discuss it with you and anyone else can contribute.

 

[WiiPower]

I knew that Waninkoko added FAT support into the dip module directly. But is any loader actually using it? If i add FAT support, i'd make the 1 step further and add the whole frag support including NTFS support. If i were you, i would check if any loader is using it, and if not, remove it from the cIOS to clean up and save some memory.

I always liked to talk to the Configurable USB Loader devs(oggzee and Dr. Clipper mostly), but i wasn't online on irc for months...

 

[davebaol]

Oh I didn't know.
However AFAIK there's no usb loader out there using it.
But I believe there's no need to remove those few lines of code, actually 2 custom ioctl commands and 3 little functions.
All the "dirty job" is done by the FAT module itself which is used directly by Mighty Channels and Triiforce for nand emulation.

 

[jurai]

has anyone had success booting Doshin The Giant (PAL) in 480i with NeoGamma r9? if so what patch options did you use, for the life of me I could not get it to boot and display properly, finally gave up and just used a GCOS disc since it's vidpatch works great

note: didn't install custom MIOS since I have a chip

 

[WiiPower]

has anyone had success booting Doshin The Giant (PAL) in 480i with NeoGamma r9? if so what patch options did you use, for the life of me I could not get it to boot and display properly, finally gave up and just used a GCOS disc since it's vidpatch works great

note: didn't install custom MIOS since I have a chip

NeoGamma can do next to nothing without cMIOS for gamecube games, no video mode patches, no audio streaming, no Ocarina. And if you use component cables, that's another problem for which there isn't a solution available yet.

Well if it's a multi game disc, then NeoGamma won't be able to help you, because NeoGamma + gamecube multi game disc + modchip is a combination that does not work.