[comp.sys.next] PLI Superfloppy vs. CubeFloppy

tenny@ootool.dec.com (Dave Tenny) (05/09/91)

I have some information to relate about buying the above drives,
and some questions, since the one I bought isn't working well on my NeXT.

I called NeXTConnection (800-800-NeXT) all ready to order the PLI 
Superfloppy 2.8 for $449.  I have an "old" cube with 330mb Maxtor drive,
68040 board, and OD.

When I spoke the the person at NeXTCOnnection, they informed me that
the PLI superfloppy doesn't WRITE to DOS formatted disks!  I was very surprised.
The person then told me that the CubeFloppy with Floppyworks bundled package,
for $579, would not only write to DOS disks, but 1.44 MB MAC disks as well.

I didn't particularly care about MAC disks, but I did need to be able
to write IBMPC DOS compatible disks.  So I ordered the CubeFloppy. 
(Which to me, after buying my NeXt, and upgrade, and other stuff
 feels like "The World's Most Expensive Floppy Drive").

After the horse was out of the barn, and I mean right after ordering,
I called PLI (800-288-8754) to see if it was true that they're drive
wouldn't write to DOS disks.  (The Spring 1991 NeXT Software & Peripherals
guide says for the PLI "A 2.8 MB floppy disk drive for use with floppy
disks from NeXT and MS-DOS, OS/2, and UNIX-based computer systems".  It
doesn't say whether it will WRITE and format all those disks).

The PLI operator forwarded me to a technical support person who didn't
know the answer to the questions "will it write to DOS disks".  She apparently
asked around and then said "yes", but didn't have any further data.
I didn't feel this was a conclusive answer, so let my order with 
NeXTConnection stand.

I then asked some fellow NeXT owners if they knew from experience.
One of them has the PLI drive.  He says it reads, writes, and formats
DOS disks without a problem.  This would imply that the PLI support
person was correct in her brief way, and that NeXTConnection has 
(not intentionally I'm sure) sold me a bill of goods for $120 more than
I wanted to pay.

QUESTION 1:  IS THERE SOME PROBLEM WITH PLI SUPERFLOPPY 2.8 DRIVES
READING, WRITING, AND FORMATTING DOS FORMAT DISKS ON THE NEXT?

If not, I've got a bone to pick with NeXTConnection.

--------------------------------- Topic 2 ---------------------------------

So I hooked up the DIT CubeFloppy 2.9 and installed Floppyworks.  I DID
RTFM carefully before installing. The floppy drive is SCSI device 3,
and the floppy is device 0.  I didn't check the OD.  How do I get a list
of the SCSI device numbers to check for conflict?

Anyway, the default (#3) for the floppy drive works, MOST OF THE TIME.
There is no on/off switch, so I just leave it plugged in all the time.
Here's the problem:  the machine only boots about 50% of the time.
Sometimes it boots without a hitch.  Other times it stops.  
If I have the verbose ROM Monitor enabled, I see these messages like:

sc: couldn't complete

and then some messages about controller hangs, errors, and reboots.
Sorry, I don't have the exact text.  The messages which arise in the
event of a hang are always the same.

When the machine DOES boot, I notice that there is an

SD1: UNIT ATTENTION

near the announcement of the PLI device presence in the monitor boot log.
The boot process then waits and issues about 15 dots (".") while it waits
for some timeout or something from the floppy drive.

QUESTION 2: WHAT IS THE PROBLEM WITH THE CONTROLLER AND THE DRIVE?

Do I need to use a different device number for the floppy drive?
I wouldn't expect so.  When the machine *does* boot, all devices coexist
peacefully. But this 50/50 chance of a controller hang since the introduction
of the CubeFloppy to my system is unacceptable.  

If the manufacturers or reps of DIT, NeXTCOnnection, and PLI read this,
I'd appreciate help.  If NeXT owners have knowledge that will help, ditto.
I've read all the ongoing dialogue of people with floppy drive problems
on their cubes (for external drives), but I haven't seen this particular
problem in the dialogues.  Perhaps I just missed it.

Thanks folks!

Dave

[Who really doesn't want to be an unpleasant customer, but is approaching
 the frustration limit for paying the extra $120 for things I might not
 have needed, and expects the darn device to work FLAWLESSLY for the
 money, aside from general principal.]

juan@bitnerd (05/09/91)

In article <1991May9.131840.11866@engage.enet.dec.com> tenny@ootool.dec.com  
(Dave Tenny) writes about difficulty booting when he's got a floppy drive  
connected to his cube:

> ... Anyway, the default (#3) for the floppy drive works, MOST OF THE TIME.
> There is no on/off switch, so I just leave it plugged in all the time.
> Here's the problem:  the machine only boots about 50% of the time.
> Sometimes it boots without a hitch.  Other times it stops.  
> If I have the verbose ROM Monitor enabled, I see these messages like...

I've experienced similar difficulties.   I have a 660MB cube that was upgraded  
from a 68030 and a PLI supperfloppy.  After I connected to floppy, my system  
would not boot at all.

Enabling the monitor verbose mode resulted in similar messages to the ones Dave  
reports when the system was powered up.  Looking at the messages, it was clear  
that the system was trying to boot from the floppy instead of the hard drive.   
If at this point, I broke back to monitor mode (<command><command>tilde), and  
issued a "b sd" command to reboot the machine, it would boot just fine.

Here is what I think is going on.  The hard drive on my machine takes about 15  
seconds to spin up.  It's a loud drive (an HP full height) so I can easily hear  
the heads going through the initialization procedure.  On power up, the ROM  
monitor looks around for SCSI devices, and sees the floppy, but since the hard  
drive is not yet powered up, it does not see the hard drive.

I would expect that NeXT would have put some hooks in the code for this case,  
like waiting for a fixed period of time on power up, but apparently, it does  
not catch all cases.  Perhaps the HP drive has a longer power up time than  
other controllers.  Since this is a timing problem, I would expect that the  
problem would depend on the particular combination of drives in your  
configuration.  In Dave's case, perhaps the Cubefloppy and his hard drive take  
about the same time to power up, and that is why his system boots  
intermittently.

Here's a work around that I've been using.

1) Normally the monitor "boot command" parameter in the ROM monitor is set to  
boot from the hard drive.  Change the "boot command" command to be blank, so  
that on power up it does not try to immediately boot from SCSI.  Do this with  
the p command in the ROM monitor.

2) Enable verbose mode in the ROM monitor with the P command.

3) Steps 1 & 2 need be performed only once, since these changes are stored in  
the ROM.  Power down the system.

