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

[Thomas Huth <th.huth@xxxxxx>]

Am Sat, 26 Oct 2013 23:55:00 +0200
schrieb 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.

Ok, that explains a lot ... thanks for debugging this!

> 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.

That might be a solution ... but I just read a little bit through my
"Scheibenkleister" book, and if I got that right, the driver has to
signal the start of a new command by driving the so-called A1 pin low.
This seems to be done by setting bit 1 in $ff8606 to zero while the DMA
unit is selected. For all the following data bytes, the A1 pin is
driven as high.
So I think it should be possible to detect the start of an new ACSI
command by monitoring that A1 bit ... and that would be much easier
than to count the length of the commands. What do you think, could that
work?

 Thomas