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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On lauantai 13 huhtikuu 2013, Nicolas Pomarède wrote:
> 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)

Ok, so it's a generic problem. :-/


> 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.

That would be a large number of extra symbols for virtual variables
to the debugger, quite a bit of code too.


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

Yeah, I just need to document them before release. :)


	- Eero