Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Using CE Pointers in PNACH format
#1
This is my first time using a forum, so if this question is already answered, though I swear I have thoroughly searched, please let me know.

I have discovered some pointers using Cheat Engine and would like to type them up in PNACH format. I've researched code writing all over Google but can't find an answer to this one.

An example of what I am trying to do is:

Use Pointer (20662570), with Offset (200002CC)

in a PNACH file with PCSX2, instead of having to use Cheat Engine.

Any advice ?

Thanks in Advance.
Reply

Sponsored links

#2
The offset is always relative to the beginning of the data area, still the first digit is used as code type identifier by pnach (which changes it to 2 before actual memory poke).

So, if you are to write a byte type value, it should be 0, 1 for short value and 2 to word (always use "extended", the old token usage is deprecated now).

Other kind of codes are possible but you'll need to research it if willing to employ them.

Ex: in your example above, if was to write a byte it should be:
patch=1,ee,000002CC,extended,000000xx (where xx is the actual byte value to be writen in the offset).

Edit: Is being assumed your offset calculation is correct, of course.
Imagination is where we are truly real
Reply
#3
(06-05-2014, 04:39 AM)nosisab Ken Keleh Wrote: The offset is always relative to the beginning of the data area, still the first digit is used as code type identifier by pnach (which changes it to 2 before actual memory poke).

So, if you are to write a byte type value, it should be 0, 1 for short value and 2 to word (always use "extended", the old token usage is deprecated now).

Other kind of codes are possible but you'll need to research it if willing to employ them.

Ex: in your example above, if was to write a byte it should be:
patch=1,ee,000002CC,extended,000000xx (where xx is the actual byte value to be writen in the offset).

Edit: Is being assumed your offset calculation is correct, of course.

Thanks for the prompt reply. Everything there makes sense with my prior experience with PNACH; however, in the example you converted for me, the address of the pointer isn't included at all...so is there a line of code I'd need to include above the offset and its value?

ie patch=1,ee,20662570,extended,????????

patch=1,ee,000002CC,extended,000000xx
Reply
#4
bad idea. the patch is a shot into the bios.

what's the offset actually doing? you wanna write that to that address? then it's

patch=1,EE,00662570,extended,000002CC

if the offset is an actualy OFFSET from that address you gotta add it to the address. then it's

patch=1,EE,0066283C,extended,XXXXXXXX to write whatever value you want in there.
Reply
#5
There are type 6 commands for pointer, and pcsx2 supports them, but I don't understand well. Smile

Here are the commands. (The original website cannot access recently)

[attachment=51002]


Edit: Also, there is a source code of a pnach implementation of pcsx2.
http://pcsx2.net/download/releases/source-code.html
pcsx2/Patch_Memory.cpp
Reply
#6
(06-05-2014, 05:38 AM)tadatada Wrote: There are type 6 commands for pointer, and pcsx2 supports them, but I don't understand well. Smile

Here are the commands. (The original website cannot access recently)




Edit: Also, there is a source code of a pnach implementation of pcsx2.
http://pcsx2.net/download/releases/source-code.html
pcsx2/Patch_Memory.cpp

Excellent! Thanks tadatada, that framework for my existing addresses and offsets worked perfectly! Brilliant, that's exactly the kinda table I've been looking for. Don't know why it was so damn hard to find. Thanks to everyone else who pitched in also.
Reply
#7
Just a comment to let it clear about the lengths to be placed in the address. In the case of:

patch=1,EE,00662570,extended,000002CC

the value is clearly a short (at least), by that code only the final "CC" would be placed there, a byte dictated by the first 0 at the address, so the code should be:

patch=1,EE,10662570,extended,000002CC - (notice the four first leading zeroes are left out).

Or even

patch=1,EE,20662570,extended,000002CC if the value is actually the length of "word", which means the whole 000002CC would be pushed into the memory, including the leading zeroes.

These are usage example, not to be taken as actual codes.

Edit: This is important, in the first case the value would be plain wrong, in the third situation, case the value was actually a "short", treating it as "word" would force the leading zeroes, possibly erasing meaningful adjacent data.
Imagination is where we are truly real
Reply
#8
(06-05-2014, 07:15 AM)nosisab Ken Keleh Wrote: Just a comment to let it clear about the lengths to be placed in the address. In the case of:

patch=1,EE,00662570,extended,000002CC

the value is clearly a short (at least), by that code only the final "CC" would be placed there, a byte dictated by the first 0 at the address, so the code should be:

patch=1,EE,10662570,extended,000002CC - (notice the four first leading zeroes are left out).

Or even

patch=1,EE,20662570,extended,000002CC if the value is actually the length of "word", which means the whole 000002CC would be pushed into the memory, including the leading zeroes.

These are usage example, not to be taken as actual codes.

Edit: This is important, in the first case the value would be plain wrong, in the third situation, case the value was actually a "short", treating it as "word" would force the leading zeroes, possibly erasing meaningful adjacent data.

Thanks for this reminder about code length, but the Offset is actually 200002CC; from my original post. I don't know why you are removing the leading 2 there, because the Offset will not function correctly without it. Therefore, it is the correct code length because the leading 2 must be considered.
Reply
#9
(06-05-2014, 07:42 AM)Twinburnersol Wrote: Thanks for this reminder about code length, but the Offset is actually 200002CC; from my original post. I don't know why you are removing the leading 2 there, because the Offset will not function correctly without it. Therefore, it is the correct code length because the leading 2 must be considered.

Indeed, that was what I understood from the first post, the reply used Dabore's example (which could actually be a valid code).

It's meant to tell that using 0 as first digit that would lose the 02 from 02CC, because only the byte "CC" would make it. Well, is not that I'm removing the 02, pnach would do it because is being told to push only a "byte" and not a short or a word.

------------------------------
Edit: I misunderstood your point. You are right that the actual offset starts with that 2 in it. Just that pnach, like many other cheat engines use that first digit as the code descriptor of type, so it has nothing to do with the actual address or offset. Pnach will care to place the 2 there for "extended" does not matter if the code starts with 0, 1, 2... or any other code type.

actually, in the first digit: 0 -> byte; 1 -> short (two bytes); 2 -> word (four bytes)... any other digit there implies special codes, like length extenders or conditionals, they are commonly followed by one or more complementary lines.
Imagination is where we are truly real
Reply
#10
ohh wtf. the 2 in front is irrelevant. on the ps2 it's just a bit to read uncached from memory. but that operand size totally ruins the idea to help to patch. oops. Laugh now for fixing my advice.

obsolete my ass @nosi. the operand sizes for simple patch writes are still "byte", "short", "word", "double", from 8 to 64 bit writes as noticeable here... and the code is actually faster to patch then running thru the extended routine.
Reply




Users browsing this thread: 1 Guest(s)