's worth doing, but there's an easier way.
The Iomega parallel Zip drive has become something between a standard and a necessity. Attach it to the parallel port of any PC, run one "guest" program from a floppy disk or your hard disk, and yo
u have a 100-MB removable-cartridge drive to use for backup and file transfer. It's extremely well behaved, attaching itself as the next unused drive letter, and it leaves no residual problems when you disconnect it.
The last time I talked about the parallel Zip drive, I casually said "alas, no Mac." Since a Mac has no parallel port, that seemed obvious enough. I have since got a ton of e-mail, some polite, reminding me that the SCSI version of Iomega's Zip drive works just fine with Macs.
Some of the mail was nasty. I know a columnist who swears he will never again mention Macs because he's weary of the hate mail he gets whenever he writes anything but fulsome praise about the Mac. Although I guess I have a bit thicker skin, really, people, you do your cause no good this way. Save your hate mail for your enemies, or better yet, for archiving before you send it.
Anyway, I have a SCSI Zip drive, and, indeed, it works with Macs. With System 7.5's PC Exchange (or a similar utility), the Mac can read
DOS-formatted Iomega disks, so you can use the Zip drive as a convenient sneakernet with backup for transferring data files between Macs and PCs.
The SCSI drive is a lot faster than the parallel drive. It took 6 minutes to transfer 44 MB (some big files, lots of small ones, a complex subdirectory structure) from a hard drive to the parallel Zip drive; doing the same operation with the SCSI Zip drive took just under 2 minutes. Writing that 44-MB directory from the parallel Zip drive to a hard drive took about 5 minutes, as opposed to about 1-1/2 minutes with the SCSI Zip drive. If you're after speed, or you want to transfer from a PC to a Mac and back, clearly you'll want the SCSI version. On the other hand, if what you want is backup and convenient file transfer among PCs, the parallel version is preferable.
The SCSI Zip drive will run off any standard SCSI controller, or you can buy Iomega's SCSI controller card, which appears to be a standard Adaptec SCSI-1 card. Installation for using it with the Z
ip drive is well documented. My advice is to get an Adaptec SCSI-2 card, but the Iomega card will certainly work. Installation of a SCSI card is simple provided you have a free interrupt request (IRQ). DOS-only systems don't need an IRQ.
For my first test, I connected the SCSI Zip drive to the SCSI outlet of the Distributed Processing Technology caching drive controller on Pentafluge, the Pentium 60 system we built a couple of years ago. This is an older controller that requires a jumper setting to activate the external SCSI port. I long ago set it to make the external port active and keep a Granite Digital SCSIVue Active Diagnostic Terminator on the port when no other device is attached, so I don't have to go inside Pentafluge to install a SCSI string.
It would have been a lot simpler if I'd had the right cable; alas, the SCSI output on Pentafluge's controller is a standard 50-pin SCSI-2 connector, while the Zip drive wants a DB-25 cable. The cable that comes with the SCSI Zip drive is a male-to-male
DB-25 that looks exactly like a heavy-duty parallel-port cable.
Of course, the potential for accidentally plugging the SCSI Zip drive into a parallel port, or the parallel Zip drive into a SCSI port, is pretty high. I don't know what would happen, but I sure wouldn't want to try it.
Pournelle's first law of making SCSI work: start with Granite Digital SCSIVue Gold Diagnostic Cables and don't change to anything else until you have everything working properly. Granite Digital makes the High Density MicroD 50/DB-25 Cable, a SCSI-2-to-DB-25 cable, but I didn't have one and didn't want to wait. Thus, I connected the Pioneer DRM-624X six-disc CD-ROM changer to Pentafluge with one Granite Digital cable and used a Granite Digital 50 Centronics/DB-25 Cable to daisy chain the SCSI Zip drive to that. The SCSI Zip drive has a switch on the back to set termination: it was the last drive in the SCSI string, so I set it to "on."
The Zip drive also has a switch that sets it as SCSI ID 5 or 6; I set it to 6. Then
I brought up the system with no cartridge in the drive and with the DRM-624X turned off and thus inactive.
Windows 95 (Win 95) came up fine, ignoring the DRM-624X as it should. There was one hitch. Pentafluge has logical hard drives C and D, a Maxoptix T3-1300 optical drive as E, and the CD-ROM drive as F. The SCSI Zip drive had taken over the F slot, moving the CD-ROM drive to G. I described a similar experience with the Syquest EZ135 SCSI hard drive in the June column. I got quite a bit of e-mail from people telling me, with various degrees of politeness, that SCSI drives take over in the order of their SCSI ID number, so I'd hoped that setting the SCSI Zip drive to ID 6 would prevent that shift. Alas, that turned out not to be the case.
Once I had the SCSI Zip drive operating, I timed some massive file transfers across the network and then shut down the system.
I got the "Please Wait" message. After about 5 minutes, it was pretty obvious that nothing else would happen, so I cut the main power.
When I turned it back on, Pentafluge trundled for a while and then Win 95 announced there were problems with the Registry. It offered to restore the Registry from backup and try again, warning me that I might lose something in the process. There didn't seem to be much of an alternative, so I told it to go ahead.
I got the same message once more, and once more told it to go ahead. Recall that the first time I brought up the SCSI Zip drive, I did so with no cartridge in the drive. I had forgotten that, and there was a cartridge in the drive this time.
The system came up on the third try, and Lo!, the drives were really out of order. The D drive, which is merely a logical partition of a single physical drive, had been moved and the SCSI Zip drive had taken over D. E was still the Maxoptix T3-1300, F was now the D drive, and the CD-ROM drive that normally lives at F was now G. All those drives worked in the sense that I could access them, but any software that expected the D drive to be D was hosed.
Shut down once more. This time, it shut down with no problem, and I have been unable to duplicate the shutdown problem on any machine since that first time. I've no idea what happened. Anyway, I removed the cartridge from the SCSI Zip drive and fired up once more. It came up fine. The D drive was once again D.
Of course, the Zip drive had shoved the CD-ROM drive aside and taken over F in its usual high-handed fashion, but otherwise I had no problems. This time it shut down properly, and from that moment on, I have had no problems other than the displacement of the F CD-ROM drive.
The moral of this story is that SCSI has a mind of its own, and if you intend to use a SCSI Zip drive, plan your drive-lettering scheme accordingly. Do not imagine that you can have a CD-ROM drive with a lower drive letter than the SCSI Zip drive; and if you plan to boot up your system with a cartridge in the drive, be prepared for some other oddities in drive lettering.
You will, however, have a perfectly good drive. You
can even boot from it, which means that you can have a series of OSes on different Zip cartridges and boot the one you like. I've tested it with Win 95 and Windows 3.11. I haven't yet tried it with Unix, Windows NT, or any flavor of OS/2, and I probably won't; but I'm told it will work just fine with those, too, since you can set up your computer to believe that the SCSI Zip drive is just another Winchester hard drive. Incidentally, that's also true of the Syquest EZ135.
One possible configuration is to have a hard drive as the data drive. Set it as a nonprimary drive and then set a Zip drive as the C boot drive. Then you can boot any OS you like by changing cartridges.
Once I was sure the SCSI Zip drive worked on Pentafluge, I transferred it to Cyrus, my Cyrix 6x86-P166 system. Cyrix claims their P166 is completely compatible with, and faster than, a Pentium running at 190 MHz. I've used the Cyrix system for a couple of months now, and I have no reason to dispute that claim. It is fast, compatible,
and reliable.
Cyrus has a PCI-bus Adaptec SCSI card with an external SCSI-2 connector port, so I moved the DRM-624X and SCSI Zip drive string over to it, and booted up with the DRM-624X turned off and no cartridge in the Zip drive. It came up fine. Cyrus does not have a Maxoptix optical drive, so the CD-ROM drive is E. As expected, the SCSI Zip drive displaced it, taking over the E slot for itself and moving the CD-ROM drive to F.
Unlike Pentafluge, Cyrus had a network drive mapped to F, but that didn't matter. The SCSI Zip drive became E, the CD-ROM drive became F, and the F network connection vanished. Actually, it didn't quite vanish. While I could read the CD-ROM drive as F, when I went into My Computer and looked at network drive connections, the pull-down menu still showed F as a network connection.
Shutdown was normal, and booting up with a cartridge in the Zip drive produced no different result from when there wasn't a cartridge. That is, while booting with a cartridge displaces the D part
ition on Pentafluge, it doesn't do that on Cyrus. No one I've spoken to can tell me why.
The next step was to connect both Zip drives to Cyrus. They worked fine, with the parallel drive taking the next empty drive letter (G), while the SCSI drive displaced the CD-ROM drive as usual. Finally, I turned on the DRM-624X, leaving both Zip drives attached to Cyrus. Everything worked. The SCSI Zip drive took over E; the internal CD-ROM drive became F; the DRM-624X took over G, H, I, J, K, and L; and the parallel Zip drive took the lowest unused drive letter after L.
The interesting thing about this is that several of the drive letters between F and L had been mapped to other network drives. Those network connections simply vanished -- except that their ghosts remained in the network setup, and booting up with the DRM-624X turned off restored them.
The bottom line here is that both parallel and SCSI Zip drives work quite well. They read each other's disks just fine. The parallel Zip drive installs simply
and works unobtrusively, finding an unused drive letter for itself.
The SCSI Zip drive installs easily if you already have SCSI devices; otherwise, you will have to install a SCSI card and drivers. This isn't particularly difficult, but it's certainly harder than just connecting a cable to the printer port. The SCSI Zip drive is more aggressive and will certainly displace a CD-ROM drive if brought up with a cartridge in the drive, and it may even displace a hard disk partition. You are unlikely to prevent this no matter how hard you try. Otherwise, no damage is done.
The SCSI drive is about three times as fast as the parallel drive and perhaps half as fast as your average hard drive. Either can be a good way to add storage capacity to your system. I particularly like the parallel Zip drive as a backup-and-sneakernet system, but, of course, unlike the SCSI Zip drive, you can't use it with a Mac. The SCSI drive works well with both Macs and PCs. If you need storage space and a backup system, either is
pretty hard to beat. Recommended.
Having said all that, I have to point out that I have for about a year had a Fujitsu DynaMO 230 magneto-optical (MO) system attached to a SCSI port on an ancient Cheetah 386. I've used it across an Ethernet, and it's about as fast as the SCSI Zip drive. It has always been reliable. Nothing in the Fujitsu literature mentions using this on a Mac, but SCSI is SCSI, and I'd be astonished if you couldn't connect the DynaMO 230 to a Mac. What you won't do is read the DynaMO cartridges on a parallel-port device. Still, the DynaMO 230 works. The drive and cartridges are smaller than the Iomega Zip drives and their cartridges, and each DynaMO cartridge holds a bit more than 200 MB compared to the Zip drive's 100 MB.
We installed the beta version of NT 4.0 on the Doubleshot 133,
which had previously been running NT 3.51. At one time, it ran OS/2, and I had hoped that Merlin, the newest version of Warp, would be able to make use of the Doubleshot 133's dual proc
essors, but IBM didn't put that feature in Merlin. IBM is beta-testing SMP for Warp Server. For now, to run OS/2 with symmetric multiprocessing (SMP), you are stuck with clunky OS/2 2.11. While I rather like OS/2 Warp Connect, and I think I like Merlin, I refuse to go back and relearn version 2.11.
Installation of NT 4.0 was really simple on the Doubleshot 133. I haven't yet tried installing it on a machine running Windows 3.1 or Win 95; I'm told that's a bit more difficult, but nothing excessive. One thing, though: be sure you know the IRQ and port address settings for all your hardware. Unlike Win 95, NT doesn't even try to be Plug and Play. On the other hand, it won't change your settings for you once you have them the way you like.
We haven't done a lot of work with NT 4.0, but what I've seen I like a lot. It's much more like Win 95 than 3.11. In fact, you can use NT 4.0 quite a while before you notice it isn't Win 95. It's also faster. Although few current applications have threaded code able to
take advantage of the Doubleshot 133's dual processors, ordinary single-threaded jobs are still faster because NT 4.0 is able to trade off between processors, putting all the background stuff like network and disk operations, monitoring the uninterruptible power supply (UPS) status, etc., on one processor while the other runs your task.
In practice, it's not quite that simple. NT 4.0 has a utility that shows a graph of processor-use history. There are two such graphs for a dual-processor system, and it's interesting to watch how NT switches loads between processors as you load it down by networking to the server.
There was a time when OS/2 was a technically more elegant OS than NT, and OS/2 Server was about the best server software around. I don't think that is true any longer; IBM long ago lost the marketing edge and may now have lost the technical edge as well. NT 3.51 is very stable and makes for a good server system; while NT 4.0, even in the beta version, is fast, easy to use, simple to install,
and looks like Windows to most of your network. Moreover, IBM is rapidly adapting its server software to run just fine on NT systems. If you have a large computer network system and the resources to manage it, you may have a need for OS/2; but NT 4.0 seems to be the NT for the rest of us. More when I know more, but my first impressions of NT 4.0 are very positive.
Meanwhile, the little Doubleshot 133 remains the quietest system in the house. It's very stable, and running NT 4.0, it may be the fastest networked system we have here. Those dual processors really speed things up. Just now, it is the NT experimental machine, but once I'm sure NT is stable, I think I'll put the Micropolis external 4-GB drive on the Doubleshoot 133 and make it the main Chaos Manor server.
Visioneer's PaperPort Vx is a blooming little miracle.
This is a gadget about 4 inches tall, 3 inches deep, and a foot wide. It sits anywhere you like and connects to a serial port with a normal cable. Once installed,
you activate it by feeding it a sheet of paper. It reads your papers, one sheet at a time, into image files, one file per sheet.
Installation was simple: I plugged the PaperPort Vx into the COM1 serial port, connected its power supply, and ran the installation program. The software seems to have scanned my system, because when it was done, the PaperPort "desktop" had icons for Microsoft Word and WinFax, as well as "printer," Exchange, Excel, WordPad, and Paint.
I fed in a printout of some e-mail I'd received on BIX. The PaperPort Vx pulled it through and quickly made an image file of the document. Then I dragged the image onto the WinFax icon and sent it to my fax machine downstairs. It came out quite readable, as good as any fax comes out on my old thermal fax machine.
Then I dragged the image onto the Microsoft Word icon. That automatically activated the OCR to produce a Word document. It made one mistake: the original said "pc." The OCR read that as "pe."
I've also fooled around with other
stuff. There are a bunch of settings to get different qualities of OCR performance and image quality. It's all quite intuitive, and now I've got electronic versions of some newspaper articles I've been saving, meaning I can find them by electronic search now. I think I'll do a lot more of that.
I had one major glitch. Once when I fed in a sheet of paper, the electric fan blew it about as it emerged, and the program said the read had failed, although examination of the document image didn't show any problems. After that, though, the PaperPort Vx wouldn't feed paper at all, and the software kept telling me there was no PaperPort device on COM1. I even tried turning off the computer and bringing it back up, and still the Visioneer software insisted there was no PaperPort on COM1. Finally, I turned off the PaperPort itself by pulling its power cord. That worked: it processed the next sheet of paper I fed it just fine. Apparently that "reset" it.
Visioneer also makes a keyboard with a PaperPort built into
it, called the PaperPort ix. It has a separate power supply, so presumably you can "reset" it the same as with the stand-alone version. I'm fairly picky about keyboards, so I haven't tried it yet, but I'll have one of the interns install it at his station. I'm sure it will work; my only question is whether I'd like the PaperPort ix as a keyboard. More another time.
Disk space keeps getting cheaper. You can put a lot of documents on a 100-MB Zip cartridge; and that's a lot of paper you don't have to keep around. My son Richard uses a PaperPort to keep his paper files small, and it sounds like a good habit to get into. I expect I'll be writing about this again.
You'll have noted that my primary e-mail address
both.
BIX isn't for everyone. It's small, and the interface is text-based and command-line-driven. It looks old and clunky. The appeal of BIX is the information density. BIX never exploded the way the Internet did, and as a consequence, there are intelligent technical conversations and very little spam. When you ask a question on BIX, you get a reliable answer.
My usual access to BIX is through a shareware program called Galahad. This is a Windows/Win 95 program that goes out to BIX, logs on, downloads all my e-mail and all the message traffic in the conferences I belong to, and then logs off, letting me deal with everything off-line with reasonable text editors. It's one of the main reasons I stay with BIX.
The main problem with Galahad has been using it on multiple machines. Galahad keeps all kinds of reference files, archives, and databases, and transferring all that when I want to use a different machine is a major pain. Then, just today, on BIX, BYTE technical editor Russell Kay suggested th
e solution: put Galahad -- program, logs, files, and all -- on a Zip cartridge. Carry the Iomega parallel Zip drive in checked luggage -- a good idea for a backup system since I do a lot of work on the road -- and access BIX that way. When I get back home, I attach the Zip drive to the parallel port of the system I'm using.
I haven't tried this, but I will. I'll probably go even further: since I have five Internet accounts and three e-mail boxes, I'll put all that Internet stuff on a Zip cartridge. Working out a backup system shouldn't be too difficult. Yet one more use for the parallel Zip drive.
Meanwhile, BYTE readers weary of the bickering and nonsense in much of the Internet might think about BIX, where all conferences are moderated and most of the participants really do know what they're talking about.
Two vital books for computer pros:
The Hard Disk Data Base
and
The BIOS Companion
, both by Phil Croucher, and both exactly what their titles imply. If you wo
rk with odd computers, particularly older ones, these are invaluable: page after page of technical data, all in one place.
The
game of the month
is the Strategic Studies Group's The Complete Carriers at War. All the older Carriers at War games and construction tools, plus new scenarios, including the North Atlantic and Mediterranean. Suppose the Germans had gotten control of the entire French navy: could the British have beaten the combination? Plus the entire Pacific carrier war. Lots of realism and no arcade action.
The
CD-ROM of the month
is The 1996 Grolier Multimedia Encyclopedia. It's well balanced between details and brevity. Philip Jose Farmer defined a dullard as a person who can go to the encyclopedia, look up one item, read it, and close the book. It's fun to browse Grolier.
The
book of the month
is by Cicely Veronica Wedgwood,
The Thirty Years War
(Routledge). I thought I knew all I wanted to about the Defenestration of Prague
, Friedrich the Winter King, Father Tilly, Cardinal Richelieu and Father Joseph "the gray eminence," and Wallenstein, but once I opened this wonderful book, I found a wealth of details more fascinating than any novel. Part of Hitler's popularity came from his promise to upset the Peace of Westphalia that ended the Thirty Years War.
The
computer book of the month
is by Gary Frerking, Nathan Wallace, and Wayne Niddery,
Borland Delphi How-To
(The Waite Group). I've neglected Borland Delphi in my language discussions, and I shouldn't: it's a practical language every bit as useful as Visual Basic, and, being rooted in Pascal, it has a more logical structure. The book teaches through examples and includes a CD-ROM with hundreds of subroutines that are useful in themselves as well as worth studying.
A computer book I overlooked when it first came out is Susan A. Kitchens'
The KPT Bryce Book
(Addison-Wesley). Bryce is the landscape-generator software portion of the Kai's Pow
er Tools series; Kai's Power Tools are one of the reasons Mac computers are so much fun. Kitchens starts with basics and explains how to build structures, from castles to planets, with examples, including the inevitable CD-ROM of routines and pictures. If you use a Mac, you'll like this.
As usual, I've written more than will appear in the magazine. You can find it on BYTE's Web site. You might also want to check out
http://www.earthlink.net/discontinuity
, where John C. Dvorak and I argue critical issues.
Of Zip and Spam and NT 4.0
