(adsbygoogle = window.adsbygoogle || []).push({});

So all i have to do is to search joker/pad address with netcheat then put the adress up on top like: 0 6CC54D12 0100 for circle button then under that code i put my code for like super speed: 0 7DA54718 40000000 and then i just write and it should activate from circle button?

i never use netcheat to put joker codes i put them on eboot bin i only use netcheat for searching codes,but i think the procedure need to be same,lol

I know it's a dead 3 1/2 year old post, but I'm going through things and this is inaccurate. What you describe looks like the PS1, and I didn't check buttons enough on the PS2 but probably that too. Looking at this kind of annoys me. I've done a crap ton of button toggle codes for many games on the PS3. Rarely do they follow that old format seen on those previous 2 consoles. This is more accurate:


1. In rare moments, all 16 buttons are actually in 2 consecutive bytes like back on the PS1/PS2, but you'll never know the button values without checking because every game has different values for them. Just a simple ???? format.
2. Almost the same as the above, except scattered between 4 bytes with zeros between. Always 00??00?? instead.
3. Each button is either 1, 2, 4, or 8 bytes for a value, with that value always being 0 for off, and almost always 1 for on, even though I remember Prototype 1 doing an odd thing with the D-pad directions being 2 for on, and Aliens Vs Predator instead doing value FF for on.
4. The addresses of the buttons can change each time you start a game or reboot a game or whatever. I first noticed that in Singularity, and have been writing button enable codes since just in case because I can't trust memory addresses to always be the same from game to game.
5. If these fail, the buttons are a single precision float value for the sensitivity of how hard you have the button pressed down. 3F800000 is always the button pressed down as hard as possible.


There are also sometimes an extra 4 values that appear with the buttons, like I saw in Prototype 2. Having L3 tilted up or down far enough can create a value of 01, another value for R3 tilted up or down, and then the same for them being tilted far enough left or right. The values were not different based on the directions either. Up and down both gave a value of 01, but odds are there was likely a sensitivity value near them with opposite values like 1 or -1 for floats.

The best approach for buttons is to hold triangle, and do a 1 byte scan for value 01. Let go of triangle, scan for 00. Keep going back and forth until nothing is left but a few results. Once you have few results, try holding square and see if the value changes. If it does not, you are probably dealing with 1 to 8 bytes for each individual button. If you end up with no results, scan for 0x10 hex instead of 0x01, and the usual 00 for no button held. If that fails, then fall back on the other bits of 80, 40, 20, 08, 04, and 02. If those fail, search for a 1-byte non-zero value while holding triangle, and 00 for nothing held. If that fails, hold triangle down hard and search for a float between 0.1 and 1, and likely 0 or at least decreased while not holding triangle depending on if your button is a little messed up. If that fails, I don't know, because these have never failed me before.


If you ever make a button enable code, do the world a favor and output the 16 buttons in the 2 consecutive bytes format to some place in memory like I do, because then people can easily use the "ANDI" operation with it and save themselves from needing to use a crap ton more lines for simple codes requiring buttons. Many operations can check 2 byte values with just 1 line of code. If you output the value as something more than that somewhere for others to use, you're making peoples' lives more difficult than they need to be. Nobody needs 16 buttons scattered across 128 bytes, that's annoying. Convert them. There's a lot of button enable codes I have done that people can learn from to convert to convert anything to the 2 byte format if they need, even though I did a crappier job on some of my earlier games farther back. de Blob 2 is embarrassing for me to look at for the button codes, they were all individual bytes that I was too dumb and lazy to fix back then, along with various other games. But most of the ones I have done in the passed few years have all been converted to the consecutive 2 byte format to make everybody's lives easier if anybody needs to use them. I've converted the 00??00??, the 1 byte per button formats, and the float value ones too. Prototype 2 was the most unusual one I ever made into that format since it had the extra 4 button values, and a 0 button value that I don't know what it was, even though it might have been the PS button for all I know.


Also when making a button enable code, set your breakpoint and actually check the registers as you see the game go through the 16 buttons. In some things that read or write to the address or addresses you found the buttons at, they don't always check every button. It also sometimes sets the values of all buttons to zero for an instant, which is not good if you do the once-per-button-combo-press toggles that I do all the time. That happened to me long ago in Dead Space 2 where my 1st result I couldn't figure out why it randomly worked until I checked my actual code and saw it randomly loaded value zero for the buttons which broke it a bit. There were the ones that also didn't load every button, like Prototype 1 and Aliens Vs Predator getting me good with that long ago where it seemed like certain areas I thought had all buttons maybe only had everything except Start + Select + L3 + R3 or whatever. Always check them to make sure things behave correctly.


I also forgot about 1 game that in unique because it loads multiple sprx files for different purposes, and that's the Okami HD game. The different sprx files have different addresses and stuff for their buttons. If you are scanning for buttons while in the pause menu, that pause menu seems to be part of a different sprx file than what is running while the game is not paused, so you will need to find the buttons for the different files. When you find the buttons, you'll notice the stuff for the pause menu does not update while not in the pause menu, and the stuff from the main game will not update while you are in the pause menu. There are 5 sprx files, but I don't think all of them use buttons. Just main, wolves_kernel, stages, movies, and some other one I forgot along with possibly the EBOOT.BIN itself. Some games have different buttons for different parts.