I have a second hard drive on my UNIXpc; HwNote03

John B. Milton jbm at uncle.UUCP
Tue Oct 11 17:05:29 AEST 1988


/mnt on /dev/fp012 read/write on Mon Oct 10 20:03:21 1988
                ^
** YOU BET! **

I see you're back. Yes, that output from my mount command was correct. I DO
have two (2) II hard drives working on my system.
I can do an mkfs on it.
I can run fsck on it.
I can mount it.
I can copy files from drive to drive.

That bit in MCR2 is indeed a select line for the second hard disk. The problem
of switching data streams turned out to be trivial. It is already supported
in the "Hard Disk Data Separator PAL". It has two pins which are grounded:
DDRIVE0* and DATA1. The nasty, messy part was what I did for the driver and
receiver. There are three spare receivers and two or zero spare drivers
depending on the version of your mother board. Some mother boards have 74LS240s
driving the Tx and Reset lines to the keyboard, later boards use two of the
26LS31 differential drivers for this. The machine I have has '240s for the
keyboard, so the two drivers are free. The problem is that the inputs for the
spares are grounded to prevent gray-state power consuption and damage. I had to
pull out three pins on each chip to break the ground connection.

The software turned out to be almost no problem at all. It turns out that the
P5.1 upgrade is needed to access the second drive. At least the gd driver
thinks it's needed. Since the P5.1 is completely invisible with the PAL out
of the socket, I tried taking it out and the accessing the second drive. No go.
It turns out that there is a word variable in the kernel "revlev" which tells
various drivers what the board revision is. It must be 0 for <=P2, 1 for
P3...P5, and 2 for >P5. You can find out your revlev with adb:
# adb /unix /dev/kmem
revlev/d
^D

You can also change your revlev to something else:
# adb -w /unix /dev/kmem
revlev/w 2
^D

It works just fine after the system is already booted. With the P5.1 PAL out
and after the adb session above, I can use the second drive just like with the
PAL in.

While I was goofing around testing this, I did get one error:

#HDERR ST:51 EF:10 CL:42C3 CH:4201 SN:4200 SC:4202 SDH:4221 DMACNT:FFFF DCRREG:91 MCRREG: 8B00
#drv:0 part:2 blk:4192 rpts:1

panic: gfpwrite F_HD_DMA set

Has anyone else ever had this one with only one drive?

I haven't even started to consider all the yucky physical stuff, namely an
external box to put all this stuff in. My next step is to try to change two
chips for one in the select circuit. After that, I am going to try out this
patch on another, hopefully different machine. No, I don't need beta testers
for this right now.

Yeah yeah yeah. How can I get one? Well, that raises an interesting question.
Assuming Convergent does have an upgrade for a second drive out. I guess it
would be like the P5.1 patch, that is, something licensed to a VAR. Now for
the really important question: Since I came up with this patch on my own, using
widely available information, do I have the right to do whatever I want with it?
Would publishing schematics with a Copyright help or hurt? Does Convergent
really give damn about the old S/50 anymore?

What will all this do to the future market for the overpriced $350.00 SCSI
board from IDT? Oh, well, gee sorry guys. I guess you took too long getting
it to market. I have not yet decided what I want to do with this. The thought
of selling it, well did sort of cross my mind. I was thinking about a daughter
board with three or four chips and a connector.

Now you've got something to do with all those full height 10M disks! Mount
the second drive on in /usr/spool/news normally. When you want to back up
your system, go single user, dismount news, drag out a stack of 10M drives,
back the system up, mount news back on, go back to multi-user.

Wow, maybe someone will even take another try at working on X!

John
--
-- 
John Bly Milton IV, jbm at uncle.UUCP, n8emr!uncle!jbm at osu-cis.cis.ohio-state.edu
home (614) 294-4823, work (614) 764-4272;  Send vi tricks, I'm making a manual



More information about the Comp.sys.att mailing list