WHAT IS THE EASIEST WAY TO MAKE A TRAINER WITH GAMESHARK OR PAR CODES FOR PS1?

I don't know if it helps in your case, but I looked at value changes in the memory of PCSX2 with cheat engine to find the one I had to change.
With save states before and after the variable changed for sure, I could eventually find out, what had to be the correct variable.
Most PS1 emulators probably also emulate the memory layout the PS1, so it probably works on a real PS1 as well.
In the case of PCSX2 there were two forum posts that explained how the cheat file is formatted with possible value types and how you react to button presses with conditions.
If you want to do something more complex with the PS1 cheat I don't know if this helps though.

 

Trainer as in hardcoded cheats?

Do we need to have a menu for this? Do the cheats need to be able to be toggled?

I did see a somewhat automated tool for patching in N64 cheats the other month (generally as you go back in time the less overhead you have for this sort of thing, and usually more complicated the automated methods become) so I could see something more automated happening here. I don't know if someone has though.

You do have the manual approach and while it will see you have to learn something it will not see you have to become a full bore hacker to do it.

Two main approaches.

1) Edit the instruction handling it*.
2) Replicate the cheat approach and add a little routine to constantly (or maybe only when buttons are pressed) write a value and effectively give you infinite whatever. Game consoles will typically have what is called a vblank routine so that usually makes a good point to hook and add some code to constantly write things.

*if you have a cheat already made, or make one as they are usually easy enough to make, you will know where the value is located in memory. You tell the emulator to stop and tell you what is going on when something reads or writes that area (it is a feature of debugging emulators called breakpoints). It will do that and you look back up to see what is going on to get there. For infinite ammo it will probably run [user presses fire weapon], read ammo counter, does it have enough ammo, do they need to reload, do fire routine, subtract whatever from ammo counter, write ammo count back to memory location. Change a relevant instruction there (you could make the subtract thing irrelevant by skipping the instruction with a NOP**, you could change subtract to an add, you could force a given value to be written instead of whatever it generates, you could make sure the ammo count check does not care what it comes back with and always fires instead...).

**NOP is short for No Operation. Some CPUs will have a dedicated instruction, some assemblers will also have one for you, others will see you have to make an instruction that essentially does nothing (typically something like mov r1, r1 which will copy the contents of r1 to r1 and thus achieve nothing other than some wasted time, which can be useful in and of itself but I will skip that discussion for the time being as it is of limited use for most cheat purposes. You would tend to want to use a NOP rather than deleting things as deleting things shifts everything forward by however much you have deleted and if it has locations hardcoded elsewhere it means they land in places they did not expect.

Both approaches have their upsides and downsides. The big ones being 1) might see many things do the same end result -- the classic thought experiment being losing a life in mario. Time, enemies, stage hazards, pits, poison mushrooms in later games, possibly being crushed, maybe falling... each of those is unlikely to defer back to something to subtract a life when it is easier to do it for each of those. Edit just one and you sort just one and still have all the others. Some are OK with that -- if you can jump in a pit any time you like to gain a life then you effectively have infinite lives. Others find such things troubling.
2) Tends not to be as immediate. My main example here is gamesharks/action replay for Goldeneye on the N64. With the in game invincibility you were just that. If you did it the classic way with a cheat search of lose some life, search, lose some life, search... to find the life location and set that full at all points then explosions could cause so much damage that the gameshark did not always manage to write it back to full before the game decided you were dead.

Button activators are easier than menus before the game launches, mainly as you have to code up a menu as well. You would probably do something like 2) to always be watching the controller state. When the combo comes up you set a piece of memory somewhere that is not used for anything else (or you don't care as it does not trouble things) to a given value, and then it might disable it if it sees the same or another combo. The cheat for styles 1) or 2) then checks this location and if it sees the cheat is "on" it will do what it does, and if not then it will go as normal. For style 2) this would mean adding extra code where a lot of things can be done in place as it were for the basic style where this needs to look at another area, compare it, branch if necessary, do what needs doing and then go back to what it was doing before.