Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!CORY.BERKELEY.EDU!dillon
From: dillon@CORY.BERKELEY.EDU (Matt Dillon)
Newsgroups: comp.sys.amiga
Subject: Re: Self-repairing SCSI disks!
Message-ID: <8810020207.AA23244@cory.Berkeley.EDU>
Date: 2 Oct 88 02:07:34 GMT
Sender: usenet@ucbvax.BERKELEY.EDU
Lines: 45


Greg Garner gmg@hcx.uucp Writes:
:While we are on the subject of scsi....
:
:How does everyone like the microbotics scsi controller? (Matt, I know
:you have one, do you like it?). I want to set up a hard drive on my
:1000, and I want to use an embedded scsi controller drive like the 
:st225n or st157n. Will the microbotics scsi (the one that goes in 
:the 2 meg expansion box) interface ok with these drives? What about
:the C ltd scsi interface?  And finally, is there a DMA hard disk interface
:for the 1000 without buying an expansion chassis? Thanks for the answers! 

	The only reason I have the microbotics SCSI controller is 
because I already had a StarBoard II when I started getting interested in
buying one.  The microbotics is hardly the cream of the crop, it *isn't*
DMA (note: I have an A1000).

	Judging by use and disassembling the code, the driver itself is
sound, but the support programs are very, very bad.  The main support program,
called MDFixer, is used to low-level format and verify the HD.  It crashes more
often than not.  The CLI-based text-menu based thing they provide on their
support disk is extremely (1) Slow, (2) Time Consuming, (3) Badly written,
and (4) provides very little help, instructions, or documentation.

	Fortunetly, I didn't have to use that stuff much.  Not owning any
other SCSI controllers I can't give a comparison, but once I got past the
initial junk I have had no problems using my HD.

	As I said at the beginning, the actual driver is sound once
you get past the support crap.  However, since the driver is based solely
on synchronous commands internally (i.e. asynchronous IO requests are done
synchronously), and since it must busy wait on the SCSI controller (not 
being DMA), I strongly suggest people set the Priority of the filesystems
in the Mountlist to 0 rather than 5.  The microbotics driver does not have
any critical timing requirements and thus they do not Forbid() or Disable()
inside it all that much, which means it essentially busy waits in the context
of the task which made the device call, which is usually the FileSystem.

	The way Amiga priorities work, the CPU is shared round-robin
fashion only amoung the highest priority tasks (all running at the same
priority).  Setting the filesystem priority to 0 means that all the other USER
tasks running in the system, such as your favorite editor or terminal program,
still get CPU even when the microbotics driver busy waits.

				-Matt