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.
