[hatari-devel] ACSI/DMA emulation issues

Uwe Seimet Uwe.Seimet at seimet.de
Sun Nov 29 15:01:42 CET 2009


Hi,

> That's funny. Actually, we had this reset code oncy already in
> FDC_ResetDMAStatus(), but according to a report from Volker Seebode, this
> was wrong, see:
> 
>  http://sourceforge.net/tracker/?func=detail&aid=2130450&group_id=28326&atid=393019
> and:
>  http://hg.berlios.de/repos/hatari/rev/5d4905926359
> 
> So what's the correct behaviour now???

This may be a misunderstanding. The code in my posting was the code used by
HDDRIVER to clear the DMA status. It was not meant to be code to be
included in Hatari. My point was when Hatari "sees" this code sequence
it should reset its byteCount because this code sequence that a new
command sequence is going to be started. If Hatari does not recognize
this sequence it might still get the byteCount wrong, even after your
code change. If for some reason a hard disk driver decides not to send
all 6 command bytes but aborts the operation and sends less, Hatari's
byteCount will be wrong at the start of the next operation.

> I think the right fix is to only increase byteCount when a valid target
> is accessed. I've fixed this in the source code now, so HDDriver (at
> least the demo version) seems now to be working. Please test if it's
> also ok for you now!

It's working better now, the commands received by Hatari no longer seem
to be garbled and the drive is found. But the drive name returned is
invalid. I think this has something to do with the Atari's ACSI DMA
hardware only being able to transfer multiples of 16 bytes. In order to
be compliant with the SCSI Driver specification, which mandates that an
aribrary number of bytes can be transferred on any supported bus, HDDRIVER
has to use a work-around in order to hide this limitation.
What happens in practice is this: The SCSI driver is called (in this
case internally by HDDRIVER) and the number of data bytes to be returned
is set to 8, for instance. As the Atari's ACSI DMA chip can only return
multiples of 16 HDDRIVER first sends the original command (the one the
SCSI driver was called with) with the original number of bytes (8) to be
transferred. After sending this command HDDRIVER will additional send as
many REQUEST SENSE commands (with a byte count of 4) as required to
reach the 16 bytes response data required by the DMA chip. Now HDDRIVER
returns the initial number of bytes (8) to the caller and discards the
excess bytes. Not discarding them would result in a buffer overflow
because the caller is not required to reserve a buffer larger than the
number of bytes the caller actually expected.
This may sound overly complicated, but the idea behind the SCSI Driver
specification is to have any bus appear like a real SCSI bus, so that
the caller is not bothered by the underlying hardware limitations.

BTW, instead of reporting "HDC: Program tries to access illegal drive."
it should probably read "HDC: Program tries to access non-existing drive."
because it's normal (and not illegal) for a hard disk driver to check
unused IDs.

Best regards

Uwe



More information about the hatari-devel mailing list