On Mon, 13 May 1996, M.R. Zucca wrote:

> What, exactly, is the firmware bug?

Aaaaargh!  Major goof.  Sorry.  I misremembered a previous post.  The ZIP
drives had a firmware bug, not the Syquest EZ135.  I wondered why I
couldn't find it in any of the files labeled EZ135.

Anyway,

> I kind of imagine the drive asking for
> n amount of data, the OS gives it to the drive, and the drive reports back
> n-m received. MacOS probably ignores step 3 and just figures the drive got
> it right or something.

I'm not even sure that it's been determined that the crashes are during
write ops.  It could be that the same thing would happen in a large scale
read.  Has anyone tried to untar a large archive from an EZ135 to a fixed
drive of known caliber?

> I still think the kernel should catch problems like this and at least attempt
> to correct them. Obviously there is *some* reliable way to get the data to the
> disk as seen in MacOS.

>From backreading earlier comments, I see that several drives have
troubles.  The conners from IIsi's and the like (40 and 80 both, I
think?), somebody's 7x0 meg drive, and... well....

> Of course, NetBSD and MacOS are worlds apart in many
> respects and SCSI is no exception but I think it's not totally unreasonable to
> be able to recover from the occasional SCSI bus error.

Would be nice.  Anybody with an EZ drive and an interrupt button manage to
figure out where it's crashing?  Oh that's right.  It's not crashing, it's
"freezing".  If I remember right, turning the drive off and back on wakes
the thing up?  Weird.  It's a question of someone who knows how and has
the time and equipment... checking to figure out what data the driver is
waiting for and why it's not receiving it.  I wouldn't even know where to
begin, nor do I have an interrupt switch.


About the SCSI driver, here's a possible approach.  Apple has a SCSI
Manager and driver structure already built into the ROMs.  Now I
understand that nobody wants to call ROM routines, but what if somebody
examined the ROM routines themselves and described how they worked so that
somebody could rewrite the code.  You know, the clean room thing.

With an emulation of the ROM SCSI code for each system, it would be
possible to simply use the RAM based SCSI Manager clone to read in (and
later purge) the drivers used on the drives already.  Thoughts?  It would
ensure 100% compatibility with any drive that runs under MacOS before
7.5... or was SCSI Manager 4.3 introduced back in 7.1?  I forget.

For that matter, why not disassemble SCSI Manager 4.3 extension and write
a routine to interface with it.  Then just make that usable for anybody
with System 7.5 to just cpin the... oh... resource fork.  Would be a
little touchy to make it into a binary, but possible....  Not much fun.
Never mind.  But the ROM thing?  What does anyone think?  Possible?

> Keep in mind that
> many devices might simply be designed for systems like MacOS and if they
> work for that OS the manufacturer doesn't give hoot about hobbyists running
> some rouge OS they built on the weekend. Never mind explaining to them that
> you're trying to do anything but run MacOS on you Mac. :)

Like the reason I couldn't get _anything_ out of Asante about their SCSI
boxes.  Not even the chip it uses for ethernet.  They wouldn't even tell
me something that I could take a screwdriver to the case and find out
myself!  Puhleeze.  :-)

Cheers,

 /---------------------------------------------------------------------\
|David A. Gatwood             And Richard Cory, one calm summer night,  |
|davagatw@mars              Went home and put a bullet through his head.|
|dgatwood@nyx.cs.du.edu              --Edwin Arlington Robinson         |
|http://mars.utm.edu/~davagatw -or- http://nox.cs.du.edu:8001/~dgatwood |
 \---------------------------------------------------------------------/