Tutorial for creating ASM codes for PS2 with Cheat Engine and pcsx2

[lee4]

its problem with forum attachment settings
attach says max 50mb but upload is max 1.4mb.

[Hacc]

Ah, thanks lee.

Update: See previous post for download.

[47iscool]

Thanks Hacc!

Here is the Breakpoint register for Cheat Engine

4 Byte Hex add this "pcsx2-dbg.exe"+2028FF8

I have tried both, setting a breakpoint using their debugger and setting one on CE gives the same result.

Pyriel, the address their debugger gave me was this when I fired 001200AC, and as you can see it's the same as the one in the action replay.

[lee4]

the plugins came with this build made the emulator run slow,
I copy plugins from older build to made the emulator run at normal speed

[47iscool]

the plugins came with this build made the emulator run slow,
I copy plugins from older build to made the emulator run at normal speed

Thanks lee, I was wondering why it was crawling so bad. Now I'm all set!

[lee4]

I glad someone notice it too

[Hacc]

Heh, I forgot to mention that. Also, use the plugins from the latest SVN (better compatibility or regression (depends on the game)). The non-debug plugins will throw an error in the PCSX2 console (marked in red), so make sure to copy the "w32pthreads.v4.dll" file from the latest SVN, or stable 1.2.1 builds. I expect a flood of ASM hacks now.

[lee4]

Heh, I forgot to mention that. Also, use the plugins from the latest SVN (better compatibility or regression (depends on the game)). The non-debug plugins will throw an error in the PCSX2 console (marked in red), so make sure to copy the "w32pthreads.v4.dll" file from the latest SVN, or stable 1.2.1 builds. I expect a flood of ASM hacks now.

Only Zero plugins will throw an error, I always delete them since 0.9.2 build

I use GSd 0.1.7 (old) and SPU2-X-1.2 (old) without any major game compatibility problems.

normal w32pthreads.v4.dll is not need for this bulid as its use w32pthreads.v4-dbg.dll

Only these two msvcr120d and msvcp120d are mandatory for this build

[Hacc]

Well, I mentioned it because I use the normal SVN build, from which this build is based upon, and I got an error after loading the debug build (SPU2-X, for example). I didn't delete the debug plugins.

[lee4]

in all new pcsx2 (1.0+)

all emu ini and plugins settings are store in your My Documents
(on by default, can be disable it, will store ini and plugins settings in pcsx2 folder instead)

non-debug plugins wont understand debug plugins settings

this why you want to copy non-debug plugins into debugger plugins folder to void this error

[Helder]

So do we delete all the plugins that come with the debugger? and use the ones linked to the thread Lee4 posted? and finally any quick tutorial to get going in ram and more importantly ASM hacking. I've already got all necessary files but haven't gotten a game image to test and wanted to have all the info to move along.

Anyone need those VB files head over here:

http://de.dll-files.com/msvcr120d.dll.html

http://de.dll-files.com/msvcp120d.dll.html

Choose Installen and download the zip file.

[47iscool]

So do we delete all the plugins that come with the debugger? and use the ones linked to the thread Lee4 posted? and finally any quick tutorial to get going in ram and more importantly ASM hacking. I've already got all necessary files but haven't gotten a game image to test and wanted to have all the info to move along.

Anyone need those VB files head over here:

http://de.dll-files.com/msvcr120d.dll.html

http://de.dll-files.com/msvcp120d.dll.html

Choose Installen and download the zip file.

I use cheat engine to get the RAM.

[lee4]

So do we delete all the plugins that come with the debugger? and use the ones linked to the thread Lee4 posted?

only you have problems with debug plugins
you can have both non-debug and debug plugins in plugins folder

[Pyriel]

I have tried both, setting a breakpoint using their debugger and setting one on CE gives the same result.

Pyriel, the address their debugger gave me was this when I fired 001200AC, and as you can see it's the same as the one in the action replay.

I didn't think to look that far down in that same subroutine. 0x001200AC looks right, but it's not very close to what you came up with in the first post (0x00120008). I don't know what you mean by "the same as the one in the action replay". You mean an official code we haven't discussed before now?

I suspect what you did in the first post is cause the game to leave rubbish on the stack, and by happenstance that resulted in an erroneous state which bypassed the logic that updates the ammo quantity. It still doesn't answer the question of how the VEH debugger presented you with a disassembly that seems unrelated to the executing code, and it seems to have either halted well before the emulator was in a state to have performed that write, or it provides you with state information that's several cycles behind or ahead of the actual state. That you get different results with a different build of the emulator doesn't explain anything.

[47iscool]

Google this: 201200AC 00000000

Also when I said their debugger I meant the one built into the emulator.