Re: [hatari-devel] Sokoban VGA (Falcon)

[Thomas Huth <th.huth@xxxxxx>]

Am Tue, 08 Oct 2013 00:24:18 +0200
schrieb Laurent Sallafranque <laurent.sallafranque@xxxxxxx>:
[...]
>  > info blitter
> 
> src addr:  0x2de9fe
> dst addr:  0xff9800
> words:     33
> lines:     1
> src X-inc: -2
> src Y-inc: -962
> dst X-inc: -2
> dst Y-inc: -962
> end mask1: 0xffff
> end mask2: 0xffff
> end mask3: 0xffff
> HOP:       0x02
> LOP:       0x03
> control:   0x80
> skew:      0xc0

Looks like the game is abusing line-a #7 (BITBLIT) to copy a new
palette to the Videl color registers at 0xff9800. The Line-a #7
handler then uses the blitter to copy the memory region. But something
seems to be going wrong there, so that the blitter accesses
non-existing IO registers before the palette region - and this causes
the bus error that you saw.

Not sure what is really wrong here, though. Two theories:

1) The game is buggy and the BITBLIT is called with bad parameters, so
that the blitter also accesses the non-existing registers on real
hardware - but there is likely no bus error on real hardware when it is
the blitter (instead of the CPU) that is accessing the bad region. So
the bug goes unnoticed on real hardware.

2) There is still something wrong with our blitter emulation.

The first case might be easy to fix, but I am not sure whether it is
the right thing to do ... does anybody know how the blitter behaves in
such cases?
If it is the second case, I think this is a problem that should be
debugged on a real Falcon, to see how the blitter is behaving there.
So if anybody has a Falcon ready, feel free to help out here ... (mine
is burried somewhere in the basement, and I currently don't have time
to dig it out again).

 Thomas