perry@key.COM (Perry The Cynic) (11/18/89)
Here's a rather oddball question for all you experts out here. It's not quite idle curiosity, but it's an interesting question in any case. The SCSI standard specifies that you can put up to eight devices on a SCSI bus, as long as you observe limits on cable lengths etc. The standard describes how ANY device can then initiate communications with ANY other (not itself). In theory, your tape drive could talk to your disk to do a backup, without your Mac needing more than to set things up initially. Of course, nobody (to my knowledge) makes SCSI controllers intelligent enough to actually do that (at least in the Mac area). But that's not my question. On a conventional Mac SCSI bus, the Mac is device #7, and the only one that initiates communications (talker). All the other devices just listen and (we hope) obey. I am told that the Mac's SCSI manager is borderline brain-dead in its restrictions. I haven't looked at it myself (yet); I'm hoping somebody who has already suffered through that can enlighten me. Let's say I have a CD-ROM reader with a SCSI interface. (Or a large hard drive with partitions. Or a scanner. Or whatever.) Let's say I have a PC compatible with a SCSI interface card. Can I make a SCSI bus containing the Mac, my CD-ROM drive, AND the PC? Yeah, I know I can, physically. But what's the chances for this to actually work? (We could try to do this with two Macs, if Apple hadn't hardwired the Mac's SCSI controller as device #7. Two devices with the same address is an obvious no-no-nooooh.) Let's say I give the PC controller a free device address. First of all, I'm given to wonder how to terminate this thing. Assuming both the Mac and PC interfaces are terminated, I could put them at the ends of the SCSI bus and line up any peripherals in between (without terminators, of course). Should that work? Does it? As long as either the PC or the Mac is off, I guess I have a reasonable chance for the "living" computer to control the devices on the SCSI bus. Yes, I know file formats are different, and a Mac-formatted disk drive won't work for the PC and vice versa, and the partition tables are probably incompatible too. But a CD-ROM drive should work for either (they sell the same drive with software kits for both Macs and PCs). Another candidate could be a SyQuest 40MB removable drive. The interesting question, of course, is whether it'll work if I turn on both computers. Assuming I use the CD-ROM drive only from one host at a time, what are my chances? Will the Mac's boot-time scan of the bus confuse it if it sees a PC host card there? Can the Mac's SCSI chip and manager (esp. the manager!) cope with a second talker on the bus? I.e., can the PC card talk to the CD-ROM player while the Mac talks to a harddrive? Am I expecting much too much of the poor weak-brained SCSI manager? Has anybody tried this? If so, did it work? What did you learn? If not, let's get some discussion going here before I start forking over my money... -- perry -- ------------------------------------------------------------------------ Perry The Cynic (Peter Kiehtreiber) perry@arkon.key.com ** What good signature isn't taken yet? ** ...!pacbell!key!perry
kaufman@Neon.Stanford.EDU (Marc T. Kaufman) (11/19/89)
In article <1240@key.COM> perry@arkon.key.COM (Perry The Cynic) writes: >On a conventional Mac SCSI bus, the Mac is device #7, and the only one that >initiates communications (talker). All the other devices just listen and >(we hope) obey. I am told that the Mac's SCSI manager is borderline brain-dead >in its restrictions. I haven't looked at it myself (yet); I'm hoping somebody >who has already suffered through that can enlighten me. I have looked through (and rewritten) parts of the SCSI manager. In principle, any SCSI device can act as Bus Master ("Initiator" in SCSI parlance). However, for this to work, all Initiator devices must use a version of the SCSI protocol that allows it. In particular, each Initiator must first go through a "Bus Arbitration" phase. This insures that no one else is on the bus, and that no one else has (successfully) bid for the bus at the same time. Apple's SCSI code DOES NOT perform bus arbitration before seizing the bus. >Let's say I have a CD-ROM reader with a SCSI interface... > ...(We could try to do this with >two Macs, if Apple hadn't hardwired the Mac's SCSI controller as device #7. The "hardwiring" is in the Rom Code. There is no "wiring" as such. However, the ROM code (and patches I have seen) "knows" that device #7 will always win a selection battle, and "knows" that the Mac is device #7, so, shall we say, "takes some shortcuts". >First of all, I'm given to wonder how to terminate this thing. Assuming >both the Mac and PC interfaces are terminated, I could put them at the ends >of the SCSI bus and line up any peripherals in between (without terminators, >of course). Should that work? Does it? Yes. That is how you should do it. >As long as either the PC or the Mac is off, I guess I have a reasonable >chance for the "living" computer to control the devices on the SCSI bus. >Yes, I know file formats are different, and a Mac-formatted disk drive >won't work for the PC and vice versa, and the partition tables are probably >incompatible too. But a CD-ROM drive should work for either (they sell the >same drive with software kits for both Macs and PCs). Another candidate >could be a SyQuest 40MB removable drive. >The interesting question, of course, is whether it'll work if I turn on both >computers. Assuming I use the CD-ROM drive only from one host at a time, >what are my chances? Slim to none, statistically. No problem electrically. > Will the Mac's boot-time scan of the bus confuse it >if it sees a PC host card there? Probably not, since I assume the PC will not respond as a Target Device either. > Can the Mac's SCSI chip and manager (esp. >the manager!) cope with a second talker on the bus? I.e., can the PC card >talk to the CD-ROM player while the Mac talks to a harddrive? Am I expecting >much too much of the poor weak-brained SCSI manager? Yes you are. Why do you think the PC card is any better, BTW? >Perry The Cynic (Peter Kiehtreiber) perry@arkon.key.com Marc Kaufman (kaufman@Neon.stanford.edu)
mclow@telesoft.com (Marshall Clow @telesoft) (11/20/89)
In article <1240@key.COM>, perry@key.COM (Perry The Cynic) writes: > Here's a rather oddball question for all you experts out here. It's not quite > idle curiosity, but it's an interesting question in any case. > > The SCSI standard specifies that you can put up to eight devices on a > SCSI bus, as long as you observe limits on cable lengths etc. The standard > describes how ANY device can then initiate communications with ANY other > (not itself). In theory, your tape drive could talk to your disk to do a > backup, without your Mac needing more than to set things up initially. Of > course, nobody (to my knowledge) makes SCSI controllers intelligent enough > to actually do that (at least in the Mac area). But that's not my question. > > On a conventional Mac SCSI bus, the Mac is device #7, and the only one that > initiates communications (talker). All the other devices just listen and [stuff deleted] > Let's say I have a CD-ROM reader with a SCSI interface. (Or a large hard > drive with partitions. Or a scanner. Or whatever.) Let's say I have a PC > compatible with a SCSI interface card. Can I make a SCSI bus containing > the Mac, my CD-ROM drive, AND the PC? Yeah, I know I can, physically. But > what's the chances for this to actually work? (We could try to do this with [more stuff deleted] > Can the Mac's SCSI chip and manager (esp. > the manager!) cope with a second talker on the bus? I.e., can the PC card > talk to the CD-ROM player while the Mac talks to a harddrive? Am I expecting > much too much of the poor weak-brained SCSI manager? It won't work. As you surmised, the Mac's SCSI manager wants to be the only "initiator" on the bus. If you want to get technical, _SCSISelect ( or whatever the trap is called ) will fail if the Mac cannot get control of the bus. ( i.e, if two other devices are communicating ). Sorry bout that. It would be a neat hack. Marshall Clow mclow@telesoft.com
time@oxtrap.oxtrap.UUCP (Tim Endres) (11/27/89)
In article <602@telesoft.com> mclow@telesoft.com (Marshall Clow @telesoft) writes: From: mclow@telesoft.com (Marshall Clow @telesoft) In article <1240@key.COM>, perry@key.COM (Perry The Cynic) writes: > ... Intro > > ... a discussion about SCSI ... > > Can the Mac's SCSI chip and manager (esp. > the manager!) cope with a second talker on the bus? I.e., can the PC card > talk to the CD-ROM player while the Mac talks to a harddrive? Am I expecting > much too much of the poor weak-brained SCSI manager? It won't work. As you surmised, the Mac's SCSI manager wants to be the only "initiator" on the bus. If you want to get technical, _SCSISelect ( or whatever the trap is called ) will fail if the Mac cannot get control of the bus. ( i.e, if two other devices are communicating ). Sorry bout that. It would be a neat hack. Marshall Clow mclow@telesoft.com Sorry, Marshall, but it will work. In fact it is done all the time! Talk to anyone with an Ensoniq EPS. Yes, _SCSISelect() can fail, but most programs deal with this. Further, other initiators on the bus does not necessarily mean that SCSISelect() will fail. The probability of a timeout on select increases, but this does not translate into failure. In fact, the opposite tends to be true, the Select almost never fails. Multiple initiators is an *important* aspect of SCSI. I wish more people would excersize it to be sure Apple keeps it functional. Disclaimer: Anything can be done. It is a matter of cost.
kaufman@Neon.Stanford.EDU (Marc T. Kaufman) (11/28/89)
In article <TIME.89Nov27140427@oxtrap.oxtrap.UUCP> time@oxtrap.UUCP writes: >In article <602@telesoft.com> mclow@telesoft.com (Marshall Clow @telesoft) writes: - It won't work. As you surmised, the Mac's SCSI manager wants to be the - only "initiator" on the bus. If you want to get technical, - _SCSISelect ( or whatever the trap is called ) will fail if the Mac - cannot get control of the bus. ( i.e, if two other devices are - communicating ). -Sorry, Marshall, but it will work. In fact it is done all the time! -Talk to anyone with an Ensoniq EPS. -Yes, _SCSISelect() can fail, but most programs deal with this. -Further, other initiators on the bus does not necessarily mean that -SCSISelect() will fail. The probability of a timeout on select -increases, but this does not translate into failure. In fact, the -opposite tends to be true, the Select almost never fails. The problem is not that SCSISelect will or will not fail, it is that SCSISelect does not go through the bus arbitration phase required for multi-master SCSI implementation. It is possible for SCSISelect to succeed when, in fact, it has no right to the bus. It may work, most of the time, but I would not want to count on it. Marc Kaufman (kaufman@Neon.stanford.edu)
time@oxtrap.oxtrap.UUCP (Tim Endres) (11/29/89)
In article <1989Nov28.041855.290@Neon.Stanford.EDU> kaufman@Neon.Stanford.EDU (Marc T. Kaufman) writes:
The problem is not that SCSISelect will or will not fail, it is that SCSISelect
does not go through the bus arbitration phase required for multi-master SCSI
implementation. It is possible for SCSISelect to succeed when, in fact, it
has no right to the bus. It may work, most of the time, but I would not want
to count on it.
Marc Kaufman (kaufman@Neon.stanford.edu)
Marc,
Thanks for clarifying the problem. I was unaware that SCSISelect() did
not arbitrate. Poor choice on Apple's part. Do you know if they ever
intend to repair this, or is it a "feature".kaufman@Neon.Stanford.EDU (Marc T. Kaufman) (11/29/89)
In article <TIME.89Nov28151630@oxtrap.oxtrap.UUCP> time@oxtrap.UUCP writes: >Thanks for clarifying the problem. I was unaware that SCSISelect() did >not arbitrate. Poor choice on Apple's part. Do you know if they ever >intend to repair this, or is it a "feature". Upon direct inquiry, Apple has told me that they do not intend to repair this (indeed, they do not deem it broken) in OS versions 6.x. However, they have announced support of disconnect/reselect protocol in OS version 7.x (I am not sure I should believe 7.0), which will REQUIRE arbitration in order to work properly. Hence, if Apple actually delivers on the promised SCSI enhancements in 7.x, we should (eventually) get arbitration. Marc Kaufman (kaufman@Neon.stanford.edu)
daveb@pogo.WV.TEK.COM (Dave Butler) (12/05/89)
I'm finding this discussion of Apple SCSI quite interesting. I've been trying
to determine the differences between Apple SCSI and ANSI SCSI. So far, I've
been told that Apple SCSI doesn't use the ATN line. Is this true, and if so,
how does the initiator send messages? Also the book "Inside Macintosh Vol IV"
states on page 286 that Mac implements both arbitration and disconnect /
reselection; I find it disturbing to find out that this is not so. Could
anyone please tell me the specific differences between Apple and ANSI SCSI, as
well as any other "gotchas" (like not implementing arbitration, when the
documentation says otherwise)?
I'd appreciate any input. Thanks in advance.
Later,
Dave Butler
Remember: Silly is a state of Mind, Stupid is a way of Life.
PS. If there is an actual document with this information, I'd love to
know its name, and how to get it.kaufman@Neon.Stanford.EDU (Marc T. Kaufman) (12/06/89)
In article <8252@pogo.WV.TEK.COM> daveb@pogo.WV.TEK.COM (Dave Butler) writes: >I'm finding this discussion of Apple SCSI quite interesting. I've been trying >to determine the differences between Apple SCSI and ANSI SCSI. So far, I've >been told that Apple SCSI doesn't use the ATN line. Is this true, and if so, >how does the initiator send messages? The ATN line is usable (note that I didn't say "used"). The MacOS provides a SelectWithATN command, but only allows 1 byte to be sent before ATN is negated - thus precluding IDENTIFY. >how does the initiator send messages? Also the book "Inside Macintosh Vol IV" >states on page 286 that Mac implements both arbitration and disconnect / >reselection; I find it disturbing to find out that this is not so. I had never noticed that. You're right, it does. They lied. >anyone please tell me the specific differences between Apple and ANSI SCSI, as >well as any other "gotchas" (like not implementing arbitration, when the >documentation says otherwise)? > PS. If there is an actual document with this information, I'd love to > know its name, and how to get it. I suggest "Mac Nosy" by Jasik Designs. Marc Kaufman (kaufman@Neon.stanford.edu)
rory@fps.com (Thomas (Rory) Bolt) (12/07/89)
In article <1989Dec5.165138.5192@Neon.Stanford.EDU> kaufman@Neon.Stanford.EDU (Marc T. Kaufman) writes: >In article <8252@pogo.WV.TEK.COM> daveb@pogo.WV.TEK.COM (Dave Butler) writes: >>I'm finding this discussion of Apple SCSI quite interesting. I've been trying >>to determine the differences between Apple SCSI and ANSI SCSI. So far, I've >>been told that Apple SCSI doesn't use the ATN line. Is this true, and if so, >>how does the initiator send messages? > >The ATN line is usable (note that I didn't say "used"). The MacOS provides >a SelectWithATN command, but only allows 1 byte to be sent before ATN is >negated - thus precluding IDENTIFY. > Why would this preclude the IDENTIFY message? The standard IDENTIFY message is only one byte. The EXTENDED IDENTIFY message may be several bytes, however, this is a moot point anyway as I will explain below. >>how does the initiator send messages? Also the book "Inside Macintosh Vol IV" >>states on page 286 that Mac implements both arbitration and disconnect / >>reselection; I find it disturbing to find out that this is not so. > >I had never noticed that. You're right, it does. They lied. > No, Inside Macintosh is correct. You do not understand SCSI protocol. >>anyone please tell me the specific differences between Apple and ANSI SCSI, as >>well as any other "gotchas" (like not implementing arbitration, when the >>documentation says otherwise)? > The Macintosh DOES support arbitration. (via SCSIget) >> PS. If there is an actual document with this information, I'd love to >> know its name, and how to get it. > >I suggest "Mac Nosy" by Jasik Designs. > I suggest the ANSI SCSI specification X3T9. The problem is that Apple provided a low level interface to the SCSI protocol chip. This means that people who wish to write SCSI device drivers MUST understand the SCSI protocol. "Mac Nosy" will tell you what the Macintosh SCSI manager does, NOT HOW TO USE IT. >Marc Kaufman (kaufman@Neon.stanford.edu) The attention line of the SCSI bus is used to signify that the initiator is capable of handling messages. Specifically, if the initiator asserts attention during the selection sequence to REQUEST that the target go to a message out phase. If the target is capable of supporting messages other than COMMAND COMPLETE, it will respond to this request by proceeding to the message out phase after selection. As I have stated in my previous posting, the TARGET controls the bus phase sequence AND determines how many bytes of data should be sent after selection has occured. This means that the target will determine when to disconnect/reconnect (once the initiator has indicated it supports this), how many bytes of message data it wants, etc. THIS IS WHY THE ATTENTION LINE EXISTS, SO THAT THE INITIATOR (WHO IS NO LONGER BUS MASTER) CAN SIGNAL THE TARGET (WHICH IS BUS MASTER) THAT IT WANTS A MESSAGE OUT PHASE. The attention line is used only to request a message phase, it DOES NOT have to be asserted for every byte of the message and does not guarantee that a message phase will occur. The Macintosh SCSI manager does supply all the pieces necessary to support disconnect/reconnect. I have personally implemented it for several companies. AS I SAID IN MY PREVIOUS POSTING, PLEASE STOP SPREADING MIS-INFORMATION. I highly advise you to read the ANSI specification for SCSI and make sure you UNDERSTAND it before you post further on this subject. Apple has provided all of the tools neccessary to support a fully ANSI compliant, single initiator, arbitrating system capable of supporting disconnect/reconnect. Individual driver writers choose how much they are willing to support. KNOWN PROBLEMS/LIMITATIONS: 1) Apple's ROM boot code is not very robust, boot will fail if another initiator is using the bus. 2) The system will only be as robust as the least compliant driver allows. 3) Using Apple's traps incurs moderate overhead for implementations which handle the SCSI protocol as a finite state automata. This overhead may be insignificant compared with the access time of the device. Rory Bolt (rory@fps.com)
kaufman@Neon.Stanford.EDU (Marc T. Kaufman) (12/07/89)
In article <4945@celit.fps.com> rory@fps.com (Thomas (Rory) Bolt) writes: >In article <1989Dec5.165138.5192@Neon.Stanford.EDU> kaufman@Neon.Stanford.EDU (Marc T. Kaufman) writes: ->The ATN line is usable (note that I didn't say "used"). The MacOS provides ->a SelectWithATN command, but only allows 1 byte to be sent before ATN is ->negated - thus precluding IDENTIFY. > Why would this preclude the IDENTIFY message? The standard IDENTIFY > message is only one byte. The EXTENDED IDENTIFY message may be several > bytes, however, this is a moot point anyway as I will explain below. You are correct. I forgot what I was trying to do, which was to send a TWO byte sequence, IDENTIFY-ABORT, to shut down a particular LUN. The Mac drops the ATN line after the first byte, making this impossible. -->how does the initiator send messages? Also the book "Inside Macintosh Vol IV" -->states on page 286 that Mac implements both arbitration and disconnect / -->reselection; I find it disturbing to find out that this is not so. ->I had never noticed that. You're right, it does. They lied. > No, Inside Macintosh is correct. You do not understand SCSI protocol. I don't think you are in a position to judge that. I have written several SCSI drivers and SCSI target controllers. > The Macintosh DOES support arbitration. (via SCSIget) Have you taken the time to disassemble the code, or have you just read the manual. YOUR Mac may support arbitration via SCSIget. MINE (a IIx running system 6.0.4) just sets a low memory byte to preclude other (Multifinder) processes from simultaneously trying to use the SCSI interface. --> PS. If there is an actual document with this information, I'd love to --> know its name, and how to get it. ->I suggest "Mac Nosy" by Jasik Designs. > I suggest the ANSI SCSI specification X3T9. The problem is that Apple > provided a low level interface to the SCSI protocol chip. This means > that people who wish to write SCSI device drivers MUST understand the > SCSI protocol. "Mac Nosy" will tell you what the Macintosh SCSI manager > does, NOT HOW TO USE IT. Well, it is certainly possible to access the chip directly and do whatever you want, including support of Arbitration and extended Messages. In fact, A/UX does both of those and Apple has announced full support of Disconnect and Reselect (which imply ATN and Arbitration) for System 7.0. The fact remains, however, that DTS strongly discourages users from accessing the chip directly -- and if you want to limit yourself to the SCSIxxx routines provided by Apple in system 6 and earlier, you do not get bus arbitration. With respect to Mac Nosy -- you would be suprised at how many things are implemented differently than the documentation states. Don't take MY word for it -- go look. Then tell me about arbitration and soft selection failures. > The attention line of the SCSI bus is used to signify that the >initiator is capable of handling messages. Specifically, if the initiator >asserts attention during the selection sequence to REQUEST that the target >go to a message out phase. If the target is capable of supporting messages >other than COMMAND COMPLETE, it will respond to this request by proceeding >to the message out phase after selection. True. But if you want to sent TWO messages (see above, IDENTIFY+ABORT), the initiator has to hold the ATN line following the first message byte out. > As I have stated in my previous posting, the TARGET controls the >bus phase sequence AND determines how many bytes of data should be sent after >selection has occured. This means that the target will determine when to >disconnect/reconnect (once the initiator has indicated it supports this), >how many bytes of message data it wants, etc. THIS IS WHY THE ATTENTION LINE >EXISTS, SO THAT THE INITIATOR (WHO IS NO LONGER BUS MASTER) CAN SIGNAL THE >TARGET (WHICH IS BUS MASTER) THAT IT WANTS A MESSAGE OUT PHASE. The attention >line is used only to request a message phase, it DOES NOT have to be asserted >for every byte of the message and does not guarantee that a message phase will >occur. All of that is true. HOWEVER, see above for multiple messages. > The Macintosh SCSI manager does supply all the pieces necessary to >support disconnect/reconnect. I have personally implemented it for several >companies. AS I SAID IN MY PREVIOUS POSTING, PLEASE STOP SPREADING >MIS-INFORMATION. I highly advise you to read the ANSI specification for SCSI >and make sure you UNDERSTAND it before you post further on this subject. I am not sure why the flame. The pieces are there, the details are not. In order to support disconnect/reselect correctly, you have to patch several SCSI routines to do proper arbitration and ATN handling (I know, MOST of the time you don't really need to arbitrate, after all the collision window is SO small, and you don't need two bytes of message if you just reset the entire device, or if you reset the bus -- but if thats the kind of code you supply to customers, please tell me who they are so I don't try to use any of their peripherals on my machine). If you want to have more than one device reselecting, or to different tasks, you need to implement command pointer tables and task identification in the command blocks -- Apple doesn't do this and I am guessing that your code will support disconnect/reselect on at most one device connected to at most one program (i.e. - not a file system hooked into HFS). > Apple has provided all of the tools neccessary to support a fully >ANSI compliant, single initiator, arbitrating system capable of supporting >disconnect/reconnect. Individual driver writers choose how much they are >willing to support. and how much they are willing to preclude others from doing the same thing. There is no dispatch method for reselection in the Apple supplied code. Indeed, some of the routines clear the ID register, so the 5380 will not automatically respond on a reselect. Presumably you would poll the chip periodically (at least twice every selection timeout period). What do you do if it's not YOUR device asking for reselect? What do you do if another disk driver, using Apple's SCSI routines (unless you have patched them) attempt a select without bus arbitration just as your device attempts to reselect? NAH, it could never happen. Please note that any system that correctly supports arbitration and disconnect/ reselect has implemented all necessary multi-initiator protocol sequences. The Mac may not be able to be a target device, but other initiators could certainly use the bus -- or a smart target could implement COPY. >KNOWN PROBLEMS/LIMITATIONS: > 1) Apple's ROM boot code is not very robust, boot will fail if another >initiator is using the bus. It's also not very friendly. It resets the entire bus rather than the single device it was trying to access. Ever see an Exabyte tape reset 6 times on startup? > 2) The system will only be as robust as the least compliant driver >allows. > 3) Using Apple's traps incurs moderate overhead for implementations >which handle the SCSI protocol as a finite state automata. This overhead may >be insignificant compared with the access time of the device. >Rory Bolt (rory@fps.com) ***** And now for a REAL hardware question: does anyone know enough about the insides of the SCSI helper PALs for the SE and the II(x) family to be able to categorically state whether the DMA ACK, cpu DTACK, and Bus Error timeout logic preclude or allow data loss on read. [i.e.: If you get a bus error, can you be SURE that a byte was not accepted from the SCSI chip?] My suspicion is that data can be lost (in a small but non-zero timing window), but then I may just have a program bug. Marc Kaufman (kaufman@Neon.stanford.edu)
neil@cpd.com (Neil Gorsuch) (12/09/89)
I haven't followed this discussion, but here is some information about the MAC SCSI performance which defines some of it's implementation: 1. We only see 250 Kbytes per second data transfer rates, as opposed to 2.5 Mbytes per second on other machines, using our new scsi box. The MAC obviously uses the CPU in a tight loop, instead of using DMA like most workstations do. 2. The MAC doesn't use a SCSI interface chip, since it doesn't tolerate fast multiple transitions between SCSI states, like most workstations do. You have to allow time for the MAC processor ro notice every state change. -- Neil Gorsuch INTERNET: neil@cpd.com UUCP: uunet!zardoz!neil MAIL: 1209 E. Warner, Santa Ana, CA, USA, 92705 PHONE: +1 714 546 1100 Uninet, a division of Custom Product Design, Inc. FAX: +1 714 546 3726 AKA: root, security-request, uuasc-request, postmaster, usenet, news
kaufman@Neon.Stanford.EDU (Marc T. Kaufman) (12/11/89)
In article <1989Dec8.232535.14072@cpd.com> neil@cpd.com (Neil Gorsuch) writes:
.I haven't followed this discussion, but here is some information about
.the MAC SCSI performance which defines some of it's implementation:
.1. We only see 250 Kbytes per second data transfer rates, as opposed
.to 2.5 Mbytes per second on other machines, using our new scsi box.
.The MAC obviously uses the CPU in a tight loop, instead of using DMA
.like most workstations do.
I don't know WHICH model of Mac you are using. A Mac II can get 600 KB/sec
in handshaking mode and 1.5 MB/sec in "blind" mode (the mode really isn't
"blind", as there is a PAL that checks for REQ/ACK sequencing -- but there
is an inter-character timeout of about 2 microseconds in this mode). Yes,
the Mac uses a CPU loop, but on 020/030 machines that goes at least as fast as
a DMA would.
.2. The MAC doesn't use a SCSI interface chip, since it doesn't
.tolerate fast multiple transitions between SCSI states, like most
.workstations do. You have to allow time for the MAC processor ro
.notice every state change.
The Mac uses an older SCSI chip that requires the CPU to watch things. But
SCSI protocol should work properly even if the Mac is slow to notice a bus
phase change (since the change is not supposed to be MADE until the initiator
drops ACK from the previous byte, and the change is not supposed to be
NOTICED until the target sets REQ, at which time the target will wait for
the initiator). I have seen some target controller implementations that were
not fully conforming in this regard.
Marc Kaufman (kaufman@Neon.stanford.edu)rory@fps.com (Thomas (Rory) Bolt) (12/12/89)
In article <4945@celit.fps.com> rory@fps.com (Thomas (Rory) Bolt) writes: >In article <1989Dec5.165138.5192@Neon.Stanford.EDU> kaufman@Neon.Stanford.EDU (Marc T. Kaufman) writes: -->The ATN line is usable (note that I didn't say "used"). The MacOS provides -->a SelectWithATN command, but only allows 1 byte to be sent before ATN is -->negated - thus precluding IDENTIFY. -> Why would this preclude the IDENTIFY message? The standard IDENTIFY -> message is only one byte. The EXTENDED IDENTIFY message may be several -> bytes, however, this is a moot point anyway as I will explain below. >You are correct. I forgot what I was trying to do, which was to send a TWO >byte sequence, IDENTIFY-ABORT, to shut down a particular LUN. The Mac drops >the ATN line after the first byte, making this impossible. It is true that the Macintosh SCSI manager does not provide a means to raise attention at any time other than selection, which makes it impossible for the Mac to request more than one message out phase. In keeping with the subject of these postings (ie Sharing the SCSI bus) it should be noted that this does not prevent disconnect/reconnect or sharing of the SCSI bus. --->how does the initiator send messages? Also the book "Inside Macintosh Vol IV" --->states on page 286 that Mac implements both arbitration and disconnect / --->reselection; I find it disturbing to find out that this is not so. -->I had never noticed that. You're right, it does. They lied. -> No, Inside Macintosh is correct. You do not understand SCSI protocol. >I don't think you are in a position to judge that. I have written several >SCSI drivers and SCSI target controllers. I must appologize for any offense generated by my statement, which was worded rather strongly. I too have written several drivers, (both target and initiator roles, embedded controllers, etc), but these merits do not prove that EITHER of us has a full understanding of the SCSI protocol, nor a full understanding of how to make use of the SCSI manager. Let us embark upon a little excursion back in time. Join Mr. Peabody and I as we set the dial of the WayBack machine to late November, 1989 and drop in on the Cleaver family... Beaver: Hey Wally, do you suppose people can share stuff on the SCSI bus? Wally: What kind of stuff, Beav? Beaver: You know, disks and and stuff between computers. Wally: Oh, you mean peripherals! Gee Beav, I don't know. I guess we should ask the net... And thus began this oddessy. Several people stated,"No, it can not be done" for various reasons. I, in turn, reply that not only can it be done, I have actually done it myself using Apple's SCSI manager and not breaking any of the SCSI protocol. I state that there are certain restrictions that occur during the boot sequence, but other than that it works very nicely. You did not ask me how I did it, nor do I feel obligated to give you the details of my implementation. You did not ask, "do you handle IDENTIFY-ABORT sequences", to which I would have replied, "No, the SCSI manager does not allow me to do that, but IDENTIFY-ABORT is NOT required for either arbitration or disconnect/reconnect". Your reply to my postings was "SCSIselect does not arbitrate" followed by "The MacOS provides a SelectWithATN command, but only allows 1 byte to be sent before ATN is negated - thus precluding IDENTIFY." This was the basis for my assertion that you did not understand SCSI protocol. In reading your subsequent responses to my postings and those of others I conceed that you have a fairly good understanding of SCSI. -> The Macintosh DOES support arbitration. (via SCSIget) >Have you taken the time to disassemble the code, or have you just read the >manual. YOUR Mac may support arbitration via SCSIget. MINE (a IIx running >system 6.0.4) just sets a low memory byte to preclude other (Multifinder) >processes from simultaneously trying to use the SCSI interface. I had disassembled the SCSI managers for the Mac Plus, SE, II, SE/30 and IIci at the time of my posting. In fairness I decided to dis- assemble the Mac IIx SCSI manager over the weekend before replying to you. It should be noted that in addition to disassembling the Mac's ROM, I have also used both a SCSI protocol analizer and an in circuit emulator to independantly verify my results. I ran my tests on a Mac IIx, 8 Mbytes ram, Quantum 80 Hard disk, Apple disk driver supplied by HDsetup distributed with 6.0.4, and a stock 6.0.4 system installed from the distribution floppies. No inits or third party drivers of any type were installed. The results are as follows: The Mac IIx does support arbitration. In fact, anyone with MacsBug can verify this by the following steps: 1) Set a breakpoint at SCSIDispatch 2) Cause a disk access. (open a DA, etc...) 3) Use the step command to single step the Mac. The instruction flow for a Mac IIx is as follows. a) you will go through a system patch in low memory b) you will jump to the ROM code c) you will go back to the ram patch and set the global "SCSI in use" variable Marc refers to. d) you will go back to the ROM code. e) you will encounter a MOVE.B $01,20(a3) at address 0x408268EC this causes the NCR5380 to arbitrate. I conclude that either Marc has a bad system, a really strange init, a funky third party driver, or an incorrect disassembly. If it is an init or third party driver patching the SCSI manager in this way, please post more information on it as it is definately not a nice patch to make. I suggest that Marc should check his configuration and his disassembly. I also suggest that he should try to independantly verify his results. Finally I suggest that Marc should talk to Apple's DTS department and see if they can acknowledge/verify/refute his claims before posting his beliefs to the entire net. ---> PS. If there is an actual document with this information, I'd love to ---> know its name, and how to get it. -->I suggest "Mac Nosy" by Jasik Designs. -> I suggest the ANSI SCSI specification X3T9. The problem is that Apple -> provided a low level interface to the SCSI protocol chip. This means -> that people who wish to write SCSI device drivers MUST understand the -> SCSI protocol. "Mac Nosy" will tell you what the Macintosh SCSI manager -> does, NOT HOW TO USE IT. >Well, it is certainly possible to access the chip directly and do whatever >you want, including support of Arbitration and extended Messages. In fact, >A/UX does both of those and Apple has announced full support of Disconnect >and Reselect (which imply ATN and Arbitration) for System 7.0. The fact >remains, however, that DTS strongly discourages users from accessing the chip >directly -- and if you want to limit yourself to the SCSIxxx routines >provided by Apple in system 6 and earlier, you do not get bus arbitration. I can only guess that I was not clear in my statement above. I was not advocating circumvention of the SCSI manager. I was expressing my opinion that people writing SCSI device drivers should first have a good understanding of the SCSI protocol before trying to understand Apple's SCSI manager. I can not comment on Apple's announcement, other than to state that it DOES NOT mean that disconnect/reconnect and arbitration were not supported in earlier releases. They were. In addition I can state that the SCSI manager used in A/UX does not have the facilities to allow you to send an IDENTIFY-ABORT message either. >With respect to Mac Nosy -- you would be suprised at how many things are >implemented differently than the documentation states. Don't take MY word >for it -- go look. Then tell me about arbitration and soft selection failures. Now who is making judgements without qualifications? :-) Frankly, nothing I find in Apple's ROMs and system code surprises me any more! In fact, that is why I was willing to find a Mac IIx and disassemble it's SCSI manager, because I was willing to believe that Apple made it different than the machines I had already disassembled! I do agree that it is worth while to disassemble the ROMs to gain a better understanding of what is going on in the Mac. However, I still feel that an understanding of SCSI is more important than the inner workings of the SCSI manager for a person writing a SCSI driver. Opinions will differ. As to your reference to "soft selection failures", this terminology is unfamiliar to me. Perhaps this is a vendor unique error? -> The attention line of the SCSI bus is used to signify that the ->initiator is capable of handling messages. Specifically, if the initiator ->asserts attention during the selection sequence to REQUEST that the target ->go to a message out phase. If the target is capable of supporting messages ->other than COMMAND COMPLETE, it will respond to this request by proceeding ->to the message out phase after selection. >True. But if you want to sent TWO messages (see above, IDENTIFY+ABORT), the >initiator has to hold the ATN line following the first message byte out. Or re-assert the attention line at any time after the IDENTIFY message. -> As I have stated in my previous posting, the TARGET controls the ->bus phase sequence AND determines how many bytes of data should be sent after ->selection has occured. This means that the target will determine when to ->disconnect/reconnect (once the initiator has indicated it supports this), ->how many bytes of message data it wants, etc. THIS IS WHY THE ATTENTION LINE ->EXISTS, SO THAT THE INITIATOR (WHO IS NO LONGER BUS MASTER) CAN SIGNAL THE ->TARGET (WHICH IS BUS MASTER) THAT IT WANTS A MESSAGE OUT PHASE. The attention ->line is used only to request a message phase, it DOES NOT have to be asserted ->for every byte of the message and does not guarantee that a message phase will ->occur. >All of that is true. HOWEVER, see above for multiple messages. -> The Macintosh SCSI manager does supply all the pieces necessary to ->support disconnect/reconnect. I have personally implemented it for several ->companies. AS I SAID IN MY PREVIOUS POSTING, PLEASE STOP SPREADING ->MIS-INFORMATION. I highly advise you to read the ANSI specification for SCSI ->and make sure you UNDERSTAND it before you post further on this subject. >I am not sure why the flame. The pieces are there, the details are not. In >order to support disconnect/reselect correctly, you have to patch several >SCSI routines to do proper arbitration and ATN handling (I know, MOST of the >time you don't really need to arbitrate, after all the collision window is >SO small, and you don't need two bytes of message if you just reset the entire >device, or if you reset the bus -- but if thats the kind of code you supply to >customers, please tell me who they are so I don't try to use any of their >peripherals on my machine). If you want to have more than one device >reselecting, or to different tasks, you need to implement command pointer >tables and task identification in the command blocks -- Apple doesn't do this >and I am guessing that your code will support disconnect/reselect on at most >one device connected to at most one program (i.e. - not a file system hooked >into HFS). I still assert that you can support disconnect/reconnect correctly using the standard SCSI manager traps. The Mac arbitrates just fine, and attention line handling beyond the IDENTIFY message is not necessary to support disconnect/reconnect. As to your aspersions regarding the quality of code that I supply to my customers, I will not sink to your level. I leave it to the readers of the net to decide which of us they are willing to believe. As to your "guesses" as to the capabilities of my code, you are NOT correct. I support full physical path management (which implies both command and data pointers). Depending on the customer's needs, I also have support for multi-threaded i/o, even though this is not necessary for the majority of them. The Mac is not a real time machine. The Mac is also not a pre-emtive multi-tasking machine. The need for multi-threaded i/o is limited by the small amount of software that benifits from it. If you think that I am flaming you, here is the reason. I have stated that I have written a device driver, using the standard Mac SCSI manager, which supports arbitration and disconnect/reconnect. I have stated that it has certain limitations during the boot sequence due to the Apple ROM boot code. I stated that unless you patch the SCSI manager, your system will be limited by the least compliant driver which is installed. I have hinted that this may be circumvented by replacing the Mac SCSI manager with a more robust version, which consists completely of calls to the original SCSI manager, and does not violate Apple's guidelines. You have yet to do anything other than raise incorrect (as in the Mac does not arbitrate) or irrelevant (as in you can't send IDENTIFY-ABORT) responses. -> Apple has provided all of the tools neccessary to support a fully ->ANSI compliant, single initiator, arbitrating system capable of supporting ->disconnect/reconnect. Individual driver writers choose how much they are ->willing to support. >and how much they are willing to preclude others from doing the same thing. >There is no dispatch method for reselection in the Apple supplied code. >Indeed, some of the routines clear the ID register, so the 5380 will not >automatically respond on a reselect. Presumably you would poll the chip >periodically (at least twice every selection timeout period). What do you >do if it's not YOUR device asking for reselect? What do you do if another >disk driver, using Apple's SCSI routines (unless you have patched them) >attempt a select without bus arbitration just as your device attempts to >reselect? NAH, it could never happen. Did it ever occur to you that if someone allowed a device to disconnect they are probably expecting it to re-connect? From the driver's standpoint, if it sees a device that is not it's own trying to reselect, it should ignore it and let the appropriate driver handle it. As to SCSI manager calls clearing the ID register, does it occur to you that the reason the SCSI manager is executing is because there is activity on the SCSI bus? If the Mac is currently using the SCSI bus, reselection can not be going on by definition. All that matters is that when you give up the bus you leave re-selection enabled. >Please note that any system that correctly supports arbitration and disconnect/ >reselect has implemented all necessary multi-initiator protocol sequences. The >Mac may not be able to be a target device, but other initiators could certainly >use the bus -- or a smart target could implement COPY. ->KNOWN PROBLEMS/LIMITATIONS: -> 1) Apple's ROM boot code is not very robust, boot will fail if another ->initiator is using the bus. >It's also not very friendly. It resets the entire bus rather than the single >device it was trying to access. Ever see an Exabyte tape reset 6 times on >startup? If I never see an Exabyte again it will be too soon. The first SCSI interfaces for these tape drives were particularly bad. I hear they are pretty good now... By the way, was the six reset scenerio on a Mac Plus? The machines after the Plus got (marginally) better about this. -> 2) The system will only be as robust as the least compliant driver ->allows. -> 3) Using Apple's traps incurs moderate overhead for implementations ->which handle the SCSI protocol as a finite state automata. This overhead may ->be insignificant compared with the access time of the device. ->Rory Bolt (rory@fps.com) ***** >And now for a REAL hardware question: does anyone know enough about the >insides of the SCSI helper PALs for the SE and the II(x) family to be >able to categorically state whether the DMA ACK, cpu DTACK, and Bus Error >timeout logic preclude or allow data loss on read. [i.e.: If you get a >bus error, can you be SURE that a byte was not accepted from the SCSI chip?] >My suspicion is that data can be lost (in a small but non-zero timing window), >but then I may just have a program bug. >Marc Kaufman (kaufman@Neon.stanford.edu) As I understand your question, it is in reference to SCSIReadBlind trap which performs pseudo-DMA to the NCR5380. All that follows is valid only for machines newer than the Mac Plus. As disassembly has no doubt shown you, the Mac transfers a byte via polled mode at the top of the TIB data transfer loop and then allows the 5380 to hold off processor reads of the data port until the data arrives or a hardware timer expires (which generates the Bus Error). If you assume asynchronous transfer on the SCSI bus (the 5380 is not capable of synchronous transfer mode), the target is free to take as long as it wants between data bytes. The SCSI specification does not specify any timouts for asynchronous data transfers. Therefore it is possible for a device to take longer than the time-out value and generate the bus error during a valid operation. The amount over this time-out value is indeterminant and it is possible for a byte to be accepted by the 5380 after the bus error has occured. I have personally observed this to happen using a combination of an in circuit emulator and a SCSI protocol analizer. Since the first byte transfered via each SCInc or SCNoInc will be transfered via polled mode, the SCLoop TIB instruction can be used to tune your transfer timings to avoid bus error timeouts (this assumes that the transfer character- istics of the device you are communicating with are known). Disk drivers for the Macintosh typically use a TIB that loops for each sector to avoid the long delays between sectors (due to reassignment, interleave, step to next cylinder, etc). I once had access to a prototype Mac SE whose PAL's did not have the security fuse blown :-). If it is useful to you I could look up the exact value of this timer, though I can not say if it is the same as a production machine. Rory Bolt (rory@fps.com) Since we have beaten this dead horse to a pulp I will not respond publically to further postings on this subject. Feel free to email me with additional questions/comments.
kaufman@Neon.Stanford.EDU (Marc T. Kaufman) (12/12/89)
The sound you hear is that of crunched crow...
I just assumed that the current system acted like an earlier one -- wrong!
As you can see, system 6.0.4 does a respectable job of SCSI arbitration, and
EVEN seems to have provision for making the address of the Mac OTHER THAN 7!
Sorry for generating confusion.
By the way: If this kind of disassembly doesn't convince you to buy MacNosy,
you must not be doing real systems code (though I cheated a little by editing
in the symbolic SCSI offsets from HardwareEqu.a)
Marc Kaufman (kaufman@Neon.stanford)
-----
; This Disassembly of scsiGet via MacNosy - MacIIx, system 6.0.4
SCSiDispatch
11DFA: 205F ' _' POP.L A0
11DFC: 301F '0.' POP D0
11DFE: 2F08 '/.' PUSH.L A0
11E00: 0C40 0018 '.@..' CMPI #24,D0
11E04: 640A 1011E10 BHS.S mmw_1
11E06: 4E56 FFFA 'NV..' LINK A6,#-6
11E0A: 4EF9 4082 66B4 $8266B4 JMP.L com_366 ;selector in range
11E10: 4EF9 4082 66FE $8266FE mmw_1 JMP.L com_367
;-refs - SCSiDispatch
8266B4: 48E7 3F38 'H.?8' com_366 MOVEM.L D2-D7/A2-A4,-(A7)
8266B8: 2678 0C00 $C00 MOVEA.L SCSIBase,A3
8266BC: 2878 0C0C $C0C MOVEA.L SCSIGlobals,A4
8266C0: 7E00 '~.' MOVEQ #0,D7
8266C2: 7800 'x.' MOVEQ #0,D4
8266C4: 3200 '2.' MOVE D0,D1
8266C6: E548 '.H' LSL #2,D0
8266C8: 2074 0000 ' t..' MOVEA.L 0(A4,D0.W),A0
8266CC: 4ED0 'N.' JMP (A0) ;jump to selected routine
;note that 97 is (3*24-1) + 2
11E16: 08EC 0000 0061 '.....a scsiGet BSET #0,97(A4)
;set the low memory interlock
11E1C: 6708 1011E26 BEQ.S mmx_1
11E1E: 7007 'p.' MOVEQ #scMgrBusyErr,D0
11E20: 4EF9 4082 6744 $826744 JMP.L com_370 ;error return
11E26: 4EF9 4082 673A $82673A mmx_1 JMP.L com_369
82673A: 6100 019C $8268D8 com_369 BSR proc1517 ;do the arbitration
82673E: 6704 $826744 BEQ.S com_370 ;successful
826740: 1947 0061 '.G.a' MOVE.B D7,97(A4)
;failure - release lock
;-refs - scsiGet
826744: 3D40 0008 '=@..' com_370 MOVE D0,8(A6)
;return error code to user
826748: 60DA $826724 BRA com_368
826724: 7000 'p.' com_368 MOVEQ #0,D0
826726: 6000 01A4 $8268CC BRA com_372
8268CC: 4CDF 1CFC 'L...' com_372 MOVEM.L (A7)+,D2-D7/A2-A4
8268D0: 4E5E 'N^' UNLK A6
8268D2: 205F ' _' POP.L A0
8268D4: DEC0 '..' ADDA.W D0,A7
8268D6: 4ED0 'N.' JMP (A0) ;exit
8268D8: QUAL proc1517 ; b# =2163 s#0 =proc1517
;-refs - com_369
; A3 points to the SCSI chip
;note that 96 is (3*24-1)+1
;96(A4) contains '0x80', a '1' in bit 7
8268D8: 16AC 0060 '...`' proc1517 MOVE.B 96(A4),sODR(A3) ;our address
8268DC: 1747 0020 '.G. ' mdi_1 MOVE.B D7,sMR(A3)
8268E0: 7200 'r.' MOVEQ #0,D1
8268E2: 3238 0DA6 $DA6 MOVE TimeSCSIDB,D1
8268E6: E189 '..' LSL.L #8,D1
8268E8: 2A01 '*.' MOVE.L D1,D5
8268EA: 4845 'HE' SWAP D5
8268EC: 177C 0001 0020 '.|... ' MOVE.B #iDB,sMR(A3)
8268F2: 082B 0006 0010 '.+.... mdi_2 BTST #bAIP,sICR(A3)
8268F8: 56C9 FFF8 $8268F2 DBNE D1,mdi_2 ;wait for arbitration
8268FC: 56CD FFF4 $8268F2 DBNE D5,mdi_2 ; in progress
826900: 6608 $82690A BNE.S mdi_3
826902: 1747 0020 '.G. ' MOVE.B D7,sMR(A3)
;something is up on the bus
826906: 7003 'p.' MOVEQ #scArbNBErr,D0
;arbitration fails
826908: 4E75 'Nu' RTS
82690A: 6100 0364 $826C70 mdi_3 BSR proc1525 ;wait for arbitration
82690E: 082B 0005 0010 '.+....' BTST #bLA,sICR(A3) ;lost arbitration bit
826914: 66C6 $8268DC BNE mdi_1 ;yes, retry
826916: 7000 'p.' MOVEQ #0,D0
826918: 7400 't.' MOVEQ #0,D2
82691A: 1013 '..' MOVE.B sCDR(A3),D0 ;read who won
82691C: 142C 0060 '.,.`' MOVE.B 96(A4),D2
826920: B500 '..' EOR.B D2,D0 ;turn off 'us'
826922: B440 '.@' CMP.W D0,D2
826924: 65B6 $8268DC BLO mdi_1 ;the other guy won
826926: 082B 0005 0010 '.+....' BTST #bLA,sICR(A3)
82692C: 66AE $8268DC BNE mdi_1
82692E: 7000 'p.' MOVEQ #noErr,D0
826930: 4E75 'Nu' RTS
826C70: 3038 0D00 $D00 proc1525 MOVE TimeDBRA,D0
826C74: EE48 '.H' LSR #7,D0
826C76: 51C8 FFFE $826C76 mdq_1 DBRA D0,mdq_1 ;wait...
826C7A: 4E75 'Nu' RTS
-----neil@cpd.com (Neil Gorsuch) (12/12/89)
In article <1989Dec10.171249.2721@Neon.Stanford.EDU> kaufman@Neon.Stanford.EDU (Marc T. Kaufman) writes: >In article <1989Dec8.232535.14072@cpd.com> neil@cpd.com (Neil Gorsuch) writes: >.1. We only see 250 Kbytes per second data transfer rates, as opposed >.to 2.5 Mbytes per second on other machines, using our new scsi box. >I don't know WHICH model of Mac you are using. A Mac II can get 600 KB/sec >in handshaking mode and 1.5 MB/sec in "blind" mode (the mode really isn't >"blind", as there is a PAL that checks for REQ/ACK sequencing -- but there >is an inter-character timeout of about 2 microseconds in this mode). Yes, >the Mac uses a CPU loop, but on 020/030 machines that goes at least as fast as >a DMA would. It's a MAC SE, and it really does only get 250 Kbytes per second data transfer. I don't know MAC's, so I might have called it the wrong name in my original posting. -- Neil Gorsuch INTERNET: neil@cpd.com UUCP: uunet!zardoz!neil MAIL: 1209 E. Warner, Santa Ana, CA, USA, 92705 PHONE: +1 714 546 1100 Uninet, a division of Custom Product Design, Inc. FAX: +1 714 546 3726 AKA: root, security-request, uuasc-request, postmaster, usenet, news