Supporting antique media

I have a bunch of those type systems.

It probably could, assuming you could find a PCI based MFM card. :-)

Uhhh, could always replace the battery. :-)

If it is a true image file, try rawrite. Google for 'rawrite'.

Otherwise, might try DRIVER.SYS, it that is still around.

Bulk erase with a big hairy magnet, format it as a 360, then write it.

The only 8" media I have ever used is an old flakey CDC 8" drive, 160 meg, I think, of the SMD flavor. Otherwise, floppy wise, I still have some original IBM 5 1/4" 360k drives floating around somewhere, that might even work. I have a pair of Teac 360k drives, too. As well as

1.2 & 1.44 drives. And systems that I am sure I could resurrect to use any of them. That's what happens when you are a packrat. :-)

--
ArarghMail001 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.

Sounds like a candidate for the alt.folklore.computers news group.

the old 'Laplink' might move the file via RS232 if you could find a copy.

And presumably an MFM hard drive.

If it's an IDE drive (unlikely, but you can probably find specs on the 'Web), you chould be able to attach it. If it's an MFM drive, you'll need an MFM controller, and at least _some_ MFM drives were controller-specific: if the controller went bad, a replacement controller of the same type might not recognize it. As I recall, this was a real problem for '086- and '286-era machines, less so for the 386es.

Batteries (as another poster pointed out) can be replaced. 3V (often 2x AA) was a common size, but ** CHECK ** before replacing it.

I understand -- I once had to use a Gen-you-wine IBM-Pee-Cee to retrieve data from a Radio Shack TRS-80 II 8" floppy disk.

The file? Or an image of the CP-386 hard drive?

Well, you probably have a serial port and a parallel port, and you might even have a built-in modem. What difficulties would you have with using one of these? After compressing the file, of course -- you might have to transfer it at 110 Baud.

The fact that you have your image on a booting machine means all sorts of possibilities exist. Heck, if you had to you could write something in BASIC to flash the keyboard ScrollLock LED and read it out through a phototransistor (but a serial port would be simpler and require less wiring ).

My own attempts at writing to 1.2Mb floppies in a 360K drive have failed more often than they have worked. You might think about exploring your local thrift shops for a $10 ISA machine with

5.25" 360K floppy drives... it only has to run for a few hours.

I think I just lost you on this step. If you have your file on the P-III why move it back to the CP-386?

If your goal is being able to _read_ old data from a floppy or HD image, then all you need is software to decode it. Bytes is bytes. A sector-by-sector transfer of the HD you originally started with onto a modern (as in "huge" ) hard drive and some software would let you (eventually) retrieve your file from it.

In fact, I _suspect_ that you could mount an MFM HD-image under Linux as a FAT-12 or FAT-16 filesystem and read off your file directly. MFM vs. IDE has to do with the way physical sectors are laid out and read/written; the partition and file system structures are identical.

Good luck.

Frank McKenney

-- Hanlon's Razor: ÿNever attribute to malice that which can be adequately explained by stupidity.ÿ

