Need Help Salvaging Data From an Old Xenix System 325
Milo_Mindbender writes "I've recently gotten ahold of an old Altos 586 Xenix system (a late '80s Microsoft flavor of Unix) that has one of the first multi-user BBS systems in the US on it, and I want to salvage the historical BBS posts off it. I'm wondering if anyone remembers what format Xenix used on the 10MB (yes MB) IDE hard drive and if it can still be read on a modern Linux system. This system is quite old, has no removable media or ethernet and just barely works. The only other way to get data off is a slow serial port. I've got a controller that should work with the disk, but don't want to tear this old machine apart without some hope that it will work. Anyone know?"
I'd do it the slow but secure way. (Score:5, Insightful)
Comment removed (Score:5, Informative)
Re: (Score:3, Informative)
Yup. 2-3 hours is about right.
Data volume for 10MB = 83886080 bits
10 Mega Bytes * (1024 Kilo Bytes / Mega Byte) * (1024 Bytes / Kilo Byte) * (8 bits / Byte)
Time to transfer 83886080 bits at 9600bps = just over 2.4 hours
83886080 bits / (9600 bits/second) / (60 seconds/minute) / (60 minutes/hour)
Re:I'd do it the slow but secure way. (Score:5, Informative)
exactly, 10mb at 9600bps will take only 2-3 hours.
Yep, and since your computer is a 586, there's a good chance the serial port will do 192kbps which even faster still. If you want to transfer binary files, I'd suggest using the zmodem protocol. Since your Xenix system was running a BBS, it almost certainly has software installed that will do zmodem file transfers.
Re: (Score:3, Informative)
Uh, you would have to uuencode it first, so
tar | compress | uuencode > /dev/serialportdevice
should work
Re:I'd do it the slow but secure way. (Score:5, Interesting)
No way it would take weeks. Even if the serial port was only 300 bit per second and he had to copy the whole 10MB disk through it this would take 10*1024*1024*8/300/3600=77.6 hours.
Mid-80s I'd expect at least five-digit bps rates - at 14400bps this would take 1.6 hours
so for G*ds sake, JUST USE THE SERIAL PORT
I'd understand if he was talking about a terabyte via serial but 10 megabytes...
But the real important question is: what to do with the salvaged data? If he'd want to post them online he might get in seriously shark-infected legal waters. Not everything I'd have posted in a BBS with a defined usergroup I gave permission to put on the internet without access control.
Pre-March 1989 publications may be easier (Score:4, Informative)
If the information was in a "public" forum, one visible with the access level generally granted to members of the general public, it's probably considered a "publication."
If they were "published" prior to March 1, 1989 but not registered with the copyright office AND not marked (c) they might be in the public domain. See a lawyer.
Re: (Score:2, Interesting)
If they were "published" prior to March 1, 1989 but not registered with the copyright office AND not marked (c) they might be in the public domain. See a lawyer.
No need to bring a lawyer into this. Everything is still copyright unless explicitly put into the public domain. The Berne convention(s) went into effect 1971.
Also, there's no longer any need to register or mark with a copyright notice to have copyright protection (see previous), though that does allow recovery of damages and more for infringment un
Re: (Score:3, Informative)
Re: (Score:2)
Re: (Score:3, Insightful)
Re:I'd do it the slow but secure way. (Score:5, Informative)
A 16550 in the early 1980s? I'm sorry, but I think not.
I wrote a lot of serial comms drivers back in those days, and I don't think I even /heard/ of a 16550 until the very late 80s. First one I actually met was probably in my brand new 486DX33 box I got in 1992, although to be honest I don't remember for sure. I didn't code for one until about 1994, and that was on an embedded system, as you still couldn't guarantee that all PCs would have them rather than 16450s or even 8250s.
Also bear in mind that the original 16550s were broken so you couldn't use the FIFO feature (which was the whole point of the thing) properly; that wasn't fixed until the 16550A came along.
Re:I'd do it the slow but secure way. (Score:5, Insightful)
Wow, that brings back memories... since X-on/X-off is software flow control over serial communications, making a cable was a simple matter: Tie together the hardware flow control transmit/request signal lines together and loop them back to the receive lines on the same connector and so ensure that they'd always be high on each side... and then let the software handle it from there...
I still have a soldering iron and solder in my service toolkit, which is in the trunk of my car - but I haven't used them in more than 15 years at this point. Hell, I can't remember the last time I used anything from my toolkit except for screwdrivers and needlenose pliers, but I still keep it around, just in case... I still have a serial breakout box, too *grin*
I did service for a customer that had an Altos system, and after they remodeled their offices, had to add some terminals in the reception area. They insisted that it be neat, and so, I ran the cable into the walls, mounted old work boxes to the sheetrock (measuring everything so that they lined up with the electical outlets, of course), and then soldered DB-25 female connectors onto the cable, mounting them to stainless steel wallplates that had DB-25 cutouts... labeled the wallplates, and the cables on the far end, then made "patch cables" to go from the wallplates to the terminals. Neat, clean - and I had a blast doing it.
And from that point on, I always tried to make any cabling I installed not only work properly, but be as neat as possible and documented as well.
Regards,
dj
Re:I'd do it the slow but secure way. (Score:5, Interesting)
Xenix was a 16 bit Unix variant pretty much SRVR3 style, /usr rather in /home or /srv.
SCSI or IDE but not both on the same system,
Bourne shell but no Bash,
probably TCL but no Perl,
more but not less are the things that pop inti my mind.
The file system topography is a nightmare of symlinks and the interesting user files are probably in
The first thing I would try is to set up a serial link between the two machines and tar the filesystem pipe it through the serial port to the Linux box and capture it to a file there or multi-volume
to the floppy disk, then just un-tar it and have fun on the copy; if that didn't work I get serious and dd the whole disk through the serial port. last resort would be to remove the hard-drive and try to mount -txenix it on a linux box.
Re:I'd do it the slow but secure way. (Score:5, Interesting)
Re:I'd do it the slow but secure way. (Score:5, Interesting)
I agree, I'm sure its minimal to read Xenix file formats for the data, but the risks of old components giving up the ghost are far to high. If it works now, just do it via serial port and be patient. Only if its in the process of dying would i take it apart.
As an aside, i find it an odd odd claim that the 'first multi user BBS' would be on a 8086... Considering i did it on an 8bit machine long before the ix86 was on the market, and on a VAX before that. ( and wasn't chicago's Z80 powered cbbs multi line at one point? ) Still, sounds like it is worthy of saving for the sake of history, but it's not as special as you might think....
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Use the serial port ... (Score:2, Informative)
Re: (Score:3, Informative)
Given the speed of hard disks from that era, I'd imagine that removing the disk, putting it in another machine, copying it, and then putting it back would take about as long as copying via the serial port. It's also worth noting that the machine has 5 serial ports, so if you're really in a hurry you can probably dump different bits of the filesystem in parallel over several ports (if the disk will handle that concurrent reads even at serial line speed).
10MB is a really small amount of data to copy via a
Re: (Score:2)
> ...our crappy serial cable didn't have the hardware error checking pins
> connected...
Serial cables don't have hardware error checking pins. I think you mean handshaking.
Re:Use the serial port ... (Score:4, Informative)
Geepers, people...a non-Compaq 8086 system from that era would almost certainly have an ST-506 interface hard drive, not IDE! Those old hard drives were built like tanks, and tend to keep their data. If you can't get the system running, you can probably dig up some old 286 system, or even a *Pentium* system, and plug an 8 or 16 ST506 hard drive card, like the old Western Digital W8006, and access the data that way. A ST-506 drive will have three cables connecting it...one for power, one (the fat ribbon cable) for control, and the last one (skinny ribbon cable) for data. JUST MAKE SURE THAT THE PIN 1s LINED UP OTHERWISE YOU CAN BLOW THE DRIVE, CONTROLLER, AND MAYBE EVEN THE COMPUTER. If the cable is not "keyed", that is, has a vertical piece of plastic to make sure pin 1 connects to pin 1 on the edge connector, you have to figure out which is pin 1 on the cable...If it is a grey cable with a red strip on one side, that is pin 1, which should connect to the edge connector side that has the notch in it. If you have a braided, multi-color cable...sorry, you will have to figure it out yourself.
Of course, if you really want to be paranoid, and have the money, contact an old hard drive recovery company like On-Track, and they should be able to hoover all of the data off for you, and give it to you in an easy to read format.
ttyl
Farrell
cu (Score:2, Informative)
The cu command is used to call up another system and act as a dial in terminal. It can also do simple file transfers with no error checking. cu is part of the UUCP source but has been split into its own package because it can be useful even if you do not do uucp.
Re: (Score:3, Informative)
He needs to use uucp, not cu. UUCP stands for "Unix to Unix Copy" and it means exactly what it says. Yes, there is a uucp command in the UUCP package.
Re: (Score:3, Informative)
There is a pretty good chance that kermit is available for that system. I would go with kermit file transfers over uucp any day it being easier to set up, has decent error detection and better feedback for the average user.
Re:cu (Score:5, Interesting)
It's Xenix. Ancient Xenix. Kermit wasn't commercial software, it was (and is) freeware. (http://www.columbia.edu/kermit/) Finding a way to compile and transfer Kermit to such an ancient system would take some serious archeological research, and some luck, because I certainly wouldn't expect to find it in Xenix from the days when Microsoft published it.
Given that it's only 10 Megabytes, "cu" or "uucp" it over the serial port twice and compare the results. Then, when you're entirely confident, consider using your controller in a newer system to do a modern Linux or UNIX "dd" of the entire disk image. I'd be fascinated to know what filesystem that ancient OS used, and if there are drivers available in a modern Linux to actually read it directly. Perhaps someone here or on an old Xenix support group would know.
There's also an odd source of SCO expertise that may be helpful, since SCO took over Xenix: the forums over at www.groklaw.net.
UUCP info you need (Score:5, Informative)
Setting up UUCP on Xenix [wb.nic.in]
Setting up UUCP on Linux [faqs.org]
If you really want to try to read the disk it is probably UFS [wikimedia.org] which you can read from Linux.
Hope this helps.
Re: (Score:2, Informative)
Re: (Score:2)
A late 80's version is hardly "ancient *nix". For that you need to go back to UNIX's first decade, not just anything that predates Linux.
Re: (Score:2)
I have an Onyx with System III. That's old.
Re: (Score:3, Informative)
Except it's early 80's (1983,) and it appears to be [classiccmp.org] Version 7.
Which is Ancient Unix, although barely.
Re:cu (Score:5, Informative)
UUCP (Score:5, Insightful)
It'll take a few hours at 9600 baud. It's your best bet. Let it run over night and the job is done.
Re: (Score:2)
So this beast actually boots? That's impressive.
The disc format was FAT, if I remember correctly, but you did reformat the discs for Xenix, so it certainly did something weird.
But if it boots, and the serial port works, that'll do fine.
Mind you, what are you going to put at the other end - what reads serial, these days? I guess the port is still there on ATX motherboards, so it probably still works!
But yes, if you can dump to the serial port, that beats taking it apart - it'll probably stop working if you d
What reads serial these days? (Score:2)
Mind you, what are you going to put at the other end - what reads serial, these days? I guess the port is still there on ATX motherboards, so it probably still works!
Assuming you dump twice and compare the output, lack of error checking should not be a problem.
With regard to do the transfer to a newer system, cables.com sells a 25-pin Serial-to-USB cable (http://www.cables.com/Products/USB-to-DB25-Serial-Adapter---USB-A-Male-to-DB25M__USB-DB25.aspx).
Have fun!
Re: (Score:2)
The serial ports on a PC are /dev/ttyS0 (COM1) and /dev/ttyS1 (COM2). Still very much supported in modern unices. Wiring up the necessary null-modem cable to hook them up should be well within the skillset of anyone attempting this.
Re: (Score:2)
> So this beast actually boots? That's impressive.
Not really. It's an Altos, not a modern pc.
> Mind you, what are you going to put at the other end - what reads serial,
> these days?
Linux. If you don't have a non-crippled motherboard buy a USB-serial converter.
Re: (Score:2)
But be absolutely sure that you got checksums and error correction working. You don’t want to lose valuable data becuase of some bad old wiring.
Probably more dangerous to move the drive (Score:2)
No Removable Media? (Score:2)
Your website, along with this website [classiccmp.org] suggests that the ALTOS 586 has a 5 1/4 floppy drive in it.
Re: (Score:3, Insightful)
This assumes that a 25-year-old 5.25" floppy drive still works, not to mention that the floppies are actually physically and/or track-compatible with anything he might have around. Both may be quite a leap.
Re:No Removable Media? (Score:4, Informative)
Actually, the floppy drive has a higher probability of working than the hard drive, although it will need some cleaning :)
The floppies can be anything... hard sector, soft sector... You'll have to verify it (xref the floppy mfg number to the manuals).
Given patience, you may even make hard sector floppies from old softsector ones.
The hard drive however is NOT an IDE drive. IDE wasn't designed until 1986, and wasn't widely marketed until a year or two later. The drive is either an MFM or RLL drive. Fifteen years ago you might have found an abundance of controllers that could handle these drives, but you'd still be hard pressed reading the data.
I recommend that you get the Altos up and running, and transfer via the serial port to another machine. You should be able to get 9600 baud, and with any luck (although I'd doubt it) you might be able to push it to 19200.
Re: (Score:2)
Yup. Further, machines of that age were typically able to take 1.2 MB floppy drives. Eight disks would cover that entire 10 MB drive.
Re: (Score:2)
Re: (Score:2)
Unless you're referring only to this hardware line, 1.2MB 5.25" floppy drives were not rare. They were standard equipment on every 286-class or above PC, until 3.5" floppies supplanted them. When a PC had both sizes, the 5.25" drive was almost always the 1.2MB variety.
Re: (Score:2)
Really? It's an 8086. My 8086 only took 360KB disks, not even 720KB. 1.2MB disks were very rare; the only machines I saw with those also had 3.5" disks and only used the 5.25" drive for interoperability with older machines (which didn't support the 1.2MB disks).
Really.
A lot of even older Z-80 based CP/M machines, predating 8086, had 96 tpi floppy drives. For a 5 1/4 disk drive, 96tpi = 1.2 MB, whereas the 360 kB disks were 48 tpi.
They were a real mo-fo to align (yes you could align the disks back then, and you actually had to for interchangeability or only your machine would read them) - the 48tpi's were a breeze by comparison, with tracks twice as wide!
There was absolutely NO compatibility in 5 1/4 floppy drive formats between ANY of the early PC's and the CP/M
audio (Score:5, Insightful)
if the thing has a pc speaker you can (with a bit of work) and a noisy export via modulated audio.
of course if you have access to a serial port controller that's easily the simplest method.
Re:audio (Score:5, Funny)
Alternatively, he could uuencode all the data, cat it to tty, take photos of the monitor and then OCR it.
Let's be realistic -- where's the fun in doing it like that?
Re: (Score:2)
I think the display offers more bandwidth: http://www.erikyyy.de/tempest/ [erikyyy.de]
yeah (Score:5, Informative)
Xenix used their "sco xenix" filesystem. The Xenix filesystem is supported under the mount utility in modern 2.6 linux kernels
by Anonymous Coward
NO DISASSEMBLE ALTOS! (Score:5, Insightful)
Seriously, don't go there, not until you get the data off via the serial port (or flatly establish that you _can't_).
You are dealing with a system that is lucky to be functional _at all_ after 25+ years, and presumably got heavy use while it was active. Corrosion, brittle plastics, dust worked into dangerous areas, etc..
If it's working now, taking it apart stands a good chance of breaking something that is difficult or impossible to fully repair, and you don't want to go there until the information is preserved.
Re: (Score:2)
I'd go for the serial port as well, worked on my old Atari.
Re: (Score:3, Informative)
Hard drives almost always die due to bearing failure at this age, more specifically, lubricants turning to glue essentially.
If that hasn't happened, he's probably pretty safe, its probably all gone!
Either way, removing the drive to put in something else most certainly increases the chances of problems, and while unlikely, the Xenix driver in Linux may have some quirks dealing with an FS that old. The Xenix driver certainly isn't one of the more well tested fs drivers.
With what really is an archological fin
Serial port. (Score:3, Informative)
Hmm, well 'Xenix' is actually an old SCO product which SCO originally bought off Microsoft, but it was then licensed to several other vendors - but as has been said here, your best bet is the serial port. Either use UUCP, or if you have a compiler on the host - compile up a simple xmodem/ymodem/zmodem binary and transfer like that. Worst case scenario, tar up all the data, compress it (it would have old style unix compress -.Z), uuencode it (if you don't have uuencode, you can download it -it's just a shell script I recall), split it up into chunks, then just cat each individual chunk onto another host and reverse the process to decode it all back into a tar file. You might want to checksum each bit too (sum should be on old Xenix systems).
I think removing the disk and mounting it on another host should be your absolute last resort.
Re: (Score:3, Insightful)
Hmm, well 'Xenix' is actually an old SCO product which SCO originally bought off Microsoft
Not exactly. Microsoft bought the code from AT&T then hired SCO to port it to 16-bit systems. SCO did the development under contract and Microsoft did the marketing.
If it runs Xenix 3 or later, it supports FAT, so copying to a floppy might be an option (if you have another machine with a 5.25" disk drive.
Compress is probably not worth bothering with. It's a 10MHz 8086. The time taken to compress the files is likely to be more than the time saved copying them.
Re: (Score:2)
First off, where did the parent mention any personal ties to SCO?
Second, the SCO in question is Old SCO (Santa Cruz Operation.) Old SCO sold their Unix rights and such to Caldera, and then renamed themselves Tarantella, and were bought out by Sun, who in turn was bought out by Oracle. They've got nothing to do with the lawsuits.
The SCO you're talking about is New SCO (The SCO Group,) which is what Caldera renamed themselves to after purchasing Old SCO's Unix rights.
Make a disk image (Score:2, Informative)
If the system isn't bootable, and you have the right drive controller, carefully connect the old drive to a new system and use something like "ddrescue" ( http://www.forensicswiki.org/wiki/Ddrescue [forensicswiki.org]) or "dd_rescue" ( http://www.forensicswiki.org/wiki/Dd_rescue [forensicswiki.org]) to take a disk image. Both those programs try to recover from bad blocks, whereas standard dd usually will error out. (Personally, I'd make an image even if the system is bootable.)
With the disk image extracted, you can pack the hardware away or do wh
Altos 586 (Score:5, Informative)
Anyway, even if there were an operating system available today that is still capable of parsing the Xenix filesystem, you wouldn't be able to get to it because the disk is attached to the system I/O board using an ST506 controller. Good luck finding a modern computer with one of those in it.
You're going to have to move that data off the machine the way we did it back in the days when an Altos was a modern computer. Plug a null modem cable into that serial port and use UUCP to get the data moved. Or if the machine has rzsz installed, you might be able to get away with using Zmodem instead.
Re: (Score:3, Informative)
Even if you could find a relic ST506 card, it would be ISA. You can't find that either. Then try to find a driver...
Reading the disk will be tricky. (Score:3, Informative)
This takes me back....
Firstly, I'm sure that there were never 10MB IDE drives. The drive will either be ST506, ESDI or possibly even SCSI.
Secondly Xenix would create several filesystems within the Xenix partition, using its own separate partition table. As far as I'm aware no mechanism to read these tables was ever added to the Linux kernel.
Re:Reading the disk will be tricky. (Score:5, Interesting)
Re: (Score:2)
Firstly, I'm sure that there were never 10MB IDE drives. The drive will either be ST506, ESDI or possibly even SCSI.
I would be surprised if you were not wrong about 10MB IDE drives. I have a GRiDPad with a 20MB IDE. I didn't believe it either. Almost all the electronics in IDE are on the drive, so the cost differential in the system is minimal. However, I would also be surprised if you were wrong about what the disk probably is, in the long term. I'd guess MFM or ESDI. Both use the same cabling but not the same interface, which is annoying.
Secondly Xenix would create several filesystems within the Xenix partition, using its own separate partition table. As far as I'm aware no mechanism to read these tables was ever added to the Linux kernel.
I saw mention once of a Xenix slice patch, but I couldn't find it.
Re: (Score:2)
Easy enough to check the interface. IDE uses one flat cable. ST-506 and its cousins used separate control and data cables. Same 4-wire power connector.
Re: (Score:2)
Don't forget (Score:2)
Watch out for ANSI Bombs! :)
Not meant to be funny... (Score:3, Interesting)
Screendump.
"WTF?"? Assuming most of the data is ASCII/ANSI, cat it to the screen, preferably with pagination (it will ease the conversion if pagination is used). Place a high res camera in front of the screen and photograph/video record the data then run the photos through OCR...voila! (of course if video is used you'll want to just grab 1 occurrence of each page...if you've just done a cat without pagination this is going to make the conversion a lot harder).
Of course the above sounds stupid but with hardware that age you want to do everything possible to capture the data as fast as possible. Depending on how much data you're talking about you might be able to do the above faster than transferring the data via serial.
Oopps, time for me to climb back into my box.
Re: (Score:2)
I thought of that, but OCR is definitely a NO-NO
However, enconding bits into different chars may work. If it's a color display you can put more data into each 'symbol', but even if you have 'dark square' / 'light square' this may work.
But using that encoding it's probably just as fast as a serial port :/
Screen? What screen? How about Google Voice? (Score:2)
uh... you know the Altos doesn't have a screen, right?
Like most older Unix-y systems, you plug a terminal (or a bank of modems, or a protocol converter or whatever) into one of the serial ports, just like how you might configure a router these days. The system might have been sold with a terminal, but video output was not part of the computer itself.
Wait a minute, computers have serial ports nowadays too! Seems like you could just use those, with a null modem cable.
I'm waiting for someone to suggest plugg
Re: (Score:3, Funny)
If you're not sure how to do this, I suggest renting and watching "Firewall" with Harrison Ford. You just need an iPod and a fax machine to tear into. There's a full tutorial in the movie. Works like a charm every time! Oh, and you'll need some tape.
Nobody asked the name of the BBS? (Score:2)
(he says nervously)
Not IDE (Score:2)
Re: (Score:2)
Most likely the Altos 586 would have used the so-called ST-506 interface (also colloquially known at the time as the MFM or RLL interface),
They're known as MFM or RLL because you have a controller which does MFM or RLL and a disk which does MFM or RLL. Therefore, you have an MFM disk and controller, or RLL disk and controller. The fact that they both use ST-506 signaling and cables is relevant, but not to the name. Some MFM disks would do RLL, which did complicate the picture a bit, but since most wouldn't, it doesn't matter. AFAIK RLL on MFM was much the same. ESDI also used ST-506 cabling, but not signaling.
Is this worth it? (Score:2, Insightful)
The porn from that era just wasn't as good as you remember it to be. Perhaps you're better off with the good memories that you have. The reality can only diminish them. Leave the data on that old machine and you'll be happier.
My two cents (Score:3, Informative)
I worked on these way back when. I'm surprised it still works. I agree with the above, you have two options:
1) tar up the whole filesystem (if it will fit), and use uucp to move it via serial port. Make a null-modem cable and ship it across. Be careful to get the flow control right. Some of the old machines had serial ports that couldn't keep up with 9600 baud, so needed RTS/CTS or DTR flow control to avoid overruns.
2) It should have the ability to make FAT format floppies. Do it piecemeal, if you can find a 1.2 MB 5-1/4 drive for a PC anymore.
The filesystem is XENIX format, not FAT. If I recall, it's similar to the original SVRX filesystem. It MIGHT mount under Linux, but I'd be more afraid of an incompatible controller frying the drive. I don't recall these machines used IDE, I could have sworn they predate IDE, and the drive would have been either the old Shugart interface, or some kind of SCSI. The Altos machines I used had either a 10MB or 40 MB Shugart, and those were the BIG sealed units. IDE didn't come in till 3-1/2" drives, and I believe the later Altos machines had at best 5-1/4 drives either ESDI or SCSI.
Re: (Score:3, Informative)
I worked on equipment of that vintage. It is possible it has mtools installed on it to read and write FAT
floppy disks.
You could create one big tar file, then use split to chop it into floppy sized pieces. Then the trick would be
finding a 5 1/4 floppy drive and matching controller to plug into a modern machine.
I had the dubious pleasure of working with Trusted Xenix, which resembled SELinux today. It required a '286 or above
because it depended on 286 protected mode and took up about 12 MB on the hard driv
Re: (Score:2)
***2) It should have the ability to make FAT format floppies. Do it piecemeal, if you can find a 1.2 MB 5-1/4 drive for a PC anymore.***
My memories of stuff two decades ago are hazy at best, but I have this vague memory of writing FAT formatted floppies in Xenix(?)/SCO Unix(?) (The outfit I worked for had clients with both) being VERY, VERY slow. Something about resetting the drive and repositioning the heads between every sector(?). Maybe it was some other situation. Or maybe I didn't do things right.
File systems were simpler back then (Score:4, Informative)
Ah, the Altos systems. 8800 series, then 486, then 586. They used up numbers years before Intel got to them (the Altos 486 had an Intel 80186 in it, and 4 serial ports). Often paired with Wyse terminals. Anybody else remember "business basic"?
It's almost certainly an ST506 drive; you will be very hard pressed to connect it to a PCI era system; probably can only get as far as AT bus machine.
In any case, if you do manage to image the drive, the filesystem will be based on either Unix version 7, Unix System V, or the Berkeley Fast File System. It wasn't until Linux rolled along that we started to seriously fork into lots of file system variants. It's most likely the basic System V file system, which is well documented, and pretty simple stuff.
The posters above are correct, however. You really should try the serial port approach first. I'd go for cu over uucp - getting uucp running can be quite an exercise in itself. And you'll want either tar or cpio; probably tar, but watchout for version and format incompatibilities there as well.
You can also just cat the data out a serial port, and capture it as a session log on the other end. That's likely to be the easiest solution, and perhaps more reliable than any other.
You haven't said what the nature of the data is, but after this much time laying dormant, you are likely to have substantial challenges at the application level interpreting the data as well.
Re: (Score:3, Informative)
Re: (Score:2)
tar over serial? (Score:5, Informative)
You can use tar and serial ports.
Once you get the systems connected via serial, you can do something like this on the Xenix box:
tar cf /dev/serialdevice0 /home (or whatever directory you want to move)
then on the Linux box on the other end:
tar xpf /dev/ttyS0
will unpack the data. Tar hasn't changed much in decades, and works very well through pipes like this. Good luck. :)
Re: (Score:3, Interesting)
I agree, a tar pipe is the best way to go, but do a drive image, not the data itself first.
Then do the data afterwords, just in case there are some sort of problem with the image.
This is computer archeology essentially, doing your absolute best to maintain the original data in its exact form will result in the most history being saved.
Then you can do other cool things like trying to get it to boot in emulators and suck to manipulate the system without the possibility of damaging the original device
SCO OpenServer on VMWare using disk image (Score:2)
Once you've taken a disk image of the original machine and have the image on a less fragile system, Linux will probably mount it with:
mount -t sysv -o loop /path/to/image /mnt/tmp
(possibly with any required -o offset= if it's a full-disk image not just an image of the partition/slice containing the file system).
Failing that, you can probably read it with SCO OpenServer 5.x if nothing else will handle it. SCO OpenServer still runs under current VMWare releases (though linux-kvm's SCSI HCI implementation is t
dd, slip (Score:2)
Assuming you have raw disk access I'd just dd the entire filesystem out over the serial port. If you have slip on that machine I'd create a slip link between the Altos and a Linux (or *BSD) box so you can use TCP. Once you have the whole disk image in an image you can use whatever tools available to extract the data.
Re: (Score:2)
netcat and dd [init.sh]
Are you sure it's an IDE drive? More likely MFM (Score:5, Informative)
IMHO you should use the serial port to move whatever data you want moved. Your chances of success with other methods are low.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
You can still buy a brand new motherboard with an ISA slot today [orbitmicro.com]. Admittedly they are more expensive than a more mainstream motherboard, but anyone telling you that they don't exist is just plain ignorant. The ISA slot is not going to disappear anytime soon. If I have $100,000 upwards worth of equipment that is controlled by a computer using an ISA expansion card, I am not throwing it out because the computer is now kaput There are a whole range of USB to ISA and PCI to ISA converters that you can buy as w
Re: (Score:2)
I haven't seen a computer manufactured with an ISA bus slot for well over 10 years.
ISA-equipped mobo's are still produced and in use (a Google search for "isa motherboard" will tell the tale), mainly for data acquisition. There are a lot of legacy DAQ apps out there that depend on the ISA bus. I have a chassis dyno in my shop, 4 years old that uses ISA for DAQ.
Not all MFM controllers are compatible (Score:5, Interesting)
I worked with a lot of MFM (ST506 interface) drives back in the day, and from my experience it was very unlikely that different models of MFM controller cards could read the drives from one another. If I installed a newer MFM disk controller card in a machine or moved the drive to a different machine with a different MFM controller, I would almost always have to re-low level format the drive before I could even run DOS format. (And mine were just FAT16 so the file system was never the issue)
So even if you have another MFM controller card, unless it is the exact same model of card it is unlikely that you could read sectors off of the drive. Their underlying low-level formats seemed to differ.
I also actually had the pleasure of briefly using an older model Altos 8600. That model had a bunch of serial ports for dumb terminals, an 8 inch floppy drive and an *8 inch* 40 meg Quantum Q2040 hard drive. I still have the 8" Microsoft Xenix floppy disks.
Re: (Score:2)
Does anyone remember making the 506 dance?
The drive was so heavy duty that certain seeks on the drive would make the drive shake violently, moving the system case itself. Folks traded these seeks. I don't recall any serious damage coming of this. These were 5 1/4 inch, full height drives, if I remember correctly. Freakin' indestructible tanks.
Hard Drive Most Likely MFM... (Score:2)
The hard drive in that ancient behemoth is most likely a MFM device. I don't think you're going to find anything "cheap" to read the data off that thing and onto some modern storage media. Other than sending it to a data recovery lab, I would have to agree with the bulk of the posts here: USE THE SERIAL PORT! Those are probably your only two options for a device that old with data that is irreplaceable and of an historic nature.
'Nuf said.
Re: (Score:2)
Oh, and what's the deal with the "slow" serial port excuse? The serial port should be able to do at least 56K (if not 115K if RS-232). If the drive is full (10 MB), at 115kbps the job would take little more than an hour! Waaa!
Not a real request (Score:2)
Not really all that *old*... (Score:2)
I do find a 10MB HDD in a 586 somewhat strange, though... Yes, they certainly did exist, but it would have counted as an antique even
Re: (Score:2)
no way! the best way is... (Score:4, Funny)
these people are all wrong...just take it to Best Buy! the Geek Squad could save the data for you fo' sure!
Re: (Score:2)
No need to bother a million Slashdot readers.
I wasn't bothered. I thought it was worth it just to see the picture of the system in the link. I can't decide if it looks more like a prop from the set of Space:1999, or the hood scoop from some 1970s AMC muscle car.
Re: (Score:2)
What you've got could very well be one of the most important finds in the field of technoanthropology.
Fortunately, his name does not seem to be Belzoni. :)