Need Help Salvaging Data From an Old Xenix System

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

Comments

I'd do it the slow but secure way.

[Securityemo]

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.

[Anonymous Coward]

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.

[jgardia]

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

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

[Anonymous Coward]

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.

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

[nurb432]

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.

[Anonymous Coward]

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.

[HBI]

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.

[HBI]

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.

[bkeahl]

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.

[JamesP]

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

[demonlapin]

Probably an 8250 in that thing.

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

[Low Ranked Craig]

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

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

[HBI]

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.

[HBI]

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.

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

[Ambient Sheep]

I was just about to say the same thing. Having done a lot of serial comms around that time, 16550s weren't really commonplace until the early 90s. I'd say you'd be guaranteed 9600, with 19200 if you're lucky, but as others have pointed out, that's plenty fast enough to transfer 10MB.

However I notice from the article describing the computer concerned that it actually has a Z80-SIO in it. Never used one of those but from memory I think it might do 19200. Whether the operating system on board the box will is another matter though...

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

[Ambient Sheep]

Correction to my post: reading the full specification (rather than just the summary), it seems that rather than a Z80-SIO chip, it actually has a dedicated Z80 processor to do the I/O with, and doesn't say what the actual UART hardware is. So could be a Z80-SIO, or more likely just a bunch of 8250s. Let us know if you open it up!

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

[budgenator]

Xenix was a 16 bit Unix variant pretty much SRVR3 style,
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 /usr rather in /home or /srv.
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.

[Anonymous Coward]

The 14.4 modem didn't come out until 1991. The serial port on that machine will do 19.2K though using a crossover cable. That shouldn't take more than 80 minutes to transfer 10MB of data.

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

[postbigbang]

Probably a 16550 USART; capable of pretty fast speeds. Use it as a tty(x) device and just blow the file system through it. Ther are lots of UUCP docs that work with Xenix, and it supported UUCP nicely.UUCP is easy to use... comparatively speaking.

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

[Hamoohead]

I was running QBBS multi-user with FrontDoor on an 8088 IBM PC with DOS 3.3 and DoubleDOS in '86. And I thought my USR 9600 baud modems were fast and my Seagate ST-80 RLL was huge.

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

[Z00L00K]

If you are lucky it would be an 8250. Nothing fancier than that. But never mind that - you are only sending data on that port, not receiving it.

For the hard disk - most likely the ST412/506 interface that's MFM formatted, SASI or first generation SCSI. So I wouldn't dare trying to connect that disk to another computer. Just moving the computer could cause the hard disk to go belly-up.

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

[Ambient Sheep]

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.

[Anonymous Coward]

Exactly. And you could be done by now instead of reading comments by people telling you that you could be done by now.

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

[Anonymous Coward]

How on earth is pointing out that the 16550 didn't exist in the early 1980s deserving of a "Troll" mod?

First one I've ever got in all the years I've been here, so I'm utterly confused.

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

[Anonymous Coward]

How on earth is pointing out that the 16550 didn't exist in the early 1980s deserving of a "Troll" mod?

First one I've ever got in all the years I've been here, so I'm utterly confused.

Ah, don't worry about it - it's most likely some jealous high-UID kid with mod points waving his iPenis around - there's a lot of them on Slashdot these days, you know. They think that since they've never known a world without the Internet, anything that came before is irrelevant, and anyone that has first-hand knowledge that has the temerity to post about it is an "old fart" that needs to be quashed.

That's why I pretty much post as AC here these days - the general lack of "nerdiness" on their part makes it almost certain that anything I'd say would get at least one downmod, should I write about anything of which they have no knowledge or that challenges their prejudices.

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

[postbigbang]

I did a lot of work on the Altos machines; the 16550 and predecessor UARTs and USARTs are easy to code for. But coding for them isn't necessary: the guts to use them are in Xenix. If there's a standard tty jack left over from the con: then just blow it all out the tty port or map it as stdout.

The commands in Xenix are simple. Finding another machine with a nice capture program ought to be easy, if one can find a machine with a serial port. I had to look for a few minutes to actually find one.

Then there's the matter of making a cable for X-on/X-off... and the plucky archivist can proceed.

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

[mikael]

Best way is to get the data off that drive as quickly as possible. Even with old floppy disk and CD-ROMS, you may only get one chance to read the data, so you have to do it right the first time. Make sure you have a UPS when you are doing the work. A single scratch could lose you the data. Use the serial port. You just need to hex dump every file out. Don't try and tar things, because you would be writing to the drive, and things could be fried if there is a power failure or spike. One scrambled bit in a header could scramble everything, and you would have to start all over again.

I recovered files off an old Atari 800 in a similar way - set up the 850 serial port module to communicate to a laptop via a RS232 patch cable. Wrote a hex-dumper on the Atari side to write out the data, and used kermit on the other side to log all the output. All the disks copied within a day.

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

[DerPflanz]

so for G*ds sake

Is God profanity nowadays, that we have to mask it from the filters?

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

[Pentium100]

I have a 43MB IDE drive. Sadly, it no longer works. WD95044-X, made in 1990. When connected to power supply it just spins up and does nothing (no head movement) and is not detected in BIOS (maybe I need a very old PC to detect this drive?), what is interesting is that this drive does not have a master/slave jumper setting, the three settings are native/translate mode, IRQ 2/IRQ 5, and DMA Demand on/off.

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

[j741]

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.

[BitterOak]

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

[dotgain]

Then there's the matter of making a cable for X-on/X-off... and the plucky archivist can proceed.

XON/XOFF are sent inband, you're thinking of RTS/CTS which have their own separate conductors in the cable.

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

[dotgain]

I'd use cpio since many versions of tar had a rather dismal maximum pathname length, and might choke when tarring the entire filesystem. Found this out the hard way, not that I hadn't been warned before.

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

[Anonymous Coward]

"586" is the model number, not the processor. The 586 had an 8086 which ran in real-mode only, and could access at most 1 MB of RAM. It had axillary Z80 processor(s) to handle serial I/O with terminals.

The Altos 586 was the first *nix computer I used. I typically accessed it via modem at 300 baud (the fastest speed generally available at the time).

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

[dotgain]

No, some old serial controllers really were quite bad, and only had a single byte buffer. This means they generate an interrupt for every single byte received, this byte needs to be fetched immediately so the next byte to arrive won't overflow the buffer (fortunately this condition is detected too). Same deal for sending, throw a byte in the buffer, wait for an interrupt asking "Next one!", repeat.

Continuous transfer tended to be quite CPU intensive.

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

[dotgain]

I should add that on asynchronous serial links buffer underrun when sending is not the disaster that buffer overrun when receiving is.

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

[djlowe]

Then there's the matter of making a cable for X-on/X-off... and the plucky archivist can proceed

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.

[yuhong]

More precisely, I remember reading that the 16550 was introduced with IBM PS/2s in 1987. At first the FIFO was buggy, but NS soon released a 'A' version which was good. The 16450 was used in the IBM PC/AT, and the 8250 was used in the original PC.

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

[igb]

As a minor point, SVR2 and SVR3 machines can't have symlinks, as the filesystem didn't include the functionality. What's referred to as `ufs' on, say, a Sun today is the Berkeley ffs or fffs; ufs in the context of Xenix is what's now sometimes called s5fs, which is a thinly veiled version of the Sixth and Seventh edition filesystem. I think there were 512 byte and 1 kilobyte versions. The correct way to shift the data off will be with uucp. SVR2 and SVR3 both shipped with HoneyDanBer uucp, and it'll interwork with modern equivalents; g protocol is the best bet. cpio and uucp should be enough to move the data.

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

[Ernesto Alvarez]

But the idea of using zmodem is not a bad one.
He should check if sz and rz are available in the xenix machine and use it for the BBS files, chances are good, considering a BBS was running on it.

The rest will probably have to go using dd, through the same serial port, though.

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

[yuhong]

Probably a 8-bit IDE drive, you'd need a 8-bit IDE controller to get this working inside a more modern PC.

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

[Pentium100]

Thanks for the info, I always thought that newer IDE controllers are compatible with all older IDE drives.

Does the controller need to be an 8bit ISA card or can it be a 16bit card, for example with integrated floppy controller and LPT/COM ports?

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

[bigtomrodney]

I wish I had mod points today. This is the type of post I love to see.

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

[postbigbang]

God bless the breakout box and little jumper cables. Amen.

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

[independent123]

Split, compress, and uuencode it before sending. Reverse process on other side.

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

[Anonymous Coward]

Why does the summary/author really act like 10MB should surprise most of us. Most of us aren't in our 20s last time I saw the marketing demographic for slashdot. And claiming a late 80s OS would be home to one of the first multi user BBS? Don't even make me laugh!

(Get off my lawn, etc)

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

[yuhong]

Thanks for the info, I always thought that newer IDE controllers are compatible with all older IDE drives.

They are with all *16-bit* IDE, or ATA, hard drives. But the drive in question is a 8-bit "XTA" hard drive, using a XT version of IDE. Some drives can be jumpered between the two, though not this one.

Does the controller need to be an 8bit ISA card or can it be a 16bit card, for example with integrated floppy controller and LPT/COM ports?

Most XTA or XT IDE cards were 8-bit ISA cards, I think. I found this using Google if you want to know what the jumpers are: http://stason.org/TULARC/pc/hard-drives-hdd/western-digital/WD-95044-X-43MB-5-25-HH-IDE-XT.html Note after you get it set up that XT hard drive controllers are different from AT hard drive controllers, and the BIOS and OS will have to be set up appropriately for that.

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

[Anonymous Coward]

Yep, and since your computer is a 586, there's a good chance the serial port will do 192kbps which even faster still.

Well for starters, the max speed of the serial port is determined by the UART chips not the CPU.

Secondly, it's an Altos model 586 computer (which was "extremely high tech" with an 80186 CPU and 512K RAM on the main board and a Z80 supporting the six built-in serial I/O ports), not a 586 CPU.

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

[dullnev]

Yep, and since your computer is a 586.....

The model is 586, but that's not the cpu in the beast. I know it's asking a lot but how about RTFA? Or even taking note of the date - late 80s. And when was the Pentium cpu (aka 586) first manufactured? 1993. Turn in your geek card fool!

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