-- Frank McKenney, McKenney Associates Richmond, Virginia / (804) 320-4887 Munged E-mail: frank uscore mckenney ayut mined spring dawt cahm (y'all)

Isn't MFM more > The drive uses an oddball partition format -- so, even

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Alright, you!!  Imitate a WOUNDED SEAL pleading for a PARKING SPACE!!

That is my experience as well; I remember buying a 386SX with whopping

105MB IDE hard drive in 1991. At that time IDE had already replaced MFM, even for smaller capacities like 40MB (which were more common back then).

I think it very unlikely that the 300MB hard drive has an MFM interface. And if it has an IDE interface I'm pretty sure that it is possible to auto detect the drive geometry (set BIOS harddrive parameters to "Auto").

As far as supporting old antique formats with modern hardware, your best bet would be to copy all files that may needed some day in the future to a new medium every time you upgrade to new storage media. As far as running the software your best bet would probably using virtual machines, and software like DOSBox to emulate old DOS computers.

---------------^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

There's the rub. Media changes way too fast. And, I have a

*lot* of material to keep "moving". E.g., my "frequently accessed" archive is just about 1TB. That doesn't count things that are archived on CD's, tape, etc.

Note that you not only have to do this "copy" each time media change but, also, each time your tools adopt new *formats* (e.g., new file system formats).

I opted (gambled) to just try to keep working machines of each vintage that could be fired up and, worst case, transfer files over serial ports, etc. (e.g., my 8" floppies can only be read on a machine that *only* has serial ports). Otherwise, its a full time job just moving archives from Solaris to NetBSD to Windows to ...

(I am currently trying to move everything to NetBSD as I can at least control that system more carefully than Slowaris, Windblows, etc.)

This will only work for software that runs under DOS! :>

I'll combine my replies here instead of responding individually to each message :-/

To restate where I currently am:

- Portable 386 has lost its CMOS. As such, it can't recognize the hard drive (doesn't know what "drive type" it is).

- The BIOS does not have the ability of querying the drive for *its* geometry and adapting to that ("AUTO"). This machine is from the era when the *PC* told the drive what its geometry was (via "INIT" message). IIRC, I modified the "disk parameter table" (or whatever it is officially called) in this machine to support this particular disk geometry (I recall editing ROM images and burning some replacement EPROMs with an "appropriate" geometry overwriting one of the "factory" drive types)

- In order to restore CMOS values (even if the batteries are good or replaced), I must be able to boot off a "SETUP" floppy (SETUP is not resident in the ROM BIOS on these machines).

- In order to prepare a SETUP boot floppy, I need to be able to write a 5-1/4" 360K floppy (which this machine can then -- hopefully -- read, boot and give me access to SETUP).

- The only machine that I have with a 5-1/4" drive in it (currently) is a Portable III (the dead machine is a Portable 386 -- different except cosmetics).

- The Portable III can boot. I *can* move files from my other machines onto this machine (using a printer port ethernet adapter). This machine has a 5-1/4" 1.2M floppy in it.

- I have moved the Compaq "SoftPaq" (a small executable and associated "Compaq Disk Image" -- whatever format *that* might be!) onto the Portable III. But, since the image is for a 360K disk, I can't write using this drive. (yes, I've tried a large electromagnet -- used for bulk erasing 1/2" 9-track tape so it's got oodles of Gauss)

- I have tried a different image for a 3-1/2 720K drive but the Compaq utility complains that this is the wrong drive type (5" vs. 3").

I can't even say for sure that the file in question resides in that partition in teh form I expect (i.e., as a Gerber photoplot). I may actually have to build it from the board layout (which means running the software that does this)

It would be easiest to simply get the machine to boot. Fix the disk "type" in the BIOS. Let the other system come up. Open the PCB application. Find the file (if it exists) or *create* the file (from the layout). Then copy the file onto the DOS partition from which it can later be copied *off* the machine.

I'll fix *this* problem, sooner or later. If push comes to shove, I'll just examine the floppy image(s) with a hex editor and see if I can just dd(1) them to a floppy (on the Portable III).

The more important question is:

Probably not. I checked a very old list of drives, and the largest MFM I saw was 191 meg. I didn't check RLL drives as I think they were mostly based of MFMs. However, it could very well have been an ESDI drive. I know for sure ESDI drives were available in larger sizes as I still have a lot of 676 meg & 1.2 gig ESDI drives that I never got around to tossing out. I remember that my first 676 meg ESDI drive cost me something like $2,500. Back in the 80s. I must have spent 15 or 20 thousand dollars buying ESDI drives over the years. :-)

IIRC, that wouldn't work for the very early IDE drives. Or maybe I was using IDE drives in systems that had no support for the 'identify drive' command.

That's one way. And I do use it, mostly. :-)

However, I also keep the old systems. Never use them, though. :-)

--
ArarghMail001 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.

So it's not the "user type 47" (old compaqs did not have that IIRC)? Then Just try the available types until it works. Or put the disk in a modern PC and try to auto detect it, the PC might even boot and you can at least write down the CHS values and set those in the old PC's BIOS.

Aargh, now it all comes back, those %^^* compaqs needed that floppy just to be able to access the CMOS! Have you tried the compaq website? They used to have pretty old stuff around, but this might be too ancient.

I would just try the disk in a new(er) PC, it might just work (at lightning speed perhaps).

Weren't there utilities around to 'fake' a 360K floppy on larger drives? What I also remember is that writing 1.2M floppies in 360K drives often failed because of the 'harder' magnetic properties of the 1.2MB floppies.

But it might just boot on another PC or do you think the particular compaq bios is required to boot from that disk?

--
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

You auto buy now.

