B-Em Debugging/Tracing

want to talk about MESS/model b/beebem/b-em/electrem/elkulator? do it here!
User avatar
fordp
Posts: 860
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England

Re: B-Em Debugging/Tracing

Postby fordp » Wed Mar 15, 2017 12:37 pm

Hi I have never seen a function/method name inside brackets in a declaration like that, what purpose does that serve (apart from confusing me ;) )
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

User avatar
hoglet
Posts: 6280
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: B-Em Debugging/Tracing

Postby hoglet » Wed Mar 15, 2017 2:48 pm

fordp wrote:Hi I have never seen a function/method name inside brackets in a declaration like that, what purpose does that serve (apart from confusing me ;) )

It's defining a function pointer as a member of a struct.

Do you know of a simpler syntax?

Dave

User avatar
fordp
Posts: 860
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England

Re: B-Em Debugging/Tracing

Postby fordp » Wed Mar 15, 2017 3:00 pm

Thanks Dave,

I have rarely used function pointers in c and never as a member of struct.

My c tends to be pretty simply static stuff and for anything more advanced I would use c++.

I guess this is similar to a pure virtual in c++.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

User avatar
ctr
Posts: 92
Joined: Wed Jul 16, 2014 2:53 pm

Re: B-Em Debugging/Tracing

Postby ctr » Wed Mar 15, 2017 3:57 pm

Coeus wrote:is there a way to describe paged access that doesn't become dependent on the particular CPU in question?


I was thinking about this a couple of weeks ago while trying to understand the B+ and Master memory architectures.

The architecture is usually described in terms of the various bits of RAM (HAZEL and so on) and where they map to in memory. The implementation in BeebEm follows this and it is rather confusing.

I find it easier to think in terms of the physical RAM. This gives a concrete identity to each of the memory regions. For example, HAZEL isn't just 8K of RAM which sometimes gets mapped at &C000, it is the physical 8K of memory starting at &9000.

The implementation in B-Em resembles this and as a result is less confusing (to me anyway) though it still keeps RAM, ROM and the OS in separate address spaces. One could go further.

The idea is to assign an imaginary (but predefined) physical memory address to each of the pieces of addressable memory in a beeb.

For example, a Master:

00000 6502 virtual address space
10000 32K normal RAM
18000 4K ANDY (&8000-&8FFF) &FE30 bit 7
19000 8K HAZEL (&C000-&DFFF) &FE34 bit 3
1B000 20K LYNNE (&3000-&7FFF) &FE34 bits 0, 1 and 2
20000 Sideways ROM 0
...
2C000 Sideways ROM 3
30000 Sideways RAM 4
...
3C000 Sideways RAM 7
40000 Sideways ROM 8
...
5C000 Sideways ROM 15
60000 OS
64000

Then the emulator would act like a memory management unit (MMU). When the 6502 made a read or a write the emulator would translate this into one of the "physical" addresses and do the read/write there.

(N.B. In some configurations a write to 8000-BFFF always goes to the sideways RAM, regardless of which ROM is selected. So the address translation would sometimes need to distinguish reads from writes. And hardware access remains a special case.)

Once this is done the emulator can communicate physical addresses to the debugger (alongside the usual virtual addresses) so the debugger can easily set breakpoints (code or data) that apply to only one region of memory or read and modify memory that is currently paged out.

The debugger would need some knowledge of the memory architecture to present a nice UI over this, but the emulator/debugger interface doesn't need to know about it.

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em Debugging/Tracing

Postby Coeus » Wed Mar 15, 2017 4:26 pm

fordp wrote:Thanks Dave,

I have rarely used function pointers in c and never as a member of struct.

My c tends to be pretty simply static stuff and for anything more advanced I would use c++.

I guess this is similar to a pure virtual in c++.


Absolutely. As an interesting aside, one of my first contributions to B-Em was to fix a bug in one of the 6502 instructions that affected the BCPL ROM. Imagine my surprise when I found it was not fixed in the 6502 tube processor because that was a complely separate copy of the code, though obviously derived from the same place, hence the same bug.

