[hatari-devel] Conditional breakpoints for DSP

[Eero Tamminen]

Hi,

On Friday 19 June 2009, Laurent Sallafranque wrote:
> >>> The .w means nothing in DSP, as you always access to DSP memory
> >>> (internal or external) in word size (24 bits).

I just added DSP memory support to the conditional breakpoints.  Please test
whether the DSP breakpoints work now fine (and memory dumping & register
setting in the debugger still work fine too).  Except maybe for syntax, it
should be now "feature complete".

For example following triggers when the "Papa was a Bladerunner" demo starts
the rotozoomer screen:
===============
> db ($33).x = $001be0
DSP condition breakpoint 1 added.
> c
Returning to emulation...
------------------------------

M68000 Bus Error at address $ff8e21.
M68000 Bus Error at address $ff8c01.
Breakpoint '( $33 ) . x = $001be0' matched.
===============

(I.e. value at X:0x33 is or changes to 0x1be0)


> > Why when writing to R* & N* registers in the DSP_Disasm_SetRegister()
> > function you limited writes to 16-bits in dsp.c?  Because the offset
> > cannot be larger (although dsp_core struct uses Uint32 for this and
> > other registers except PC)?
> > For some registers you used even bitmasks that have holes...?
>
> No, in DSP, memory and registers are 2 completly different things.
>
> 1) Memory
>
> Memory is 32Ko word sized. (a dsp word is always 24 bits).
> Memory goes from $0 to $FFFF (Yes, I know it's 64 Ko, let me explain).
>
> DSP contains 3 internal RAM
>
> X internal RAM : 0 -> FF
> Y internal RAM : 0 -> FF
> P internal RAM : 0 -> 1FF
>
> DSP also contains 2 internal ROMS
> X internal ROM : FF -> 1FF
> Y internal ROM : FF -> 1FF

This is bit strange, why the code for checking for ROM accesses uses
also this:
              if (dsp_core.registers[DSP_REG_OMR] & (1<<DSP_OMR_DE)) {
?

Does additionally some specific bit need to be set to when accessing ROM?


> DSP contains 2 peripheral datas area
> X peripheral : FFC0 -> FFFF
> Y peripheral : FFC0 -> FFFF
>
> DSP contains also a 32K external ram
>
> P memory is mapped on the 32 K of this ram (the upper 32K addresses are
> identical to the lower 32 K) (it's a 32k shadow memory)
>
> Y memory is a 16K area and is mapped from 0 to 3fff in P memory
> X memory is a 16K area and is mapped from 4000 to 7fff in P memory.
>
> So, if you write to address x:300, x:4300, x:8300, x:c300, p:4300,
> p:c300, you write to the exactly same addresses. The same for y memory.
> But if you write to x:0 (internal DSP Ram), or x:4000 (external RAM),
> these are 2 different rams.
>
> 2) Registers
>
> Registers are not in memory, they're not used to access to memory except
> R0-R7 registers.
>
> A and B are 2 56 bits registers.
> A is composed of A2 (8 bits), A1 (24 bits) and A0 (24 bits).
> B is composed of B2 (8 bits), B1 (24 bits) and B0 (24 bits).
>
> X and Y are two 48 bits registers.
>
> X is composed of X1 (24 bits) and X0 (24 bits).
> Y is composed of Y1 (24 bits) and Y0 (24 bits).
>
> R0-R7 are 16 bits registers
> N0-N7 are 16 bits registers
> M0-M7 are 16 bits registers
>
> LA and LC are 16 bits registers.

What are the (6-bits?) SP and the (16-bits?) SSH & SSL registers?

(they seem to be related to stack handling)


> SR register is used to keep the state of the DSP (carry bit, overflow
> bit, ...) This register contains holes (not all the bits are used to
> keep informations, the unused bits must be 0).

Ok, the mask for this in dsp.c is:
	1110111111111111
	1234567812345678

But I'm wondering also about the OMR register:
	01011111
	12345678

What's this and why its mask has holes?


> A move x:(R6) reads the value of register R6 (a 16 bits value), then
> reads at address (R6) in x memory the 24 bits value.
>
> R0-R7 are 16 bits registers because DSP memory is ranged from $0 to
> $ffff (16 bits). The datas contained in memory are 24 bits ranged.


	- Eero