Exactly. The machine only supported a fixed set of drive geometries. I think I had to edit this table (in ROM) to make this particular drive work with the machine (this is relatively easy to do -- the location of the table in memory is indicated, IIRC, by one of the PC "interrupts" and its format is pretty obvious. So, just change the CHS, etc. to match that of the actual drive being used, tweek the ROMs checksum -- so the BIOS doesn't complain about a bad checksum -- and Voila!)

Can't *access* the old (Portable 386) BIOS *settings* without the "SETUP" floppy! :> (or, some other bootable floppy that I could then use to manually diddle the values in the CMOS using DEBUG.EXE)

Exactly! That is where I am: trying to get the floppy image *onto* a real floppy so I can boot that floppy and run SETUP.

I have pretty much everything Compaq ever had re: these older machines. E.g., I have images of several versions of these disks (diagnostics, setup, etc.) going back many years. I had the foresight to save the images. I just didn't expect it to be so hard to get them onto *real* media!

That assumes the disk is able to tell the PC what its geometry is (things worked the other way ages ago -- the PC told the *disk* what it's geometry was).

I would never boot off the disk but could attach it as a "second drive".

But, even if the disk was accessible in this way, that would only let me access the stuff on the DOS partition of that hard disk. I would need to have software that understood the *other* partition to be able to even examine its contents.

And, if the photoplot isn't sitting there with a nice obvious name, I wouldn't be able to generate it on a new machine (hence my reason for keeping the Portable 386)

Yes. The heads on 1.2 drives are smaller. I've never been able to reliably use them to create 360K media. What I *should* have done was saved a 360K drive! (for the Portable 386, I think this might have had to have been a special drive -- not sure a regular 5" drive fits in the enclosure...?)

See above. The "non-DOS" partition is the problem. The Compaq itself can't read it under DOS.

Still waiting on suggestions, here... ;-)

The "IDENTIFY" command was used to send geometry information

*to* the drive. The interface has changed over the years. :<

Running most (PC) software is relatively easy to do. I use a SunPCi2 to support various old DOS/Windows images and the applications that ran on them -- under Solaris.

The problem comes when you have to deal with particular I/O devices. In this case, media. E.g., I suspect I have

*literally* 30 different types of media that I can read and write (though that doesn't mean I can always put meaning to the particular data formats!).

In this case, I screwed up by failing to take into consideration the "ALMOST compatibilities" of 360K and 1.2M floppies. They were "close enough" in my mind that I didn't think twice about holding onto a 360K drive in one of my "equipment purges". Note I didn't make that mistake when it came to hard sectored vs. soft sectored 8" drives, etc. Nor the gazillion "almost the same" varieties of tape... :-(

I think you will wind waiting a long time. :-)

The only one that I know of that has stood the test of time is: . . . Ink on paper. (Be sure to use acid-free paper these days. :-)

But not very cost effective. And not much capacity.

--
ArarghMail001 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.

Depending on the value and budget Maybe a disk recovery company can copy the drive.

Op Wed, 06 Jan 2010 00:06:11 +0100 schreef :

There seems to be a huge hiatus in your knowledge of antique writing media.

Ever heard of parchment, wood carvings, stone/clay tablets, carpets, microfilm (polyester-based, not cellulose), bone carvings?

Is there really so much information that you want future historians to know about you?

--
Gemaakt met Opera's revolutionaire e-mailprogramma:  
http://www.opera.com/mail/
(remove the obvious prefix to reply by mail)

Not really.

Counts as ink on paper.

Counts as ink on paper, I guess. :-) But slower.

Stone takes forever and a day to create. Clay tablets are a lot bulkier than paper or parchment.

Not quite as bad as Stone, but still pretty slow. Besides, somebody will dump it on the floor and walk on it. :-)

As long as you can dig up a working reader, or have REALLY good eyesight.

Still not as good as paper.

Me personally, zilch. :-)

--
ArarghMail001 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.

Don't keep data on obsolete media. Copy it onto new media whenever you start being concerned about whether the existing media can be read.

Also, avoid storing data in proprietary formats. It isn't much use having

8" floppy images stored on a new SATA drive if the only software which can read it requires a 386 and uses copy-protection mechanisms which won't work with an emulator.

I know that's easier said than done, but it doesn't make it any less important.

Boudewijn Dijkstra escreveu: [snipped]

You forgot the oral tradition :-P

--
Cesar Rabak
GNU/Linux User 52247.
Get counted: http://counter.li.org/

Problem is, media changes pretty often. If you are talking about preserving things over the course of a career, you may have to deal with several shifts. I started out: Hollerith -> PPT ->

large sealed disk units -> 8" floppies -> 5" -> 3" floppies... now you have a hard time finding a machine *with* floppies of ANY size, etc. CD -> DVD plus a whole slew of backup media options.

The problem is that not all data *has* "non-proprietary" formats. E.g., files for early FPGAs, damn near *all* schematic and board layout formats, every MCU vendor has had proprietary object file formats (unless you talk about bigger machines, a.out, elf, coff, etc.) -- hell there must be 30 or more "binary" formats for use in burning PROMs...

Agreed. But what's practical and what's logical are often very different. Especially when you consider that you are always gambling in this regard -- *will* this data ever need to be accessed in the future? how much effort should i put into trying to carry it forward (by porting it to new media, new formats, or just "saving an old working machine, etc.) vs. the chance of actually needing it (expected value analysis).