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

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


 Hi Uwe,

Am Sun, 27 Oct 2013 10:16:18 +0100
schrieb Uwe Seimet <Uwe.Seimet@xxxxxxxxx>:
> 
> > > 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?

As far as I understood, the A1 pin has always be set to zero when
starting a new command, no matter whether there is a DMA transfer
involved or not. Or did I miss something here?

 Thomas



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/