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

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

Is this old thread relevant to the current ACSI discussion?

        - 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/100293068a
> > .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. :))