Sure, most operations were faster, but disk access speeds dropped to 50K/s from 600K/s because my trusty 2091 SCSI controller could only write to the older memory on the system bus, not into the higher ranges where the new CPU's associated memory exists (only the hardware on the new CPU board can access it). So, the OS transfers a sector at a time into the old memory then copies the data to the final destination (thankfully it has enough smarts to work in this situation). Yes, one sector at a time, thus making it very slow.
I found a few software patches that let the OS write more than one sector at a time, which speeded things up to a large fraction of the original speed. Still, the CPU board manufacturers had thought of this problem and had put a SCSI-2 controller on the board (as well as the CPU, memory, and an FPU). Great! I moved my 1G Quantum Fireball hard drive from the 2091 card over to a drive bay near the new CPU card (so that the cables would reach, bumping out my oldest floppy drive) and hooked it up. The drive spun up, made a few clunking noises, and spun down, then kept on flashing its little light. Not good.
Thinking it was something that could be fixed by a jumper change, I got lucky and found http://www.quantum.com/products/manuals/, a web page with detailed manuals on many of Quantum's drives. The Fireball was there, including pictures and jumper settings, and even an explanation of all the SCSI commands that it understands. Well, I found out about the termination jumper, but that didn't help. All the rest of the settings were only software programmable (by setting SCSI Mode Page values). I looked through the settings, looking for a plausable one that would fix everything. I found a suspicious SCSI Plug-and-play setting that was turned on by default. Maybe that would fix it.
Off to Aminet, for a SCSI configuration program. I found lots of programs for reading SCSI parameters, but none for setting them. A couple of weeks later, and a switch from GNU to SAS C (picked up cheap in a closeout sale) I had written AGMSSetSCSI, a program which reads the current SCSI Mode Page settings, edits them, and writes them back. To make a long night short (the one where I stayed up until 4am :-), I finally found out that I had to turn off the Plug-and-play feature and a turn off a disconnect while doing IO feature (this involved many rounds of plugging the drive into the 2091, changing parameters, plugging it into the new CPU board controller, testing).
The drive finally showed up in the new board's drive formatting software. Unfortunately, attempts to partition were forgotten after a reboot. Something was still wrong. A bit more fidding around revealed that the SCSI controller was running faster than the drive, so it got errors while reading the boot information. Fortunately there was software to slow it down. Now how do you run the slow-down software before it boots up so it can boot up? Well, you normally can't, unless you boot from a floppy disk, which is what I ended up doing. After a few more tweaks of the startup sequence, and resetting the don't disconnect during IO feature (it only needs the plug-and-play adjustment) I got it working perfectly.
Well, it ended happily. Now I get 1110M/s reading and writing speed from the Fireball and I can tweak the other SCSI parmeters with my new software (things like power down when idle, cache control).
Now back to the virtual file system project...
- Alex
Copyright © 1996 by Alexander G. M. Smith.