[Anonymous Coward]

2 things: a) them old serial ports were unreliable above 9600 and even then I would make sure that nothing is keeping the processor busy. b) I probably still have a version of the installation disks on 5" and/or 3.5" format. arthur@horizoninfosys.com.au (assuming they still read).

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

[The_mad_linguist]

It belongs in a museum.

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

[burisch_research]

I had a 20MB IDE drive, dating from 1989.

The drive was in a machine most people will never have heard of, a Commodore 286 machine (PC-III). It was pretty good actually, for its time, with 256-colour VGA (and Commodore branded 14" VGA monitor), 20MB drive, 1MB RAM, and a 3.5" FDD.

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

[burisch_research]

Do *NOT* compress or otherwise manipulate the data before sending. This is mesozoic-era hardware - avoid writing to the disk if at all possible. You don't do archaeology with bulldozer.

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

[that this is not und]

The Altos 586 was called that because it has five user ports and the processor is an 8086.

Yes. Microsoft produced a version of Unix that supports 5 users in 512K of memory. That's how much my Altos 586 has.

I am elated to see the Altos 586 featured in an article on Slashdot.

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

[that this is not und]

The Altos 586 has five serial ports. So in addition to the Console it supports 5 users. There is also a sixth serial port for a printer, if I am not mistaken (my Altos 586 is within view, but the side of the case with the I/O ports on it is currently obscured by other stuff)

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

[that this is not und]

The hard drive is ST506. I am not sure if it's MFM encoding, but probably. I replaced the stock 10MB drive on an Altos 586 that I had about ten years ago with an 80MB drive. My present Altos 586 has the stock 10MB drive.

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

[tgeek]

Actually, Altos did implement symbolic links for use with their Worknet product (early implementation of CSMA networking on twisted pair). It was pretty handy too - you could even create symlinks across machines and to devices. In some ways it was similar to the old AT&T RFS except I don't recall RFS allowing device links (I could be wrong). So for example on machine1 you could "ln -s @machine2/dev/lp /dev/lp" to share a printer from machine2. But aside from networking, it was never used very much in their products. In fact, I don't even recall one bundled application that used it - think it was meant primarily for use by VARs and integrators (which was their target market anyway). And it was the Booster Pak option that permitted the larger block sizes (2k, IIRC)

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

[pdwalker]

egad! I understood every word of that!

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

[HBI]

XT HD controllers had their own BIOS ROM and would have to be jumpered (if possible) to not intersect their ROM memory area with anything else you might have in the system. Many of them inhabited C800:0000 and could not be adjusted.

IRQ issues would of course apply, as well.

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

[HBI]

I'm not entirely shocked that someone created a less than 40MB IDE drive, but i'm glad to know that. I really had never seen one before. The first IDE drive I had was in an ALR Research box that had swappable CPU cards - started as a 286-12 on the board, and you could slide in 386SX-20 and 486-25 boards into the CPU slot. Nifty box, really. From about 1988 or early 89. 40MB WD IDE. It was 3.5" half-height and some info on the drive is available here: http://stason.org/TULARC/pc/hard-drives-hdd/western-digital/WD-93048-X-40MB-3-5-HH-IDE-XT.html

Sure enough, it was produced in 20MB and 30MB versions, though I never saw one of them. At the time, ST-251 (40MB) MFM drives were cheap and common so I can't imagine much trade in 20MB IDE drives.

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

[Anonymous Coward]

Not sure what it being a '586' has to do with the serial port speed. That number doesn't refer to the processor. From the description on the old-computers.com web site:

"A fully-loaded 586 contained four printed-circuit boards. The main board held the 80186 and 512 KB of RAM; a Z80 I/O processor supporting six serial I/O ports ..."

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

[Milo_Mindbender]

The system actually dates from 1985 or so. I'm aware it isn't "the first" however it is one of the first BBS systems that:

* Was privately owned (not Compuserve or a university computer)
* Had 5 simultaneous dial-up connections.
* Was designed for and used mainly by non-computer people.

There were plenty of single-line BBSs at the time but very few multi-line ones that were available to the general public.

This system used the general BBS structure made popular by the CDC Plato system back in the early 1970's.

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

[Anonymous Coward]

I used Xenix (and SCO UNIX) in 92 and we upgraded the hardware in around 94 so that could have a 16550 on it.

First question is what hardware is it?

Use the serial port ...

[Anonymous Coward]

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

Re:Use the serial port ...

[Anonymous Coward]

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

[Anonymous Coward]

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

[Anonymous Coward]

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

[TheRaven64]

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

[Anonymous Coward]

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.

Re:Use the serial port ...

[John Hasler]

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

[farrellj]

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

Re:Use the serial port ...

[Z00L00K]

I think that even if you were able to connect the hard disk to a PC you would still need to have a system on that PC that could read the hard disk - and a controller that could understand the formatting of the tracks.

The ST-506 interface was used both for MFM and RLL formatting, and on top of this - this were under an era when every company also was working with varying sector sizes. Not only the 512 byte size we see today, but also 128 byte sectors. Of course - 1024 byte sectors could also be what was used.

Just because the hardware connects doesn't mean that the software is even remotely able to make sense of what it sees.

Re:Use the serial port ...

[farrellj]

Agreed, it could be MFM ,or RLL, but come on, a 10 Meg drive being a RLL drive? If it was a 25 Meg, or some other odd number like that, sure. But it's almost certainly an MFM drive. Yes, you can fiddle with the cluster size, and 10 meg drives had a problem with their default cluster size being huge. I remember using a debug call to go in and low-level reformat to cut down the size of the clusters since Fido BBSs originally stored ever message as it's own file...so the overhead (ie, unused part of a cluster) was obscene! Later on, Spin-Rite came along, and would adjust the cluster size, and interleave of the drive to best optimize for speed. But this is before Spin-Rite. Actually, thinking about it, the WD8002 was the MFM controller, and the WD8006 was the RLL version of the controller...both used 16 Bit slots.

ttyl
          Farrell

Re:Use the serial port ...

[Anonymous Coward]

Threre are 2 significantly different flavors of st506 drives: MFM and RLL. If you don't have a matching controller, you won't be able to read anything. In addition to that, there are ESDI drives, which use similar cables but a fully digital interface, instead of digital contol lines (small separate cables) and analog data (shared calbe).

Re:Use the serial port ...

[Z00L00K]

OK, I can agree that it's likely to be a MFM drive.

But the Altos 586 wasn't a PC, even though it did use the 8086 processor.

I found this one: http://www.classiccmp.org/dunfield/altos/index.htm, which I think clearly shows that it's not a PC so don't expect anything PC-related to work with it.

And yes - I have used the BIOS low level formatting routines once upon a time too. G=C800:5 was used now and then for a while.

Re:Use the serial port ...

[Anonymous Coward]

ST-506 - also known as MFM.
The hardware would also have been likely compatible with an RLL controller but odds are at 10MB capacity it was an MFM drive.

Re:Use the serial port ...

[Tubal-Cain]

...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 email it to you in an easy to read format.

Fixed that for you.

Re:Use the serial port ...

[that this is not und]

G=C800:5 is a jump command to the low level formatting code in the BIOS extension on a Western-Digital type 8-bit Hard Disk controller. It was also the method for a lot of the clone cards.

It didn't always work, though. The original IBM-PC and PC-XT machines had the Xebec controller. You started the low level format with that controller by poking values into various I/O ports on the controller card, again using Debug. I don't remember the sequence offhand but it's all documented in IBM's Technical Reference Manual section for the Fixed Disk controller so can be easily looked up. The Xebec controller low level routine is sort of spooky, as you don't get any user feedback. After you've send off the bytes to start the low level format, the light on the hard drive comes on and the long, slow formatting process begins. You know it's completed when the Debug prompt comes back. The Western Digital low level format provides a little more interactive feedback while it runs.

cu

[jzu]

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

[John Hasler]

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

[Jah-Wren Ryel]

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

[jewelie]

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

[Antique Geekmeister]

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.

Re:cu

[spong]

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

Re:cu

[tverbeek]

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

[Ambient Sheep]

Yup, and Zmodem is generally preferable to Kermit as it's so much faster.

As a former Fidonet point this really takes me back! Happy days.

Re:cu

[John Hasler]

I have an Onyx with System III. That's old.

Re:cu

[brusk]

Fairly recent Xenix binaries of Kermit exist: http://www.columbia.edu/kermit/ck80binaries.html#sco

Re:cu

[bhtooefr]

Except it's early 80's (1983,) and it appears to be Version 7.

Which is Ancient Unix, although barely.

Re:cu

[Anonymous Coward]

Kermit wasn't commercial software, it was (and is) freeware. (http://www.columbia.edu/kermit/)

Not exactly. The spec itself is open; the sixth edition protocol manual dated June 1986 is floating around in PDF and PS. gkermit is free (GPL); ckermit is zero-cost but not freeware. Kermit95 is a commercial Windows client that costs about $50 per license (which is in truth a very good bargain considering its features).

ckermit is very portable and would probably compile pretty easily. At worst the OP might need to find an earlier version. As for transferring a kermit binary: uuencode/uudecode could do it easily enough.

Disclaimer: I'm not too familiar with Xenix, but I know kermit well enough to implement it.

Re:cu

[fizzup]

It's Xenix. Ancient Xenix.

It was a bulletin board system. It probably has kermit (1981), xmodem (1977), maybe ymodem (1985), and possibly zmodem (1986) already installed on it. Others have mentioned uucp (1979?), which was probably included in the default installation of Xenix.

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.

I have personally written a basic stop-and-wait kermit in Bourne shell for a lark. It's not as hard as you think.

Re:cu

[Hognoxious]

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.

According to fdisk (command l) it has its own - user and root with IDs of 3 and 2 respectively.

Re:cu

[MightyMartian]

That would have been my first thought. Kermit's probably the best of the bunch. UUCP would be a bit of a pain to set up for what amounts to a one-time file copy session.

Re:cu

[BrokenHalo]

Finding a way to compile and transfer Kermit to such an ancient system would take some serious archeological research...

No it wouldn't. Well, no more than 5 minutes' worth of research.

Kermit was a well established data transfer protocol during the heyday (such as it was) of Xenix. I remember there were definitely binaries of kermit that ran quite happily under Xenix, but since Kermit was (and presumably still is) standard ANSI C, there should be no difficulty in compiling the program to run on Xenix.

Kermit was ubiquitous across many platforms because of its ability to transfer individual files with a minimum of hassle. Transferring whole directories was less reliable, and if there was an opion, UUCP was the preferred channel.

Re:cu

[pcjunky]

I got Kermit running on an old 8-bit Intel MDS system with 8 inch floppies from the late 70's.

Re:cu

[Antique Geekmeister]

Did you compile it yourself, on a no longer available operating system and a non-gcc based compiler? Can you do it _again_, now 30 or more years later?

Good luck with that. There some ancient binaries and source code at ftp://kermit.columbia.edu/kermit/bin/ and ftp://kermit.columbia.edu/kermit/old/. But it wouldn't be clear to me that our original poster has the tools to install it if it's not already present.

Research Resources

[Phat_Tony]

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 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 it. No need to bother a million Slashdot readers.

Re:Research Resources

[Anthonares]

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.

Re:Research Resources

[Waffle Iron]

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:Research Resources

[Z00L00K]

Considering the amount of air it takes I would rule out the car scoop from the beginning.

UUCP

[John Hasler]

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

[SimonInOz]

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

Re:UUCP

[Hurricane78]

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.

Re:UUCP

[tverbeek]

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

[John Hasler]

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

Probably more dangerous to move the drive

[assemblerex]

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

Image it first

[Anonymous Coward]

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

[Anonymous Coward]

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.

No Removable Media?

[lobiusmoop]

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

Re:No Removable Media?

[NNKK]

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?

[TheSHAD0W]

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?

[Der PC]

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?

[TheRaven64]

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?

[tverbeek]

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?

[Mister Transistor]

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.

Re:No Removable Media?

[Anonymous Coward]

No, it's an 80186, which is like an 80286. Not many IBM-compatible PCs were made with 186 processors, but a few were. The type of floppies it will take will depend on the motherboard chipset.

Re:No Removable Media?

[TheRaven64]

No, it's an 80186, which is like an 80286

Completely inaccurate. The 80186 is a slightly-tweaked 8086 with a few other things on die that were on separate chips with the 8086, to reduce costs. It was primarily sold to for telecoms use, but ended up in a few PCs, like the RM Nimbus and the machine in TFA. It does not contain an MMU or support the protected mode introduced with the 80286.

Re:No Removable Media?

[yuhong]

Yep,IBM itself introduced them in their PC/AT.

Re:No Removable Media?

[PAjamian]

A 10MB drive is almost certainly going to be MFM, early RLL drives were 30 or 60 MB at least (although it was possible at the time to reformat an MFM drive to RLL and get some additional capacity but you wouldn't have ended up with 10MB). At any rate you're biggest problem with moving the drive to the new system will be finding an MFM controller that fits into the motherboard on a modern system. MFM controllers used either an 8 or 16 bit ISA bus which modern motherboards no longer have expansion slots for (modern boards have PCI slots). If you're very lucky you may have a motherboard that's old enough to still have one or two ISA slots on it. Also, if the current system has an 8 bit controller then it may have a block of proprietary drive info written down on the first track of the drive and will need to use the same controller to get the data off. These controllers did this because they pre-dated battery backed CMOS to store the drive parameters on. If it's a 16 bit controller (has an extended extra bit of slot on the end) then it will likely have stored the drive parameters in the CMOS and you'll be alright with any 16 bit controller (again, as long as you can find a slot to plug it into).

Good luck

Re:No Removable Media?

[that this is not und]

The Altos 586 has a 5-1/4" floppy drive. But it's a quad density drive, that means it's 80 tracks and 720KB. You can't find 80 track 5-1/4" media anymore, but you can use higher quality double-density (360K) media. Don't try using High Density (1.2M) media.

Re:No Removable Media?

[that this is not und]

The Altos 586 has an 80-track 'quad density' disk drive. It is 720K.

There's one about four feet from me here.

Re:No Removable Media?

[networkBoy]

I keep a SMP tyan board in a 4U case around for this reason. I can mount and read:
MFM, RLL, ESDI, SCSI, and IDE drives on that machine. In addition I have two boot disks (one IDE the other SCSI) so no matter what technology drive I need to read I can boot off of my known boot disk. Also, I have a 720/1.44 floppy and can swap out either a 360K or 1.2M 5.25" floppy as needed and have an external 180K 5.25 and 1.2M 8" drive.

More than once I've used that machine to retrieve data from old disks. The fun part is that even if I don't know the format I can usually make a dd image of the drive.

Downside is that I have to go and swap controllers out as there are not enough ISA slots for the MFM, RLL, ESDI, and external floppy all at the same time (they don't all play nice together either).

I also keep my old CSC HDD Bible around. Only thing missing is the ability to read 5.25" hard sector disks.

-nB

audio

[nadaou]

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

[Anonymous Coward]

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?

Re:audio

[Hurricane78]

I think the display offers more bandwidth: http://www.erikyyy.de/tempest/

Re:audio

[Anonymous Coward]

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

Seems like a lot of work. Why don't you just place the monitor on the flatbed scanner?</PHB>

Re:audio

[the_humeister]

Why not just hook it up to some bongo drums instead? Too bad it's only 2bps though...

Re:audio

[siglercm]

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.

I don't care who y'are, that's funny right there! Why, oh why!, do mod points have to max out at five. I hereby nominate parent for funniest post of the month.

Re:audio

[multipartmixed]

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

Wouldn't it be funny if he posted it to youtube, and it looked exactly like a Russian Cat?

yeah

[Anonymous Coward]

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!

[NNKK]

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!

[Der PC]

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

Re:NO DISASSEMBLE ALTOS!

[dbIII]

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

[LizardKing]

Err, I have music equipment that's as sophisticated and old (if not older) than the Altos which still works fine. This is music gear that's unlikely to have ever been serviced, and I can assure you that it's had a far rougher time of it than most computers.

Re:NO DISASSEMBLE ALTOS!

[BitZtream]

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 find from a geek perspective, I wouldn't take any risks at all, and like everyone else suggests, if the system is bootable, serial it off FIRST, as an image if at all possible. Verify the image is valid and consistent on a Linux machine before you do anything else to the original hardware.

What actually hasn't been hit on yet and to me is a big one ... if it boots, don't turn the damn thing off!

Get some of the hard disk lube moving around, or start working some dry capacitors and you're likely not to have a high number of boots left, especially if this thing has been sitting for an extended period of time.

Re:NO DISASSEMBLE ALTOS!

[Dogtanian]

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

One possible explanation?

Also, the guy was basically saying not to take any unnecessary risks. Serial port may be hideously slow by modern standards, but it's still not going to take *that* much time to transfer 10MB over one.

Re:NO DISASSEMBLE ALTOS!

[Der PC]

True, but I considered two points before answering:

a) the sheer number of machines that I have serviced (professionally) and owned in the past 30 years (I won't count my childhood ;-))

b) The fact that shit is exponentially more likely to hit the fan with your brand new computer than one of these old geezers, that is unless you can spot corrosion on the casing.

On the other hand, I did say the same thing in another reply in this thread - that is, use the serial port. Not because it's safer for the hardware in any way (it isn't - you may wire the serial cable incorrectly since it's almost certain that its wiring is non-standard as per RS-232C, there may be a substandard capacitor in the machine that blows when powered up... plenty of risk factors available) but mostly because he's S.O.L. when it comes to reading MFM/RLL hard drives on his modern whatchamacallit.

The latest MFM/RLL interface cards were ISA bus (not used anymore), EISA bus (not used either) and there were a very few PS/2 bus as well. I don't recall a single PCI MFM/RLL card.

(and yes.. the hard drive is most certainly not an IDE drive since the IDE standard was only concieved 3 years after the Altos 586 was marketed)

Re:NO DISASSEMBLE ALTOS!

[Xardion]

The problem isn't the computer itself really. If it wasn't in a very poor environment, it probably just has some dust contamination that a little compressed air or a PC vac can solve. The hard drive, which your equipment likely doesn't have, is going to be the primary point of failure. A hard drive is NOT solid state. It is a piece of mechanical equipment. The thing is probably well past the MTBF, and even though many of these old drives lasted long beyond that, its life expectancy is short.

Re:NO DISASSEMBLE ALTOS!

[LizardKing]

My Emulator II from 1985 still has the original hard drive, and it's working fine. I've never taken the beast to a rehearsal, let alone gigged with it, but the previous owner did. I also use a mid 1980s Commodore 1541 floppy drive with my E-mu SP-12, and until a couple of years back I owned a 1987 vintage Vaxstation 2000 that still booted up from the original hard drive (it was probably felt slower to use than the Altos).

Re:NO DISASSEMBLE ALTOS!

[Dogtanian]

The latest MFM/RLL interface cards were ISA bus (not used anymore), EISA bus (not used either) and there were a very few PS/2 bus as well. I don't recall a single PCI MFM/RLL card.

If he's desparate- and he was bothered enough to make this an "Ask Slashdot"- it's probably not that hard to get an old computer with ISA. My first PC from the late-90s had ISA (and used it too- it came with an ISA soundcard *and* modem) along with the PCI slots.

As for finding the interface cards themselves- I'll concede that might be harder.

Serial port.

[mrbill1234]

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.

[TheRaven64]

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.

[LVSlushdat]

Not to mention, the fact that an RLL/MFM controller will most defiantly be ISA, and.. good luck in finding a system with an ISA bus anymore...

Re:Serial port.

[bhtooefr]

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.

Re:Serial port.

[dotgain]

Nitpicky, but you mean ISA slots. The ISA bus is alive and kicking, all PC-compatible machines have them.

Re:Serial port.

[networkBoy]

more info or link please?
Been looking on Google and not had much luck. The only site I saw come up was blocked by my office proxy.
This would be *very* useful...
-nB

Make a disk image

[jdimpson]

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) or "dd_rescue" ( http://www.forensicswiki.org/wiki/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 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

[IGnatius T Foobar]

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:Altos 586

[sjames]

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

Re:Altos 586

[Anonymous Coward]

At one time I had a SCSI to st506 (dual) that was powered by a drive power connector and was not slot based. I appear to longer have the beast.

Re:Altos 586

[RocketRabbit]

One of these might do the trick:

http://www.arstech.com/item-USB-2-0-to-ISA-card-ROHS-usb2isar.html

Reading the disk will be tricky.

[shippo]

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.

[charlie]

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

[drinkypoo]

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.

[systemeng]

Take a look at the unix heritage society. See http://minnie.tuhs.org/TUHS/ 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.

Re:Reading the disk will be tricky.

[Smallpond]

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.

[rickb928]

Booting this on other hardware is unnecessary and probably won't work. Xenix and SCO Unix were terribly picky about hardware, and usually you had to boot to single-user mode and be ready with driver diskettes. Moving to new hardware was a recipe for lost weekends and lost data.

The HP 97500-60011 or -85600 were 10MB drives. But this could be am MFM drive. Check the connectors. A single IDE connector is obviuously IDE, but if there are two connectors besides power, you are in a different world.

If it's running, UUCP everything off of it. ASAP.

Re:Reading the disk will be tricky.

[ISoldat53]

Ah, I remember the Tandy Model 16 with two Floppy disks running Xenix. I used to upgrade them to the 10Mb hard drive. It took 2hrs to format. At $90 and hour plus travel time. Those were the days.

Re:Reading the disk will be tricky.

[BitZtream]

There were, you'll likely find several 'I owned one' posts following up. The certainly werent' common, but they did exist.

Re:Reading the disk will be tricky.

[drinkypoo]

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.

Depends on how proprietary this machine is. IBM PS/2 systems used ESDI disks with wacky cardedge connectors designed to make the whole thing easy to snap together. This machine is old enough to have an entirely proprietary disk interface, which is just another reason why using the serial port to transfer the data absolutely makes the most sense. Depending on how advanced the serial ports are, it might be possible to do the transfers at (or near) 19.2 kbps. And if the UUCP packages were installed, as others have pointed out, then you can just copy the files. Otherwise, you won't even have uuencode, so if you don't have a compiler you're going to want some fancy shell scripts to facilitate your transfers. You could use od to spew hex values for your files, which would have substantial overhead but be easy to reassemble into your data. I'm sure you could do something far cleverer with od, though.

Re:Reading the disk will be tricky.

[yuhong]

Yea, I think they are suggesting putting this as a second (non-boot) HD in an already running SCO UNIX or derivatives system with ISA slots.

Re:Reading the disk will be tricky.

[Anonymous Coward]

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.

I owned at 10mb IDE hdd, we used to back it up on 1.44mb 3.5" floppies..

It finally got close to being full (took about 4 years with a 2400baud modem), then we upgrade to a wd 100mb drive.

this was in an Epson 8086xt clone.

Don't forget

[CODiNE]

Watch out for ANSI Bombs! :)

Pre-March 1989 publications may be easier

[davidwr]

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:Pre-March 1989 publications may be easier

[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 under US copyrght. SEE: www.templetons.com/brad/copymyths.html for more details.

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

Chancey at best, but generally true. It's considered "best fit" a la usenet. The most anyone upset about having their deathless prose made public in another venue is probably being able to have it removed from view- which would be the polite thing to do sans lawyer, anyway.

Re:Pre-March 1989 publications may be easier

[fruitbane]

Personal correspondences and public communications are not works considered to have commercial value, so while they are technically copyrighted (there is some minor debate concerning such things), I would imagine a lawsuit would only result in the messages having to be taken down and actual damages (punitive damages require a copyright notice in the US). Further, it's possible the BBS had used agreements and notices that messages posted there are publicly available and either automatically owned by or licensed to the operators of the BBS.

Re:Pre-March 1989 publications may be easier

[davidwr]

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.

The Berne Convention went into effect in the United States in March 1989. I just assumed the BBS in question was US-based.

Not meant to be funny...

[MrBandersnatch]

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

[baka_toroi]

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

Re:Not meant to be funny...

[Anonymous Coward]

What a load of bullshit...

Re:Not meant to be funny...

[Anonymous Coward]

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

[JamesP]

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

Re:Not meant to be funny...

[maxume]

Dewarping (or whatever the correct term would be) is pretty well understood, it is used in all the camera based book scanning systems.

Re:Not meant to be funny...

[Anonymous Coward]

"...then run the photos through OCR... Depending on how much data you're talking about you might be able to do the above faster than transferring the data via serial."

Even if it's "only" 10MB, that would still be thousands of pages. Not to mention the fact that OCR of binary data doesn't work (multiple values of unrepresentable characters showing up as blanks on the screen, tab characters vs. space characters, etc.), and even if it did it would have to be flawless from the first bit to the last.

While it might sound... er, novel in theory, it isn't practical or effective.

Re:Not meant to be funny...

[MrBandersnatch]

Sounds like a challenge to me - I'll stick it on my todo list when I've got my term papers out of the way.

Re:Not meant to be funny...

[dotgain]

Exactly. Even with the flattest of flat panels, lenses themselves have their own distortions that need to be corrected anyway. It's a well-understood and already-solved problem. OCR has to deal with a hell of a lot more problems than barrel distortion.

Re:Not meant to be funny...

[toygeek]

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.

Google?

[Gizmoguy]

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

You're welcome. =P

Re:Google?

[Anonymous Coward]

Mostly it'd be because that page only tells you "here's what you *would have needed to have done 20 years ago* in order to be able to do what you want now", and doesn't really tell you anything else except what I posted this afternoon: it's inside a divvy slice, and you need to peel it out before you try to work on it... and Linux almost certainly doesn't know how.

DD

[AC-x]

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

[Anonymous Coward]

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

[Anonymous Coward]

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?

[ibsteve2u]

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)

Re:Nobody asked the name of the BBS?

[dotgain]

I'll bite.

When you made these hypothetical beer-posts, did you have any expectation or guarantee that they would vanish in the first place? What if the BBS you posted them on never went offline, and was still available (presumably over the Internet) today? Would this situation be any different to you?

Re:Nobody asked the name of the BBS?

[ibsteve2u]

That comment was more to make precisely that point than anything else.

Besides, I always invented a name. Wouldn't it be funny if my random choice of names turned out to have been your name?

Not IDE

[BBCWatcher]

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.

Re:Not IDE

[drinkypoo]

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.

Re:Not IDE

[bhtooefr]

From what I've heard, doing RLL on MFM drives is very much possible. The problem is doing it reliably, because a lot of MFM drives from after RLL drives started coming out were drives that weren't good enough to do RLL, but were good enough to do MFM. Yup, they used binning back then.

Doing MFM on RLL drives is pointless, but should be perfectly reliable, as MFM is lower capacity than RLL. Only reason to do it is if you have a legacy system that can't be upgraded to RLL, and you can't find an MFM drive.

UUCP info you need

[Kjellander]

Setting up UUCP on Xenix
Setting up UUCP on Linux

If you really want to try to read the disk it is probably UFS which you can read from Linux.

Hope this helps.

Re:UUCP info you need

[tumutbound]

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

Re:UUCP info you need

[Anonymous Coward]

No - Xenix of that era used a filesystem that was pretty much (and quite possibly exactly) identical to V7 - 16 byte directory entries with a 14 character maximum limit on the name and a 16 bit inode number, 24 bit block numbers for 10 direct and the three indirect (single, double, triple) blocks stored in the inode, file mode bits with the same values av V7 - probably 1024 byte block size.

Re:UUCP info you need

[Kjellander]

Ok, that is the one I actually meant. The ancient Unix File System called FS, not Unix File System which is FFS. So many confusing implementations.

man mount shows you -txenix so try that if you dd the whole drive over a serial line.

Re:UUCP info you need

[einhverfr]

Some versions of Xenix used COFF for a filesystem which Linux can also read.

Honestly I would pull the HDD if it is an IDE one, make an image of it (dd if= /dev/[device] of=~/xenixhd.img bs=512) and then put it back. This allows you to play with the disk image, mount it with a loopback adaptor, etc. and read the files from it without disturbing your original for too long.

Re:UUCP info you need

[pe1chl]

COFF is not a filesystem, it is an object file format.

Re:UUCP info you need

[BitZtream]

UFS != FFS, sorry.

They are different, even if one is compatible with the other.

I suppose you say FAT and NTFS are the same too?

Re:UUCP info you need

[einhverfr]

Yep you're right Sorry for the brain fart...

Re:UUCP info you need

[jonadab]

> If you really want to try to read the disk it is probably UFS

I bet it's not.

Xenix is *old*. Older than System V.

Not only does it probably not have the Berkely FS, it probably doesn't have a straight-up unaltered version of the Berkely filesystem's predecessor either. The people who ported Xenix probably made modifications to the AT&T filesystem code to suit the hardware they were porting to. That was a common practice at the time. So it probably has something that can best be described as "Xenix filesystem".

The good news is, Xenix was actually pretty popular for a few years, so there's actually a chance you might be able to find something that can read the thing.

But if it has UUCP, that's going to be easier.

Re:UUCP info you need

[Kjellander]

Did you read the link above? The wiki page specifically says that UFS also is called FFS, but anyway, there are tons of UFS:es and the one he should use is -txenix and nothing else.

Re:UUCP info you need

[Jah-Wren Ryel]

There is no chance of it being IDE. He'll be lucky if it is a plain old MFM controller in an ISA slot - at least then he can probably move the controller to an older linux machine which might have a driver for that controller. He'll be unlucky if the controller is on the original motherboard instead.

Re:UUCP info you need

[Anonymous Coward]

I guess you fail at reading comprehension.

Re:UUCP info you need

[that this is not und]

It's an ST-506 interface. The controller is built into the main board. It doesn't feature ISA slots.

The Altos 586 is from before the ISA slot was invented by IBM.

This isn't a Pee Cee.

Is this worth it?

[Profane MuthaFucka]

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.

Re:Is this worth it?

[machine321]

You're assuming the porn is graphical, not written.

My two cents

[Ken Hall]

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

[KenSeymour]

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.

Re:My two cents

[vtcodger]

***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. But anyway, it might turn out that the serial port isn't that much slower than a floppy.

And since I haven't seen anyone else mention it, if the serial port is configured to use hardware flow control RTS, CTS, DTR etc, getting it to talk to another computer can be a non-trivial and decidedly annoying task. If the two devices aren't configured compatibly, not only may they refuse to talk, they may talk, but cheerfully discard a lot of the data without notification.

It's a BBS? Is it possible to call into it and extract the call logs through the BBS software? My guess is that the system used an external modem and that calling in would be an enormous amount of work unless the modem it used is still hooked to it and works. But still, it is another possibility.

File systems were simpler back then

[bradm]

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

[demonlapin]

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

[bartwol]

For the possibility that you are being sincere...it's a frequently used Unix command 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.

Re:File systems were simpler back then

[Anonymous Coward]

Thanks, I was not trolling. I thought it would be some ancient arcane trick or something. I've never used Unix based system past a Ubuntu live disc.

Re:File systems were simpler back then

[moosesocks]

This is the "de facto" use of cat.

However, the intended use of cat is to concatenate (join) multiple files or strings (hence the name).

Wikipedia provides a fairly self-explanatory example of this functionality:

cat Morning.txt Evening.txt > Day.txt

which joins Morning.txt and Evening.txt to produce Day.txt with the contents of both.

The carat (>) indicates that the output is being redirected to a file -- Day.txt in this case. It could alternatively be piped into a printer, serial port, etc. If you don't redirect the output, cat simply displays the contents of the resulting file on the screen (hence the de-facto use of conveniently displaying files on screen with a 3-letter command).

Re:File systems were simpler back then

[dotgain]

Thanks for that. The other day I suggested to someone here he keeps a "/bin/cat swear jar" on his desk. Whenever you use /bin/cat for something other than concatenating files, but a dollar in the jar.

His crime was cat *.txt | grep "somePhrase" and wanted to know he could report which file and line number the matches were found on. First suggestion was get rid of the damn cat!

Re:File systems were simpler back then

[bartwol]

Seeing that even this explanation of yours was modded down, we can infer that at least some Slashdot moderators are curmudgeons.
Cheers.

A few points

[Anonymous Coward]

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!

Re:A few points

[Anonymous Coward]

Actually I'd have to go dig around, but I'm pretty sure early pentium 4 and even some LGA775/Early Core 2 era motherboards still have ISA as an option. While it is a niche application, there's still a metric ton of embedded controllers out there that are ISA only, and there need to be computers that can still interface to them.

But generally speaking, yes, consumer level systems had them dropped by the pentium 3 era on most 'standard' brand motherboards.

tar over serial?

[ZorinLynx]

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:tar over serial?

[BitZtream]

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

Re:tar over serial?

[Anonymous Coward]

SERIAL flow control will bite that command sequence.

Run it through uuencode first and uudecode on the other end. This adds one third of the transfer to the overhead but results in a copy guaranteed to work.

Re:tar over serial?

[multipartmixed]

I disagree;

Tar over serial is fine -- hint, man stty -- but I disagree about hitting the whole-disk image before a filesystem dump.

If you are unlucky and hit a bad sector in an used section of disk, your house of cards could come down on you as the disk starts clicking. Instead, do a filesystem back up first, in order of most-to-least-interesting directories.

Re:tar over serial?

[MrKaos]

You can use tar and serial ports.

Several people have suggested using this approach - but it will not work. The data has to be made 7 bit safe so the pipe has to include uuencode and uudecode. So if your commands are modified thus

Transmit;

tar cf - /home | uuencode > /dev/serialdevice0

Receive;

cat /dev/ttyS0 | uudecode | tar xpf -

to unpack the data it should be ok. "tar" is not 7 bit safe so it will *not* prepare the data for transport over a serial link. However if you are going to do this you will more than likely have to use the stty command as so

stty line characteristics > /dev/tty1A

to set the serial characteristics of the line for the serial link to work properly. SCO nomenclature for serial ports were /dev/tty1A for COM1 and tty2A for COM2 with a modem or the /dev/tty1a (/dev/tty2a) for a serial cable without a modem. Using the uppercase variant (from memory - so check) was hardware flow control over serial. I'd only use hardware handshaking to move this amount of data as it will have a hard time keeping up on a system this old and XON/XOFF just won't cut it. The weakest link is the old system.

However tar is not a good candidate for moving this amount of data on a system this old because as soon as the transmission drops out *for any reason* you won't know where from in the archive you were. If you want to use this method to transfer the data consider creating a file list on the XENIX box first and using

cpio

. If the transfer fails for some reason then you can delete the file list up to the point where the transfer failed and then continue, with tar you will have to start again.

Some have suggested using UUCP and really this is the best option as it will manage the transfer of the files and checksum each one to ensure the receipt but it is understandable why you wouldn't set up UUCP as it is a bit of pain, but worth it when complete.

Brings back memories of supporting SCO systems - good luck

What reads serial these days?

[managerialslime]

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:What reads serial these days?

[greed]

Serial is still well-served. I can log in to the serial console on my Linux server using minicom on Mac OS X and a Keyspan USB-Serial adapter. zmodem should be good to go. Linux to Linux is slightly easier, as all my Linux boxes have built-in RS-232 support (though some need a header-to-DE9/DB25 adaptor).

Though I've got those 8p8c modular adaptors on everything now so I don't have to find the right cables.

Depending on what's around, Kermit and patience might be the best solution. Ahh, memories of the HP-48 calculator... and mainframes... and lots of other things, now that I remember.

Memory Lane...

[Anonymous Coward]

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

[Craig Ringer]

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

[knarf]

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:dd, slip

[Pikoro]

That box has a proper tcp/ip stack included IIRC:
netcat and dd

Oh Brother....

[NoOnesMessiah]

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?

[gjyoung]

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

There are tonnes of ways to do this..!

[JasonStevens]

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

[laing]

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.

where's Milo?

[karlzt]

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

Re:Get in touch with a data restoration specialist

[K. S. Kyosuke]

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

Not all MFM controllers are compatible

[linebackn]

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:Not all MFM controllers are compatible

[macbeth66]

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.

Re:Not all MFM controllers are compatible

[JasonStevens]

I think the deal here was the interleave.... But yes it was quite the dance for disks that'd been formatted in some crazed interleave to move them around... I *THINK* the 1:1 cards that were fast enough could read any of those disks..... Although it's been so long I'm just lucky to remember that you needed two ribbon cables for MFM/RLL and that you could use lots of MFM disks on RLL controllers.... and get that 'free' 30% increase in storage space.....

Re:Not all MFM controllers are compatible

[rickb928]

That won't be as much trouble as you think. If they used a standard table, it will read fine.

Now a lot of larger MFM drives kept a CHS table on their own firmware and used that instead, but a 10 MB model probably did not. That was usually used after about 120MB, when LBA was needed but not supported. And I'm not sure how many >120MB MFM drives there were. Early IDE drives did the same thing, bypassing the BIOS tables. Often with marginal results. At one time, if you weren't careful, you could program your own I/O and let your application talk to the BIOS directly isntead of using the OS (DOS) calls. I supported one such bit of joy that, when it finally had to write to the last block, happily started over from 0. Your next data write started in writing to the partition table. When I figured it out and told the developers, they went past telling me wrong and asked that I be fired. Two days later and half of them weren't answering their phones any more. Someone learned to use Norton Disk Editor real quick. The next version of their app was much slower, but at least it didn't erase your disk.

Re:Not all MFM controllers are compatible

[toygeek]

c:\>debug
g=c:800

"Those were the daaaaaaays"

Re:Not all MFM controllers are compatible

[multipartmixed]

Sorry, you meant g=c800:5, I'm pretty sure.

Mind you, it's been... awhile.

1990 for me?

Re:Not all MFM controllers are compatible

[toygeek]

Gosh, you are right! I knew I was missing something.

g=c800:5

Its been probably 1991 or 1992 for me.

Re:Not all MFM controllers are compatible

[Anonymous Coward]

In case of MFM HDD one might also run out of luck of retrieving the data from it. It needed a periodic refreshment, as the data would physically disappear from the disk itself over a period of time...

Although in 2001 I opened an industrial PC with MFM HDD in it. It was still happily working! Slow, noisy and dusty - but it still fully functional after a decade of hard work (and not a single day of maintenance, not even the dust cleaning).

Hard Drive Most Likely MFM...

[multimediavt]

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:Hard Drive Most Likely MFM...

[multimediavt]

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!

Re:Hard Drive Most Likely MFM...

[CAIMLAS]

He could certainly use the serial port, but there are also "cheap" ways of doing it:

Granted, you'll have to find an old system with an ISA port to use the card, but it's quite doable. I did the same for a 10MB (IBM brand? I don't remember) 8" MFM years ago. In my case, it was actual data recovery: I had to locate the lost (previously deleted) files. That took some time; I wish there had been something like photorec back then.

Re:Hard Drive Most Likely MFM...

[JasonStevens]

56k serial ports in the early 1980's? Dream on, the 8250 was buggy, and had major issues.

Re:Hard Drive Most Likely MFM...

[Anne Thwacks]

I Guarantee its MFM, unless the controller was a very special RLL unit. If its the original, it definitely can't be IDE. I designed MFM and RLL controllers in the 1980's and they were almost all analogue (the digital ones were mostly cheap crap and did not work very well). They were not interchangable meaning Its very likely that the data can only be read by the controller that wrote it OTOH, it might actually be SCSI, and could be read by any modern Un*x with a SCSI controller. As someone else said "mount -t xenix" will probably work on any Un*x or Linux.

If its a 10MB drive, I would bet that there is not more than 5MB of data on the drive, and the serial chip is definitely not going to be a 16550 in a standard PC it will be terrible. I had a BBS in the '90s, and paid a lot for high performance serial cards. However, its a Xenix system, and might have Zilog's SIO chips which can do 1MB synchronous serial (SDLC or HDLC) if you program them to.

I would not remove the HD from it under any circumstances if the machine can still boot. tar /home and /etc through the serial port to something else - who cares if it takes a month! If they get through ok, then tar the lot as a separate operation. Much better you boot it and get the data, than you shut down and re-start several times. If its going to die, it will die during a boot sequence for sure.

The OS will probably have been built without drivers for hardware thats not there, so unless you have access to the OS build tools, you wont have any ability to add hardware (that was normal i those days). An OS build would probably take 3 days (if you have the tools) It is basically the link stage of compiling a Un*x.

Xenix only existed because the '86 family's memory mapping was too poor for real Un*x, and you can expect it to perform like NetBSD scaled by clockspeed over 4 Ie if it has a 10MHz clock it will be 400 times slower than NetBSD on i386 on a 1GHz processor (ie grimly slow). p

Re:Hard Drive Most Likely MFM...

[otis wildflower]

If the host has ethernet connectivity, perhaps rsh would be better than serial as it'd likely be faster than any pre-16550 UART.. Many's the time I passed dump or dd over rsh on a crossover ethernet link to useful effect..

(actually, back when I was using rsh it would have been token-ring, but the idea's the same..)

Re:Hard Drive Most Likely MFM...

[multimediavt]

Ummm, yeah. Plenty of computers in the early 1980's with 115K baud RS-232 serial ports. The port speed wasn't the problem. The problem was finding devices that weren't ridiculously expensive that ALSO operated at that speed. Now, I haven't played with any 8250s, but I did have an IBM 5150 (Yes, the 4.7 MHz, dual 5 1/4" floppy, PC) that I frequently used a null modem cable with at speeds in excess of 56K baud in 1983-1984. If I still had one or two of the damn things, and they worked, I could probably validate that statement.

Hell, even at 1/10th the 115K speed it would still copy everything overnight!

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

[demonlapin]

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.

Not a real request

[hduff]

unless you post pr0^H^Hics of the machine . . .

Not really all that *old*...

[pla]

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 back then. By the time I had a 586 (1994, they debuted in 1993), you could already get drives measured in gigabytes, and most people ran drives in the high-3-digit megabytes.

Others, however, have already given you your answer. Dump the whole FS over the serial link. Don't bother screwing around with trying to get it running in a modern box, just get what you want off it while it still works in its current form.

Re:Not really all that *old*...

[brusk]

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.

Re:Not really all that *old*...

[Ambient Sheep]

If you look at the specification page, it actually has an 80186 processor in it. "586" was the model number of the machine.

Re:Not really all that *old*...

[pla]

You're confusing the Intel 586 CPU with the Altos model 586 (which had an 8086 CPU running at a blazing 10 MHz)

D'oh! Okay, mods, beat me into oblivion. Mea culpa, mea culpa, mea maxima culpa...

A bit of advice

[Anonymous Coward]

As someone who, even now, is buildworlding FreeBSD 4.9 on a 486 with 32MB of RAM; Craigslist that piece of junk and go outside for a walk. Look at the trees and clouds and the sun. On Monday make an appointment with a shrink. That's what I'm going to do, once I get ppp working.

Screen? What screen? How about Google Voice?

[name_already_taken]

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 plugging in a speech synthesizer and a DTMF dialer, then using a Google Voice account to transcribe the speech back into text which would then be emailed to you.

Re:Screen? What screen? How about Google Voice?

[MrBandersnatch]

Some of the Xenix systems did have CGA/Hercules adaptors - its been a long time since I had to touch an altos. I also seem to recall that many of them used SCSI for the terminal multiplexing so its quite possible that a display could be attached without resorting to the serial port.

As for your suggestion...love it :)

Re:Screen? What screen? How about Google Voice?

[LizardKing]

According to the article about the Altos that's referenced in the summary, it did come with a matching monitor. Perhaps it was a terminal though.

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

[blackest_k]

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.

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

[jabuzz]

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 well. Personally a new motherboard with ISA slot is the way I have gone in the past and would again.

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

[pongo000]

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.

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

[Anonymous Coward]

Hm, my first PC in 1990 was a 286 with onboard IDE controller, and came with a 3.5in 40MB IDE drive.

Another interesting way to skin this cat..

[mswhippingboy]

You can try porting the entire system over to a virtual machine, using dd to copy the entire system, then booting it up in qemu... Here's a link to someone who's had success with this approach... http://virtuallyfun.blogspot.com/2007/05/running-xenix-on-qemu.html Good luck!

Re:Another interesting way to skin this cat..

[JasonStevens]

I knew I should have posted that one.... Although the ALTOS isn't exactly an IBM pc compatible from what I understand... But I've never had a copy of the Xenix disks, or a HD image to test.... The 'hard' part for this user will be transporting a copy of the disk... But then again he always could literally do a "cat /dev/hd00 > /dev/tty1a" and capture the output....... I'd love to get a copy of it and try.

Re:Another interesting way to skin this cat..

[shippo]

I seriously doubt that there will be a VM capable of running this OS. The Altos 586 used an Intel 80186 processor, which was an 8086 with several external components (clock generator, interrupt controller, DMA controller etc.) integrated into the chip. Therefore the machine is not PC compatible as these bits of hardware will be accessed in a different mechanism compared to a standard PC.

The 80186 was typically used in embedded devices. A few non-PC compatible or semi-PC compatible machines did use it, most notably the Tandy 2000.

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

[JasonStevens]

Yeah, I scored one of those on ebay.... I have a P4 1.8Ghz cpu with 3 ISA slots and 3 PCI.. so I get the best of both worlds, PCI video cards for SPEED, and a REAL sound blaster 16...

But yes, we use them at work, because of some old MS-DOS app we have that has all these specialized terminals on a non standard serial bus thing.... It was cool in the 1980's but some people just will *NOT* upgrade their kit.
I got mine for about $150 but I've seen them go for WAY more then that... You have to keep on shopping around...

Yes, but ...

[troll8901]

Perhaps he wasn't looking at porn - he was spending nights with actual women. (Those adventurous ones using BBSes in that era.) And now he wants to contact them to, you know, "get together" again?

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

[rickb928]

My first IDE drive was a 30MB or 40MB Seagate ST-138, I think that was the model. There were smaller, HP made them. You can still find them for sale , though other than a collector item I wonder why.

I have an ISA slot in my spare Sempron machine that's about 6 years old or so now. ISA could be found up to about 2 years ago if you strayed off the beaten path.

There will be more trouble getting the drive booted to any new hardware.

Late '80s == 1200/2400 baud at the low end

[tomhudson]

... so 10 million characters , at 100 cps, is only 100,000 seconds, or just over a day @ 1200 baud, or 14 hours@ 2400 baud. Of course, if you zipped it first, you could probably transfer it in an hour or two, since text files are VERY compressible, and you only want the data, not the system files. Heck, the zipped file might fit on one high-density 5-1/4" floppy.

Forget about transplanting the hard drive into a more modern machine - it won't work.

Since many modern machines don't have a serial port, you may have to buy a serial-to-usb converter, as well as a null modem cable.

Wow; lots of people who don't know what they're on

[Anonymous Coward]

about.

Oh, wait. This is Slashdot.

The filesystem is going to be BFFS or Xenix format, and you could, in fact, mount those, *if* you have a controller that a) has drivers in Linux (the last one I remember is the WD 100...3? 7?) b) for which you have a bus slot.

The xda drivers haven't been in the kernel since, I think, 2.2; maybe 2.0.

But the *real* problem is that Xenix is going to have wrapped the actual filesystem partiiton inside a "division", with a divvy table, which is *then* further inside the disk partiiton.

To the best of my knowledge, Linux has never had divvy table handling; you could mount Xenix filesystems, but only if they'd manually been made on an entire partition, instead of inside a division -- I had to do this a couple times, during conversions.

If you have a working ethernet adapter and the TCP stack, by all means, FTP the entire raw division image over to a Linux box, and then loopback mount it there. If not, then UUCP it over the serial port.

Once you *do* have it in a file on a current linux box, you should be able to mount it, though you may have to rebuild some things into your kernel that aren't there by default.

If you need details, I have a complete set of SCO Xenix manuals, including development and, I think, TCP, on my shelf, ca 2.3.4 timeframe; let me know.

(I would sign in, but Slashdot won't let me from the laptop for some reason; jra/5600)

Great BBS, dude.

[Anonymous Coward]

I'm too young to know the awesomeness, but I enjoyed the experience. :)

Telnet rocks. :D

Re:Great BBS, dude.

[Anonymous Coward]

Telnet?! Cute Kid. Come back when you can at least share the experience of ANSI auto-detection or when you have to quick-swap the handset plug into your modem before carrier drops ;]

Cough... Xenix...

[Anonymous Coward]

http://www.megaupload.com/?d=CGD3RFSD

Enjoy.

Anonymous coward

[Anonymous Coward]

First and foremost, clone the D*mn drive! Then play with clones to your heart's content.

Parallel Port

[dtdmrr]

Any chance you have a parallel port? Should be able to boost your dump rate to 500kpbs or so.

Ask Slashdot

[ThurstonMoore]

This is one of the only ask Slashdot questions that isn't completely stupid and couldn't be answered with common sense.

Re:Simplify... work smarter, not harder.

[Anonymous Coward]

You have no idea what you are talking about.

Re:Simplify... work smarter, not harder.

[ledow]

What on Earth makes you think that any modern adaptor will accept that ancient type of hard drive, even if it used IDE connectivity? Hell, it's hard to read anything less than about a Gig with modern adaptors sometimes. The addressing modes have been changed any number of times since then, and the specs in the article even refer to it as a "Winchester" drive... when was the last time you heard that?

lol but .. err actually a good idea

[Anonymous Coward]

using a video camera and some video code you could get some decent throughput, in theory.

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

[BitZtream]

I have a 105MB WD IDE drive in my desk draw and I've seen 10MB ide drives sold as replacements for failed equipment.

However, I'd say its highly unlikely its an IDE drive as they were very rare at that size.

Here is the script I used in a similar situation.

[Anonymous Coward]

I did a consulting gig for someone who had a similar problem. The state police needed the information off of a database that was running on an old [3|4]86 Xenix system. Here is the script I used.

#!/bin/sh

for I in bin boot dos etc lib oa.files once shlib tmp u unit57 unit58 unit59 usr xenix
do
                echo "tar -cf - $I|uuencode -"
                tar -cf - $I|uuencode -
done

tar -cf - `find /usr -type f -print` >2/usr.err|uuencode -

for I in `cat usr.txt`
do
                tar -cf - $I |uuencode -
done

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

[Anonymous Coward]

Nope, I distinctly remember the first IDE drive I used was a Western Digital 40 Meg, had that shiny gold metal look, with a stick on sticker on top, and a clear cover over the head stepper motor that stuck out and it had a pretty loud head movement to it too...They were neat because we didn't have to low level format'em! AND they only had a single cable to the computer instead of two on ST506, so that was different. I don't think this system used IDE.

What I did for almost exactly the same situation..

[Glasswire]

Well, not the entire disk but...
In about 1988 I was migrating a union office off an old Altos Xenix system over onto a network of PCs served by a Novell file server (the hot setup at the time).sds

They got a ridiculous quote from the company that provided the accounting / WP apps and the OS and Hdw for the Xenix system to provide a set of the word processing docs. I was a PC LAN guy and had not remembered much UNIX (this was pre Linux days) but did a little scoping and found the following solution worked. No doubt this will seem crude and inelegant, but it worked....

Got a PC attached to the Altos via a null-modem cable to PC serial port and used ProComm, a popular serial terminal program to match the protocol the old IBM dumb ASCII terminals used ( 9600 / 8, N , 1) so I got a shell on the Altos. Wasn't sure if there was any serial transfer programs (Xmodem or preferably Zmodem) on the Altos side but I found word processing files were plain text and were in each users directories. You could cat them to the screen. There were a few hundred files so I wasn't going to do this manually, so I dredged up shell scripting manual and wrote a little script (sorry actual code was lost). Then did the following
1) Put Procomm in loggin mode and removed all the limits from file size, so it was going to create a local text file on the PC that contained the entire session
2) Created from ls'ing each dir and editing it, a target list of wp filenames.
3) Ran the script which
      a) echo'd each filename with some special markers eg "*****$FILENAME_BEGINS*****"
      b) cat (type'd for you Win/DOS people) contents of each file to the screen
      c) echo'd each filename with some special markers eg "*****$FILENAME_ENDS*****"
