Re: [hatari-devel] ACSI: READ/WRITE (10) incorrectly evaluate block number

[Uwe Seimet <Uwe.Seimet@xxxxxxxxx>]

Hi,
> 
> > Hm, but root sector has address 0, right? So the shift should not
> > matter anyway. Could you maybe HDC_VERBOSE and HDC_REALLY_VERBOSE in
> > hdc.c and send me the output that corresponds to the two read commands?
> 
> After turning on debugging I found that the READ commands (the comparisons
> of the data returned) only fail when READ CAPACITY was executed before.
> After that the READ commands are not even logged anymore, but the log
> output shows TEST UNIT READY commands instead. It looks as if the
> command sent are not analyzed correctly anymore. My guess is that the
> DMA address counter does not always work correctly.

I can see now what's wrong: When Hatari receives an unknown opcode it
stops processing the CDB, and the remaining bytes from the old CDB are
read later, when a new command is sent. So the ACSI emulation gets out of
sync, and any command sent from now on results in unpredictable behavior,
which also explains the wrong/missing logging information.

In order to solve this problem the emulation would have to always read the
*complete* CDB, so that no bytes are left over from previous CDBs.
Provided all non-CDB transfers are done using DMA the end of the CDB
transfer can be detected by the fact that the last CDB byte is sent with
bit 7 of the DMA mode register cleared, which starts the DMA transfer.
This would not work, though, if after sending the CDB there is no DMA
but only a PIO transfer.
The best solution would probably be to have a table with the byte count
of *all* SCSI commands, so that Hatari can exactly determine the number of
bytes in a CDB. If somebody would like to set up the code infrastructure
for that I would later fill in the missing data.

Take care

Uwe