4) Now every time you power up the system, it will break to the ROM monitor,  
since the boot command is blank.  Wait until your hard disk is ready.  I can  
hear mine, you may have to experiment, and time the delay, if yours is not as  
loud.  At the ROM prompt, type "b sd" to boot from the hard drive.  It should  
boot just fine.

Note that in verbose mode, you see the PLI floppy waiting for about 15 seconds  
for a disk to be inserted.  This is the message with lots of dots that Dave  
Tenny mentioned in his post.  Just ignore this message.

It's not pretty, but it does work.

--
Juan Pineda
juan@apple.com
-- 
Juan Pineda

jim@ljkiraly.lerc.nasa.gov (L J "Jim" Kiraly) (05/10/91)

In article <1991May9.165912.1042@bitnerd.uucp> apple.com!bitnerd!juan (Juan Pineda) writes:
->In article <1991May9.131840.11866@engage.enet.dec.com> tenny@ootool.dec.com  
->(Dave Tenny) writes about difficulty booting when he's got a floppy drive  
->connected to his cube:
<Stuff Deleted>>

ME TOO.  - only I have a slightly different problem.  My external PLI
superfloppy keeps going away- lost from the SCSI chain.  (I have an
'040 upgraded cube running 2.0 with a number of devices on the SCSI
chain).  I generate hundreds of console log messages reporting that 
the cube can't find the PLI drive.  I've put extra terminators on, 
taken them off, changed the position of the devices in the chain, taken
everything off except the PLI drive and I still get these intermittent
losses.  I've called PLI 4 or 5 times and can't seem to find anybody 
who knows anything about the drive or who can make any kind of comment.
The last time, I was told there was a bug in the NeXT ROM monitor and 
that I should reboot as soon as the diagnostic monitor messages reached
the PLI mount. -- This sounds like the problem previously discussed 
with the slow powering up of the boot disk.  I called the NeXT tech
rep and he said he knew of the latter problem on some systems but 
never heard of the problem I am having being related to a ROM problem.

Anyway, I am going to have to return the drive as soon as some of the 
software that I am waiting for arrives and can be loaded.  BTW, the PLI
drive does write to DOS formatted diskettes without any problem.

PLI folks, please get some technical support people who are capable
of answering technical questions.  Your poor response will certainly
influence my future purchasing decsions!!
--
___________________________________________________________________________
  Jim Kiraly  - jim@ljkiraly.lerc.nasa.gov  -  NASA Lewis Research Center
---------------------------------------------------------------------------

scott@nic.gac.edu (Scott Hess) (05/11/91)

In article <1991May9.165912.1042@bitnerd.uucp> juan@bitnerd writes:
   In article <1991May9.131840.11866@engage.enet.dec.com> tenny@ootool.dec.com  
   > ... Anyway, the default (#3) for the floppy drive works, MOST OF THE TIME.
   > There is no on/off switch, so I just leave it plugged in all the time.
   > Here's the problem:  the machine only boots about 50% of the time.
   > Sometimes it boots without a hitch.  Other times it stops.  
   > If I have the verbose ROM Monitor enabled, I see these messages like...

   Enabling the monitor verbose mode resulted in similar messages to the
   ones Dave reports when the system was powered up.  Looking at the
   messages, it was clear that the system was trying to boot from the
   floppy instead of the hard drive.  If at this point, I broke back
   to monitor mode (<command><command>tilde), and issued a "b sd"
   command to reboot the machine, it would boot just fine.

   Here is what I think is going on.  The hard drive on my machine
   takes about 15 seconds to spin up.  It's a loud drive (an HP full
   height) so I can easily hear the heads going through the
   initialization procedure.  On power up, the ROM monitor looks
   around for SCSI devices, and sees the floppy, but since the hard  
   drive is not yet powered up, it does not see the hard drive.

This is the case.  We've had this problem with some high performance
drives connected to the NeXT.  Basically, these drives were pushing
the technology (or something) and took quite a while to power on/spin
up.  The machine would then try to boot off the darn floppy . . .
NeXT needs to put in some ROM code to allow the setting of a delay
time to let the disk spin up.

[BTW:  The drive was exceeding fast, 650M, Core (I believe).  It
 was pretty much the same drive as the NeXT one, but with a better
 controller (or something).  Anyhow, it was _fast_.  Probably about
 as fast as the 400M in the NextStations, which is also faster than
 the 600M, so far as thumbnail tests indicate.]

Later,
--
scott hess                      scott@gac.edu
Independent NeXT Developer	GAC Undergrad	<almost out!>
<I still speak for nobody>