Re: [hatari-devel] HDC/ACSI command sector count & error handling?

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

Uwe Seimet wrote:
> On sunnuntai 27 lokakuu 2013, Eero Tamminen wrote:
>> Is this old thread relevant to the current ACSI discussion?
>
> I don't think that the FIFO behavior is causing the problems I have
> observed, at least not those related to unknown commands.
> As fara s the FIFO is conderned any hard disk driver compliant to the
> SCSI Driver specification (i. e. CBHD and HDDRIVER) has to ensure that any
> byte count can be transferred.
> In practice HDDRIVER (and I guess CBHD as well) when required sends an
> additional command (INQUIRY) just for the purpose of filling the FIFO with
> up to 16 bytes, so that everything is transferred. The excess bytes are
> internally discarded and the caller just sees the data that were
> transferred in response to the command he sent.
> 
> So when using the SCSI Driver interface the caller does not have to care
> for this ACSI/DMA peculiarity but can treat the ACSI bus more or less
> like a regular SCSI bus.

Ok.

(and sorry that I initially replies to wrong list, I didn't notice that
the 2011 message was on BerliOS list...)


	- Eero


> On keskiviikko 11 toukokuu 2011, Eero Tamminen wrote:
> > On keskiviikko 04 toukokuu 2011, Uwe Seimet wrote:
> > > > Uwe, could you comment on this?
> > > 
> > > I don't think I can comment on it in detail right now. As far byte 4
> > > in the SCSI command block is concerned this is either a byte or a
> > > sector count, depending on the SCSI command. It tells the SCSI
> > > device the maximum number of bytes or sectors it shall return.
> > 
> > Thanks, so one cannot unconditionally get the sector count from it...
> > 
> > > http://en.wikipedia.org/wiki/SCSI_command provides more information,
> > > http://www.seagate.com/staticfiles/support/disc/manuals/scsi/10029306
> > > 8a .p df has all the details.
> > > The ST's ACSI/DMA bus is basically a stripped down SCSI bus and as
> > > far as the structure of commands is concerned they are identical to
> > > standard SCSI commands.
> > > Note that it is a restriction of the DMA chip that it always buffers
> > > 16 bytes before they get available. This means that in order not to
> > > lose bytes the software sending the SCSI command has to ensure that
> > > the byte count is always a multiple of 16. When transferring sectors
> > > this is not an issue because the READ/WRITE commands use byte 4 as a
> > > sector count, and the sector size is usually be a multiple of 16.
> > > (Usually, but not always. There are SCSI drives where you can
> > > configure the sector size when formatting, and they allow sectors
> > > sizes that are not a multiple of 16.)
> > 
> > Any idea whether the HDC sector count needs to affect the DMA status
> > register byte or disk controller register byte?
> > 
> > (Currently it doesn't because the HDC sector cound fdc.c gets is always
> > zero.)
> > 
> > > > On sunnuntai 01 toukokuu 2011, Thomas Huth wrote:
> > > > > > >  From above you can see that "HDCSectorCount" can never get
> > > > > > >  any
> > > > > > > 
> > > > > > > other value than zero (unlike e.g. FDCSectorCountRegister
> > > > > > > which seems to be used for similar purpose).  So what's the
> > > > > > > point in having that variable?
> > > > > > > 
> > > > > > > hdc.c code gets the HDC sector count with this macro, it
> > > > > > > doesn't use the variable:
> > > > > > > #define HD_SECTORCOUNT(a) (a.command[4]&  0xFF)        /* get
> > > > > > > sector count */
> > > > 
> > > > Attached is a cleanup patch for hdc.c which also makes this
> > > > mismatch clearer.
> > 
> > Has anybody comments on the patch?
> > 
> > Functionally it should be equivivalent to the current code.
> > 
> > > > > hdc.c originally hasn't been written by me but by Sven de
> > > > > Marothy... Dunno why this variable isn't used (anymore)? Maybe it
> > > > > was used in the past,
> > > > 
> > > > Looking at the first hdc.c source version from 2002:
> > > > 	http://hg.berlios.de/repos/hatari/rev/b518e26c49a6
> > > > 
> > > > That code worked similarly already from the beginning.
> > > > 
> > > > > or it is not necessary since the ACSI commands are executed
> > > > > immediately instead of delayed like the FDC commands?
> > > > 
> > > > In fdc.c, that variable (would) affect:
> > > > - Read DMA status byte (DMAStatus_ff8606rd variable)
> > > > 
> > > > - DiskControllerByte (0xff8604 HW register), when:
> > > >         if ((DMAModeControl_ff8606wr & 0x18) == 0x08)     /* HDC
> > > >         status reg
> > > > 
> > > > selected? */
> > > > 
> > > > Should those be affected by HDC command sector count, as the fdc.c
> > > > code seems to expect, or not, as it happens with the current hdc.c
> > > > code?
> > > > 
> > > > If it should affect them, do all HDC commands have a valid sector
> > > > count at command[4], or is the sector count something that's valid
> > > > only for specific HDC commands?
> > > > 
> > > > If former is true, the new HDC_GetSectorCount() function can just
> > > > return HDCCommand.command[4], otherwise e.g. the HD_SECTORCOUNT()
> > > > macro could be changed to store the queried sector count to an
> > > > internal hdc.c variable that will be returned by that function.
> > > > 
> > > > Or if the sector count isn't actually needed, it can be just
> > > > removed competely...
> > > > 
> > > > 
> > > > And another thing I noticed is that the DMA status register bit is
> > > > set only floppy read/write errors, not on HDC/ASCI read/write
> > > > errors...
> > 
> > Any idea whether the HDC read/write errors need to affect the DMA
> > status register too?
> > 
> > (I would image them to be pretty unlikely to happen with HD images
> > though, so this would be mostly for emulation accuracy reasons. :))