Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Need Help Salvaging Data From an Old Xenix System

timothy posted more than 4 years ago | from the warrior-princess dept.

Data Storage 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?"

cancel ×

325 comments

Sorry! There are no comments related to the filter you selected.

I'd do it the slow but secure way. (5, Insightful)

Securityemo (1407943) | more than 4 years ago | (#31556766)

Even if it would take weeks. You're handling a historical relic, don't want to mess it up.

Re:I'd do it the slow but secure way. (0)

Anonymous Coward | more than 4 years ago | (#31556792)

Even if it would take weeks. You're handling a historical relic, don't want to mess it up.

Which is pretty much what Milo has already said in his post.

Re:I'd do it the slow but secure way. (5, Informative)

jgardia (985157) | more than 4 years ago | (#31556836)

exactly, 10mb at 9600bps will take only 2-3 hours.

Re:I'd do it the slow but secure way. (5, Interesting)

Anonymous Coward | more than 4 years ago | (#31556842)

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 (4, Informative)

davidwr (791652) | more than 4 years ago | (#31556986)

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:I'd do it the slow but secure way. (2, Informative)

HBI (604924) | more than 4 years ago | (#31557304)

I would be shocked if you couldn't get 38400 or even 57600 out of a null modem cable. Assuming a buffered chip at the receiving end - 16550 type.

Re:I'd do it the slow but secure way. (1)

demonlapin (527802) | more than 4 years ago | (#31557450)

Probably an 8250 in that thing.

Re:I'd do it the slow but secure way. (1)

bkeahl (1688280) | more than 4 years ago | (#31557400)

I agree. Even at 9600 baud you'd get 3.5MB in about an hour. I was performing data transfers @ 19200 all over the place back in the 80's, so 9600 or 4800 should be a snap. Most likely a couple hours, and at worst overnight. The big question is do you have the software on the Xenix box to perform a file unload like that. I remember sitting in front of one once upon a time as part of an engineering project but don't remember a darn thing other than thinking this was not going to be the OS of the future, so I have no clue what is built into the OS.

Re:I'd do it the slow but secure way. (0)

JamesP (688957) | more than 4 years ago | (#31557402)

I'm guessing the serial port can get to 115200bps it's modems that are a problem.

But still, even at 14400bps this is 'fast' (like, a couple of hours)

Funny story, I once made myself an ""mp3"" player using an old Pentium 100, http://www.damp-mp3.co.uk/ [damp-mp3.co.uk] and a small parallel port keyboard. Loading files was done thru the serial port at 115200 using a zmodem client.

Re:I'd do it the slow but secure way. (5, Interesting)

nurb432 (527695) | more than 4 years ago | (#31556972)

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:I'd do it the slow but secure way. (1)

HBI (604924) | more than 4 years ago | (#31557292)

I don't buy the 'one of the first' either. Trash-80 BBS' were commonplace in that timeframe and there were CP/M based BBS' in operation before 1980. Hell, C-64 BBS' were so common that the term "Commie BBS" had a real, derogatory meaning.

Not to mention the mini and mainframe systems that looked like BBS.

Re:I'd do it the slow but secure way. (1)

Low Ranked Craig (1327799) | more than 4 years ago | (#31557454)

TRS-80 Model 4 made a really good BBS system. Searchlight BBS...

Re:I'd do it the slow but secure way. (1)

HBI (604924) | more than 4 years ago | (#31557560)

I ran the DOS version of SL but I saw Frank's Trash-80 version. It was in BASIC but it ran well. He put the source code for it up on his website not that long ago.

DOS SL was one of the coolest pieces of work i'd ever seen. A BIOS-interrupt hooking comm driver. The whole BBS was a Turbo Pascal program simply compiled using CRT directvideo:=false, atop that comm driver. All the hard work was in the teeny little comm driver.

Re:I'd do it the slow but secure way. (0)

Anonymous Coward | more than 4 years ago | (#31556996)

Hi,

Maybe you must considerer to mount old disk on a linux filesystem. Take a look on mount man page and you will discover that usually it supports xenix filesystems. as "mount -t xenix'. Good luck,

Re:I'd do it the slow but secure way. (-1, Troll)

Anonymous Coward | more than 4 years ago | (#31557002)

Even if it would take weeks.

exactly, 10mb at 9600bps will take only 2-3 hours.

No way it would take weeks. Even if the serial port was only 300 bit per second ... 10*1024*1024*8/300/3600=77.6 hours ... at 14400bps this would take 1.6 hours

Dear Slashtards,
When he said Even if it would take weeks he meant it as a figure of speech, used to encourage the poster to take his time and get it right (you know, kind of like sex). It was not an actual estimation of time.

Your Pal,
Get A. Clue

Use the serial port ... (2, Informative)

Anonymous Coward | more than 4 years ago | (#31556772)

... I mean, why not? Yeah, it's slow, but you only have 10 meg of data!

Re:Use the serial port ... (0)

Anonymous Coward | more than 4 years ago | (#31556818)

10MB on serial, assuming 9600 baud is somewhere around 2.5 hours? Why is there even any question on this? Unless he thinks the drive wont last 2.5 hours of course.

Re:Use the serial port ... (0)

Anonymous Coward | more than 4 years ago | (#31556830)

Indeed, assuming full 10 megabytes of data at 9600 baud, it'll take less than 2 hours 20 minutes.
Since there's probably only a few megabytes of actual data you need to copy, and the serial port might support faster data rates, it really won't take very long.

Re:Use the serial port ... (1, Interesting)

Anonymous Coward | more than 4 years ago | (#31556888)

Seconded, use the serial port. Least invasive method, even if it takes ages.

There's also the human angle to consider. If we are talking decades ago, can you be sure all folk who posted all those messages want them to come back to life again? It wasn't unreasonable for the individuals of that time, when the Internet was something few had heard of and only a few Universities and research labs had access to, to assume that their postings to a BBS might only have a temporary existence - they weren't to know that some nerd would be archiving them and releasing them in the future to a world where an equivalent of an entire T1 internet connection to your own home would be considered by most as inadequate! :)

As an example: I had to do some requests-for-deletion when Google got their hands on many decades old Usenet archives. Now that every bugger has teh interweb tubes, there are people I don't fancy seeing that stuff from my yoof - when it was posted I didn't intend it to be pushed off into the future to be published to entire bloody world, forever. Had enough bloody trouble with a stalker from back then as it was, I do not fancy them joining the dots and working out where I am now. I don't fancy you guys digging either... hence posting Anon! ;)

Re:Use the serial port ... (2, Informative)

TheRaven64 (641858) | more than 4 years ago | (#31557164)

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 serial link. Back in the early '90s I had an 8086 PC with 5.25" disks and my father had a 386 laptop which took 3.5" disks. The only way of copying games between them was via a serial link. The 8086 machine could handle 115Kb/s, meaning that the entire transfer would only take about 10 minutes. We usually ran it at about half this speed though, because our crappy serial cable didn't have the hardware error checking pins connected, so we needed to use software parity and reducing the line speed made things more reliable.

Re:Use the serial port ... (0)

Anonymous Coward | more than 4 years ago | (#31557252)

Also, the "IDE hard drive" is quite likely to be incompatible with modern IDEA controllers. The first Compaq IDE drives, for example, were incompatible with just about everything else in those days. Lord only knows what is in the Altos.

As others have said, if it is running at all I would NEVER try to remove the drive, but use the serial port and sufficient time.

cu (2, Informative)

jzu (74789) | more than 4 years ago | (#31556798)

UUCP had a command called cu (call up) which is what you need. From "apt-cache show cu" on Debian/Ubuntu:

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:cu (2, Informative)

John Hasler (414242) | more than 4 years ago | (#31556824)

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:cu (2, Informative)

Jah-Wren Ryel (80510) | more than 4 years ago | (#31556866)

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 (1)

jewelie (752077) | more than 4 years ago | (#31556912)

Quite; I used to use Kermit to shift data between all sorts of odd systems via dialup and serial port in the old days. It was the one program that was pretty much guaranteed to be available for everything, really ubiquitous. Definitely the best solution assuming you can get a binary on to it that'll work with it!

Re:cu (4, Interesting)

Antique Geekmeister (740220) | more than 4 years ago | (#31556924)

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 (5, Informative)

Kjellander (163404) | more than 4 years ago | (#31557118)

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:UUCP info you need (2, Informative)

tumutbound (549414) | more than 4 years ago | (#31557296)

If it's Xenix, then it probably predates UFS. I'd expect the original V7 UNIX file system.

Re:cu (1)

tverbeek (457094) | more than 4 years ago | (#31557356)

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:cu (1)

spong (32007) | more than 4 years ago | (#31556956)

If it used to be a BBS system, it will probably have software for one of xmodem, ymodem or zmodem file transfers. You should be able to use rzsz on Linux to transfer files

Research Resources (0, Flamebait)

Phat_Tony (661117) | more than 4 years ago | (#31556802)

Now that this is an "Ask Slashdot," I'm sure someone (who probably helped develop Xenix or something) will give you an exact answer. But in general, "what file system does Xenix use and will it interoperate with Linux/anything modern" is not a difficult sort of question to research, if you're willing to go beyond a Google search. Amazon [amazon.com] has plenty of used Xenix books for cheap, and at least the Dallas and Cleveland (and based on that sample, I'm guessing most large city public) libraries have at least a title or two. Even Ebay has a Xenix manual up for sale.They should tell you whatever you need to know about Xenix, and then you can Google about support for it in modern OS's. .

In fact, you may even be able to just [google.com] Google [google.com] it [indiana.edu] . No need to bother a million Slashdot readers.

Re:Research Resources (1)

Anthonares (466582) | more than 4 years ago | (#31556948)

No need to bother a million Slashdot readers.

It's hardly a bother, I had no idea how to answer his question (as I'm sure most readers don't). Instead, I was interested in the answers.

Even if I went through the Google I'd still want to ask Slashdot and the expertise here.

Slashdot expertise (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#31557122)

http://goatse.fr/ [goatse.fr]

Re:Research Resources (1)

Waffle Iron (339739) | more than 4 years ago | (#31557280)

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.

UUCP (5, Insightful)

John Hasler (414242) | more than 4 years ago | (#31556806)

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:UUCP (1)

SimonInOz (579741) | more than 4 years ago | (#31557012)

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 do that. If it ain't broke, you definitely don't want to fix it. 9600 baud, that's 960 bytes per sec, 60k per minute, 3600kb per hour, so it ought to take about 3 hours. But of course what you want is the message log, which is probably just a small part - really, it won't take long.

Sounds like fun. (I remember when I had time for hobbies like this. Must have been before I got married and had children).

What reads serial these days? (1)

managerialslime (739286) | more than 4 years ago | (#31557286)

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:UUCP (1)

tverbeek (457094) | more than 4 years ago | (#31557302)

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:UUCP (1)

John Hasler (414242) | more than 4 years ago | (#31557510)

> 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:UUCP (1)

Hurricane78 (562437) | more than 4 years ago | (#31557030)

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 (1)

assemblerex (1275164) | more than 4 years ago | (#31556810)

Old connectors, pcb cracks, static damage...why risk it? Write a script and automate it...

Image it first (0)

Anonymous Coward | more than 4 years ago | (#31556822)

You might have done this already, but since you do not mention it: I would highly suggest making an image of the disk (using dd or dd_rescue) and working on a copy of that, before the original disk dies. Maybe foremost [forensicswiki.org] can be of any use, although I doubt it can either handle the original Xenix file system - whatever it might have been - or BBS text files very well...

Get in touch with a data restoration specialist. (0)

Anonymous Coward | more than 4 years ago | (#31556828)

Do some research, and find professional data restoration specialists in your area. If there aren't any nearby, get ready to travel. You've got a real gem on your hands. DON'T FUCK THIS UP. Get it to a professional who does data retrieval of this sort for a living, and knows how to avoid cock-ups. You'll probably have to pay at least a few hundred dollars, but it will probably be worth it.

What you've got could very well be one of the most important finds in the field of technoanthropology.

Re:Get in touch with a data restoration specialist (1)

K. S. Kyosuke (729550) | more than 4 years ago | (#31557522)

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. :)

No Removable Media? (1)

lobiusmoop (305328) | more than 4 years ago | (#31556832)

Your website, along with this website [classiccmp.org] suggests that the ALTOS 586 has a 5 1/4 floppy drive in it.

Re:No Removable Media? (2, Insightful)

NNKK (218503) | more than 4 years ago | (#31556882)

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? (4, Informative)

Der PC (1026194) | more than 4 years ago | (#31556966)

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:No Removable Media? (1)

TheSHAD0W (258774) | more than 4 years ago | (#31556946)

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:No Removable Media? (1)

TheRaven64 (641858) | more than 4 years ago | (#31557188)

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).

Re:No Removable Media? (1)

tverbeek (457094) | more than 4 years ago | (#31557414)

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:No Removable Media? (1)

Mister Transistor (259842) | more than 4 years ago | (#31557436)

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 machines that preceded them. I used to have a format exchange program years ago and it had at least 50 different disk formats it would do. Finding anything today that would read them would be most likely impossible, still better to do a serial capture, IMHO.

audio (4, Insightful)

nadaou (535365) | more than 4 years ago | (#31556834)

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 (5, Funny)

Anonymous Coward | more than 4 years ago | (#31557004)

if the thing has a pc speaker you can (with a bit of work) and a noisy export via modulated audio.

Alternatively, he could uuencode all the data, cat it to tty, take photos of the monitor and then OCR it.

of course if you have access to a serial port controller that's easily the simplest method.

Let's be realistic -- where's the fun in doing it like that?

yeah (5, Informative)

Anonymous Coward | more than 4 years ago | (#31556860)

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! (5, Insightful)

NNKK (218503) | more than 4 years ago | (#31556872)

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:NO DISASSEMBLE ALTOS! (1)

Der PC (1026194) | more than 4 years ago | (#31556982)

Enough with the scaremongering. I have several computers older than the Altos that still perform, look and behave like new.

Serial port. (2, Informative)

mrbill1234 (715607) | more than 4 years ago | (#31556932)

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:Serial port. (2, Insightful)

TheRaven64 (641858) | more than 4 years ago | (#31557220)

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:Serial port. (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#31557250)

Dude, serious mistake, announcing your ties to SCO ... I mean they are going to sue the hell out of you, and if they don't it means you're working for them, so /.ers lynch him!

btw, why don't you wait another decade or so and sell it for tons of cash?

Make a disk image (2, Informative)

jdimpson (789437) | more than 4 years ago | (#31556952)

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 whatever with it. Then you can focus on finding (or writing) tools to read the disk image. If you find that there is a Linux filesystem driver, you can use the loopback behaviour (see the man pages for "mount" or "losetup") to treat the disk image as if it were a drive. If you don't find a driver, perhaps you'll find some specialty command-line tools that can extract information, or documentation to write your own. At worst, you could use the "strings" command to read any text found on the image. Since you're working against an image, you can take your time, experiment with ad hoc techniques, make mistakes (remember to make backups), and try again and again.

Altos 586 (5, Informative)

IGnatius T Foobar (4328) | more than 4 years ago | (#31556958)

What a great machine. The Altos 586 was the first machine I used to run my BBS (which has run nonstop since 1988 and is still online today) [citadel.org] before SCO Xenix and later Linux arrived on the scene. It was an insanely cool computer.

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.

Reading the disk will be tricky. (2, Informative)

shippo (166521) | more than 4 years ago | (#31556964)

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. (4, Interesting)

charlie (1328) | more than 4 years ago | (#31557150)

... However, as I remember from back when I worked at SCO (years before the name and some assets were sold to the lunatics from Utah), Xenix filesystem and partition table support was rolled into SCO UNIX SVR3.2/386. And Open Desktop. And ODT came with a proper working TCP/IP stack. It's probably overkill, but once you've tried using uucp to get the files off the BBS, you might want to pull the ST506 drive (presumably an MFM-encoded one, not RLL-encoded) and stick it into a shiny new 386 with, say, 4Mb of RAM and a 40Mb disk with SCO UNIX installed. That should enable you to mount the filesystems and export them via NFS. It's a lot of work, though.

Re:Reading the disk will be tricky. (1)

drinkypoo (153816) | more than 4 years ago | (#31557158)

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:Reading the disk will be tricky. (1)

Smallpond (221300) | more than 4 years ago | (#31557488)

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:Reading the disk will be tricky. (1)

systemeng (998953) | more than 4 years ago | (#31557300)

Take a look at the unix heritage society. See http://minnie.tuhs.org/TUHS/ [tuhs.org] I once used some code I found there as the basis of a program I wrote that could read an antique CCC scsi disk from that era on a Sun workstation and export the files.

Don't forget (1)

CODiNE (27417) | more than 4 years ago | (#31556978)

Watch out for ANSI Bombs! :)

Not meant to be funny... (2, Interesting)

MrBandersnatch (544818) | more than 4 years ago | (#31556988)

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:Not meant to be funny... (1)

baka_toroi (1194359) | more than 4 years ago | (#31557262)

That display is most probably curved. Do you really think OCR would work properly on those conditions?

Re:Not meant to be funny... (0)

Anonymous Coward | more than 4 years ago | (#31557430)

It can be uncurved. Once you get one image uncurved, it'd be rather trivial to write a batch script to process the rest, and THEN you run them through OCR.

Re:Not meant to be funny... (0, Insightful)

Anonymous Coward | more than 4 years ago | (#31557336)

What a load of bullshit...

Re:Not meant to be funny... (1)

JamesP (688957) | more than 4 years ago | (#31557474)

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 :/

Google? (1, Informative)

Gizmoguy (818250) | more than 4 years ago | (#31556992)

Have people lost the ability to Google for answers before pestering other people? After about 5 seconds I found this:

http://aplawrence.com/SCOFAQ/FAQ_scotec1linuxfs.html [aplawrence.com]

You're welcome. =P

DD (0)

AC-x (735297) | more than 4 years ago | (#31557036)

If the drive is actually compatible with a modern PC you could start by just taking a straight rip of the data using DD. That way you've at least got an archive of the data, and at only 10 megs you could probably analyse the data in a hex editor fairly easily.

Use tar, uudecode, and capture it (0)

Anonymous Coward | more than 4 years ago | (#31557046)

Setup your terminal emulator package to capture to a file.

You'll need to test this and make sure syntax is write because it has been a while since I've needed to do this.

tar -cvf - /datadir | uuencode data.tar -

Capture in emulator then transfer it to Linux and uudecode it and untar it. 10MB will take about 2 hours at 9600

null modem cable (0)

Anonymous Coward | more than 4 years ago | (#31557062)

treat it like a bbs connection. have your new system connect to the old one and download the files and pray the 10mb IDE drive still works.
You obviously dont have to copy the whole drive just the relevant bbs files. Of course you might need to know the old passwords.

Nobody asked the name of the BBS? (1)

ibsteve2u (1184603) | more than 4 years ago | (#31557068)

Depending on which one it was, some of us may not want our beer-posts out there for the whole world to see....





(he says nervously)

Not IDE (1)

BBCWatcher (900486) | more than 4 years ago | (#31557070)

The Altos 586 was available in 1983 and predated Western Digital's invention of IDE. 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), although SASI or a proprietary interface would have been possibilities. If it's ST-506 then you might be able to fire up a old 386 or 486 PC/AT-compatible with an old ST-506 controller and copy the contents of the drive using Linux. But I would agree with essentially everyone else: use one of the serial ports to get the data transferred. Xenix has uucp available, and uucp is also still available for today's operating systems. That'll work.

Is this worth it? (2, Insightful)

Profane MuthaFucka (574406) | more than 4 years ago | (#31557126)

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 (2, Informative)

Ken Hall (40554) | more than 4 years ago | (#31557132)

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:My two cents (2, Informative)

KenSeymour (81018) | more than 4 years ago | (#31557312)

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 drive.

File systems were simpler back then (4, Informative)

bradm (27075) | more than 4 years ago | (#31557198)

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:File systems were simpler back then (-1, Offtopic)

Anonymous Coward | more than 4 years ago | (#31557306)

Under 20 noobie here. What do you all mean by "cat"?

Re:File systems were simpler back then (2, Informative)

demonlapin (527802) | more than 4 years ago | (#31557528)

On the random chance this is not a troll, cat is the command in Unix to display the contents of one or more files. It can be redirected to output to anywhere you like, e.g. a serial port.

Re:File systems were simpler back then (1)

bartwol (117819) | more than 4 years ago | (#31557562)

For the possibility that you are being sincere...it's a frequently used Unix command [linuxmanpages.com] that, in some of its simpler usage forms, copies the contents of a file to another file, or to a communications port (such as the serial port as discussed here), or to the computer's screen.

A few points (0)

Anonymous Coward | more than 4 years ago | (#31557230)

1. One or more mentioned Google. It was obviously tldr for them. You should start at http://justfuckinggoogleit.com Serously.

2. That drive is most likely MFM due to it's size and age. Even if you find a controller you won't likely have a machine that you can plug it in to. When was the last time you saw an ISA slot? IDE was designed in 1986 and your machine was 1983ish. If it has 2 ribbon cables going to it, it's MFM (or RLL), or ESDI. If 1 it's going to be SCSI.

3. Linux should mount it just fine. Even if it runs MP/M-86 (a CP/M variant), Xenix, or MS-DOS.

4. Given the age everything is likely to be stored in straight text files.

5. Magnetic media used Ferric Oxide (Rust) to record on. They were dying from the day the were manufactured. Good Luck with that!

tar over serial? (4, Informative)

ZorinLynx (31751) | more than 4 years ago | (#31557234)

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. :)

Memory Lane... (0)

Anonymous Coward | more than 4 years ago | (#31557308)

Off topic but I'm gonna be an old man.. I remember those machines from the early 90s. Working at a consulting firm that sold accounting software I replaced many of them with X86 boxes running SCO UNIX driving serial terminals off digiboards and eventually ethernet. SCO owned the market back then for small business UNIX. That is why they fought so hard against linux, because suddenly there was a free solution out there spreading like a brush fire.

When it came time to extract the data off the old Altos boxes, we used magnetic tape. The machine you have should have a tape drive. Buy an old scsi tape drive off ebay and plug it into a modern box and away you go...

SCO OpenServer on VMWare using disk image (1)

Craig Ringer (302899) | more than 4 years ago | (#31557332)

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 too incomplete so it crashes on kvm) and can be pointed at the disk image that way.

You can still find the old FreeSCO ISOs around on the mouldier corners of the 'net. I can't offer you any, since I only have fully licensed OpenServer 5.0.5 which I can't distribute. It's for a truly amazingly legacy Microsoft Xenix application from 1983!

SCO uses HPFS by default, but I think Xenix used something more elderly. SCO's mount(ADM) lists it only as fs type "XENIX".

dd, slip (1)

knarf (34928) | more than 4 years ago | (#31557338)

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.

Oh Brother.... (1)

NoOnesMessiah (442788) | more than 4 years ago | (#31557404)

Oh, Hesu..., you whiners haven't looked in my garage, ever!; Apple /// with 5Mb Profile Hard Disk anyone? If I recall correctly, that flavour of xenix is EFS and there are still some old unixes (and early 90s BSDs) that can bridge that gap. It's probably an MFM or RLL ISA controller but I'm sure you could cobble together the hardware to either extract data or image the drive. The people whining about "OMG! Don't Touch It! You might break it!" never lived through that vintage of hardware....

UUCP? (1)

gjyoung (320540) | more than 4 years ago | (#31557426)

Inset witty quote about knowing a buncha binary evaporator languages here....

There are tonnes of ways to do this..! (1)

JasonStevens (1574841) | more than 4 years ago | (#31557464)

Dude, it'd be easy.... First you need to make a raw disk image of the thing. I'm assuming you can do that? Your ancient machine should have one of those ST-506/MFM controllers.... You could even use dd on the native platform and swap floppies out of it just by grabbing how many kb you can fit on a floppy at a time, and reconstruct the hd image onto a linux PC.. From there you can either try to mount that hard disk image on linux with an old sysv filesystem driver... Another alternative if you have a serial hookup is to simply hook up a serial port, and do something like "tar -cvf /dev/tty0a /" And redirect it on the other side. If you have uuencode/uudecode you could throw that in there. Heck, you could even use tar with floppy disks. I don't know what you plan to do with your 'stuff' off of the old machine though.... Have you tried to score a copy of Xenix for the pc? It runs on Virtual PC/VMWare ok, it'll boot from a HD with Qemu but the floppy emulation is screwed up in Qemu. There is (was?) the ibcs2 emulation thing for linux as well... There are ways of keeping these things going, although I know the Altos was a unique machine...

Are you sure it's an IDE drive? More likely MFM (4, Informative)

laing (303349) | more than 4 years ago | (#31557508)

As I recall, IDE drives first appeared with about 200MB of capacity. They replaced RLL drives which maxed out at about 140MB. Before RLL there was MFM (same electrical interface, different coding). If it's a 10MB drive, it's probably a Seagate ST506/412 (I had one on my CP/M box). You'll need an MFM controller in anything you hook it up to. You'll also need a BIOS that has a proper disk parameter table for the drive geometry. One problem that you're going to have is that all MFM controllers use ISA bus interfaces. (First there was ISA, then EISA, VLB, then PCI, then PCI-X and finally PCIe.) I haven't seen a computer manufactured with an ISA bus slot for well over 10 years.

IMHO you should use the serial port to move whatever data you want moved. Your chances of success with other methods are low.

Re:Are you sure it's an IDE drive? More likely MFM (1)

demonlapin (527802) | more than 4 years ago | (#31557550)

I had a 70 MB IDE drive in a 386 around 1990, FWIW. But I think anything under 40 is going to be MFM/RLL.

where's Milo? (1)

karlzt (1410199) | more than 4 years ago | (#31557520)

so where's the guy who posted this? He got lots of replies.

Not all MFM controllers are compatible (4, Interesting)

linebackn (131821) | more than 4 years ago | (#31557532)

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.

Hard Drive Most Likely MFM... (1)

multimediavt (965608) | more than 4 years ago | (#31557546)

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.

Not a real request (1)

hduff (570443) | more than 4 years ago | (#31557556)

unless you post pr0^H^Hics of the machine . . .
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>