| Re: [hatari-devel] Re: ACSI issue with Hatari |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Am Fri, 03 Oct 2014 10:46:50 +0200
schrieb Nicolas Pomarède <npomarede@xxxxxxxxxxxx>:
> Le 03/10/2014 10:35, Thomas Huth a écrit :
> > Am Sun, 28 Sep 2014 22:02:42 +0300
> > schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
> >
> >> Hi,
> >>
> >> On sunnuntai 28 syyskuu 2014, Eero Tamminen wrote:
> >>> Thomas, could you look at the ACSI issue raised by "AtariZoll"
> >>> at Atari Forum:
> >>> http://www.atari-forum.com/viewtopic.php?f=51&t=26779&start=75
> >>> ?
> >>>
> >>> It could be related to your following change:
> >>> "ACSI: Reset command counters when A1 pin is zero"
> >>> (which code has changed later a bit)
> >>
> >> Corrected the subject (there's another issue reported by AtariZoll,
> >> related to Blitter / IDE).
> >
> > I've now had a look at the ACSI issue, and the problem was/is that
> > this hard disk driver is accessing the FF8604 and FF8606 registers
> > with one long word access. Not sure whether this is "legal" on real
> > hardware, since it might depend which register content is put on
> > the 16-bit bus first - I don't know how hardware is doing this, but
> > I assume that it sends out FF8604 first and FF8606 afterwards, so
> > there might be a race condition on real hardware, too. So IMHO this
> > is a bug in that driver.
> >
> > It used to work with old Hatari ACSI emulation since this was simply
> > ignoring the A1 bit in FF8606. Anyway, I've "fixed" the Hatari code
> > now to update FF8606 first when the program tries to write to
> > FF8604 with a long word access, so the first problem with this disk
> > image now should be gone. Unfortunately there seem to be some other
> > problems left, so that movie player still does not work yet.
> >
>
> Hi,
>
> that strange, word accesses are supposed to be in ascending order.
> For example, many music drivers use .L accesses to write to both
> $ff8800 and $ff8802 to select YM register and put value at the same
> time.
Ok, that's what I also expected, lower address goes out on the bus
first, then the higher address. So this driver has definitely a bug.
> Maybe there're some dma specific buffer at ff8604/06 ?
> Or could it be that in case of long access the low word is ignored,
> so only $ff8604 is modified and $ff8606 keep its old value (which
> happens to be the expected one in that case ?)
No, the expected behaviour of that driver is that ff8606 has to be
changed first.
This is what the driver is doing:
$001882 : 7202 moveq #2,d1
$001884 : 7408 moveq #8,d2
$001886 : 4df8 8606 lea $ffff8606.w,a6
$00188a : 4bf8 8604 lea $ffff8604.w,a5
$00188e : 50f8 043e st $043e.w
$001892 : 4850 pea (a0)
$001894 : 11ef 0003 860d move.b 3(sp),$ffff860d.w
$00189a : 11ef 0002 860b move.b 2(sp),$ffff860b.w
$0018a0 : 11ef 0001 8609 move.b 1(sp),$ffff8609.w
$0018a6 : 588f addq.l #4,sp
$0018a8 : 3cbc 0198 move.w #$198,(a6)
$0018ac : 3cbc 0098 move.w #$98,(a6)
$0018b0 : 3a82 move.w d2,(a5)
$0018b2 : 3cbc 0088 move.w #$88,(a6)
$0018b6 : 303c 0008 move.w #8,d0
$0018ba : 4840 swap d0
$0018bc : 303c 0088 move.w #$88,d0 ; has A1 bit set to low
$0018c0 : 6100 006e bsr $1930
$001930 : 2a80 move.l d0,(a5) ; write to both registers
HDC: Write cmd byte addr=0, byte=08
$001932 : 780a moveq #$a,d4
$001934 : d878 04bc add.w $04bc.w,d4
$001938 : 0839 0005 ffff fa01 btst #5,$fffffa01
$001940 : 6708 beq.s $194a
$00194a : 4e75 rts
$0018c4 : 6600 0086 bne $194c
$0018c8 : 2001 move.l d1,d0
$0018ca : 303c 008a move.w #$8a,d0 ; has A1 bit set to high
$0018ce : 6100 0060 bsr $1930
$001930 : 2a80 move.l d0,(a5) ; write to both registers
HDC: Write cmd byte addr=0, byte=00
For the second command byte, the A1 line should be high again, but
Hatari of course still detected it as low since the handler for ff8606
has not been called yet.
I think this just works "by accident" with other emulators and real
hardware, e.g. because in real hardware there might be a small delay
within the device or so.
Thomas