|
Debugging 6809 RAM writes with MAME debugger (Robotron 2084)
#325860 - 05/12/14 10:27 AM
|
|
|
In one of the games I'm studying, Robotron 2084, there are writes to addresses $8B.
$8B can map to the screen *AND* RAM underneath. But it's the RAM copy I want, as that is an important variable that controls some of the grunts behaviour.
I don't know how to access the contents of this byte via the MAME memory inspector. I type in $008B and what I read is not the same as what the register that just read that location says it should be.
I've selected program memory, sound memory etc.... not getting any joy.
Any ideas?
If you want to see this for yourself, put a breakpoint on $3A7D (in the Blue label Robotron) and try and read the byte value.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: Debugging 6809 RAM writes with MAME debugger (Robotron 2084)
[Re: tunstals]
#325865 - 05/12/14 04:58 PM
|
|
|
> I've selected program memory, sound memory etc.... not getting any joy.
For Robotron, this is the relevant source line:
Code:
AM_RANGE(0x0000, 0x8fff) AM_READ_BANK("bank1") AM_WRITEONLY AM_SHARE("videoram")
So you need to find "bank1" in the drop-down listing all the viewable memory regions. It'll be near the end, prefixed with the driver name.
|
|
|
|
Re: Debugging 6809 RAM writes with MAME debugger (Robotron 2084)
[Re: R. Belmont]
#325868 - 05/12/14 05:38 PM
|
|
|
Thanks for replying.
I forgot - I'll need to check what the DP register is set to, lest it not be stored in the zero page.
Robotron2084 isn't easy to follow. The 6809 is a beast 
6502, Z80 or 80x86 code is much easier to read IMHO...
|
|
|
|
Re: Debugging 6809 RAM writes with MAME debugger (Robotron 2084)
[Re: tunstals]
#325946 - 05/15/14 01:04 PM
|
|
|
DP was set to $98 which means that the writes were taking place to $988B.
Loving the 6809 architecture, really elegant, not to mention advanced for the time.
One more question I have: is there a better debugger for MAME than the inbuilt one? I'd really like to be able to view the call stack, for one thing.
|
|
|
|
Re: Debugging 6809 RAM writes with MAME debugger (Robotron 2084)
[Re: tunstals]
#325950 - 05/15/14 07:14 PM
|
|
|
> One more question I have: is there a better debugger for MAME than the inbuilt one?
> I'd really like to be able to view the call stack, for one thing.
No & if we could do that, why do you think we'd not include it in the default one?
You can't really use the actual stack, because the stack is also used for storing variables & you can't differentiate them. So you'd have to keep a separate list of calls and try to guess when to remove entries.
You then have problems if you have a multitasking OS that is swapping stacks.
|
|
|
|
Re: Debugging 6809 RAM writes with MAME debugger (Robotron 2084)
[Re: ]
#325953 - 05/15/14 10:21 PM
|
|
|
> > One more question I have: is there a better debugger for MAME than the inbuilt one?
> > I'd really like to be able to view the call stack, for one thing.
>
> No & if we could do that, why do you think we'd not include it in the default one?
>
> You can't really use the actual stack, because the stack is also used for storing
> variables & you can't differentiate them. So you'd have to keep a separate list of
> calls and try to guess when to remove entries.
>
> You then have problems if you have a multitasking OS that is swapping stacks.
It's possible to attepmt a stack crawl on systems with frame pointers or backlinks.
|
|
|
|
Re: Debugging 6809 RAM writes with MAME debugger (Robotron 2084)
[Re: Vas Crabb]
#325958 - 05/16/14 01:51 PM
|
|
|
So are you trying to say that all BSR and JSR calls can't be intercepted by the MAME 6809 emulator and their text equivalent pushed onto a list control? e.g.
if (opcode == BSR)
log('BSR ' + ToHex(destination)
if (opcode == JSR)
log('JSR ' + ToHex(destination)
etc etc. (PS pseudocode is in C# not C++ of MAME.)
Looks straightforward to me. I'd try to write something like that if I could get MAME to compile properly 
That's all I'd require, but that's not in the debugger.
It must be possible to trace the call stack. Absolutely. With an emulator you have full control of the tiny 64K address space, I see no reason that this isn't feasible.
Edited by tunstals (05/16/14 02:25 PM)
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: Debugging 6809 RAM writes with MAME debugger (Robotron 2084)
[Re: tunstals]
#325959 - 05/16/14 08:11 PM
|
|
|
Getting a higher-level view of code paths is something you can do really well with IDA Pro, and most serious devs have a copy handy. You can get the older 5.0 version for free. It's not the latest/greatest, but 6809 support isn't exactly a recent addition.
|
|
|
|
Re: Debugging 6809 RAM writes with MAME debugger (Robotron 2084)
[Re: tunstals]
#325961 - 05/16/14 11:15 PM
|
|
|
> So are you trying to say that all BSR and JSR calls can't be intercepted by the MAME
> 6809 emulator and their text equivalent pushed onto a list control? e.g.
Sure you can, but that isn't anything like what a call stack is.
You'd need to prune the list when you rts, taking into account that your rts might be on a different stack than the last JSR or the address might have been pushed onto the cpu stack as an indirect jump.
(forgive me it's 6502 as it's the assembly I wrote the most)
JSR myroutine
RTS
:myroutine
LDA #$d0
PHA
LDA #$c0
PHA
RTS
Some cpu's can move the stack pointer for multitasking, others can just copy the whole stack somewhere and restore it. When you do that the call stack is going to be even more messed up.
|
|
|
|
Re: Debugging 6809 RAM writes with MAME debugger (Robotron 2084)
[Re: tunstals]
#325964 - 05/17/14 03:42 AM
|
|
|
> So are you trying to say that all BSR and JSR calls can't be intercepted by the MAME
> 6809 emulator and their text equivalent pushed onto a list control? e.g.
No, what I'm saying is that if you want to see a call stack you really need to know the ABI and take advantage of that.
For example on most PowerPC ABIs you can look at R1 and from that you can find previous R1/LR and follow the chain. However this isn't actually a hardware thing, it's just an ABI convention. You need to follow it on a multi-tasking OS or all hell will break loose on the first context switch, but you can implement a completely different ABI if you want to. You can't really identify calls from instruction sequences - there's no need to actually use the BL instruction, and you can do things like transform one function's frame into another to implement a tail call for example. It's very flexible.
Register window architectures like SPARC and HyperStone need strict rules concerning stack use in order for the supervisor to implement window overflow/underflow interrupts. Any* non-leaf function will have to roll the window and fill in the frame register correctly (*functions that only make tail calls are an exception).
Similarly, 68k operating systems typically use A6 as a frame pointer, so you can follow A6/A7 links to get a call stack. 68k is a quite a bit less flexible than PowerPC, so you're guaranteed to know that call instructions will push the return address onto the A7 stack, but you can still omit the frame pointer in optimised code if you track how much crap you push/pop. The sc6/sc7 commands in MacsBug follow A6/A7 links to guess the call stack; if you had much experience using it you'd remember getting completely meaningless results when an application was doing something unusual.
Some chips like PIC16x and Saturn have a hardware stack that you can walk, but it usually has so few levels that people simulate calls in other ways to avoid overflow (on HP-48/HP-49 you only have four stack levels available, and two of them are needed for the OS/interrupts, leaving you with two for your application). So walking the hardware stack won't tell you much on these systems.
The upshot is, if you want this functionality you'd need to implement something like sc6/sc7 MacsBug commands for the system you're working with. Fire up System 7 in MESS (ArBee's done a great job with this) and screw around in MacsBug to get a feel for what it does, what its limitations are, and how you could implement a similar command in the MAME debugger. But intercepting call instructions is definitely not a viable alternative.
|
|
|
|
Re: Debugging 6809 RAM writes with MAME debugger (Robotron 2084)
[Re: Vas Crabb]
#325970 - 05/17/14 11:54 AM
|
|
|
> But intercepting call instructions is definitely not a viable
> alternative.
I think you could do something with it, but even a naïve implementation would be a lot of work for something that worked only in specific cases.
We have "step over" functionality which might be usable for it, at least it would show how poorly that works too.
Edited by smf (05/17/14 11:56 AM)
|
|
|
|
Re: Debugging 6809 RAM writes with MAME debugger (Robotron 2084)
[Re: R. Belmont]
#325972 - 05/17/14 04:12 PM
|
|
|
|
|
|
Re: Debugging 6809 RAM writes with MAME debugger (Robotron 2084)
[Re: tunstals]
#325990 - 05/18/14 04:48 AM
|
|
|
R. Belmont already suggested this, but I also want to recommend IDA Pro + emulator debugger as a great combination to study what the program is actually doing.
Unfortunately, I believe that the free version only will disassemble x86 (last I checked) so I recently (earlier this year) shelled out something like $600 for the "starter" version which is way more than I need but after getting over the initial price pain, I am quite pleased to have it in my toolkit.
|
|
|
|
Re: Debugging 6809 RAM writes with MAME debugger (Robotron 2084)
[Re: R. Belmont]
#325993 - 05/18/14 05:31 AM
|
|
|
As others have said, the free version only does x86 and is therefore no good for MAME work really.
|
|
|
|
Re: Debugging 6809 RAM writes with MAME debugger (Robotron 2084)
[Re: ]
#325995 - 05/18/14 12:55 PM
|
|
|
> > So are you trying to say that all BSR and JSR calls can't be intercepted by the
> MAME
> > 6809 emulator and their text equivalent pushed onto a list control? e.g.
>
> Sure you can, but that isn't anything like what a call stack is.
>
> You'd need to prune the list when you rts, taking into account that your rts might be
> on a different stack than the last JSR or the address might have been pushed onto the
> cpu stack as an indirect jump.
>
> (forgive me it's 6502 as it's the assembly I wrote the most)
>
> JSR myroutine
> RTS
>
> :myroutine
> LDA #$d0
> PHA
> LDA #$c0
> PHA
> RTS
>
> Some cpu's can move the stack pointer for multitasking, others can just copy the
> whole stack somewhere and restore it. When you do that the call stack is going to be
> even more messed up.
No, it's not a true call stack but it's a list of calls in a LIFO order, is that better
I would like the last 10 or so JSR and BSR to be logged somewhere. I would like to click on an entry on the log and go back to the relevant line of assembly .
I don't care about when RTS is hit, I just want to have a quick look of the subroutine being called, see if I recognise what it does, and if not quickly go back to the JSR and step over it.
Right now, I have to put a breakpoint on the RTS, run to that, but sometimes that's not really what I'm after, especially if PC is changed by something unexpected.
Right now I'm reverse engineering Robotron 2084, there are a lot of indirections, many JSRs that call JMP instructions, and these are quite hard to keep track of UNLESS I step through the function in its entirety and return to the caller that way.
|
|
|
|
Re: Debugging 6809 RAM writes with MAME debugger (Robotron 2084)
[Re: R. Belmont]
#325996 - 05/18/14 12:58 PM
|
|
|
> Getting a higher-level view of code paths is something you can do really well with
> IDA Pro, and most serious devs have a copy handy. You can get the older 5.0 version
> for free. It's not the latest/greatest, but 6809 support isn't exactly a recent
> addition.
I am a serious dev (I work as a software engineer) but don't have a copy. What does that make me?
Seriously though, thanks for the link - I've played around with IDA before a few years ago with x86 code, not really sure I'd need it for Robotron. I can get by with the MAME debugger, it just takes longer to do some things than I like.
|
|
|
|
Re: Debugging 6809 RAM writes with MAME debugger (Robotron 2084)
[Re: tunstals]
#325999 - 05/18/14 03:38 PM
|
|
|
> I don't care about when RTS is hit, I just want to have a quick look of the
> subroutine being called, see if I recognise what it does, and if not quickly go back
> to the JSR and step over it.
That will be fine until a subroutine calls another one and you want to bail out two levels as you'll be back to where you are now, the LIFO list will be littered with dead addresses that the first subroutine called.
|
|
|
| R. Belmont |
|
Cuckoo for IGAvania
|
|
|
|
|
|
Reged: 09/21/03
|
|
Posts: 9716
|
|
Loc: ECV-197 The Orville
|
|
|
|
Send PM
|
|
|
Re: Debugging 6809 RAM writes with MAME debugger (Robotron 2084)
[Re: The_Hamster]
#326034 - 05/19/14 05:42 PM
|
|
|
> I would think you would need ida handy when using the mame debugger.
Yeah, the two compliment each other very nicely. Things you discover stepping in MAME can be applied to making labels for functions and such in IDA, and IDA's ability to show the overall structure means you can figure out exactly where you want to place breakpoints in MAME.
|
|
|
Index 
Threaded 
Debugging 6809 RAM writes with MAME debugger (Robotron 2084)
Reply
[Re: 
