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

[Eero Tamminen]

Hi,

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


	- Eero