|Re: [hatari-devel] Missing DMA sector count register emulation for ACSI transfers?|
[ Thread Index |
| More lists.tuxfamily.org/hatari-devel Archives
- To: hatari-devel@xxxxxxxxxxxxxxxxxxx
- Subject: Re: [hatari-devel] Missing DMA sector count register emulation for ACSI transfers?
- From: Christian Zietz <czietz@xxxxxxx>
- Date: Thu, 2 Sep 2021 16:23:02 +0200
- Dkim-signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1630592583; bh=fVoigKECvligHDFUvWJjhuv5jtVpiwCGJ3CrmwV2fpk=; h=X-UI-Sender-Class:To:References:From:Subject:Date:In-Reply-To; b=NCkg7H9tyg6R8Ahr0rMIDAHBXq097WUmDTYLtnI2ldUVUmAQYmJXN+9/wt518xicm fEcFgRZVuRe49K+QcBd78RXyo70Vvl6zGwanwj2ufEQQdSN+OrSHralaX4csaPNZNG D88I2znk+j+qdJIlkDHLVVWSA7QzsEMVPZkwjAyg=
Nicolas Pomarède schrieb:
IMO Acsi_DmaTransfer() should be modified to use FDC_DMA_FIFO_Push()
when reading as it's already the case for FDC read accesses.
For write case it's harder to share code with fdc's FDC_DMA_FIFO_Pull(),
so it should at least check FDC_DMA.SectorCount>0 and decrement it
Afaik, software cannot read back the DMA sector count, anyway; thus, it
only matters whether it is zero or not. My (previously mentioned) "hack"
just set the DMA sector count to zero unconditionally at the end of
every ACSI DMA transaction, regardless of its outcome. For sure, this is
*too* simplistic for a proper patch, but maybe it would suffice to zero
the sector count when a ACSI DMA transaction is successful.
Going on a tangent: The comment w.r.t. to the $FF8606 DMA status
register that reads "unused bits 3-15 are the ones from the latest
$ff8604 access" is not fully accurate. In fact, bit 3 is wired to a
specific function: it returns the read/write setting. I.e., what you
write into $FF8606, bit 8 can be read back from as $FF8606, bit 3.
Afaik, this is true for all ST/STE DMAs. (I'm unsure about the Falcon
DMA.) Unfortunately, I'm not at liberty to share the evidence I have on
this; but you can confirm it via your own observations, if you like.
Then again, this bit 3 is not documented anywhere; so, its emulation
Christian Zietz - CHZ-Soft - czietz@xxxxxxx
PGP/GnuPG-Key-ID: 0x52CB97F66DA025CA / 0x6DA025CA