| Re: [hatari-devel] Missing DMA sector count register emulation for ACSI transfers? |
[ Thread Index |
Date Index
| More lists.tuxfamily.org/hatari-devel Archives
]
Le 02/09/2021 à 16:23, Christian Zietz a écrit :
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
accordingly.
Afaik, software cannot read back the DMA sector count, anyway; thus, it
only matters whether it is zero or not.
Yes I agree, current sector count itself can't be read from ff86xx, it
can only be written. My point was that internal (emulation) sector count
should be updated in ACSI mode and then reading status should report if
==0 or !=0.
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.
It could work ; FDC emulation updates sector count when enough DMA fifo
were read/written to emulate the delay required to transfer date (as
some games' protection might expect a specific number of cycles before
SectorCount goes to 0 in status word).
But for ACSI transfers where cycle accuracy doesn't really matter, it
might be ok to zero sector count at the end of the transfer.
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
shouldn't matter.
Interesting. Unlike some protections that rely on undocumented bits in
CPU stack/exceptions, I never saw a program that required bit 3 to work,
but I could change it anyway to reflect the value written in bit 8.
Being more accurate can not hurt :)
Nicolas