Re: [hatari-devel] SCSI DMA Control

[Eero Tamminen <oak@xxxxxxxxxxxxxx>]

Hi,

On 4.2.2022 0.48, Uwe Seimet wrote:
> > I've found that looking at the Hatari code is often a useful way of
> > understanding how real hardware works, although of course I realise that it may
> > not always be 100% accurate.

And your experiments with real (e.g. TT) HW have been very nice for 
improving Hatari emulation. :-)


> > I have been trying to figure out why bit 7 of 0xff8715 on a real TT is set
> > (that's part of SCSI DMA control).  However, I couldn't find anywhere in Hatari
> > that sets it.  So I have 2 questions:
> > (1) did I miss something?
> > (2) even if Hatari never sets it, apparently real hardware does set it
> > sometimes.  Does anyone know the conditions that would set this bit?  I looked
> > in the TT030 Hardware Reference Manual, but all it said was that it is only set
> > by reads, and it is cleared by a read.
>
> I'm afraid I don't have more information on this bit except that it is
> supposed to be set when there is a bus error during a DMA transfer. The
> German Atari Profibuch, which is very detailed, also does not provide more
> information. I doubt that Hatari fully implements the TT's SCSI chip, and in
> particular not all possible error conditions.
> If you have a scenario where this bit is set, wouldn't it be the best guess
> to assume that exactly what the bit signals has actually happened? The
> transfer address might simply not be valid. At least that's my understanding
> of what this bit means.

Hatari TT / SCSI / 2nd MFP emulation is quite bare bones.  It for 
example does not work with m68k Linux (like IDE emulation does), 
mounting root FS from SCSI fails to:
------------------------------------------------------------
DEBUG: raw_scsi: selected id 0
DEBUG: raw_scsi_put_data got message c0 (1/1)
DEBUG: raw_scsi_put_data got message c0 (1 bytes)
DEBUG: raw_scsi: got command byte 1a (1/6)
DEBUG: raw_scsi: got command byte 00 (2/6)
DEBUG: raw_scsi: got command byte 3f (3/6)
DEBUG: raw_scsi: got command byte 00 (4/6)
DEBUG: raw_scsi: got command byte 04 (5/6)
DEBUG: raw_scsi: got command byte 00 (6/6)
TODO : HDC: Unsupported MODE SENSE command
DEBUG: raw_scsi: no data, status = 2
DEBUG: raw_scsi: status byte read 02. Next=1
DEBUG: raw_scsi: message byte read 00. Next=1
DEBUG: raw_scsi: arbitration initiator id 7 (80)
DEBUG: raw_scsi: arbitration
DEBUG: raw_scsi: selected id 0
DEBUG: raw_scsi_put_data got message 80 (1/1)
DEBUG: raw_scsi_put_data got message 80 (1 bytes)
DEBUG: raw_scsi: got command byte 03 (1/6)
DEBUG: raw_scsi: got command byte 00 (2/6)
DEBUG: raw_scsi: got command byte 00 (3/6)
DEBUG: raw_scsi: got command byte 00 (4/6)
DEBUG: raw_scsi: got command byte 60 (5/6)
DEBUG: raw_scsi: got command byte 00 (6/6)
WARN : HDC: *** Strange REQUEST SENSE ***!
DEBUG: raw_scsi: data in 22 bytes waiting
DEBUG: raw_scsi: data in finished, 22 bytes: status phase
DEBUG: DMA initiator recv PC=001839da
DEBUG: SCSI BUS reset
sd 0:0:0:0: Device offlined - not ready after error recovery
sd 0:0:0:0: rejecting I/O to offline device
sd 0:0:0:0: [sda] Write Protect is off
sd 0:0:0:0: [sda] Mode Sense: 00 00 1f ff
sd 0:0:0:0: rejecting I/O to offline device
sd 0:0:0:0: [sda] Asking for cache data failed
sd 0:0:0:0: [sda] Assuming drive cache: write through
sd 0:0:0:0: rejecting I/O to offline device
sd 0:0:0:0: rejecting I/O to offline device
sd 0:0:0:0: [sda] Attached SCSI disk
VFS: Cannot open root device "sda" or unknown-block(8,0): error -6
------------------------------------------------------------


	- Eero