4) When all files were done script terminates, closed the ProComm SESSION.LOG file which now had the entire contents of all the WP docs in it.
5) Wrote a VBSCRIPT parser that found the FILENAME for each file and saved contenst between the BEGIN and END for each file under that name.
Ugly and dumb but it worked. - Sometimes that's the fastest way to do it,

Can you print the data?

[JDOHERTY]

Random suggestion: Can you print the data out in text format and then OCR it into a new machine?

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

[gjyoung]

I hada 20 meg connor HDD IDE in my 286 back in the day.

Recently used Xenix.

[MikeFM]

Sadly I've recently worked for a place still using Xenix as their main computing platform. I was a bit amused.

Re:Simplify... work smarter, not harder.

[dotgain]

Probably being born in the mid 90's or something. Consider yourself lucky he didn't recommend mkisofs | cdrecord

Probably can't read hard disk directly

[Anonymous Coward]

I did a lot of work with hard disks in those days (of course I was a toddler cough cough) and I remember all too well that a hard disk formatted by one controller would almost always NOT work with a different controller. The ST-506 interface carries quite raw signals and the timing would vary slightly from controller to controller. So, plugging that disk into another machine's controller is not likely a good move, unless you can replicate the Altos' controller in an ISA controller form factor, and even then it's not likely.

