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

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

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 "fdc.tr" or 
"blitter.cr".

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 :)

Nicolas