ftp.nice.ch/peanuts/GeneralData/Usenet/news/1991/CSN-91.tar.gz#/comp-sys-next/1991/May/PLI-Superfloppy-vs.-CubeFloppy+Floppyworks;-NeXTConnection

This is PLI-Superfloppy-vs.-CubeFloppy+Floppyworks;-NeXTConnection in view mode; [Up]


Date: Sun 09-May-1991 12:57:59 From: tenny@ootool.dec.com (Dave Tenny) Subject: PLI Superfloppy vs. CubeFloppy (DIT) & Floppyworks; NeXTConnection 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: 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.]
Date: Sun 09-May-1991 16:59:12 From: Unknown Subject: Re: PLI Superfloppy vs. CubeFloppy (DIT) & Floppyworks; NeXTConnection 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.
Date: Sun 09-May-1991 20:38:04 From: jim@ljkiraly.lerc.nasa.gov (L J "Jim" Kiraly) Subject: Re: PLI Superfloppy vs. CubeFloppy (DIT) & Floppyworks; NeXTConnection 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!!
Date: Sun 11-May-1991 03:25:05 From: scott@nic.gac.edu (Scott Hess) Subject: Re: PLI Superfloppy vs. CubeFloppy (DIT) & Floppyworks; NeXTConnection 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,

These are the contents of the former NiCE NeXT User Group NeXTSTEP/OpenStep software archive, currently hosted by Marcel Waldvogel and Netfuture.ch.