The change from 0x7FFFFF to 0x01FFFFFF should also be applied to line 501 of
ActionReplay.cpp as well.

Actually it looks like it needs to be applied EVERYWHERE in ActionReplay.cpp.

I'll post my own ActionReplay.cpp with all the changes once I'm finished fixing other
code types.

Here it is: http://dl.dropbox.com/u/733696/ActionReplay.cpp

are you sure about the signed casts in Subtype_AddCode(u32 addr, u32 data)?

just asking because things like this don't really make sense:
{{{
u32 repeat = (u16)((data & 0xFFFF0000) >> 16);
for (int i = 0; i <= repeat; i++) {
Memory::Write_U16(data & 0xFFFF, new_addr + i * 2);
}}}

Oops, that should be casted to u32 if anything.

Here's the description of the zcode RAM Fill and Slide,where fields are described as
signed:
00000000 80000000
000000vv xxyyzzzz

vv: Byte to write for fill\slide, beginning at address 80000000
xx: Value increment (signed)
yy: Number of bytes to write, zero-based
zzzz: Address increment (signed)

Here's a modified version with less pointless casting plus warning fixes.
http://dl.dropbox.com/u/733696/ActionReplay.cpp

ok here is a patch file (the nice way to share changes)
I took out some unneeded stuff:
u32 thing = (data & 0xffff0000) >> 16
is the same as
u32 thing = data >> 16

also, x << 1 is the same as x * 2

let me know if the changes in this patch should be committed

Oh, thanks.

some codes use a 0x80FFFFFF according to the AR doc.

Using 0x80FFFFFF makes the code an unsigned increment for address 0x80FFFFFF.

Also, the action replay codes included with dolphin (More notably in SMS and Z:WW)
are wrong. They were probably modified to compensate for the lack of correctness in
AR.cpp

that's pretty funny ^_^
any chance you can attach corrected ini files?
dolphin can use encrypted AR codes; probably we should include the original encrypted
codes instead of unencrypted, possibly modified ones.

I'm sure someone else will tend to it. I'm working on some other things right now.

which files specifically? (GMSP01, GMSE01, GZLE01, GZLP01)
just so you know, the ones in the /Data/User/GameConfig dir on svn are the originals,
and they are copied to /Binary//User/GameConfig when dolphin is built. Then, if
the file is accessed, the encrypted codes may be written back unencrypted (tbh, i
forget the conditions which trigger write-back, but nowadays it might just happen from
launching the game).

The first fix in the issue wasn't fixed:

Line 119 and 120 of ARCodeAddEdit.cpp should be¶

u32 addr = strtoul(pieces[0].c_str(), NULL, 16);
u32 value = strtoul(pieces[1].c_str(), NULL, 16);

The original code with "strtol" was converting the values of the code to a
signed integer, rounding it to 7FFFFFFF. "strtoul" fixes this.

indeed. it should have been in your patch :)