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

[ Thread Index | Date Index | More Archives ]


On torstai 11 huhtikuu 2013, Douglas Little wrote:
> Making it deeper can't solve problems where a block is several kwords in
> size and the fault happened near the start, and surfaced near the end.
> Nobody would search through that much history anyway, unless the debugger
> did sanity checks on the history itself (which is another possibility -
> some common faults are detectable)

Note that Hatari has already quite a few options for tracing DSP activity:
$ hatari --trace help 2>&1 | grep dsp

For example for the freezing Stocasto demo:
	--trace dsp_host_interface,dsp_host_command

Will end at this:
Dsp: (Host->DSP): Direct Transfer 0x0006ff
Dsp: (Host->DSP): Dsp HRDF set
Dsp: (Host->DSP): Dsp HRDF cleared
Dsp: (Host->DSP): Direct Transfer 0x000702
Dsp: (Host->DSP): Dsp HRDF set
Dsp: (Host->DSP): Dsp HRDF cleared
Dsp: (Host->DSP): Direct Transfer 0x000705
Dsp: (Host->DSP): Dsp HRDF set
Dsp: (Host->DSP): Dsp HRDF cleared

(Whereas SSI tracing output didn't end and was *much* more verbose.)

Is that enough for what you were looking for, or what kind
of output you were wishing for?

> > How short?  Could it be fixed size (e.g. 20), or does it need to
> > be configurable?
> Good question. I think something like 20 would be enough to be useful.

In that case I guess it could be added to the "info dsp" command
(implemented in falcon/dsp.c) I think, with a small ring buffer.

Laurent, any comments on this?

	- Eero

Mail converted by MHonArc 2.6.19+