The machine has two bays, a small bay and a large bay. The small bay can hold a battery, a floppy drive, or a zip drive. The large bay can hold a CD player, a second 3.2G hard disk, or any small bay device using a plastic size-adaptor.
I thought it was a pretty good deal: $1500 including the zip drive.
I decided to install the Debian version of the Linux operating system. Since the 3.2G disk was formatted with the new Fat32 filesystem and I also wanted to maintain the existing Windows environment, I used the fips15c tool to split the single existing DOS partition into two 1.6G DOS partitions, then used the cfdisk tool to delete the second DOS partition and created a Linux swap partition and a Linux filespace partition Note that the fips15c documentation recommends deleting the windows swap file before partitioning. For instructions on how to do this see Removing Win95 swap file in my Windows Hacker area.. Note also that there is no "cylinder 1023" problem here since the hard disk reports its geometry as 128 heads and 787 cylinders.
The solution was to use the tecra version of the kernel. To do this:
Speaking of libraries, you have to tell ld.so that the X11 libraries are present by putting the line:
/usr/X11R6/libinto the /etc/ld.so.conf file and then running /sbin/ldconfig as root.
Another problem is that xfree86 prefers to live in /usr/X11R6/bin but the Debian su institutes a hard-coded PATH that includes the /usr/bin/X11 directory instead. Since it was not possible to modify this compiled-in path by editing a system configuration file, I kluged it by making a symbolic link from /usr/bin like this:
ln -s /usr/X11R6/bin /usr/bin/X11
It was not obvious which server binaries to download. It turns out that XF86Setup uses the VG16 server and I eventually wanted the SVGA server for this laptop. So the important files to get were:
Setting the X server to the VG16 server by making the link
ln -s /usr/X11R6/bin/XF86_VG16 /usr/X11R6/bin/X
causes the 16 bit VGA server to be used. Later I selected the SVGA server with
ln -s /usr/X11R6/bin/XF86_SVGA /usr/X11R6/bin/X
to be able to run the 9385 mode.
Running SuperProbe didn't tell me anything useful, so I ran XF86Setup. You just have to play around to find a working setting. For pointing device it was /dev/psaux and PS/2 protocol. Note: I am using a PS/2 mouse plugged into the laptop's side port. For card I initially used Trident Cyber 9382 (which is what the win95 systems control panel said) but I noticed from the X server startup that it was reporting a 9385 instead, so I started using that for the card setting instead. Selecting monitor "combination 640x480/800x600" and mode 800x600x24 almost worked. There was a good display but it was shimmering badly. I used the Xvidtune tool to find a better vertical sync setting, but there was still some shimmering around the active window menubar.
Later I read the output from the X server, that 70 MHz was the maximum clock frequency. So I redid the mode line. Here is the resulting XF86Config file. The only change from what XF86Setup generated was the new modeline and horizontal and vertical frequency limits.
boot=/dev/hda install=/boot/boot.b map=/boot/map vga=5 prompt image=/vmlinuz label=unix root=/dev/hda3 read-only other=/dev/hda1 label=win95 table=/dev/hdaThis causes it to wait and ask which system to load. See /usr/doc/lilo if you want it to behave differently.
/sbin/ifconfig eth0 129.2.8.98 netmask 255.255.254.0 broadcast 129.2.9.255 /sbin/route add -net 129.2.8.0 /sbin/route add default gw 129.2.8.1 metric 1(I'm manually running them from a script just now) and create the file /etc/resolv.conf containing the IP addresses of our campus nameservers:
domain umd.edu nameserver 128.8.xx.yy nameserver 128.8.pp.qq nameserver 128.8.rr.ssNote that I have obscured the actual addresses. You want to substitute the IP addresses of your campus nameservers.
Note the strange network mask. Our 129.2 network is split 7/9, that is, there are 128 subnets each with 512 nodes. That is why the broadcast address got rounded from 8 up to 9.
mount -t msdos /dev/hdc4 /mntBy creating a /zip mount point and putting the fourth line in the /etc/fstab file
# /etc/fstab: static file system information. # #I made it possible for users (as opposed to just root) to mount and unmount zip media using/dev/hda3 / ext2 defaults,errors=remount-ro 0 1 /dev/hda2 none swap sw 0 0 proc /proc proc defaults 0 0 /dev/hdc4 /zip auto defaults,user
mount /zip umount /zipcommands. But the kernel grumbles at me if there is no media installed at bootup, so I may have something wrong in here. Also, there doesn't seem to be any automatic way to eject the media.
There does appear to be some kind of interlock. If you push the eject button when the media is mounted, nothing happens, but then when you unmount the media it is ejected. Alternatively you can unmount the media, then push the eject button. There was some information on the web about configuring SCSI emulation for ATAPI then using some SCSIEJECT ioctl but this will have to wait until I try building my own kernel. For now manually ejecting seems to be workable. After all, it is the same paradigm as the floppy :-)
To format a zip media in unix mode:
fdisk /dev/hdcI did a p to show the current partition table but there wasn't one. I did a n to create a new partition, answering p for primary and 4 for the partition number (to be compatable with the fstab entry). I answered 1 for the start cylinder and 96 for the end cylinder. Then I used w to write the partition table to the media and q to quit.
Then I did
mke2fs /dev/hdc4This put the zip disk into a state where it could be mounted via the fstab entry above. Note that initially there is only a lost+found directory present.
Watch this space for progress...