[hatari-devel] DSP debugger

I think the DSP debugger is somehow broken - several times recently I have tried to trace code and found the debugger switching to 68k disasm mode, and then forgetting where the DSP PC was, unable to continue execution.

This seems to happen if the DSP disassembler is asked to disassemble an invalid instruction. e.g.

dd $xxxx

where xxxx = 2nd (data) word of a 2-word instruction

Here is a sample where the program is broken into at a sensible place:

CPU=$35c36, VBL=7717, FrameCycles=72, HBL=0, LineCycles=72, DSP=$153

$035c36 : 67fa beq.s $35c32

> dd pc

DSP disasm 0x153-0x15b:

p:0153 0e2151 (04 cyc) jne p:$0151

p:0154 47f000 004004 (04 cyc) move x:$4004,y1

p:0156 56f000 004003 (04 cyc) move x:$4003,a

p:0158 66f000 004002 (04 cyc) move x:$4002,r6

p:015a 00000c (04 cyc) rts

...and then gather info on the stack...

> info dsp

DSP core information:

- SSH stack: 0000 0000 01fd 020f 0135 00de 03bd 0000 0000 0000 0000 0000 0000 0000 0000 0000

- SSL stack: 0000 0000 0055 8054 8054 8054 8050 0000 0000 0000 0000 0000 0000 0000 0000 0000

- Interrupt IPL: 0003 0003 0003 0003 0003 0002 0002 0002 ffff ffff ffff ffff

- Pending ints: 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000 0000

- Hostport: 00 12 02 0f 00 ff ff ff 00 00 00 06

And then diassemble one of the stack locations...

> dd $3bd

DSP disasm 0x3bd-0x3c5:

p:03bd 56e100 (04 cyc) move x:(r1),a

p:03be 0604a0 (04 cyc) rep #$04

p:03bf 200032 (02 cyc) asl a

p:03c0 565900 (04 cyc) move a,x:(r1)+

p:03c1 4cae00 (02 cyc) move y:$002e,x0

p:03c2 46ec00 (04 cyc) move x:(r4+n4),y0

p:03c3 47ed00 (04 cyc) move x:(r5+n5),y1

p:03c4 20001b (02 cyc) clr b

And then things start to go wrong when we disassemble a bad location, one word back....

> dd $3bc

DSP disasm 0x3bc-0x3c4:

CPU=$35c36, VBL=7717, FrameCycles=72, HBL=0, LineCycles=72, DSP=$3bc

$035c36 : 67fa beq.s $35c32

...showing a 68k disassembly instead of DSP!

But one additional word back from here and the location disassembles correctly again, being a valid instruction:

> dd $3bb

DSP disasm 0x3bb-0x3c3:

p:03bb 060280 0003c0 (06 cyc) do #$0002,p:$03c0

p:03bd 56e100 (04 cyc) move x:(r1),a

p:03be 0604a0 (04 cyc) rep #$04

p:03bf 200032 (02 cyc) asl a

p:03c0 565900 (04 cyc) move a,x:(r1)+

p:03c1 4cae00 (02 cyc) move y:$002e,x0

p:03c2 46ec00 (04 cyc) move x:(r4+n4),y0

Disassemble a few more locations from the stack.....

> dd $1fd

DSP disasm 0x1fd-0x205:

p:01fd 44f400 000100 (04 cyc) move #$000100,x0

p:01ff 5ef000 0005f1 (06 cyc) move y:$05f1,a

p:0201 4cf040 0005f2 (06 cyc) add x0,a y:$05f2,x0

p:0203 200045 (02 cyc) cmp x0,a

p:0204 0af0ab 00020b (06 cyc) jmi p:$020b

> dd $1fb

DSP disasm 0x1fb-0x203:

p:01fb 069f80 000216 (06 cyc) do #$009f,p:$0216

p:01fd 44f400 000100 (04 cyc) move #$000100,x0

p:01ff 5ef000 0005f1 (06 cyc) move y:$05f1,a

p:0201 4cf040 0005f2 (06 cyc) add x0,a y:$05f2,x0

...but having done nothing at all with the machine state, Hatari no longer diassembles the interrupted PC address!

> dd pc

DSP disasm 0x3bc-0x3c4:

CPU=$35c36, VBL=7717, FrameCycles=72, HBL=0, LineCycles=72, DSP=$3bc

$035c36 : 67fa beq.s $35c32

> dd pc

DSP disasm 0x3bc-0x3c4:

CPU=$35c36, VBL=7717, FrameCycles=72, HBL=0, LineCycles=72, DSP=$3bc

$035c36 : 67fa beq.s $35c32

...instead it's trying to disassemble $3bc - the bad opcode encountered a few steps back, and reporting 68k info.

...so we try to trace the original code interrupted....

> ds

p:03bc 0003c0 (00 cyc) dc $0003c0

p:03bd 56e100 (04 cyc) move x:(r1),a

p:03be 0604a0 (04 cyc) rep #$04

p:03bf 200032 (02 cyc) asl a

p:03c0 565900 (04 cyc) move a,x:(r1)+

p:03c1 4cae00 (02 cyc) move y:$002e,x0

p:03c2 46ec00 (04 cyc) move x:(r4+n4),y0

p:03c3 47ed00 (04 cyc) move x:(r5+n5),y1

...and it now executes from $3bc instead of the interrupted PC address!

> dd $3bb

DSP disasm 0x3bb-0x3c3:

p:03bb 060280 0003c0 (06 cyc) do #$0002,p:$03c0

p:03bd 56e100 (04 cyc) move x:(r1),a

p:03be 0604a0 (04 cyc) rep #$04

p:03bf 200032 (02 cyc) asl a

p:03c0 565900 (04 cyc) move a,x:(r1)+

p:03c1 4cae00 (02 cyc) move y:$002e,x0

p:03c2 46ec00 (04 cyc) move x:(r4+n4),y0

The pattern seems to be where you diassemble a bad opcode, then disassemble a good one - the PC seems to magically jump to the bad address without executing anything. Other things may also be happening but this at least is reproducible.

I'm not sure when this problem began - perhaps late in version 1.7. I'm sure it was not present in v1.6 because I used the debugger a lot then and never noticed it. I seem to run into this regularly now - during most debug sessions using v1.8.