Toggle sidebar

Hacking NEW Wiigator Modified Loader

I would tend to agree with Zapu. No offence or disrespect meant to the people that are releasing these programs. I would prefer that they reported these to Wiigator so that he can integrate them with his existing loader and check that they are compatible and work fine and then give them credit for their work in the next release. I would feel more comfortable installing the fixes then.

Thetonman
 
Actually, as I stated before I do not intend to release ANY binaries. Sources only.

Edit:
Ok, I think I'm giving up for tonight. Some insight on what I'm working on. (Though I've been fairly quiet about it up until now.)

I contacted Waninkoko around the time his loader was leaked asking if I could help with anything in the future, and respectfully received no reply. Understandable, he's a busy man, I'm sure.

Likewise, I contacted WiiGator via PM here, and again received no reply. Again understandable.

However, I realized that the only way "scratch the coding itch" was to start from scratch, using what I've learned from studying their respective source releases to attempt to
build a more "open" loader project. It contains ZERO code from either Waninkoko or WiiGator, and is 100% my work. I have received PMs from knowitall599, however, as of yet we are not collaborating directly. I believe his version is based on WiiGator's.

Starting from scratch has helped me to eliminate bits of code that aren't directly related to backup loading to make the code easier to read, easier to understand, and hopefully will perform well with less errors.

Side note, the new loader is coded almost entirely in C++, and uses classes for most everything except where I needed some ASM for relocation.

Again, I don't want to get anyone's hopes up, but fixed or not, I will be setting up a PUBLIC SVN where anybody can check out the latest revision of the code. I will NOT be releasing ANY binaries at any time. Since any and all development is OPEN, after I get the code uploaded to SVN absolutely ANYONE can compile and test the code as they wish, as it is updated.

I apologize for any confusion, and hope this has cleared a few things up.
 
requiem4d said:
Actually, as I stated before I do not intend to release ANY binaries. Sources only.

Edit:
Ok, I think I'm giving up for tonight. Some insight on what I'm working on. (Though I've been fairly quiet about it up until now.)

I contacted Waninkoko around the time his loader was leaked asking if I could help with anything in the future, and respectfully received no reply. Understandable, he's a busy man, I'm sure.

Likewise, I contacted WiiGator via PM here, and again received no reply. Again understandable.

However, I realized that the only way "scratch the coding itch" was to start from scratch, using what I've learned from studying their respective source releases to attempt to
build a more "open" loader project. It contains ZERO code from either Waninkoko or WiiGator, and is 100% my work. I have received PMs from knowitall599, however, as of yet we are not collaborating directly. I believe his version is based on WiiGator's.

Starting from scratch has helped me to eliminate bits of code that aren't directly related to backup loading to make the code easier to read, easier to understand, and hopefully will perform well with less errors.

Side note, the new loader is coded almost entirely in C++, and uses classes for most everything except where I needed some ASM for relocation.

Again, I don't want to get anyone's hopes up, but fixed or not, I will be setting up a PUBLIC SVN where anybody can check out the latest revision of the code. I will NOT be releasing ANY binaries at any time. Since any and all development is OPEN, after I get the code uploaded to SVN absolutely ANYONE can compile and test the code as they wish, as it is updated.

I apologize for any confusion, and hope this has cleared a few things up.
Click to expand...
This is awesome! Just to make sure, if the loader went wrong or wrote something to a wrong memory address, it's not going to brick my wii, is it?
 
Possible. That's why I'm keeping any hard-coded direct memory accesses to a minimum in my code. That's also why I want to be sure I have at least a working version (even if it isn't perfect) before I upload the sources. I have 6 kids who all love to play the wii, and not enough money to buy a new one yet. As I'm sure there are others out there in similar situations, I'd like to keep the number of bricks caused by my loader down to a zero.

(I hope that made sense... It's late here, and I'm a programmer, not an english professor.)
 
OK, do people seriously think this change speeds up game loading? This could not be possible!
Because the changed code is enclosed in this if-block:
if(geckoattached){
...
}
We're not using any USB Gecko, so we're not receiving any gecko commands. Therefore, that code is never executed!

roy_hu said:
requiem4d said:
diff -ruN = man's best friend.


Code: 
--- Desktop/main-old.cÂÂÂÂ2008-10-30 17:20:00.000000000 -0400
+++ Desktop/main.cÂÂÂÂ2008-10-30 17:20:02.000000000 -0400
@@ -546,7 +546,7 @@
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂnowiird = 0;
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂmemset((void*)0x80001800,0,kenobiwii_size);
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂmemcpy((void*)0x80001800,kenobiwii,kenobiwii_size); 
-ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂfrozenvalue = *(u32*)0x80001808;
+ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂfrozenvalue = *(u32*)0x80001800;
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂ*(u32*)frozenvalue = 1;ÂÂÂÂ
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂDCFlushRange((void*)0x80001800,kenobiwii_size);
ÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂÂusb_recvbuffer_safe(EXI_CHANNEL_1,&configbytes,2);ÂÂÂÂ// Get config
Click to expand...

Hey guys,

Do you really believe this change is going to speed up game loading? I know nothing about Geck OS, but from reading the source code, the original code seems to be correct.

The buffer kenobiwii is the raw binary generated from newasmpatch/kenobiwii.s. The first two words are filled with 0, and the third word stores the address of frozenvalue. So the original code loads the address of frozenvalue from *0x80001808, which seems correct to me. The change loads 0 into the pointer instead, and then dereferences the pointer for writing. This means we are writing something to address 0. I don't know about wii, but on PC writing to 0 will crash the program.

In summary, I think the change is incorrect. Besides, I don't think it's even relevant. The frozenvalue thing seems to be used for debugging with USB Gecko oS. I don't think this piece of code is executed in normal processes.

I got other two questions as well:
1. Why pad the first two words of kenobiwii with 0?
2. Why do we need memset before memcpy?

Of course, I could be sooo wrong because I'm an idiot. I'd appreciate your comments.
Click to expand...
 
Why don't all you guys just get together and make some sort of uber loader! Everyone looks at the code and points out bits that can be improved, Any news from wiigator on a 0.4 as of yet?
 
I've tried both of Knowitall's releases and timed results for Mario Kart show it is exactly the same speed as WiiGator's release at initial loading AND loading tracks.

Which games have you found load quicker? Please post your findings so we can verify...
 
Jesse Sander said:
With the new possibility of bigger icons I couldn't resist creating another channel, with updated icons and an improved banner. (In my opninion, since I found the other one quite 'empty'. )

Video:

Screenshot: (bad quality)

Icons I (partially) created:


Download here
(Sorry WiiShizzza, I stole your B button. , Sorry Forsaekn I replaced your music. (Made it more Wii-ish )
Click to expand...

Hey guys, I have injected the .dol for the new modified loader into the channel above so that we can have a channel version.

Download
Also note this is not the autoboot channel, it doesn't autoboot. It is JUST THE .DOL FILE ON THE 2ND POST INJECTED INTO THE CHANNEL BANNER ABOVE!
 
All I did was inject the .dol file in the 2nd post to the channel in the Modified Loader thread and uploaded it to Mediafire, I made no changes whatsoever...
 
Somewhere I read something about a read retry fix. What exactly is that? And is that in a modified loader or in an cios?
 
That is just a somewhat fix for Super Paper Mario, it doesn't fix the "disc error" problem.
Btw, it is a cIOS but for some odd reason it never installs for me...
Also if you have any problems with the channel, please tell me.
 
ebdynasty said:
Has anyone tried 007 Quantum with this by any chance?
Click to expand...

Quantum of Solice has a disk read error. All disk read error's have not been repaired yet. This code is very confusing and takes a while to understand, but give it some time and I will get those error's out. I am also very excited about playing Quantum of Solice on my Wii.
 
Oh ok, thanks a lot for any attempts in advance. I hope to be playinh QoS with people here soon
biggrin.gif
 
fuuuuuu said:
Why don't all you guys just get together and make some sort of uber loader! Everyone looks at the code and points out bits that can be improved, Any news from wiigator on a 0.4 as of yet?
Click to expand...

Yeah! Just like linux distros! Thats what makes them work so well, because so many people check whats wrong with it
 
; ) Im glad someone is fixing the "ERROR TURN POWER OFF" Error, I hope this version gets released soon.(With a channel too)
 

Site & Scene News

Go to forum More news

Popular threads in this forum

Hacking  Wii Preloader stuck

Hacking Emulation  What is the best way to recover my Wii Shop purchases?

Wii doesn't show image on TV after replacing DVD drive

Wii Brickers

Gaming Hardware  What can I do to increase the lifespan of my wii?

Issues with an Updated Jailbreak

Rare games N64 port

Hacking Homebrew  wiicalib: calibrate your Classic Controller (Pro)