At that time I thought it would be good to restructure it. C++ relationships and inheritence would seem like a logical fit so for example:

main 6502 is a 6502 and an I/O processor.
tube 6502 is a 6502 and a tube processor.
a 6502 can be an NMOS variant or a CMOS variant (common base class)
Z80 is tube processor.

etc.

It would be a lot of work, though, to restructure in that way and do away with the various global variables that get written to from various places and subsitute proper access methods.

So, yes, this is a poor mans pure virtual methods - each CPU (class) has to provide an implementation of a set of standard functions. In Java-speak this would be an interface - we have defined an interface which a CPU must implement.

User avatar
hoglet
Posts: 6280
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: B-Em Debugging/Tracing

Postby hoglet » Wed Mar 15, 2017 4:40 pm

Steve,

I've just hit another interesting gap.

When a memory read / write breakpoint is hit I want to have the debugger show the address of the instruction that caused the breakpoint.

We could I guess extend debug_memread/debug_memwrite to include an instruction address, but I'm concerned about the performance implications of doing this (to support the rare case that a breakpoint is actually hit).

Instead, I would prefer to retrieve it from the cpu_debug_t.

At first I thought this just amounted to reading the program counter register, but actually in most processors the program counter is incremented as the instruction is fetched and decoded.

What I'm thinking is that the cpu_debug_t interface needs one extra method, get_instr_addr(), that returns the address of the currently executing instruction.

What do you think about adding this?

Edit: Here's my header file with it included:
https://github.com/hoglet67/PiTubeDirec ... pu_debug.h

Dave

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em Debugging/Tracing

Postby Coeus » Wed Mar 15, 2017 6:36 pm

That's fine by me.

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em Debugging/Tracing

Postby Coeus » Fri Mar 17, 2017 8:57 am

I now have debugging working on the core (I/O) 6502, the Tuibe 6502 and the Tube Z80. The version of B-Em with these available is at https://github.com/stardot/b-em/tree/sf/debugging

I haven't tried compiling this with MingW yet, though.

I was going to open an issue to track this but then I couldn't decide whether to have one issue for tube processor debugging which would be closed when the this branch is finally merged, or one per processor so it is easier to see progress being made.

User avatar
hoglet
Posts: 6280
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: B-Em Debugging/Tracing

Postby hoglet » Fri Mar 17, 2017 12:36 pm

Hi Steve,
Coeus wrote:I now have debugging working on the core (I/O) 6502, the Tuibe 6502 and the Tube Z80. The version of B-Em with these available is at https://github.com/stardot/b-em/tree/sf/debugging

I just tried building this on Linux, and it seems some files are missing:

Code: Select all

$ make
Making all in src
make[1]: Entering directory `/home/dmb/atom/b-em/src'
 cd .. && /bin/bash /home/dmb/atom/b-em/etc/missing automake-1.14 --foreign src/Makefile
 cd .. && /bin/bash ./config.status src/Makefile depfiles
config.status: creating src/Makefile
config.status: executing depfiles commands
make[1]: Leaving directory `/home/dmb/atom/b-em/src'
make[1]: Entering directory `/home/dmb/atom/b-em/src'
  CC       b_em-6502.o
In file included from 6502.c:7:0:
6502.h:4:23: fatal error: 6502debug.h: No such file or directory
 #include "6502debug.h"
                       ^
compilation terminated.
make[1]: *** [b_em-6502.o] Error 1
make[1]: Leaving directory `/home/dmb/atom/b-em/src'
make: *** [all-recursive] Error 1

Dave

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em Debugging/Tracing

Postby Coeus » Fri Mar 17, 2017 1:08 pm

Oops!

I have added the missing files and pushed to GitHub (same branch).

User avatar
hoglet
Posts: 6280
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: B-Em Debugging/Tracing

Postby hoglet » Fri Mar 17, 2017 1:21 pm

Coeus wrote:I have added the missing files and pushed to GitHub (same branch).

