PAUL KIENITZ'S STUFF FOR SUCKERS WITH XEBEC HARD DISKS I have an excuse for why I got mine: it was part of a used system at a good price. What's your excuse? If you have a Xebec 9720H or other Xebec hard disk on your Amiga, these two programs may be helpful to you. The first one, called Scum (short for scsi mount) is for getting the Fast File System to work on the Xebec. The problem is, even with the best Mountlist entry I can come up with, Mount will not successfully mount a FFS partition on a Xebec unless first you either mount another partition with the Slow File System, or run Scum instead. Scum is an extremely simple program, and I have no idea either why it works or why it's necessary. Note that the Xebec provided SCSIMOUNT program can't use FFS. Using Scum is several seconds faster than mounting another partition from floppy disk, so even if you have such a partition (as I do; I use it as a sort of experimental animal) Scum is still worth having. It returns error code 10 if it fails (if it can't find devs:scsi.device). EVERY ONCE IN A WHILE, something seems to hang up in my startup sequence. I don't know whether it's Scum or Mount or what, but it seems safe to assume that this program, which never should have been necessary in the first place, is not a perfect solution. If your startup sequence freezes up when it's just getting going, simply give it the old triple finger to start over. Here is a working Mountlist entry for a Xebec 9720H with no partitions: DH0: Device = scsi.device Unit = 0 Flags = 0 Surfaces = 4 BlocksPerTrack = 17 Priority = 10 Reserved = 1 LowCyl = 0 HighCyl = 614 /* Don't believe the manual when it says 611 */ Buffers = 30 /* or whatever */ BufMemType = 3 DosType = 0x444F5301 StackSize = 4000 GlobVec = -1 FileSystem = L:FastFileSystem Mount = 1 # And here is a pair of mountlist entries for one with a large FFS partition and a minimum size slow partition: DH0: Device = scsi.device Unit = 0 Flags = 0 Surfaces = 4 BlocksPerTrack = 17 Priority = 10 Reserved = 1 LowCyl = 2 /* number of cylinders used by slow partition */ HighCyl = 614 Buffers = 30 /* whatever */ BufMemType = 3 DosType = 0x444F5301 StackSize = 4000 GlobVec = -1 FileSystem = L:FastFileSystem Mount = 1 # SLOW: Device = scsi.device Unit = 0 Flags = 0 Surfaces = 4 BlocksPerTrack = 17 Priority = 10 Reserved = 1 LowCyl = 0 HighCyl = 1 /* last cylinder before first FFS cylinder */ Buffers = 4 BufMemType = 3 DosType = 0x444F5300 StackSize = 1000 Mount = 1 # (Actually, I put my own slow partition at the high cylinder end.) Typical use in a startup-sequence: setpatch ; if you've got release 1.3 scum mount dh0: movesys dh0: ; reassigns SYS:, C:, DEVS:, etc -- see MoveSys ; probably in the CLImax directory on this disk If you want to create some new arrangement of partitions, you don't need (in fact you should certainly avoid) the Xebec MAKEPART program. Just get the mountlist entries right and then FORMAT QUICK should do ya just fine. If you used MAKEPART before, I think you'll have to reformat all partitions even if none of them are different, because Xebec puts the partition information on the disk and Mount doesn't. You don't need HDPARMS any more. ---------------- The other program is a replacement for the bloated and cumbersone Park program provided by Xebec. It assumes the disk is unit zero; this can be easily changed by anyone with a C compiler (Aztec, hopefully) in the unlikely event that you have some other device on the SCSI chain before it. You just type Parx or double click the picnic table icon and the disk parks. It's one twentieth the size of their Park program. This leaves you with no need for any Xebec software except scsi.device, and HDINST if you ever need a low-level SCSI format (I think that's what you use to map out bad sectors). All in all, I'm extremely unimpressed with Xebec "the zero defect company". Though I must admit that the hardware has never had trouble (why should it? it's mature, well-understood (i.e. obsolete (85ms)) technology) the software is dog meat. I once started disassembling the device driver (while figuring out how to write Parx) and within minutes found two busy-wait loops, as well as ridiculous code which essentially replaced the Exec message passing mechanism with a strange ring-queue and signal arrangement with no discern- ible improvement over regular messages. And I doubt that it's really necessary for the disk unit to weigh eleven pounds and take up as much desk space as the keyboard does. This stuff is public domain; any feedback is appreciated. Like, if you want a Parx not restricted to unit 0, let me know. Paul Kienitz 6430 San Pablo ave Oakland CA 94608 USA (°¿°) <- Official Seal of Dorkiness certifies that Scum and Parx were written without the use of ROM Kernel Manuals.