|Re: [hatari-devel] Most wanted debugger/profiler feature or convenience? (Blitter/LED)|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 12/04/2013 15:52, Eero Tamminen a écrit :
On torstai 11 huhtikuu 2013, Eero Tamminen wrote:
Another useful thing for blitter problems - having the debugger
notice/alert when the blitter HW registers (other than busy bit)
Do you mean changes in any of the registers, or or just the control
Easiest would be to take a copy of the register values when blitter
starts working and checking when blitter stops working whether any
of them had changed. This would of course need to disregard any
regs that change while blitter works:
lines, words, src and dst adress and halftone bits in control register..
Probably best would be to add separate trace level to blitter for
It would be good to have common part in name for these kind of "coding
bug detection" messages, maybe a "_bug" postix?
I.e. trace option name for such blitter messages would be "blitter_bug"
("blitter" is used to enable control register tracing)...
I'm not sure it's easy to choose what kind of blitter access should be
considered as "bug" or not and traced as such in Hatari.
As with the pacemaker example, we see they alter some registers while
blitter is on.
IMO, using --trace blitter already allows to see when blitter
start/stop, and if some registers are accessed in between.
If we want Hatari to report some possible coding bugs / bad practices, I
think it would be better to keep traces in Hatari as they are and feed
the output trace file to another program to do a higher level analysis
(as you do with the python profiler tools for example).