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

[ Thread Index | Date Index | More Archives ]


I did first implement these options for DSP debugging itself (when I used to code it) and then to help me finding bugs in the DSP (by looking at the exchanges between the 68030 and the DSP). Of course, if someone has another needs, just ask and I'll see what I can do.

Actually, I use the dsp_host_command and the dsp_host_interface commands (nearly never the SSI actually).

Best regards

Le 11/04/2013 21:56, Eero Tamminen a écrit :

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+