Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!usc!ucsd!ucsdhub!celit!rory From: rory@fps.com (Thomas (Rory) Bolt) Newsgroups: comp.sys.mac.hardware Subject: Re: Sharing the SCSI bus? Message-ID: <5168@celit.fps.com> Date: 11 Dec 89 23:12:48 GMT References: <1989Nov29.030959.27969@Neon.Stanford.EDU> <8252@pogo.WV.TEK.COM> <1989Dec5.165138.5192@Neon.Stanford.EDU> <4945@celit.fps.com> <1989Dec7.090026.16543@Neon.Stanford.EDU> Sender: daemon@fps.com Reply-To: rory@fps.com (Thomas (Rory) Bolt) Distribution: na Organization: Bolt Technologies Lines: 341 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.