Some months ago I had to upgrade my Debian machine which no longer allows me to run Legacy PyiiASMH for cheat code assembling. PyiiASMH3 won't work on my machine at all so I'm left with power-eabi-as (barebones engine you can get from Devkit or GCC), WiiRDGUI, or CodeWrite. Thus I use Codewrite on my machine.
Codewrite does this odd thing of adding arbitrary data to the end of a code if said code contains paired single instructions. For example, let's say we have a code with this 1 instruction in its source
Codewrite will assemble this as...
As you can see there's a bunch of appended junk after "1000001A".
However this is *NOT* the bug I am talking about. Yes the junk data being appended is a bug too, but we can simply remove it and alter the byte amount at the top right word (C2 line count) and the code will work fine. In fact, I knew about this junk data issue a long time ago, just never cared to report it because it's so obvious.
The bug here is the assembled word for the ps_res instruction.
ps_res uses a mask of 0x10000030. Thus, regardless of what FPRs you use in the instruction, it's impossible for the result to end in 1A or 1-anything.
This bug also effects ps_res(.). The record dot is enclosed in parenthesis for easy visual notice.
Open up Codewrite and assemble the following source.
These 2 instructions should assemble as 0x10000030 and 0x10000031 respectively. However, they don't.
What's causing this? Here are the possible reasons (1 or both are true)
Will this bug effect you?
Simply no, afaik there are zero Wii Gecko Codes (in ANY game) that use the ps_res instruction.
Does Codewrite botch any other instructions?
Nope, I've tested all other (yes all...) Broadway PPC instructions. Zero issues.
Codewrite does this odd thing of adding arbitrary data to the end of a code if said code contains paired single instructions. For example, let's say we have a code with this 1 instruction in its source
Code:
ps_res f0, f0Codewrite will assemble this as...
Code:
C2000000 00000004
1000001A 00000008
00000004 00000002
41505569 6E666F00
00420001 00000000As you can see there's a bunch of appended junk after "1000001A".
However this is *NOT* the bug I am talking about. Yes the junk data being appended is a bug too, but we can simply remove it and alter the byte amount at the top right word (C2 line count) and the code will work fine. In fact, I knew about this junk data issue a long time ago, just never cared to report it because it's so obvious.
The bug here is the assembled word for the ps_res instruction.
ps_res uses a mask of 0x10000030. Thus, regardless of what FPRs you use in the instruction, it's impossible for the result to end in 1A or 1-anything.
This bug also effects ps_res(.). The record dot is enclosed in parenthesis for easy visual notice.
Open up Codewrite and assemble the following source.
Code:
ps_res f0, f0
ps_res. f0, f0These 2 instructions should assemble as 0x10000030 and 0x10000031 respectively. However, they don't.
What's causing this? Here are the possible reasons (1 or both are true)
- Codewrite uses an outdated/bugged version of the powerpc-eabi-as engine thats included with it
- Codewrite application itself is modifying the assembled instruction sometime after the engine was executed for whatever reason
Will this bug effect you?
Simply no, afaik there are zero Wii Gecko Codes (in ANY game) that use the ps_res instruction.
Does Codewrite botch any other instructions?
Nope, I've tested all other (yes all...) Broadway PPC instructions. Zero issues.