http://gamehacking.org/faqs/hackv500c.html - cheat code formats
http://doc.kodewerx.org/hacking_psx.html - cheat code formats
http://gamehacking.org/wiki/Code_Types_(Playstation) - cheat code formats
This is what I got together so far:
PSX Xplorer/Xploder Code Format
The second code digit (t) contains encryption type (bit0-2), and a "default
Code: Select all
3taaaaaa 00dd ;-8bit write [aaaaaa]=dd 8taaaaaa dddd ;-16bit write [aaaaaa]=dddd 00aaaaaa dddd ;-32bit write [aaaaaa]=0000dddd <-- not "0taaaaaa dddd" ? 4t000000 000x ;-Slow Motion (delay "x" whatever/ns,us,ms,frames?) 7taaaaaa dddd ;-IF [aaaaaa]=dddd then <execute following code> 9taaaaaa dddd ;-IF [aaaaaa]<>dddd then <execute following code> Ftaaaaaa dddd ;-IF [aaaaaa]=dddd then activate "other selected" codes (uh?) 5taaaaaa ?nnn ; d0d1d2d3 d4d5 ; write "?nnn" bytes to [aaaaaa] ;ordered d0,d1,d2... ? d6d7d8.. .... ;/ 6t000000 nnnn ;\COP0 hardware breakpoint aaaaaaaa cccc ; aaaaaaaa=break_address, mmmmmmmm=break_mask mmmmmmmm d0d1 ; nnnn=num_bytes (d0,d1,d2,etc.), cccc=break_type (see below) d2d3d4.. .... ;/ B?nnbbbb eeee ;\Slide/Patch Code, with unclear end: "end=?nn+/-1" ? 10aaaaaa dddd ;/for i=0 to end, [aaaaaa+(i*bbbb)]=dddd+(i*eeee), next i C0aaaaaa dddd ;-garbage/mirror of 70aaaaaa dddd ? ;\or maybe meant to be D0aaaaaa dddd ;-garbage/mirror of 70aaaaaa dddd ? ;/same as on GameShark?
on/off" flag (bit3: 0=on, 1=off; whatever that means, it does probably require
WHATEVER actions to enable codes that are "off"; maybe via the Ftaaaaaa dddd
break_type (cccc) (aka MSBs of cop0r7 DCIC register)
E180 (instruction gotton by CPU but not yet implemented) (uh, gotton what?)
EE80 (data to be read or written) ;<--looks okay
E680 (data to be read) ;<--looks okay
EA80 (data to be wrtten) ;<--looks okay
EF80 (instruction) ;<-- looks crap, should be probably E180
The CPU supports one data breakpoint and one instruction breakpoint (though unknown if the Xplorer does support to use both simultaneously, or if it does allow only one of them to be used).
If the break_type/address/mask to match up with CPU's memory access actions... then "something" does probably happen (maybe executing a sub-function that consists of the d0,d1,d2,etc-bytes, if so, maybe at a fixed/unknown memory address, or maybe at some random address; which would require relocatable code).
The "gotton by CPU but not yet implemented" part might be a translation error, ie. it does probably mean "fetched but not yet executed"?
The size of number of bytes parameter ("?nnn") is unclear, some docs say "0nnn" (12bit), others "nnnn" (16bit). Some doc suggests that the bytes are copied directly to the debug vector address at 80000040h, if that's true then "?nnn" should be max 40h (else it'd destroy the IRQ vector at 80000080h), or best max 20h (for not destroying the kernel variables at 80000060h).
The "Slide" code shall be used only with even addresses, unknown if other 16bit/32bit codes do also require aligned addresses.
32bit write code
According to existing docs this can write only unsigned numbers (?) and there are at least two docs mentioning that the 32bit write code doesn't support the code disable flag (bit3 of the "t" digit), though I don't know why it shouldn't be supported, unless bit3 is used for some other purpose... such like (maybe) as sign-flag?
Would be great if somebody could clarify some details!