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

[Uwe Seimet <Uwe.Seimet@xxxxxxxxx>]

Hi Thomas,

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

This might work, I have also already been thinking about this. This is a
general problem where not only Hatari is affected, but also real
hardware that supports the ICD mechanism for using all SCSI command
classes (GigaFile, UltraSatan, ...) connected to the ACSI bus.
But would this also work if there is no DMA transfer at all, but only
PIO? What happens if I read (or send) data not by DMA but by PIO
exclusively? In this case we could not draw any conclusions from the
state of these pins, could we?

Take care

Uwe