Great, that builds now. And it even seems to work!

Dave

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em Debugging/Tracing

Postby Coeus » Fri Mar 17, 2017 1:39 pm

hoglet wrote:Great, that builds now. And it even seems to work!Dave


You make it sound like I didn't do any testing. Obviously one test I didn't do it to check out a fresh copy from git and check that it builds.

Assuming you don't find any bugs there are a couple of possible next steps, one of which is to tackle another virgin processor, and there are 65816 and X86 to go as far as I can see, the other is to integrate your work on the 32016. I have the SD card interface and MMFS to play with and hopefully get a hardware Music 500 working so if it helps for me to leave this for a little while for you to do the 32016 that could work out well.

User avatar
hoglet
Posts: 6280
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: B-Em Debugging/Tracing

Postby hoglet » Fri Mar 17, 2017 1:47 pm

Coeus wrote:You make it sound like I didn't do any testing. Obviously one test I didn't do it to check out a fresh copy from git and check that it builds.

That was my weak attempt at humour. :oops:
Coeus wrote:Assuming you don't find any bugs there are a couple of possible next steps, one of which is to tackle another virgin processor, and there are 65816 and X86 to go as far as I can see, the other is to integrate your work on the 32016.

I was going to have a go with the 32016 over the weekend.

I'm sure this will show some minor environment differences.
Coeus wrote:I have the SD card interface and MMFS to play with and hopefully get a hardware Music 500 working so if it helps for me to leave this for a little while for you to do the 32016 that could work out well.

Good luck with that.

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em Debugging/Tracing

Postby Coeus » Fri Mar 17, 2017 2:05 pm

hoglet wrote:
Coeus wrote:That was my weak attempt at humour. :oops:


No, I did chuckle when I read it. Perhaps my response was too serious. I need to check out the smilies.

I'll be interested to hear how you get on.

User avatar
hoglet
Posts: 6280
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: B-Em Debugging/Tracing

Postby hoglet » Fri Mar 17, 2017 5:55 pm

Hi Steve,
Coeus wrote:I'll be interested to hear how you get on.

I gave this a try this afternoon. It went pretty well I think. On Linux all everything is working fine:

Code: Select all

$ ./b-em -debug

Debuggable CPUSs are as follows:
  1: core6502
  2: tube6502
  3: Z80
  4: 32016


On Windows B-Em starts and you can use the Co Processors, but the debugger just gives you a blank screen.

Is that expected at this stage?

I've create a pull request for your sf/debugging branch.
https://github.com/stardot/b-em/pull/25

This also fixes the Windows Makefile and one compilation issue in debugger.c on Windows

Dave

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em Debugging/Tracing

Postby Coeus » Fri Mar 17, 2017 6:36 pm

hoglet wrote:On Windows B-Em starts and you can use the Co Processors, but the debugger just gives you a blank screen.


It looks like I have inadvertently broken it, then. I'll have a look a bit later and work out what the Windows code is doing. I think it is just providing a means of accessing the command line debugger as the stdio streams don't work on Windows. I'll take a look a bit later.

User avatar
hoglet
Posts: 6280
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: B-Em Debugging/Tracing

Postby hoglet » Fri Mar 17, 2017 7:07 pm

Coeus wrote:It looks like I have inadvertently broken it, then. I'll have a look a bit later and work out what the Windows code is doing. I think it is just providing a means of accessing the command line debugger as the stdio streams don't work on Windows. I'll take a look a bit later.

I think the problem in Windows is just that none of the CPUs have their debug_enable set by default, and there is currently no way in the UI to select the CPU to debug.

It seems debugger_do() is only entered as a result of a debug callback from a CPU.

This is slightly different to how it works in PiTubeDirect, where the debugger can be used even if the CPU is free running.

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em Debugging/Tracing

Postby Coeus » Sun Mar 19, 2017 10:54 pm

