Re: [hatari-devel] Data cache Issues?

[Nicolas Pomarède <npomarede@xxxxxxxxxxxx>]

Le 28/06/2015 23:35, Eero Tamminen a écrit :
> * ChainZ loops with exception 3 at startup
>    - works at least with older oldUAE
>
> * JewelZ loops with exception 3 at startup
>    (if user selects real Falcon instead of Hatari)
>    - works at least with older oldUAE
>
>
> * RG's Tautology II (Sentry v2.11 packed) freezes at startup:
> 	$00023bf2 :             btst      #0,(a0)
> 	$00023bf6 :             beq.s     $23bf2
> > r
>    D0 004E544B   D1 004E544B   D2 004E544B   D3 004E544B
>    D4 00000001   D5 00000000   D6 00000000   D7 000001F1
>    A0 FFFFA202   A1 FFFFA204   A2 0007AC1C   A3 000F8356
>    A4 0002386C   A5 0001C844   A6 000F24FC   A7 00100BD2
>
> -> DSP communication reg problem?
> - cancache change didn't help
> - works at least with older oldUAE

Hi

thanks for your list.

Regarding chainz and jewelz, the problem was related to the blitter :
during the init, the game moves some blocks of data using the blitter 
(can't say what kind of data it is) and it reads data near the end of 
the RAM to copy it elsewhere.
The problem is that the code seems buggy, because it starts to read in 
the RAM, then it reads beyond the RAM in the region that should give a 
bus error :(
So, with 4 MB RAM, it will read $400000,$400002, ...

There was an error in the blitter code because it triggered a bus error 
in that case ; but as the blitter uses DMA, it should not do bus error, 
it should ignore the write or return random data when reading.

This is now fixed,so chainz and jewelz don't bomb at start.

Nevertheless, they now stop on the same loop as tautology, waiting for 
bit 0 of ffa202 to change. I confirm this work with old cpu core, so I 
think that something was broken when I updated the code to integrate DSP 
interrupt into recent WinUAE core (which uses a slightly different code 
path)

I will have a look, having a working case will help fixing this.

Didn't have a look to the other cases for now.

Nicolas