|Re: [hatari-devel] Re: ACSI issue with Hatari|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
Le 03/10/2014 10:35, Thomas Huth a écrit :
Am Sun, 28 Sep 2014 22:02:42 +0300
schrieb Eero Tamminen <oak@xxxxxxxxxxxxxx>:
On sunnuntai 28 syyskuu 2014, Eero Tamminen wrote:
Thomas, could you look at the ACSI issue raised by "AtariZoll"
at Atari Forum:
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.
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.
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 ?)