Re: [hatari-devel] Most wanted debugger/profiler feature or convenience? (Blitter/LED)

[ Thread Index | Date Index | More Archives ]

On 13/04/2013 20:48, Eero Tamminen wrote:
How one knows when blitter has finished its activity?

If it's not already there, we can add a log for that.

Another problem is breakpoints not working for this (because busy bit
clearing isn't updated to blitter control register until emulated code
either reads or writes it).

Yes, the internal register of most components (status register in FDC, ACIA, MFP, blitter, ...) is not available to the debugger until it's read/written (accessed bu the cpu)

Copying it to the corresponding IO area is not necessarily a way to solve this, because some IO addresses are shared by several internal registers.

For example, in the FDC you can read track number, status register or data register from the same IO address, depending on what you wrote in the "select reg" (same for the YM2149)

So, the only clean way I see to handle this in a modular way would be that each component provides some access functions to read its internal register, some names for each register as well as a callback function when such register are changed (to call the debugger / breakpoints main function for example).

In that case, we could use a syntax like "mfp.ipra" or "" or "".

This way, we would get "hardware breakpoint" that could be mixed with cpu breakpoints.

But as it's a rather big change to many components, I'd rather look at this after next Hatari release. There's already enough news in the debugger to keep people busy until release n+2 is made :)


Mail converted by MHonArc 2.6.19+