Hacking Coding vWii 3-core support - everything you need to know.

[Maxternal]

The bit shift isn't needed... I've been using that hook code on xbox 360 for ages now, and it works as-is (like I said, reliable.) But yeah, they basically re-use the &3 bits for flags in some instructions because of 4 byte alignment for instructions.

notice...
range 0-0x1FFFFFC (0x3FFFFFC sign extended, negative bit 0x2000000) link bit 0x1

A DWORD/u32 is unsigned, subtraction of two u32 when the value being subtracted is greater than the value being subtracted from is by no means guaranteed to give you a value that can just be stuffed into the sign extend mask. Notice the dest/cur are reversed in subtraction of the backwards branch vs. the forward branch, this is to ensure a positive value as a result (instead of using int and a bunch of casting), which gets or'd with the bit that indicates negative/sign extend. To make this function totally safe/complete it really should have a range check before assembling the instruction, but in the case of a bootloader or something, you should know before using it if it will be effective as there are really no feed back mechanisms other than <crash><unplug from wall>.

Anyway, do what you want with the code. I posted it because I use it regularly and know absolutely it is reliable. About the most you'll get me to agree to is that the mask can be simplified from 0x3f to 0x1f.

edit:
bonus round... in a 32bit address system, is 0x80000000 address negative zero, or what? xD (it's much more work to mask that bit out and convert to int than to just deal with it as a pair of positive u32)

Okay, I see how that works now. Thanks for clarification

 

[cory1492]

Okay, I see how that works now. Thanks for clarification

Correction, you saw how I thought it was supposed to work (see edits, I had to fix it... I think it's time I do a code audit and look for any other things like this in my base code)

 

[Maxternal]

bonus round... in a 32bit address system, is 0x80000000 address negative zero, or what? xD (it's much more work to mask that bit out and convert to int than to just deal with it as a pair of positive u32)

hmm, I think I had learned that the msb was supposed to always be the sign bit in 2's compliment numbers and that (because of overflow) adding a negative number ended up the same as adding the same binary value as an unsigned number

example:
-1 + 1 = 0
0xFFFFFFFF + 0x00000001 = 0x00000000
(adding 1 to unsigned 0xFFFFFFFF would overflow to 0 anyhow so it ends up the same.)

so even though that works fine casting it and masking it out, it may not be necessary.
I'd have to test that, though.


EDIT : that does mean, though, now that I think about it, that branching from 0x100 and branching from 0x81330100 for core are probably too far apart for them to both branch into the same address so I might have to have 2 copies of the same code for each ... or manually load an address into the link register and run the "blr" instruction to fake returning from a function in order to get that far.

EDIT2 : wait, 0x100 isn't actually in mem2 or mem1 according to wiibrew
http://wiibrew.org/wiki/Memory_Map so how is it supposed to be accessible as a reset vector?

 

[shuffle2]

http://codepad.org/cUTpuzBD

 

[Maxternal]

http://codepad.org/cUTpuzBD

okay, well, that just shot to death everything I thought I knew about signed ... *thinks about it* Wait, never mind. I see what I was doing wrong. I somehow miscounted my bits.

*feels rather silly*

EDIT : love that site BTW

 

[Maxternal]

(it's much more work to mask that bit out and convert to int than to just deal with it as a pair of positive u32)

Even though that works fine casting it and masking it out, it may not be necessary.
I'd have to test that, though.

I just took advantage that nice little site that [user]shuffle2[/user] used and tested this out and GOOD NEWS, it looks like the masking and casing isn't really necessary. The result is the same either way, with or without casting and with or without the mask.
http://codepad.org/6NOTcxr6
http://codepad.org/CeMqSAGh
(with only a minor adjustment since that site apparently doesn't like "bool")

 

[the_randomizer]

Because I don't know coding, is this code pad stuff the finished product?

If so, all I can say is...that was pretty frikin' fast

 

[izzydeank]

. Happy to see the wonderful help. What is benefit of code pad?

Its nice, because you can post your code online and it executes it for you. Plus you can share it easily.

 

[the_randomizer]

I edited. Check op; still some "to do" but this is awesome. Every time I look here I see progress and great help given. I realized my post was wayyyyy premature.

Even so.....there are some coding geniuses on here....and here I was all ready to read up on PPC ASM and just plain ASM.

Its nice, because you can post your code online and it executes it for you. Plus you can share it easily.

Didn't even know about that site. Nice!

 

[comex]

0x100 is a physical address. 0x80000100 is the corresponding virtual address. When a PPC processor takes an interrupt, including reset, address translation is initially off.

 

[Ray Lewis]

0x100 is a physical address. 0x80000100 is the corresponding virtual address. When a PPC processor takes an interrupt, including reset, address translation is initially off.

Thanks for stopping by Comex. There has been a LOT of changes.

 

[Maxternal]

"a lot" is relative but we've definitely made progress, yes.

 

[the_randomizer]

"a lot" is relative but we've definitely made progress, yes.

Indeed, and I have the utmost respect for those who dedicate what little free time they have in their lives to research, test and spread information in such an easily-accessible manner

 

[marcan_troll]

At this rate, you might even know what you're doing by the time the WiiU2 comes out!

(I *am* a troll, but it *does* take longer than a couple of years to go from having trouble with two's complement arithmetic to being able to start a serious port of an SMP operating system to a new platform. Keep trying, though, and you'll get there, just don't expect it to be in time to be relevant for the Wii U).

 

[BIFFTAZ]

At this rate, you might even know what you're doing by the time the WiiU2 comes out!

(I *am* a troll, but it *does* take longer than a couple of years to go from having trouble with two's complement arithmetic to being able to start a serious port of an SMP operating system to a new platform. Keep trying, though, and you'll get there, just don't expect it to be in time to be relevant for the Wii U).

Ouch..

 

[Ray Lewis]

Useless babbling of an idiot; edited (per Sven, Marcan et al)

 

[Quincy]

I am able to test, if needed

 

[the_randomizer]

At this rate, you might even know what you're doing by the time the WiiU2 comes out!

(I *am* a troll, but it *does* take longer than a couple of years to go from having trouble with two's complement arithmetic to being able to start a serious port of an SMP operating system to a new platform. Keep trying, though, and you'll get there, just don't expect it to be in time to be relevant for the Wii U).

Alrighty then, guess that's a sign to work harder then.

 

[Crewman]

The only problem is that an absolute branch can only work within the first 64mb of memory addresses, max (16mb with the bit shift ) so I'd have to check again the mem addresses for mem1 and mem2 from the PPC side to see how limiting that would really be.

There is a work around. Load the absolute address to the LR register and then do a blr to jump.
If you look out for a Op Code for blr there is non because it is a virtual instruction, that means it is a special case of the bclrl instruction.
So you have to use the code of the bclr instruction:

bclr:
bit 0-5:
0b01011 -> Op Code
bit 6-10:
1z1zz -> branch always. z means bit will be ignored and can set to what ever you want
bit 11-15:
00000 -> Condition register used. You can probably set this to what ever you want because we branch always
bit 16-20:
00000 -> always has to be 0
bit 21-30:
0000010000 -> always has to be like this
bit 31:
1 -> if this bit is set, then the effective address of the instruction following the branch instruction is placed into the link register.

so you have to load 0x4E800021 into memory

btw. lis and li are also virtual instructions, so as you have to set the LR register, you have to use addis and addi instead

At this rate, you might even know what you're doing by the time the WiiU2 comes out!

Any help is welcome, I think we are all no experts in this.

 

[comex]

For the record, the reason libogc is copyright infringement is not that the hardware or general operation of the SDK was reverse engineered, but that large numbers of individual SDK functions were reverse engineered and translated directly into C.