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
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.