I did some reading with a view to implementing this for the 65816. As it is an enhanced 6502 with many of the same opcodes I thought it could be a quick win by adding a third pair of decoding table and an extra address mode or two to the existing 6502 disassembler. I have hit an interesting thing, though, in that for some instructions the address mode used and, for some modes, the number of operand bytes following the opcode, depends on the setting of some flags in the flag register, i.e. this is how 16 but inatructions work instead of having a parallel set of opcodes.

That need not be an issue when tracing, including the one line disassembly presented at a beakpoint and while single-stepping, but does present a challenge when disassembling an arbitrary block of memory as the disassembler can't work out what the state of those flags would be when that code is executed.

User avatar
fordp
Posts: 860
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England

Re: B-Em Debugging/Tracing

Postby fordp » Mon Mar 20, 2017 9:50 pm

Coeus wrote:I have hit an interesting thing, though, in that for some instructions the address mode used and, for some modes, the number of operand bytes following the op-code, depends on the setting of some flags in the flag register, i.e. this is how 16 but instructions work instead of having a parallel set of op-codes.

This is always somewhat of an issue as even the ARM2 where all instructions are word aligned can go wrong when you treat data as if it is instructions.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em Debugging/Tracing

Postby Coeus » Sat Mar 25, 2017 3:28 pm

I have added support for debugging the 65816 in the sf/debugging branch. It isn't that well tested at the moment but I am following the puibish early thing. I also haven't checked it compiles on Windows yet. I may do that later today if I have time.

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em Debugging/Tracing

Postby Coeus » Sun Mar 26, 2017 11:03 am

fordp wrote:This is always somewhat of an issue as even the ARM2 where all instructions are word aligned can go wrong when you treat data as if it is instructions.


Yes, it's common to find a disassembler gets out of sync if it starts disassembling code and then continues on into data, like embedded strings or a jump table etc. In the usual case that is because the opcode, whether that is a byte or a word, encodes information on how many operand bytes or words are needed for the addressing mode being used. This is where one of those inteligent disaasemblers can help - one that follows the branch, jump and call instructions so it can tell which regions are code and which are data.

In the case of the 65816 the issue is slighly different in that the same opcode can be followed by a varying number of operands bytes and the information needed to work out how many bytes to consume is not to be found in the opcode but in the state of the processor flags registers, i.e. a run-time characteristic, not something inherent in the code being disassembled.

Usually, when disassembling a suboutine is it sufficient to specify the correct start address for the subroutine and the disassembler will remain in-sync. For the 65816 the disassembler would also need to know whether the subroutine was intended to be called with the M or X flags set or clear.

So in the debugger I have addressed this by making the disassembler examine the starte of these flags. That means when single stepping or tracing it should do the right thing. On the other hand if you ask it to disassemble some other address, even if it is valid code, if it was designed to be executed with the flags in a different state it still may get out of sync. I think that is the best we can do.

So further to my last message the latest version of the debugging branch as pushed to github, which includes debugging for the 65816, does compile and run on Windows.

So, there are two processors to go, 80186 and ARM.

User avatar
fordp
Posts: 860
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England

Re: B-Em Debugging/Tracing

Postby fordp » Sun Mar 26, 2017 11:16 am

I used a trick to help on the 32016. We had performance counters tracking how often 32016 instructions were called. This can be used to track where the code is. It has the weakness of only disassembling instructions that have been hit, but is a useful tool however.

It may be an idea to add this feature to all emulated cores. It cannot work on the native core while running native of course!
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

User avatar
hoglet
Posts: 6280
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: B-Em Debugging/Tracing

Postby hoglet » Sun Mar 26, 2017 12:26 pm

Coeus wrote:So, there are two processors to go, 80186 and ARM.

I've done both of those now for PiTubeDirect - feel free to leverage what you can:
https://github.com/hoglet67/PiTubeDirec ... 86_debug.c
https://github.com/hoglet67/PiTubeDirec ... rm_debug.c

I don't think they will just work, because I think B-Em uses different cores.

Dave

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em Debugging/Tracing

Postby Coeus » Sun Mar 26, 2017 2:44 pm

