> They represent the "Instruction calls" > (aka opcode and operand) as bytes, > a Z80 16 bit jump opcode is represented by C3 > and with an operand of $BEEF we have JP $BEEF > which we be represented by C3 EF BE > (lo/hi byte order on the operand).
I've been doing more work with cheats and the debugger and just wanted to confirm if my understanding is correct. Apologies for my ignorance; I've never really done any assembler coding.
The OPCODE and OPERANDs are machine language functions and parameters (respectively). From what I have seen from existing cheat examples, when making ROM hacks, a ROM address is changed to point to a different OPCODE. This will allow the original OPCODE to be skipped.
A question I have is if the combination of OPCODE and OPERAND (together) create a unique OPCODE? Example, as seen in the debugger window:
---- MOV 1234 DDCC FFEE ----
[Question #1]: Is the OPCODE, "1234" (MOV), along with "DDCC FFEE", always identified as "1234", or can the OPERANDs of "1234" change but still be identified as "1234"?
In other words, is this possible, considering the above example:
---- MOV 1234 CCDD AABB ----
In the case of Mortal Kombat, I've noticed that the OPERANDs proceed the OPCODE in memory.
[Question #2]: Considering question #1, when changing ROM memory to call different signature OPCODEs (different number / types of OPERANDS), do the OPERANDs need to be specified in the call adjustment as well?
It seems in the examples that I've seen, just the OPCODE is specified, without a specifying any new parameters. I guess I'm thinking about this in relation to higher-level programming, such as C++, where calling a different function requires specifying the parameters of the new function. However, if the OPCODE and OPERAND are unique (together), just specifying the OPCODE would then seem to be sufficient.
All of my experience so far in debugging is still in working with the Mortal Kombat (Midway) machine.
Thanks for any insights.
|