vintage computer
Jean-Pierre Radley
can't find /boot.
The hard disk controller card is not one I can recall ever seeing. It's
an ISA card with four connectors: one running to a 5.25" floppy (and
also to a Colorado Junko), one marked Drive 0 with nothing connected to
it.
There's a connector (about twelve pins) marked Drive 0, and another (about
twenty pins) marked Winchester. Both of these are connected to the hard
drive with ribbon cables.
I thought to take the hard drive with me, but I have no HA adapter with
that sort of cabling at all.
I have no 5.25" Xenix boot disks either.
Any bright ideas out there?
--
JP
Dale Stover
news:2002112521...@jpradley.jpr.com...
Sounds like the old ESDI or MFN drives.
http://www.aquascape.com/theref/tech_talk/tech_talk03.html
This might help you figure out what you have for hardware...what you really
need are the XENIX floppies.
Dale
Stuart J. Browne
hehe :) much fun.. have one of those in a cardboard box at home.. fired it
up (with a 20MB hdd) a whole once in my life :P More than enough..
Dale's memory serves him well..
bkx
Jean-Pierre Radley
Would you lend me the HA card to see if I can read the hard drive at all?
--
JP
Tony Lawrence
Yeah, does sound like ESDI. Long time since I've seen one.
I have a set of Xenix 2.3.4 on 3.5" disks but can't vouch for their
usability..
--
Please note new phone number: (781) 784-7547
Tony Lawrence
Unix/Linux Support Tips, How-To's, Tests and more: http://aplawrence.com
Free Unix/Linux Consultants list: http://aplawrence.com/consultants.html
James J
"controller" cable that went to one or two drives and two smaller "data"
cables, one for each drive. I think at least some of them also included a
floppy controller.
FYI, the MFM and RLL interface was the same. RLL just used a 50% higher
density than MFM. For example, a 40 MB MFM drive was about 60 MB in RLL
format (assuming that the media could handle the higher density). But the
controllers that I recall were one or the other, MFM or RLL. So if you do
find a new card, it will have to be the right type for the drive or it
won't work.
You know, I knew this was going to happen. Two months ago I threw out at
least one MFM card and an RLL card and several MFM/RLL drives. They'd
been sitting in a box for years, so I finally decided to get rid of them.
I joked that once they were gone, I'd probably find a use for them. :-)
Sorry, wish I still had them around to help you out.
Of course, if you have the brand and model of the hard drive, that could
help answer the question of what type it is, although if it is an MFM/RLL
type, it could be in either format.
I might be able to help with the Xenix. Which version was it? I have a
copy of 2.3.2, if that will help.
James
Jean-Pierre Radley
|
| Of course, if you have the brand and model of the hard drive, that could
| help answer the question of what type it is, although if it is an MFM/RLL
| type, it could be in either format.
I didn't bother to try to read any small print on the drive...
| I might be able to help with the Xenix. Which version was it? I have a
| copy of 2.3.2, if that will help.
How should I know, if the machine doesn't boot?
--
JP
Tom Parsons
| I was called to try to revive a vintage computer, running Xenix, which
| can't find /boot.
|
| The hard disk controller card is not one I can recall ever seeing. It's
| an ISA card with four connectors: one running to a 5.25" floppy (and
| also to a Colorado Junko), one marked Drive 0 with nothing connected to
| it.
|
| There's a connector (about twelve pins) marked Drive 0, and another (about
| twenty pins) marked Winchester. Both of these are connected to the hard
| drive with ribbon cables.
|
| I thought to take the hard drive with me, but I have no HA adapter with
| that sort of cabling at all.
If it is MFM (or RLL, which is a subset of MFM), you would have one
34 pin control cable that would run to all drives and a 20 pin data
cable for each drive. (Sound familiar, exactly the same as a Tandy 6000).
Unfortunately the only MFM bits I have left are a standalone 4 drive
WD controller card.
I've forgotten the ESDI bits.
| I have no 5.25" Xenix boot disks either.
Probably somewhere around here.
--
==========================================================================
Tom Parsons t...@tegan.com
==========================================================================
Bill Vermillion
James J <SPAMMY...@netscape.net> wrote:
> Sounds like an MFM or RLL controller card. They had one larger
>"controller" cable that went to one or two drives and two
>smaller "data" cables, one for each drive. I think at least some
>of them also included a floppy controller.
Most common was the Western Digital 1003 and all others were
compatible with it. I think that may be in a Radio Shack 3000 that
is in the back room with Xenix on it - that hasn't been turned on
in years.
> FYI, the MFM and RLL interface was the same. RLL just used a
>50% higher density than MFM. For example, a 40 MB MFM drive was
>about 60 MB in RLL format (assuming that the media could handle
>the higher density).
And pity the people who tried to format coated media drives with
RLL which worked best with plated media. Actually MFM is a 1:3
RLL format. Everything past the original single density was some
form of RLL.
--
Bill Vermillion - bv @ wjv . com
Steve Fabac
JP:
I have used SCO 5.0.0 Emergency boot floppy set with Xenix File system
support to boot and access a Xenix system Hard disk and copy files
to a tape drive and then move the tape backup to a partition on my
office system.
Booting the 5.0.0 Emergency boot floppy on the Xenix system complained
about memory, but I was lucky as the system had 16M of RAM and was
able to get it to run.
The auto hardware detect in the 5.0.0 will probably recognize the
hard disk controller better than trying a 5.0.6 as the 5.0.0 is
closer in time to the controller being supported by SCO. (Just
a guess)
If you can get the root disk mounted on the 5.0.x Emergency boot floppy
(mount /dev/boot on /mnt at root on Xenix is at zero division 1,40)
and examine the /usr/adm/messages file for the boot up hardware
display to get more information on the controller. I have an old 486
I use for a DOS based fax server and it has a Xenix 3.2v4.2 operating
system on it that I keep for reference for times like this. If your
system is supported by SCO Xenix without third party drivers, I can
e-mail you an emergency root and boot floppy set with the proper
drivers and tape device linked into the kernel. Let me know if I can
help.
--
Steve Fabac
S.M. Fabac & Associates
816/765-1670
Steve Fabac
Oops, That's Xenix 2.3.4
Scott McMillan
wrote:
Rummaging through our cabinets, I've found a copy of Xenix 2.2 (286AT)
and 2.3.2 (386) on 5.25". Don't have any machine in here to verify
them with, but if you'd like them, email me and we'll set it up.
Scott McMillan
Abid Khan
Sounds like you have a MFM controller/drive, if you can get the hard
disk make and model then we can confirm that, Is it a full size, full
height Seagate drive!!, I do have a Xenix 386 (2.3.x) on 5.25".
Abid!
Jean-Pierre Radley
| I was called to try to revive a vintage computer, running Xenix, which
| can't find /boot.
|
|
| Any bright ideas out there?
Thanks for all the suggestions. I'm thinking of substituting a 3.5"
floppy drive for the larger one, and having the computer on my own
workbench. At the moment, the client isn't sure if and how he wants me
to proceed.
--
JP
Stuart J. Browne
Umm.. it is at the bottom of a box (never thought I'd use it again), so I
don't even know if it works. That, plus international shipping..
Will search for it when I get home tonight if you want though.
bkx
James J
news:2002112602...@jpradley.jpr.com:
>| I might be able to help with the Xenix. Which version was it? I
>| have a copy of 2.3.2, if that will help.
>
> How should I know, if the machine doesn't boot?
I thought the owners of the system might have it in their records or
something.
Hey, it was worth a shot. :-)
James
James J
> In article <Xns92D1CC3EF5E2...@205.188.138.161>,
> James J <SPAMMY...@netscape.net> wrote:
>
>> Sounds like an MFM or RLL controller card. They had one larger
>>"controller" cable that went to one or two drives and two
>>smaller "data" cables, one for each drive. I think at least some of
>>them also included a floppy controller.
>
> Most common was the Western Digital 1003 and all others were
> compatible with it. I think that may be in a Radio Shack 3000 that
> is in the back room with Xenix on it - that hasn't been turned on
> in years.
Ah yes, the WD 1003. I remember that model number. I think one of the
controllers I tossed was one of those.
James
John DuBois
Jean-Pierre Radley <j...@jpr.com> wrote:
>I was called to try to revive a vintage computer, running Xenix, which
>can't find /boot.
>
>The hard disk controller card is not one I can recall ever seeing. It's
>an ISA card with four connectors: one running to a 5.25" floppy (and
>also to a Colorado Junko), one marked Drive 0 with nothing connected to
>it.
>
>There's a connector (about twelve pins) marked Drive 0, and another (about
>twenty pins) marked Winchester. Both of these are connected to the hard
>drive with ribbon cables.
>
>I thought to take the hard drive with me, but I have no HA adapter with
>that sort of cabling at all.
If it's complaining about not being able to read /boot, it's successfully read
masterboot, hdboot0, and hdboot1, so it may be that the hardware is all fine,
and the problem is just disk corruption. In that case, you might bring both
drive and the controller card currently in use to another machine, even one
running 5.0.x, configure XENIX fs support in, and try mounting the root
filesystem and either patch it up or copy the data to another drive.
John
--
John DuBois spc...@armory.com KC6QKZ/AE http://www.armory.com/~spcecdt/
Jean-Pierre Radley
Which can't work if my 5.0.X drive is SCSI, can it, since I don't think
non-SCSI drives can coexist with SCSI drives?
--
JP
Bela Lubkin
> John DuBois typed (on Tue, Nov 26, 2002 at 11:51:57PM +0000):
> | If it's complaining about not being able to read /boot, it's successfully read
> | masterboot, hdboot0, and hdboot1, so it may be that the hardware is all fine,
> | and the problem is just disk corruption. In that case, you might bring both
> | drive and the controller card currently in use to another machine, even one
> | running 5.0.x, configure XENIX fs support in, and try mounting the root
> | filesystem and either patch it up or copy the data to another drive.
>
> Which can't work if my 5.0.X drive is SCSI, can it, since I don't think
> non-SCSI drives can coexist with SCSI drives?
It's a little tricky to boot such a system, yes...
There are two problems to overcome. One is convincing the BIOS to boot
your SCSI disk despite the presence of an ST506 disk. The other is
convincing Unix to pay attention to the SCSI disk first.
BIOS: it's easy on many newer systems, just tell BIOS setup to boot from
SCSI.
On an older system, the trick is to completely trump the boot sequence
by booting from a boot floppy. Make sure IDE support is in the kernel
("wd" driver, supports ancient ST506 and ESDI controllers as well as
IDE). Also make sure Xenix filesystem support is in (`mkdev xenix`).
Relink, reboot, run `mkdev fd`, create a boot floppy. (All this with
the ST506 controller _not_ in the system.) Then power off, insert ST506
controller+drive, and boot from the floppy.
That'll get you to the kernel problem. /boot will load the kernel off
the floppy, the kernel will start up, and it will want to root off the
ST506 drive. You probably shouldn't ever try that, but if you do, I'll
whimsically speculate about the possible outcomes. Useful text
continues at the word "anyway", below.
If the controller or drive is broken, or just won't work in your
much-newer system, not much interesting happens. Probably a panic due
to can't mount root.
If the controller and drive are working, but disk parameters are wrong,
probably the same thing.
If controller and drive are working but the partition table, division
table, or inode table of the root filesystem are corrupt, about the
same.
If it's a fully functional Xenix root filesystem (e.g. maybe nothing at
all wrong with it, the problem your client is having could be caused by
the _rest_ of the system having gone bad) -- what happens then? That
is, what happens if you boot an OpenServer kernel (with appropriate
hardware and filesystem support) with a Xenix root filesystem? (You'll
probably have to use "fd(64)unix root=hd(40)" else it'll try to root on
hd(42), which will be /u at best, and die due to no /etc/init.)
I think what happens now is that the Xenix /etc/init gets loaded. It
works. It runs sulogin to prompt for root password, or ^D to go to
multiuser mode. You enter the root password. You get a shell prompt.
An attempt to go multi-user would fail, because the OSR5 kernel doesn't
know it's licensed until ifor_pmd starts (which obviously isn't present
on this Xenix root filesystem). An unlicensed kernel is limited to
something like 20 concurrent processes.
All this applies to 386 Xenix only. For 8086 or 286 Xenix, it could
still work, but you would need the OpenServer /etc/x286emul binary and
all of its support files (at least: /usr/lib/libc.so.1 and /dev/zero;
probably more). Plus, if you've installed the security fix that broke
286 execution, you would have to rebuild your kernel to disable that
(allow_dscr_remap=1 in /etc/conf/pack.d/kernel/space.c) (note that this
has been fixed properly in 507).
Oh, and all of this can only work if the device nodes in the Xenix root
filesystem have the same major/minor numbers as in Unix. I _think_ this
might actually be true for the few device nodes needed to get to
single-user mode.
Well, anyway... What you really want to do is boot a Unix kernel with a
Unix root filesystem, and mount the Xenix stuff. The last remaining
trick is to use "hd=Sdsk" to override the kernel's tropism towards
ST506/IDE. So you're going to boot the boot floppy and enter
"fd(64)unix hd=Sdsk".
Oh, one further trick. You'll need device nodes to access the Xenix
drive. `mkdev hd` is a bad idea because (1) it doesn't believe in
systems with SCSI root and ST506/IDE secondary drives, and (2) it's a
real pain to undo what it does, and this is a temporary condition you're
setting up.
All you really need is some nodes. For that, you need to know the major
number of the "wd" driver:
# grep wd /etc/conf/cf.d/mdevice
wd IRocrwi BiRbcCHhdg wd 53 53 1 2 -1
^^
# MAJ=`awk '$1 == "wd" { print $5 }' /etc/conf/cf.d/mdevice`
# echo $MAJ
53
Let's make whole-disk and active-partition nodes, using "hdX" as the
base name (like "hd0", "X" for "Xenix"):
# mknod /dev/rhdX0 c 53 0
# mknod /dev/hdX0 b 53 0
# mknod /dev/rhdXa c 53 47
# mknod /dev/hdXa b 53 47
Now run `divvy /dev/hdXa`. If you're lucky, a division table shows up,
with start/end blocks but no names. Give them names (if you keep "hdX"
in each name then cleanup will be easier). 0 is almost certainly root,
1 swap, so name those "hdXroot" and "hdXswap". If 2 is in use, it's
probably "hdXu".
Up to here you have not attempted to write anything to this disk. It's
probably a good idea to keep it that way. So, always mount read-only:
# mount -r /dev/hdXroot /mnt
Even better, once you've got divisions and divvy shows sensible looking
filesystem types (which means the disk parameters are right),
immediately copy the data. Then you can set the physical drive aside
for safe keeping until you know that you can properly access the data.
To do this, name each division that has start/end blocks. Then `dd`
them elsewhere:
# dd if=/dev/hdXroot of=/recovery/hdXroot bs=64k # bs for speed
# dd if=/dev/hdXu of=/recovery/hdXu bs=64k
If you get no I/O errors, that's a miracle; and if you do, a bummer.
Supposing you get the data, then:
# marry -a /recovery/hdXu
# mount -r /dev/marry/recovery/hdXu /mnt
Anyone still with me?
>Bela<
Tony Lawrence
Too early in the a.m. for me, but I've filed it away at
http://aplawrence.com/Bofcusm/ should I or anyone else ever need it.
Rick Peters
formats are proprietary to the specific controller. A WD MFM controller
can't be substituted for a Seagate MFM controller. Been there...done thatnews:2002112600...@jpradley.jpr.com...
Thom Price
Hi, JP. Sorry to jump in late, but...
1- what's the drive model #? (old ST251-1 were RLL, if memory serves,
but whatever it is, it's "findable" with detail on whether MFM or
RLL.) I forget if you mentioned form factor of the drive, but that'd
help. (3.5" or 5.25", full-height or half-height)
2- I've got some old MFM and RLL controllers in Northern NJ. Tell me
if you want them shipped or dropped off in some nearby place. (trip to
Manhattan is difficult, usually)
3- seems to me that MFM/RLL controllers used UMBs (or UMAs, depending
on your background), so be careful of the SCSI controller you add - it
may stomp on the BIOS of this card... (also if mem serves.)
4- I believe the floppy type used was physically jumpered on the
MFM/RLL card, so you may not be able to simply drop in a new floppy,
but I may be remembering jumpering the floppy's from 0 to 1, so we'd
have A: and B:.
5- just curious - is this VGA or MDA/CGA/EGA?? (I've got old monitors
around if needed)
6- no history at all with ESDI, other than HP used to use them alot,
for HPIX back when. So, if its ESDI, all bets are off. ;-]
Email t p r i c e @ w a r w i c k . n e t if you want the card(s) I've
got. Get the drive model, and we'll know what card is compatible.
(still have some old lookup tables, I believe)
HTH.
Thom
Thom Price
Hi, JP. This post got me to thinkin'. (still smell smoke)
This may be as simple as a dead CMOS battery. I made a leap here, but
if it's "vintage", then battery is probably long gone. I remember
this problem frequently occurring, with those old Lithium (?) black
batteries with Velcro pads...
If it lost its CMOS settings, you'd know because date was probably
1-1-80. If it lost its settings, then you'd have lost the
Cylinder/Head/Sector settings which is most critical with these old
boys, as I recall. Remember the days where some OSs couldn't see the
entire disk correctly, unless its geometry was translated for the OS?
(like today, with still too many OSs)
I remember 820/6/17 as a fairly popular drive geometry back then,
which had to be set either via internally defined Drive Type in BIOS
or User Defined Drive Type. You need the exact match of C/H/S or you
won't get a boot. Boot sector may be OK, but boot sector is missing -
not gone, just missing...
Post the drive model, and we can try some combos. Remember that mfr
stated geometry wasn't always used, and many drives were manually
entered. Ex., 820/6/17 may have been 410/12/17, which C*H*S products
equal, but which geometries are entirely different. It may be as
simple as entering the correct CHS values for that drive. Plus, you
may need the Write Pre-Comp and ...what was the other value...
I also believe there was comaptibility across controller cards, thanks
to the ST506 standard. However, cross-matching drives and controllers
across MFM and RLL was not good.
MFM ctrlr + MFM HDD --> OK
MFM ctrlr + RLL HDD --> OK
RLL ctrlr + RLL HDD --> OK
RLL ctrlr + MFM HDD --> NFG
I seem to recall that RLL drives were backwards-compatible to MFM
controllers, but that may be wrong)
HTH.
Thom
Tom Parsons
You can wander far afield on this topic. If the existing controller
has a WD chip (something like WD 1005, WD 1003, WD 1001), then the
possiblities for head and sectors are limited. I'm pretty sure I have the
WD databook for those chips buried in the back room.
Thom Price
Can't wander too far. It's usually either C*2 and H/2 or C/2 and H*2,
to create the proper geometry. However, if someone went nuts with
User Defined, then something like SpinRite from grc.com can help
determine its geometry. Even DiskManager could figure out most
combos.
I realized later that the ST506 standard is probably cabling and
signals, and not drive geometry. I still believe that MFM/RLL drives
can be used on different controllers. I think SCSI is more proprietary
in low-level format, in the a controller can house geometry different
from others. So, it's harder to take a working SCSI drive and get it
to boot off another company's controller than it was to move an RLL
drive to another company's, FWIRecall.
Point is that this may be as simple as redefining the geometry
properly in BIOS because a battery died and the machine was powered
down for more than 10 seconds. (or less)
Regards,
Thom
-bill-
Bill Vermillion
Thom Price <whudd...@yahoo.com> wrote:
>I realized later that the ST506 standard is probably cabling and
>signals, and not drive geometry. ...
Just a heads-up on this. You often see drives listes as 506/412.
Those are two different standards and with later controllers you
are ok, however if you attempt to use a 412 drive on a pure
controller that only knows ST506 standards wou WILL come to grief.
On all the early systems the user supplied the parameters to the
controller. The original ST506 had you specify a
write-precompensation starting track. write-precomp is where the
data bits started to be written with slightly different spaceing
because of the bit-shift problem which caused adjancent bits to
shift slightly on the lower coercivity media used in those days.
When we'd write data starting at the designated track the system
would toggle thr write-precomp line.
As the specs only had enough bits for 8 heads - numbered 0 thru 7,
this limited the drives of that era to about 70MB. 8 heads, and 17
sectords/track.
The ST412 did any write-precompensation internally, so the line
used for write-precomp was used for head-select. With the line low
you would send signals for tracks 0-7, with it high those same
numbers translated to 8 thru 15.
So if you had a controller that was a pure ST506 and you tried
to write to heads numberered 8 thru 15, the 412 drive would expect
head-select to be high for those heads, but since it was
write-precomp on a 506 it would be low and the data inteneded for
tracks 8 through 15 would be written on tracks 0 thru 8 overwrittin
the boot information, etc.
This really is only of consequences for people trying to resurect
really old systems. On the old RS 16s, the ST4096 [from memory]
which was a Shugart/Seagate 77MB with 9 heads, you'd could use
those on a 506 controller providing you said it only had 8 heads
and throw away 7MB. Trying to use all 9 heads would cause the
system to overwrite track 0 with track 9.
I love how easy Unix systems and computers in general are today
compared to the hoops we had to jump through in the past.
Bill