hoglet wrote:I've done both of those now for PiTubeDirect - feel free to leverage what you can:
https://github.com/hoglet67/PiTubeDirec ... 86_debug.c
https://github.com/hoglet67/PiTubeDirec ... rm_debug.c


Dave, thanks for those. I think these will be a big help not least because it saves tracking down a disassembler for each of these two processors. I did search for one for 80186 and didn't get any useful results - some written in 8086 assembler, once written in C#, nothing usable in C so I was at the point of having to guess at other projects that might embed one or write one.

I have thought of another couple of things in connection with the debugger and in particular entering the debugger for something other than a breakpoint.

Return From a Subroutine

Debuggers often have the feature to either execute a subroutine call as if it were a single instruction (while single-stepping) or having entered a subroutine, continue until it returns to the caller and then stop. I think to implement that CPUs would need to call the debugger when a return instruction is executed. I was initially wondering about an extra argument to the prexec call but thinking about how a CPU might implement this it may be better to use a seperate call. That means the CPU implementation can either make a specific test for a return instruction when alreading in a:

Code: Select all

if (debug_enabled)
    debug_preexec(&cpu, pc);


so that becomes:

Code: Select all

opcode = memread(pc);
if (debug_enabled) {
    debug_preexec(&cpu, pc);
    if (opcode == RTS)
        debug_return(&cpu, pc);
}


or if that is not easy, for example because there are a list of return instructions and it is easier to hook later on into the implementation of one or more of the return instructions that can be more easily done with a separate call for example:

Code: Select all

if (debug_enabled)
    debug_preexec(&cpu, pc);
opcode = memread(pc);
switch(opcode)
{
...
    case RTS:
        if (debug_enabled)
            debug_return(&cpu, pc);
        pc = *sp++;
        break;
...
}


What do you reckon?

Other CPU-Specific Reasons/Traps

I am thinking here that before I started changing things the 6502 would stop in the debugger when it executed the BRK instruction, i.e. when an error is about to be processed. I am sure there may be other CPU-specific cases where it may be good to enter the debugger, for example invalid opcode/invalid memory access/privilege violoation, before these are handed off to the OS to deal with. As the list of possible reasons would vary from one processor to another I am wondering about just passing a string, so for example:

Code: Select all

void debug_trap(cpu_debug_t *cpu, const char *reason);


That assumes we don't want't a way to selectively enable/disable these. It does have the advantage that the CPU can construct the reason string dynamically if that would convey useful information. Alternatively we could add another null-terminated list of strings to cpu_debug_t, for example trap_names, and then the CPU would call a function of the form:

Code: Select all

void debug_trap(cpu_debug_t *cpu, int reason);


where reason would be an index into that list. In theory that means the debugger could mainain the state of these and offer to enable/disable them. I am not sure how often people would want to disable such traps, though. What do you think?

User avatar
hoglet
Posts: 6280
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: B-Em Debugging/Tracing

Postby hoglet » Sun Mar 26, 2017 3:03 pm

Coeus wrote:Dave, thanks for those. I think these will be a big help not least because it saves tracking down a disassembler for each of these two processors. I did search for one for 80186 and didn't get any useful results - some written in 8086 assembler, once written in C#, nothing usable in C so I was at the point of having to guess at other projects that might embed one or write one.

A couple of further things to note.

I ended up extending cpu_debug_t with methods for IO accesses:
https://github.com/hoglet67/PiTubeDirec ... pu_debug.h

You might want to replicate that on B-Em.

I also wondered whether we needed to do anything to better deal with the 80x86's segmented addresses. In the end, I just converted them to physical addresses and used those. I did wonder whether to make use of the full 32 bits of address to hold <segment> <offset> but then it seemed to get complicated.

Coeus wrote:Return From a Subroutine
...
What do you reckon?

I see several possible problems with this:
- keeping track of nested RTSs
- handling cases where a subroutine returns without using RTS (e.g. the typical print-embedded-string code)

Did you consider just using the existing breakpoint mechanism and have the debugger set a "transient" breakpoint on the next instruction?

