Re: [hatari-devel] SCSI DMA Control

[ Thread Index | Date Index | More lists.tuxfamily.org/hatari-devel Archives ]


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



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/