|Re: [hatari-devel] Most wanted debugger/profiler feature or convenience? (Blitter/LED)|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel 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
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
This way, we would get "hardware breakpoint" that could be mixed with
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 :)