Coeus wrote:Other CPU-Specific Reasons/Traps
...
What do you think

I think support for this would be nice.

The 6502 might then have BRK, IRQ and NMI traps.

I prefer an integer reason, and then in cpu_debug_t an array of human readable strings describing these. That way you can build a UI that allows for selective enable/disable.

Dave

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em Debugging/Tracing

Postby Coeus » Sun Mar 26, 2017 3:24 pm

hoglet wrote:I ended up extending cpu_debug_t with methods for IO accesses:
https://github.com/hoglet67/PiTubeDirec ... pu_debug.h

You might want to replicate that on B-Em.


That seems like a good idea.

hoglet wrote:I also wondered whether we needed to do anything to better deal with the 80x86's segmented addresses. In the end, I just converted them to physical addresses and used those. I did wonder whether to make use of the full 32 bits of address to hold <segment> <offset> but then it seemed to get complicated.


Yes that complication is a nuisance. Perhaps, as a concession, the parser for address input can accept the 8086 syntax and convert to a physical address. Not sure what to do the other way as each physcal address can have multiple segmented representions. I haven't really tried using it yet so it is hard to say how this will work from a usability standpoint. If someone says "break 4000" does he mean physical address 4000 or 4000 relative to CS?

Return From a Subroutine
...
What do you reckon?
hoglet wrote:I see several possible problems with this:
- keeping track of nested RTSs
- handling cases where a subroutine returns without using RTS (e.g. the typical print-embedded-string code)


Ok, this is more complicated than I thought.

hoglet wrote:Did you consider just using the existing breakpoint mechanism and have the debugger set a "transient" breakpoint on the next instruction?


The problem with that is that the debugger doesn't know how long the JSR/CALL instruction is so it can't calculate the next address. It could always play safe, I suppose, and set a temporary breakpoint for a small number of subsequent addresses. Alternatively we'd need a way for the debugger to know the next address.

hoglet wrote:I think support for this would be nice.

The 6502 might then have BRK, IRQ and NMI traps.

I prefer an integer reason, and then in cpu_debug_t an array of human readable strings describing these. That way you can build a UI that allows for selective enable/disable.


That way is fine by me.

User avatar
hoglet
Posts: 6280
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: B-Em Debugging/Tracing

Postby hoglet » Sun Mar 26, 2017 5:29 pm

Coeus wrote:[
The problem with that is that the debugger doesn't know how long the JSR/CALL instruction is so it can't calculate the next address. It could always play safe, I suppose, and set a temporary breakpoint for a small number of subsequent addresses. Alternatively we'd need a way for the debugger to know the next address.

Can't it use the disassembler API to find that out?

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em Debugging/Tracing

Postby Coeus » Sun Mar 26, 2017 9:00 pm

hoglet wrote:Can't it use the disassembler API to find that out?


Of course! In fact it actually calls the disassembler as it enters the debugger but discards the new address in this case - that was intended so the assembler could be called repeatedly for a group of lines but, of course, it will be useful here too.

Coeus
Posts: 407
Joined: Mon Jul 25, 2016 11:05 am

Re: B-Em Debugging/Tracing

Postby Coeus » Sun Mar 26, 2017 9:57 pm

Ok, this feature is now in the B-Em debugger - the 'n' command sets a transient breakpoint for the following instruction and then continues. When the next instruction is a subroutine this has the effect of executing the subroutine and then returning to the debugger.

The BRK trap on the 6502 is also back.

https://github.com/stardot/b-em/tree/sf/debugging

Lastest cpu_debug: https://github.com/stardot/b-em/blob/sf ... pu_debug.h - I added an address argument to debug_trap so it can run the disassembler on the trapping instruction.

User avatar
hoglet
Posts: 6280
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol

Re: B-Em Debugging/Tracing

Postby hoglet » Mon Mar 27, 2017 7:10 am

Nice work Steve.

I'll do the same in the PiTubeDirect debugger.


Return to “emulators”

Who is online

Users browsing this forum: No registered users and 3 guests