Hacking Decompiling waninkoko's softmod

I can't believe the hate on here (esp the first few pages) for a guy who has given us so much.

Come on, people! Stop being assholes! Seriously!
 
Seems that getting past the 3x limit is going to be quite a barrier, as the drive itself is in control of what type of access it gives to the IOS.

But judging by how the loader functions (basically emulating the di interface), seems like it wouldn't be too much of a jump to modify cIOS to read an ISO from an SD Card. Even more useful would be reading an iso off of an SMB share, and writing the di wrapper around functions to treat this ISO as if it were a physical disc. (although with wireless G you are still looking at less throughput than a 6x DVD-ROM, more like 5x. With the 10/100 ethernet adapter you could reach DVD speeds).

Just a thought. Personally I would prefer to keep all of my Backup ISOs on a server anyway, not waste any blanks, or have to swap discs.
 
Jumping in here...

Dual format would be fantastic and does seem like a possibility with everything you guys are talking about. I know alot of people can more easily afford blank DVDs and like to be able to display a collection, and there are others of us that would just love to network the Wii to a computer or hook up an external drive as this is much more space (both physical and storage) efficient.

I for one would also like to add in that it is great to see the community pick this up and embrace the forward movement of this project. It was unfortunate in the beginning but this is turning into a great project. I wish I had the know-how to help, but if anyone needs help with testing a feature or limited graphics stuff then please let me know via PM, I'd be glad to help in any way I can.
 
Well... anyone with IDA/ARM knowledge? (Unfortunately I'm ix86-only
smile.gif
)

Crazy idea. May be, may be... it will fix NTSC issue.

When playing around with loader I've noticed that loader appears to force PAL 480i mode even if the console setting is set to PAL 576i. I noticed it sincemy old TV that is assigned to the wii-duty does not support 60Hz/480i.

So, I think may be the issue is not with PAL output per se, but rather that in apploader videomode is forced with the hardcoded value (say, 480i), when it should be taken from the console settings.

May be it is possible to unpack, disassemble cIOS (or just patch an unpacked code with vmc?... crazy idea
blink.gif
) to force not PAL 480i but some other mode?.. 576i,... NTSC?
 
1) Yes, in dol.. But I don't know if it is done in the backuploader or in the cIOS - so, one need to decompile cIOS wad

2) It can be as well, that the video mode is passed as a function call parameter (and it will not be handled by the vmc
wink.gif
)

3) backuploader already has all video modes (NTSC, PAL), and you can see the text correctly on all systems - so, it is not the backuploader per se..
 
I doubt that video mode patching is done from IOS, Video mode is modified by writing to VI registers and this is generallty handled by PPC code (like most homebrew are doing during video initialization). IOS have no access to the Video Interface.

the problem is that the game itself can change the video mode (like any other PPC application) so I think you have to patch either the game or some kind of RAM location, I'm not really sure how game loader (like GeckoOS or GCOS) were doing technically
 
Well, I don't know the wii technical specs. But with general computer background...

We have some settings in the console (say, PAL 50Hz/60Hz/Progressive) and the game just uses them (well, not 100%, but it definitely can fallback to the lowest setting, if the highest one is not active in settings).

So, it can be

1) Game looks for the some setting variable (inside the console settings) - via the callback API function or just memory location (global variable).
2) Console apploader, when calling a game bootstrap, passes the maximum possible mode to the game (for example, it says: no more than 480i, or use any PAL you like, etc). And the apploader takes it from the settings.

In any case, it appears that this mechanism is not working - it stores in the memory, or passes the hardcoded value - PAL 480i.

What you get - the console is in the correct mode (NTSC, 576i..) - since you can see the backuploader's text. But then the game recieves (reads) PAL480i value and... just switches to it. If it is possible to make a quick dirty hack, say, set it to force NTSC - you'll get NTSC backuploader
wink.gif
Or 576i backuploader.

But I doubt anyone here except waninkoko will/can/want do this reversing.

I will try to bruteforce patch backuploader dol to another video mode, but I give it 10% chance of success (since the initial loader text menu is Ok).

P.S. IOS can provide some callback API that returns the desired/possible video mode...
 
I was gonna say, since it's already running in our native video mode (NTSC) at the actual loader, would bruteforcing really make any difference at all? Would it actually patch the area that's telling it to switch to PAL? =\

Let us know how that goes anyways, I'm curious to see what the outcome is.
 
BTW, I will patch not to NTSC, but to PAL 576i... And only tomorrow evening - wii is at the different place.

And yes, I highly doubt, that it will change anything, since the game itself changes video mode, not the loader (you can have wii menu in progressive mode, and the loaded game will change it to the interlaced one).
 

Site & Scene News

Popular threads in this forum