Best bet is serial port with a null-modem (crossover RX and TX). Could the Altos only do 9600 BAUD? I'd try for 38,400 or more and use X-MODEM, Y-MODEM, or best: Z-MODEM protocol for transfer.

RS422 to USB?

[otis wildflower]

This could be helpful if it has linux drivers?

http://www.iofast.com/product_info.php/products_id/3949

Should be much quicker than any RS232 ports.. It advertises OSX compatibility so presumably there are linux drivers for it or something like it? Likely a rather long shot though, RS232 and a long coffee break or two are likely your best bets :/

I'd like to know more about this BBS

[FrankHS]

I'd like to know more about this BBS. How many incoming lines did it have? What modem speeds did it support? What topics did it cover?

Will the OP put the BBS (or a copy of it) back on line (perhaps in read only mode)? I'm not sure how easy this would be to do but it would be cool if it were possible. Or perhaps just the text of the messages.

Disk is UFS, but do you have tape too?

[James Youngman]

The Altos 586 I used to own also had a QIC tape drive in it (it's in the front of the unit). It also had an Ethernet connector - blanked off in the case of my machine, the Ethernet controller wasn't installed. But check yours.

The filesystem format is UFS and is intelligible by Linux (I verified this in the case of the 5.25" floppies, but the hard disk should be the same).

Document

[Noodlenose]

If you manage it, could you please document the process and share it with the rest of us? Sounds fascinating.

NN

Plug the cables in the CORRECT WAY!!!!!

[Anonymous Coward]

>> JUST MAKE SURE THAT THE PIN 1s LINED UP
          OTHERWISE YOU CAN BLOW THE DRIVE,
          CONTROLLER, AND MAYBE EVEN THE COMPUTER.

Was it the ST-506's hard drives or the old 8 inch floppies that would write 1's all over head 1 if you plugged a cable in backwards?

old sub 100MB hard drives

[juliusbeezer]

I had a lot of fun with machines equipped with low end hard drives at a time when 40MB seemed like a big deal compared with 20. The old Mac Plus, the first 9" B&W classic. Of course, its users were normally well content with an 800kB floppy drive, but the former owner had lashed out on a 20MB external hard drive whose audible chattering betrayed its good humour and continuing health. I believe it was powered mainly by clockwork, but it also had a SCSI controller, oldie stylie 50 PIN cables, and a military-grade steel case of generous proportions and massive weight, and a hardworking fan. The sound it made as it booted from off was lovely: like a miniature knife-grinding museum starting up at 11am for Visitors' Hour. But hey! If it's worked this long, it'll probably work a bit longer. I'd advise techniques that use the absolute minimum of violence on the hardware. And once you've got the data backed up and reformatted for the modern reader, think of all the fun you can have if you network up that machine and use it as a webserver for a couple of novels or something.

textfiles.com

[Eil]

My advice is coming late in the thread, but I hope the submitter gets it:

The first person I would talk to is Jason Scott of textfiles.com. He collects old BBS files and some hardware. He would be able to give you some tips on the system or put you in touch with someone who can.

And if you do manage to get the data without his help, please send it to textfiles.com anyway so the world has access to it.

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

[KennyP]

Incorrect.

As an initial shareholder of Conner, I can assure you - they started at 10MB and went up, and up, and up...

If the drive is truly IDE - anything should be able to make a disk image. Hell - there might be a entry in the BIOS for that drive!

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

[Anonymous Coward]

IDE harddisk as small as 10MB from Conner Peripherals were used in orginial Compaq Portable III PC, so IDE drive were available at a lot smaller capacity then 200MB.

ethernet?

[cas2000]

are you sure it has no ethernet? that old-computers.com page you linked to says it has.

back in those days, ethernet ports were mostly either BNC (coax cable, 10base2) or AUI.

You can still find PCI cards for PCs with BNC connectors. Probably not new any more, but try a swap meet or ebay or in the old-parts bins at small computer retailers. lots of cheap NE2000 clones had both RJ45 and BNC. you'd also need a length of cable and a terminator for each end of the cable. this stuff is all long-obsolete but not that hard to find. esp the connectors and terminators.

you can even find MAUs with RJ-45 connectors (i've still got one lying around some where).

of course, getting this working might end up transferring the data a lot faster but could take you days to figure out how to set up networking on the old machine. serial is probably still best and easiest.

one easy way would be to use a linux box as a terminal (null-modem cable, running cu or minicom or something). set the linux software to log everything to disk and then cat the /dev/ node for the hard disk through 'od'. or, optionally, 'cat /dev/XXX | compress | od'.

that will get you a text hex dump of the entire disk. you can then extract that into a disk image. you may even be able to mount that on linux.

NOTE: od will massively inflate the size of the transfer. that's because it's converting the binary into an ascii representation. if the altos system has uuencode installed, that would probably be a better choice than od (it's a lot more efficient, averaging about 40% inflation of file size instead of more than doubling it with od).

similarly, you can get the files rather than a disk image by using tar. capture and log the output of "tar cf - / | od". again, optionally use compress in the pipeline. that will end up giving you a standard old-fashioned tar file which can just be extracted with GNU tar.

unfortunately, od has no ecc or even checksumming. if you have awk on the altos system, it might be better to write an awk script that does a hex dump with support for error correction). you could probably do it in sh too if you had to. note: it would be better to do it in a scripting language rather than C because the system may not even have a compiler installed, and even if it does you don't want to thrash the disk to compile something.

if the altos system has zmodem software installed (quite likely since it was a BBS), that would be even better. use minicom on the linux end (and make sure you have the lrzsz package installed for zmodem receive support), then pipe the output of cat or tar into sz instead of od. that would give you a transfer with error detection and recovery (i.e. error free transfer) and no need to mess around with the log to extract the actual data.

carefully read the man page for sz on the altos system to find out how to set the filename when transferring stdin. it may have a default filename that it uses, or it may let you set an env var (e.g. the linux version of sz you can set the $ONAME environment variable).

to summarise:

1. "cat /dev/XXX" (disk image) or "tar cf - /" (files). or do both.
2. use zmodem "sz" if it's installed.
3. otherwise use "uuencode" if it's installed
4. otherwise, use "od"
5. if the system doesn't have od (unlikely) or some other hex-dumper, then write up a clone in awk or sh or something.

no way! the best way is...

[Kwirl]

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

Serial is not so bad

[Anonymous Coward]

Just because the hayes modems could only modulate at 9600 baud didn't mean that was the speed limit of the old serial ports. The UART chip on the old x86 PCs would often support 56Kb or 110kb transfers when using a hard-wired "null modem" cable with RTS and CTS wires crossed internally. You had to put the UART into 8-bit transfer mode with hardware flow control and NO PARITY (that allows the use of the 8th bit for data instead of parity on the 7-bit character). But then a protocol like xmodem or zmodem would provide the error detection coding/retransmission, and you could send files over at a really good clip. Send 10MB in about 1/2 hour,easy.

1983?

[Bratmon]

That thing's older than I am! I refuse to get off your lawn.

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

[multipartmixed]

> As I recall, IDE drives first appeared with about 200MB of capacity.

Not so, I have a Western Digital Caviar 280 around here somewhere (I may have just thrown it out, actually) -- that's an 80MB IDE disk.

I also remember 40MB IDE drives quite clearly.

I may even remember 10MB "XT-IDE" drivers. These weren't ATAPI, they were IDE for PC-XT machines.

SCO Unix can read Xenix volumes

[kriston]

Just download the SCO OpenServer trial download. It reads Xenix filesystems with no problem. After all, SCO Unix is Xenix.
Be careful, because I'm not talking about SCO Unixware, but the older software called SCO OpenServer. That's the new name for Xenix-based SCO Unix.
This from an old-time Xenix on-site service guy.

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

[Anonymous Coward]

Segate had a 30MB IDE drive that shipped with some 386 SX units.

Serial port.

[rew]

The disk probably is NOT IDE as the article says. The harddisk is probably MFM. It probably has 17 sectors per head, 4 tracks per cylinder and 312 cylinders.... IIRC...

The serial line sounds reasonable to me.

I'm currently recovering data from a seagate drive. The seagate drive has a debugging serial port. The sata port is completely dead.... I'm hoping to figure out which parts I need instead of having to copy everything over the serial port....

*fwoing*

[YankDownUnder]

Would be great to know WHICH BBS this was - I used XENIX for a while, but on a PC based machine running xbbs - but also had a BNC/coaxial based 3com network card (8mbps) - painful to get set up properly, but worked like a champ once it WAS working...and I wouldn't even care of someone divulged the content of conversations back then - was a great time, had heaps of fun. Too bad you can't image the whole shebang and stick it in a VM and play with it from there...(gosh this brings back heaps of great late night memories)

Xenix had tar

[LostMyBeaver]

Simply tar the entire hard drive and direct it to a serial port. No special tools needed.

Oh... if I recall correctly, it also had compress, so you can probably tar | compress > /dev/serialportdevice

no problems :)

Re:Xenix had tar

[MrKaos]

Oh... if I recall correctly, it also had compress, so you can probably tar | compress > /dev/serialportdevice

Uh, you would have to uuencode it first, so

tar | compress | uuencode > /dev/serialportdevice

should work

What about Floppy Disks

[old unix admin]

My first real computer (after a few Tandy CoCos) was a Altos 586. It has long since passed away, but I still have a Altos 486 at home. I also still have the manuals (somewhere).

Xenix on an Altos 586 would have been licenced from Microsoft, not SCO, and was Microsoft's version of Unix (they had a license from AT&T / Bell Labs). Later Microsoft sold their Xenix stuff to SCO.

I have install disks for Xenix 2 which was 7th edition Unix (manuals are on the web http://cm.bell-labs.com/7thEdMan/) and Xenix 3 which was AT&T System III (pre System V).

My system had a 40 MB ST506 Hard disk (you could only access 32 Meg), a 720 KByte floppy drive (Double sided, Double Density 96TPI, 5 1/4") and 5 (or was it 6) serial ports, 512K of memory and an 8086 processor. I think that the 586 name indicated that you could have 5 users and a printer connected on a 8086 processor. The Altos 986 had 10 ports for 9 users!

By far the easiest way to get data on and off at the time was using the floppy. With a 10 meg drive it would only take a dozen or so floppies to back the system up. Tar was the standard backup command, but I think there was an odd extension to tar for multi-volumes.

I think all the machines should have had 720KB floppy drives. Xenix came on floppies and so did diagnostics. These are much easier to swap with other systems than ST506 hard disks. Other systems such as some NEC PCs (IBM clones) also used these 720 KB drives And they were pin compatible with 720k 3 1/2 drives (different connector, but same pins).

Second best method was kermit (I remember having a lot of trouble trying to compile kermit on this) and with a 10 meg system, it is quite possible that you don't have a C compiler.

UUCP is an option, but it may not be installed. You could also use cu from another unix system, but it does not have error checking.

However if it was a BBS server, there is a better chance that it does have Kermit, UUCP, or X-modem software installed. I think the serial ports default to 9600 baud, 1 sotp bit, no parity.

Many of the comments suggest using SCO software. Most SCO software requires either a 286, 386, or higher processor and won't run on an Altos 586. SCO did sell Xenix for 8086, but it was not very widely used.

Of course I bought this machine around 1987 and threw it out around 2004, and my memory is a bit rusty, so my comments should probably be considered as hints at the truth.

Grant

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

[Anonymous Coward]

Well, my first one was 80Mb. I seem to remember that being reasonably respectable for a desktop at the time, so there were probably lower capacity ones. In fact, I seem to remember my office PC at the time had a 30Mb drive.

Dump the files, then the disk image

[WindShadow]

You can certainly dump 10MB through the serial port, should only take a few hours (as noted by others). But if you dump a raw image copy of the entire hard drive, there's a high probability that you can run the whole machine as a virtual machine under Linux (or whatever). I had probably the first UNIX based BBS in the country, back when the "UNIX-PC" (aka at&t 7300) came out with SysVR3. I ran both Citadel and my own MBS on it, with a modem on each serial port. Good fun!

Given the power of current hardware, you could probably put it back up in a VM and let people use it.

BrandX

[tgeek]

Your best bet is to call up Century Software and see if they still have a copy of "term" for the Altos laying around somewhere. Developing this product for the Altos boxes was what put them into business. I first discovered it back around 1985 when I was developing vertical apps (medical) for the Altos boxes and needed a way to transfer programs to clients over 1200 baud dialup. Give my regards to Greg H. if he's still around (one of the founders).

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

[CompMD]

I still have several IDE Type 17 42MB hard drives, both in 5.25" and 3.5" form factors.

No compilers people!

[tbuskey]

My 1st admin was Xenix on a 386 with a 40MB MFM drive. I worked as a computer operator before that at a place that had Altos Xenix, SunOS i386, Sequent and DTSS.

Anyways...

You have up to 10MB of data. It can use a serial port. Without hardware handshaking, 9600 baud is the fastest you can expect.

10485760 bytes @ 2400 bytes/sec ~= 73 minutes. Geez, why not just use the serial port?

Plug a PC with a 3 wire serial port cable & a terminal program that can log to file. Even Hyperterm can capure text.

If it's just text, cat it on the Xenix just after you start the capture txt on your terminal.

If it's binary, you have 2 choices.

1) Get something like xmodem, zmodem or kermit running on both ends.
2) uuencode the data to convert it to 7 bit ascii and cat it as above.

compress should be on Xenix to reduce the file size before you transfer. uuencode will convert 3 bytes to 4 bytes. gzip can uncompress.

I had xmodem and zmodem for Xenix back in the day. Since I didn't have a compiler, I had to get a binary from CompuServ's Unix SIG. If I had known about uuencode, I would have used that.

The only problem with uuencode it error checking. You might want to do some kind of checksum on your data.
I don't remember the tools. Zmodem and kermit both do error checking. If you have a short cable ( 9600 baud without hardware handshaking, you will get errors. I used to use a 50' 5 wire hardware handshaking cable for zmodem transfers at 115k all the time.

Correct calculation

[TheLoneGundam]

10*1024*1024*10/300/3600=97.09 hours because there are start/stop bits with each character transmitted. Calculation needs to be further adjusted to account for any overhead of the protocol (not familiar with zmodem myself).

I just threw away...

[Anonymous Coward]

I just threw away some SCO Xenix manuals this last weekend... Oops... also worked on ACER/Altos many years ago... you might just find out the Fstype if it is IDE/eIDE put it in an external HD case (saw some at Best Buy the otherday for eIDE/IDE) put it in there hook it up to your favorite Linux variant on it's USB, mount it any copy away. Linux has quite a variety of legacy FS drivers, would have to look, but I'll bet you can mount it... and copy the entire FS to your favorite home NAS.... Used 586 Acer/Altos in mid 1990's... not that old, SCO Xenix early 90's... also... can put in external drive and dd the whole thing off for safe keeping at the device level... exactly what the FBI does when they save for forensic purposes... not a big deal. You pay shippin' and handlin' and $500.00 I'll get it off for you...

Re:no way! the best way is...

[networkBoy]

nah, they'll just re-format it.

Nabu 1600

[Hugh Redelmeier]

My Xenix box is actually a little older. It's a Nabu 1600. It has an 8086 CPU plus an MMU built out of TTL chips. It uses ST506 disk drives (broken now).

The filesystem is the standard 7th edition Unix filesystem. Partitioning is compiled into the kernel (if I remember correctly). Actually, so is disk drive geometry. This makes it hard to substitute other drives.

The original Nabu Xenix port was done by HCR, starting from Altos work done by Microsoft (and possibly SCO). Years later SCO bought HCR, but that is another story.

Xenix at this point was really 7th Edition Unix. Right down to using the Ritchie C compiler, not PCC. The system was very much like a PDP-11, right down to the limitation of 64k bytes for code and 64k bytes for data ("split I and D").

Obvious ways of getting data off this machine (might apply to the OP's machine): uucp (9600 baud is probably the limit on mine) or tar to raw floppies. Using 7th edition filesystem floppies is probably a mistake. Linux could surely read tar files off of raw (no-filesystem) floppies.

Xenix and the rz sz command

[sglines]

If you can bring the system to life then login as root and make an old fashioned tar file of whatever you want to recover. Then use something like Windows Hyperterminal that supports Z-Modem file transfer (gosh I'm old) . On the Xenix side just type "sz filename" and the transfer should start up. A word of caution however. I did this once (about 20 years ago) and the transfer took 4 days. On the last day we had a power failure and I had to start all over again so make sure both boxes are on reliable power.

If you want to mount the disk on a new machine good luck. The disks are ST506 format.

SG