|
|
Hi:
I'm running MAME0148 on Vector Linux. Everything is built and working fine but I'm trying to understand some parts of the debugger and cheat system. I've been working with Mortal Kombat [mk] mainly and I have been successful in hacking a couple simple things like health and credits.
I have a general debugger question and a couple cheat-system questions. Sorry for noobishness.
[Debugger Question]
I've attached a screenshot in regards to my debugger question. If you can't see the photo, the areas I'm referencing are:
-----------
Debugger Window Frame #1: Registers area
Debugger Window Frame #2: Instruction calls area
Debugger Window Frame #3: Top-right frame right of Instruction calls area
Debugger Window Frame #4: Debugger command input/output..
-----------
My understanding is that section #1 is the register list. Section #2 is the instruction call. Not entirely sure on what #3 is supposed to be? #4 is just the input/output window for the debugger.
In regards to areas #1-#3, is there a place to get a really good break-down / documentation for these? I'd like to get a thorough explanation of how the registers work (#1) and what their acronyms stand for. Area #2 seems straight forward, much like a debugger call stack but with instruction codes. I have no clue what I'm looking at when I see area #3. Looks like hex codes related to the instruction calls in area #2.
Any info would be greatly appreciated.
[Cheats Question]
I would have posted these on Pugsy's forum but new accounts cannot be created right now:
http://www.mamecheat.co.uk/forums/ucp.php?mode=register
(Creating a new account is currently not possible.)
Here's an example MK cheat portion that relates to my question (new cheat system - chars <> are changed to []):
Code:
[cheat desc="CPU always finishes with a Fatality"]
[script state="run"]
[action]maincpu.mw@00B5D08=0300[/action] [!-- FFDAE840 --]
[/script]
[/cheat]
Question 1: how does "FFDAE840" relate to "00B5D08"? I can set a breakpoint at "FFDAE840" and the debugger stops and the cheat works. However, I don't understand how instruction "FFDAE840" relates to "00B5D08". Is "00B5D08" a rom address (since this is a ROM cheat)?
Question 2: is there a way to force an instruction call using the cheat system? For example: I want to mimic an input press (such as a low-punch button), so I want to find the originating (very first) instruction call outside of mame and have the cheat system force that call when a condition occurs during a fight.
Thanks!
[ATTACHED IMAGE]
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: MAME0148 Debugger & Cheats Question
[Re: BlackGreen]
#311386 - 07/11/13 08:30 PM
|
|
|
> In regards to areas #1-#3, is there a place to get a really good break-down /
> documentation for these? I'd like to get a thorough explanation of how the registers
> work (#1) and what their acronyms stand for. Area #2 seems straight forward, much
> like a debugger call stack but with instruction codes. I have no clue what I'm
> looking at when I see area #3. Looks like hex codes related to the instruction calls
> in area #2.
Regarding the registers and instructions, these of course vary by the specific processor being emulated. For many CPUs emulated by MAME, you can pretty easily bury yourself in relevant documentation with a some light Google usage.
|
|
|
|
Re: MAME0148 Debugger & Cheats Question
[Re: R. Belmont]
#311391 - 07/11/13 08:45 PM
|
|
|
> > In regards to areas #1-#3, is there a place to get a really good break-down /
> > documentation for these? I'd like to get a thorough explanation of how the
> registers
> > work (#1) and what their acronyms stand for. Area #2 seems straight forward, much
> > like a debugger call stack but with instruction codes. I have no clue what I'm
> > looking at when I see area #3. Looks like hex codes related to the instruction
> calls
> > in area #2.
>
> Regarding the registers and instructions, these of course vary by the specific
> processor being emulated. For many CPUs emulated by MAME, you can pretty easily bury
> yourself in relevant documentation with a some light Google usage.
Thanks Belmont.
Edited by BlackGreen (07/11/13 09:43 PM)
|
|
|
| Pugsy |
|
Cheat Collection Maintainer
|
|
|
|
|
|
Reged: 05/06/04
|
|
Posts: 48
|
|
|
|
|
|
Send PM
|
|
|
Re: MAME0148 Debugger & Cheats Question
[Re: BlackGreen]
#311395 - 07/11/13 09:30 PM
|
|
|
> Debugger Window Frame #3: Top-right frame right of Instruction calls area
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).
> [Cheats Question]
> I would have posted these on Pugsy's forum but new accounts cannot be created right
> now:
It's back on for a few days at least (spambot registrations...)
> Question 1: how does "FFDAE840" relate to "00B5D08"? I can set a breakpoint at
> "FFDAE840" and the debugger stops and the cheat works. However, I don't understand
> how instruction "FFDAE840" relates to "00B5D08". Is "00B5D08" a rom address (since
> this is a ROM cheat)?
The simple formula for this is:
FF800000 + ( 00B5D08 * 8 ) = FFDAE840
That works for all ROM addresses
> Question 2: is there a way to force an instruction call using the cheat system? For
> example: I want to mimic an input press (such as a low-punch button), so I want to
> find the originating (very first) instruction call outside of mame and have the cheat
> system force that call when a condition occurs during a fight.
This may help:
http://www.mamecheat.co.uk/forums/viewtopic.php?f=16&t=2945#p11110
EDIT: That URL may not be what you want, but it's a similar principle
Edited by Pugsy (07/11/13 09:50 PM)
|
|
|
|
Re: MAME0148 Debugger & Cheats Question
[Re: Pugsy]
#311396 - 07/11/13 09:38 PM
|
|
|
I love you Pugsy. Thanks much.
|
|
|
| AWJ |
|
|
|
|
|
|
|
Reged: 03/08/05
|
|
Posts: 936
|
|
Loc: Ottawa, Ontario
|
|
|
|
Send PM
|
|
|
Re: MAME0148 Debugger & Cheats Question
[Re: Pugsy]
#311398 - 07/11/13 10:30 PM
|
|
|
> > Debugger Window Frame #3: Top-right frame right of Instruction calls area
>
> 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).
>
> > [Cheats Question]
> > I would have posted these on Pugsy's forum but new accounts cannot be created right
> > now:
>
> It's back on for a few days at least (spambot registrations...)
>
>
> > Question 1: how does "FFDAE840" relate to "00B5D08"? I can set a breakpoint at
> > "FFDAE840" and the debugger stops and the cheat works. However, I don't understand
> > how instruction "FFDAE840" relates to "00B5D08". Is "00B5D08" a rom address (since
> > this is a ROM cheat)?
>
> The simple formula for this is:
> FF800000 + ( 00B5D08 * 8 ) = FFDAE840
> That works for all ROM addresses
Note that this formula only applies to Midway hardware using the TMS34010 CPU. The relation between ROM addresses and CPU addresses is different between CPU types and hardware, and the TMS34010 is particularly weird as it addresses individual bits rather than bytes--that's where the "times 8" comes from.
Look at the ADDRESS_MAP macro in the source code for the MAME driver of the game you're debugging to see where ROM, RAM and input ports are.
If you're completely new to debugging using MAME, I strongly advise that you start with a game that uses a Z80 or 68000 as the main CPU (and preferably one without encryption or bankswitching, so not CPS2 or NeoGeo. CPS1 is OK.) Machine code for these CPUs is relatively easy to read and there is a ton of documentation since both CPUs were used in popular home computers.
|
|
|
|
Re: MAME0148 Debugger & Cheats Question
[Re: AWJ]
#311400 - 07/11/13 11:22 PM
|
|
|
> > > Debugger Window Frame #3: Top-right frame right of Instruction calls area
> >
> > 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).
> >
> > > [Cheats Question]
> > > I would have posted these on Pugsy's forum but new accounts cannot be created
> right
> > > now:
> >
> > It's back on for a few days at least (spambot registrations...)
> >
> >
> > > Question 1: how does "FFDAE840" relate to "00B5D08"? I can set a breakpoint at
> > > "FFDAE840" and the debugger stops and the cheat works. However, I don't
> understand
> > > how instruction "FFDAE840" relates to "00B5D08". Is "00B5D08" a rom address
> (since
> > > this is a ROM cheat)?
> >
> > The simple formula for this is:
> > FF800000 + ( 00B5D08 * 8 ) = FFDAE840
> > That works for all ROM addresses
>
> Note that this formula only applies to Midway hardware using the TMS34010 CPU. The
> relation between ROM addresses and CPU addresses is different between CPU types and
> hardware, and the TMS34010 is particularly weird as it addresses individual bits
> rather than bytes--that's where the "times 8" comes from.
>
> Look at the ADDRESS_MAP macro in the source code for the MAME driver of the game
> you're debugging to see where ROM, RAM and input ports are.
>
> If you're completely new to debugging using MAME, I strongly advise that you start
> with a game that uses a Z80 or 68000 as the main CPU (and preferably one without
> encryption or bankswitching, so not CPS2 or NeoGeo. CPS1 is OK.) Machine code for
> these CPUs is relatively easy to read and there is a ton of documentation since both
> CPUs were used in popular home computers.
Thanks AWJ.
I did see somewhere (MAME cheats forum I think) that Midway machines had a tendency to be a pain in the ass. For some reason I always tend to find my way to the hard road  . Always good learning experiences, though.
|
|
|
|
Re: MAME0148 Debugger & Cheats Question
[Re: Pugsy]
#315317 - 10/03/13 07:08 PM
|
|
|
> 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.
|
|
|
|
Re: MAME0148 Debugger & Cheats Question
[Re: BlackGreen]
#315663 - 10/10/13 10:36 PM
|
|
|
|
|
|
Re: MAME0148 Debugger & Cheats Question
[Re: BlackGreen]
#315665 - 10/10/13 11:18 PM
|
|
|
Seriously, you'll need to read an assembly language tutorial for the CPU your targetting. Google is your friend.
|
|
|
|
Re: MAME0148 Debugger & Cheats Question
[Re: BlackGreen]
#346233 - 10/24/15 02:16 AM
|
|
|
Hi guys
i have an issue on my jamma mk board that uses tms34010
apparently there is no horizontal sync and screen goes white ,does anyone have been abble to dump the tms content,as far as i know is a programmable graphic ic ,and i don´t know how i am going to solve this problem :/
Best REgards
JOSÉ
|
|
|
Index 
Threaded 
MAME0148 Debugger & Cheats Question
Reply
[Re: 
. Always good learning experiences, though.
