Please create an account to participate in the Slashdot moderation system


Forgot your password?
Data Storage Microsoft Unix Hardware Linux

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?"
This discussion has been archived. No new comments can be posted.

Need Help Salvaging Data From an Old Xenix System

Comments Filter:
  • by Securityemo ( 1407943 ) on Sunday March 21, 2010 @08:25AM (#31556766) Journal
    Even if it would take weeks. You're handling a historical relic, don't want to mess it up.
    • by jgardia ( 985157 ) on Sunday March 21, 2010 @08:38AM (#31556836)
      exactly, 10mb at 9600bps will take only 2-3 hours.
      • Re: (Score:3, Informative)

        by j741 ( 788258 )

        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)

      • by BitterOak ( 537666 ) on Sunday March 21, 2010 @03:08PM (#31559196)

        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.

    • by Anonymous Coward on Sunday March 21, 2010 @08:39AM (#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.

      • by davidwr ( 791652 ) on Sunday March 21, 2010 @09:07AM (#31556986) Homepage Journal

        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)

          by Anonymous Coward

          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)

        by HBI ( 604924 )

        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.

        • Probably an 8250 in that thing.
          • Re: (Score:3, Insightful)

            by HBI ( 604924 )

            I would expect a 16450 in something with an IDE drive. Though the smallest IDE drive I ever saw was a 40MB one. 10MB makes me think MFM. So you might be right on that.

    • by nurb432 ( 527695 ) on Sunday March 21, 2010 @09:04AM (#31556972) Homepage Journal

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

      • by HBI ( 604924 )

        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.

        • TRS-80 Model 4 made a really good BBS system. Searchlight BBS...
          • by HBI ( 604924 )

            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.

  • by Anonymous Coward

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

    • Re: (Score:3, Informative)

      by TheRaven64 ( 641858 )

      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

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

      • by farrellj ( 563 ) * on Sunday March 21, 2010 @11:36AM (#31557850) Homepage Journal

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


  • cu (Score:2, Informative)

    by jzu ( 74789 )
    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: (Score:3, Informative)

      by John Hasler ( 414242 )

      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)

        by Antique Geekmeister ( 740220 ) on Sunday March 21, 2010 @08:56AM (#31556924)

        It's Xenix. Ancient Xenix. Kermit wasn't commercial software, it was (and is) freeware. ( 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

  • UUCP (Score:5, Insightful)

    by John Hasler ( 414242 ) on Sunday March 21, 2010 @08:34AM (#31556806) Homepage

    It'll take a few hours at 9600 baud. It's your best bet. Let it run over night and the job is done.

    • 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

      • 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, sells a 25-pin Serial-to-USB cable (

        Have fun!

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

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

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

  • Old connectors, pcb cracks, static damage...why risk it? Write a script and automate it...
  • Your website, along with this website [] suggests that the ALTOS 586 has a 5 1/4 floppy drive in it.

    • Re: (Score:3, Insightful)

      by NNKK ( 218503 )

      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.

      • by Der PC ( 1026194 ) on Sunday March 21, 2010 @09:04AM (#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.

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

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

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


          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)

    by nadaou ( 535365 ) on Sunday March 21, 2010 @08:38AM (#31556834) Homepage

    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)

      by Anonymous Coward on Sunday March 21, 2010 @09:09AM (#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?

    • I think the display offers more bandwidth: []

  • yeah (Score:5, Informative)

    by Anonymous Coward on Sunday March 21, 2010 @08:43AM (#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

  • by NNKK ( 218503 ) on Sunday March 21, 2010 @08:45AM (#31556872) Homepage

    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.

    • by dbIII ( 701233 )
      The funny thing is some loser on another thread was telling us all how fantasticly reliable hard drives are. In contrast I've had in a few tapes older than that Xenix box transcribed this year already.
      I'd go for the serial port as well, worked on my old Atari.
      • Re: (Score:3, Informative)

        by BitZtream ( 692029 )

        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)

    by mrbill1234 ( 715607 ) on Sunday March 21, 2010 @08:58AM (#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: (Score:3, Insightful)

      by TheRaven64 ( 641858 )

      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.

  • Make a disk image (Score:2, Informative)

    by jdimpson ( 789437 )

    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" ( []) or "dd_rescue" ( []) 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)

    by IGnatius T Foobar ( 4328 ) on Sunday March 21, 2010 @09:02AM (#31556958) Homepage Journal
    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) [] 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.
    • Re: (Score:3, Informative)

      by sjames ( 1099 )

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

  • by shippo ( 166521 ) on Sunday March 21, 2010 @09:03AM (#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.

    • by charlie ( 1328 ) <charlie.antipope@org> on Sunday March 21, 2010 @09:41AM (#31557150) Homepage Journal
      ... 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.
    • 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.

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

    • Take a look at the unix heritage society. See [] 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.
  • Watch out for ANSI Bombs! :)

  • by MrBandersnatch ( 544818 ) on Sunday March 21, 2010 @09:07AM (#31556988)


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

    • by JamesP ( 688957 )

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

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

      by toygeek ( 473120 )

      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.

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

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

    by Ken Hall ( 40554 ) on Sunday March 21, 2010 @09:39AM (#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: (Score:3, Informative)

      by KenSeymour ( 81018 )

      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

    • ***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.

  • by bradm ( 27075 ) on Sunday March 21, 2010 @09:48AM (#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.

  • tar over serial? (Score:5, Informative)

    by ZorinLynx ( 31751 ) on Sunday March 21, 2010 @09:54AM (#31557234) Homepage

    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)

      by BitZtream ( 692029 )

      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

  • 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

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

  • by laing ( 303349 ) on Sunday March 21, 2010 @10:44AM (#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.

    • 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.
      • my ole man has an old 286 has windows 3.1 on a 20meg ide hdd and 1 meg of ram used to run word perfect 5.1 and firstchoice a spreadsheet program. Took years to get him off that and he won't sell it since it was so expensive to buy. I bet he never throws it out.
    • by jabuzz ( 182671 )

      You can still buy a brand new motherboard with an ISA slot today []. 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

    • by pongo000 ( 97357 )

      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.

  • by linebackn ( 131821 ) on Sunday March 21, 2010 @10:47AM (#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.

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

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

    • 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!

  • unless you post pr0^H^Hics of the machine . . .
  • A working 586? C'mon, not exactly modern, but not really ancient, either. Also zero chance of your box containing "one of the first" BBSs... For reference, Compuserve went live in 1969 - Six years before even the legendary Altair 8800, 17 years before Western Digital developed the IDE standard, and a good 24+ years before Intel released the CPU in Altos to which you refer.

    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
    • by brusk ( 135896 )
      You're confusing the Intel 586 CPU with the Altos model 586 (which had an 8086 CPU running at a blazing 10 MHz); it was introduced in the early 80s. And it might not have been the original machine housing the BBS, so some of the data could be from the 70s.
  • by Kwirl ( 877607 ) <> on Sunday March 21, 2010 @07:07PM (#31561252)

    these people are all wrong...just take it to Best Buy! the Geek Squad could save the data for you fo' sure!

Disks travel in packs.