Life Support for an Old PC by Fred C. Macall September 2004 When Zeke's ST-225 disk and disk controller set went bad this summer, I didn't have another replacement set for it. Zeke is my late '80s vintage Zenith PC XT clone. I cherish it for testing old PC software like DosLynx because it has a switch selectable choice of 8088 and 80286 processors. It has 640 KB of DOS ram, an additional 256 KB of EMS ram, a Hercules video adaptor and a 19.2 K bits/second dial-up modem. This is a PC that came with DOS v3.3 and doesn't qualify to run Windows. But, I have it connected to my home LAN and on to the Internet, via its parallel (printer) port, with PLIP and other DOS software. This is explained in: http://users.nccw.net/fmacall/PLIP112.TXT Several months of garage sale and curb-side shopping have yet to locate a replacement disk for Zeke. This is largely because Zeke's 8-bit ISA adaptor bus more or less precludes attaching an ATA IDE interfaced disk drive. (The ATA IDE interface was designed, a few years after Zeke was built, for the 16-bit ISA adaptor bus introduced in the IBM PC AT. One company is said to have made IDE attachment cards for the 8-bit ISA bus. But, just try to find one of those today.) At the same time, I've been pursuing some other approaches for replacing Zeke's disk. I have a few old SCSI interfaced disk drives lying around. So, I've been looking for an 8-bit ISA SCSI controller card for attaching one of those. A lot of these have been made for attaching scanners to PCs. However, these controllers have 25 pin D connectors for external scanner cable connections. While my old disk drives have 50 pin connectors for internal ribbon cable connections. Finding suitable disk device driver software for one of these cards seems to be another obstacle that would have to be overcome. After taking another look at another old PC, which has been standing by to provide replacement parts for Zeke, I realized that its Hercules video card also carried a parallel (printer) port. Zeke's original parallel port is provided by its memory card, while its video card carried a serial port. So, Zeke could have a second parallel port, for a cost of only its unused serial port, by replacing its video card. I've made that change and that has opened up a number of possibilities for Zeke. For a while, I ran Zeke on a parallel port connected Zip 100 drive using unpublished device driver software. (Iomega's device driver and GUEST software is said to require a '386 or later processor.) Three 32 MB partitions fit neatly on a Zip 100 disk! (32 MB is the maximum partition size that DOS v3.3 fully supports.) While the Zip drive was a little slower than the ST-225, it worked pretty well and gave Zeke about five times as much space. One problem with the Zip drive was that DOS v3.3 always spent about eight seconds determining one of its partition's free space, each time that was requested. By default, DosLynx still makes a number of free space inquiries from its idle loop. (Even though those were greatly reduced in DosLynx v0.20b. See: Annoying Disk Activity, in: http://users.nccw.net/fmacall/dlx20/history.txt .) So, those eight second responses were making DosLynx real sluggish! Fortunately, I found that DosLynx has an undocumented /U command line option pretty well suited for avoiding this problem. (I promise to add the /U option to the README.HTM at the next release of DosLynx!) It is like the /B command line option, in that it tells DosLynx to omit some of its progress reporting. However, unlike the /B option, /U doesn't suppress reporting of Messages and communications progress. Either /B or /U keeps DosLynx from making any of those trouble prone free space inquiries. Only one thing really kept me from being satisfied with the Zip drive solution for Zeke. The parallel port Zip drive seems to have gone out of new production sometime in 2000. So, the two Zip drives I now own may represent my lifetime supply of them! The thought of wearing out one of these precious drives keeping Zeke alive took a lot of the fun out of doing that. Other parallel port enabled storage solutions I've considered are: The Trantor (now merged into Adaptec) parallel port to SCSI adaptor. The MicroSolutions (http://www.micro-solutions.com) parallel (or USB) port connecting Backpack hard drive. And, DOS v6.x's INTERLNK/INTERSVR software for making Block Device connections between a pair of PCs. This software was also included in Windows 95. Well, the Trantor adaptor seems to present no fewer complications than the SCSI controller approach discussed above. And, while a used Backpack drive might be a good match for Zeke, the present new models start at 40 GB and cost at least $ 129 (wholesale?). Would it be possible to put three or four 32 MB partitions on one of these? But, say, why not devote another old PC to Zeke's life support, by means of the INTERLNK/INTERSVR software? Would Zeke even know or care if its support PC should happen to be Pentium based?! I did happen to have a mature Pentium based PC available to provide life support for Zeke. I've named it Hank. If Hank hadn't been handy, I think I know of a second hand store where I could have gotten a machine like Hank for about $ 15. Once set up, this machine doesn't need a monitor. Although I'm sure this isn't necessary, I decided to partition and format Hank's 2 GB drive with Zeke's DOS v3.3 software. I was able to attempt this by means of a DOS v3.3 Boot diskette that was able to Boot Hank. Well, the PART command, which is the Zenith DOS v3.3's forerunner of FDISK, was somewhat challenged by the size of Hank's disk. However, it was able to put down a valid primary 32 MB partition, an additional pair of imperfect 32 MB partitions and an imperfect 512 MB final partition. I used fdisk from a diskette based Linux rescue system to touch up those imperfect partition tables. The PART command didn't object to seeing the touched up partitions. The partitioning described above left about two thirds of Hank's 2 GB drive unused. It is interesting that the DOS v3.3 PART command would attempt that 512 MB partition, even though the DOS v3.3 FORMAT command wasn't able to successfully format it. I'm leaving that 512 MB partition on Hank only for use with a later DOS version. So, Zeke's life support actually only requires about a twentieth of the space available on Hank's 2 GB drive. Next, I restored all of the files from a backup of Zeke's ST-225 to Hank's C: partition. The two systems mainly differ in the contents of their CONFIG.SYS and AUTOEXEC.BAT files. Hank's come from its C: disk partition, while Zeke's come from its Boot diskette. Since Hank never does much more than run INTERSVR, its CONFIG.SYS is short and simple. Near the end of Hank's AUTOEXEC.BAT things get a little more interesting. Here there are MODE COM1:2400,N,8,1,P and CTTY COM1 commands that transfer Hank's CONsole to a "terminal" connected to Hank's COM1 port. This terminal stands in for a monitor that, otherwise, might be needed for Hank. Another way to avoid dedicating a monitor to Hank would be to let it share another PC's monitor (and keyboard and mouse), by means of a keyboard, video, and mouse switch (or, KVM switch). Hank's CONsole terminal actually consists of a "Null Modem" or LapLink Serial cable connected to a serial port on my Windows system, Digerydo. In Digerydo, an unpublished "COM1 Support TSR" provides an "INT 14" interface for Hank's CONsole, to a terminal emulator which may be run from a Windows DOS window. The COM1 Support TSR keeps its port's DTR and RTS lines active, to keep Hank from thinking that it has been abandoned, if and when the terminal emulator isn't actually running in Digerydo. This function might also be provided by special Null Modem cable wiring. After Booting Hank, I use this CONsole arrangement to CHKDSK each of its disk partitions. Then, I conclude with a SERVEFS command. SERVEFS.BAT is merely a "wrapper" for an INTERSVR C: D: E: A: /LPT:1 command. This command provides Hank's three 32 MB partitions and diskette drive to Zeke, where they'll appear as partitions C: through F:. The CONsole terminal provided by the CTTY COM1 command mentioned above isn't able to see INTERSVR's fancy real time display of disk activity. Nor is it able to stop INTERSVR. If I ever want to do that, I use Hank's reset button to start a reBoot. Zeke's CONFIG.SYS includes a DEVICE=A:\INTERLNK.EXE /NOPRINTER /DRIVES:4 /LPT:1 command. And, in case it matters, Zeke's AUTOEXEC.BAT includes an INTERLNK command. For almost everything, this kind of arrangement proved to work as well as, or better than, the parallel port connected Zip drive. When I run DosLynx on Zeke, with its INTERLNK provided disk, I don't even need a /B nor /U command line option! By now, you may be wondering: Why is this document named ILNKFIX.TXT, then? Well, when it came to surfing the Web with DosLynx, Disk not ready Critical Errors started showing up! PMPOP got these errors while receiving my e-mail, too. These errors couldn't be ignored because they seemed to be associated with disk writing and weren't successfully corrected by R(etry) requests made in response to the Critical Error prompts. They were frequent enough that I wasn't able to download a good copy of a 48 KB .ZIP file from the Internet. But, when I tested with HTTP and FTP servers on my own LAN, I couldn't reproduce the problem! Well, early on, I figured that this problem might be coming from PLIP's long interrupt service times. As explained in PLIP112.TXT, PLIP services its interrupts with all interrupts masked. And, its interrupt service times are long enough to cause the PC's Real Time Clock to noticeably loose time, when PLIP is in use. I could almost imagine an IRQ for PLIP's port interrupting an INTERLNK/INTERSVR dialog in process on the other parallel port. Zeke's INTERLNK process would be held-up in the middle of the dialog while Hank's INTERSVR process would run-on and be trying to figure out what had happened to Zeke. I tried slowing Hank down, to make it more tolerant of Zeke's delays, by turning off its caching. That reduced its 66 Bogo MIPS speed rating to under 3 Bogo MIPS but didn't seem to have any effect on the frequency of the Disk not ready Critical Errors. After it became clear that slowing Hank wasn't of any help, I normalized Hank's caching. Next, I went searching the Internet for reports of Disk not ready Critical Errors with INTERLNK/INTERSVR. A lot of what I found shed more heat than light on INTERLNK/INTERSVR. That includes two Microsoft Knowledge Base articles I found. Q96938, available from ftp://ftp.microsoft.com/MISC/KB/en-us/96/938.HTM , did provide some insight as to how Disk not ready Critical Errors might be expected. But, Q96555 available from ftp://ftp.microsoft.com/MISC/KB/en-us/96/555.HTM , lead me off on a tangent. Up to this point, I had been assuming that INTERLNK/INTERSVR didn't make any use of their parallel port's IRQs. However, my early readings of Q96555 found it contradicting that view. As neither of Zeke's parallel ports provided an alternative to the use of IRQ7, I decided I must modify one of Zeke's cards to use a separate IRQ. I wound up modifying Zeke's memory card, to make its parallel port use IRQ5. After all, Zeke no longer had a disk controller using that IRQ! This is the parallel port that PLIP uses. After completing this modification, I used PARALLEL, available from ftp://ftp.lpt.com/parallel/para14.zip , along with an IRQ test jumper in each parallel port, to verify that both parallel ports were able to interrupt as planned. This change had no apparent effect on my INTERLNK/INTERSVR problem! I now understand Q96555 to be reporting only that INTERLNK/INTERSVR couldn't tolerate another process' use of an IRQ! That's just about what I suspected my problem was in the first place. I am again assuming that INTERLNK/INTERSVR don't make any use of their parallel port's IRQs. (Wouldn't you just love trying to explain these things to a non-technical jury?) But, I haven't taken back my modification for the IRQ for the parallel port provided by Zeke's memory card. Having made quite a lengthy (but nowhere near complete) search of the Internet, and found no INTERLNK/INTERSVR magic, I decided it was time to try a bypass of my own for my problem. I would write a small TSR that would hook into the beginning of the INTERLNK Device Driver's Interrupt routine. My TSR would mask the PLIP port's IRQ, in the Peripheral Interrupt Controller's Mask Register, until the INTERLNK Device Driver's Interrupt routine makes its RETF. When the RETF does get made, the Mask Register bit(s) that have been set would be restored, rather than cleared, to whatever they were just before being set. I've done this, and the result is ILNKFIX.COM. Since I started using ILNKFIX.COM on Zeke, I haven't seen another Disk not ready Critical Error! I had been worrying that holding up PLIP's IRQs might hurt its performance. So far, I haven't been able to see much sign of that happening. I suppose ILNKFIX.COM's success stems from the fact that most of the INTERLNK Device Driver Interrupt routine's runs don't actually coincide with a PLIP IRQ. Probably none did when I tried to duplicate my original problem with servers on my LAN. When a coincidence does occur, it usually doesn't hurt to delay the PLIP IRQ for a while. If and when a delay occasionally does hurt, the TCP/IP protocol's error control provisions take care of getting a lost packet resent. The relatively low rate of coincidences of INTERLNK provided disk I/O with PLIP IRQs, that I have observed, may owe something to Zeke's EMS memory. DosLynx is able to use that to hold most of its program overlays. Since it is reading most of its overlays from EMS memory, rather than disk, DosLynx keeps the rate of its disk I/Os much lower than it might be, otherwise. In turn, that keeps ILNKFIX's effect on the PLIP IRQs much less than it might be, otherwise. So, your results with ILNKFIX may vary. There is just a little more to say about ILNKFIX.COM. It expects a single parameter expressing a mask to be used on the PC's first or only Peripheral Interrupt Controller Mask Register. This is given as a hex value between 01 and FF. This allows any combination of IRQ(s) 0 through 7 to be masked while the INTERLNK Device Driver's Interrupt routine runs. On a PC with dual Peripheral Interrupt Controllers, masking IRQ2 will mask all interrupts handled by the second Peripheral Interrupt Controller. However, I find a situation where this might have to be done hard to imagine. The mask value for IRQn is 2 ** n. So, the mask value for IRQ0 is 1. The mask value for IRQ5 is 32. And, the mask value for IRQ7 is 128. One or more of these values may be summed and expressed in hex to provide the parameter for ILNKFIX.COM. Since I need to mask IRQ5 on Zeke, my command is: ILNKFIX 20 If I wanted to mask Zeke's IRQ2 and IRQ7 as well, my command would be: ILNKFIX A4 Perhaps needless to say, ILNKFIX is intended to be run on any PC that can run INTERLNK. When ILNKFIX is run, it reports on whether or not it finds an INTERLNK Device Driver resident in memory and hooks it. It won't hook each INTERLNK resident more than once. If you decide you don't want your INTERLNK resident hooked, after all, reBoot your system and don't rerun ILNKFIX. If you are getting unexpected Disk not ready Critical Errors while running INTERLNK, and have an identifiable IRQ driven process with long service times, ILNKFIX may be just what you need. If so, I hope you'll give it a try, and let me know how it goes. Either way. fcm