On Tue, 2006-08-29 at 14:11 -0600, J Blaser wrote: I'm not a guru by any stretch of the imagination, but I know that the RQDX3 controllers wrote a low level format different than RQDX1/2, so its not unlikely that the PC MFM controllers won't be able to read it. That said, you might be able to retrieve the data from there by booting NetBSD on the uVAX and dd'ing out the network (or heavens!) the serial port. You should be able to boot NetBSD without writing anything to the drives. If it has a tape, you could spool out to it and then try reading it on a more PC-happy tape drive. I kinda miss my uVAX II w/RA82 hanging on it :) Not terribly efficient, but it sounded cool. Now if I could get a reasonable PDP-11 that my wife wouldn't object to :) Brian

Excellent idea, years later, I still regret not *IMMEDIATLY* doing some sort of backup of an RD53 with VAX/VMS 4.x on it that I got with a MicroVAX III. Am I correct in assuming that you don't have any newer hard drives than the MFM drives on these systems? This idea seems sound to me, although I have *never* heard of anyone attempting this. I have done this with SCSI drives from my PDP-11. I suspect, but this is only a guess, that the issue is the way the DEC MFM drives are formated. There are only two ways that I'm aware of to format an MFM drive for use on a VAX. One is with a MicroVAX/VAXstation 2000 (formatter is built into the ROM's), the other is with the Field Service Diagnostics (customer diagnostics can't format drives). Hopefully someone here as some idea on this, as this is an interesting idea. Zane

On 8/30/06, J Blaser <oldcpu at rogerwilco.org> wrote: Given your problems you list further down the message, what models of uVAXen do you have, and most specifically, what disk controllers (uVAX 2000-built-in, RQDX1, RQDX3...)? Nothing wrong with being cautious. Good plan in theory, but there's a problem with it in practice - there is no standard for low-level format on MFM drives. You must have happened to have used WD-formatted MFM drives (since the rig has a WD1002 in it). Your setup will work fine for imaging some PC drives, but not others. Or that the low-level format isn't recognized by a WD1002. It's _possible_ that the previous owner erased the drives, but unlikely. The only two (easy) ways I can guess how it might have been done would be to use the internal (ROM-based) format utility on a uVAX2000 or to boot the Field Service diagnostic tape (the customer tape lacks the format utility) and use the tape-based format utility. Unlikely. The only jumper change from VAX to PC use I know of is the one that must be installed into a Micropolis 1355 to turn it into an RD53 (J7?). You have to unscrew the lower board from the drive (2 screws and it hinges up), and there's a marked spot for a wire jumper. Without that jumper, the VAX format utility won't "see" the drive as an RD53, but it would work fine in a PC. I've added this jumper to drives pulled from PCs and reformatted them - no problems. I don't think you have to pull the jumper to go the other way. The rare jumper aside, yes. What you've hit upon was a daily problem in the pre-IDE world - the data interface between the controller and the drive is a raw analog channel. As long as you didn't exceed the bits-per- inch limit of the medium and the MFM clock rate (5MHz?), you were free to invent your own marking scheme on the disk. One non-DEC example is that the Commodore D9060 and D9090 drives wrote 32 sectors of 128 bytes on each track on the same sort of drive that a PC put 17 sectors of 512 bytes on each track. The drive was unchanged on the surface. In your VAX-to-PC setup, it's all 512-byte sectors, but there's no requirement that the same encoding scheme or header scheme be used. In a PC-only context, think of this real example - the ST-225 was nominally a 21.4MB MFM drive. The ST-238 was nominally a 30MB RLL drive. With the exception of manufacturer surface quality verification (checking for bad spots), the drives are identical. If you stuck an ST-238 on an MFM controller, it formatted to 21.4MB. If you stuck an ST-225 on an RLL controller, if formatted to 30MB (but you might or might not have any luck keeping your data intact, depending on how good the platters were). In other words, it was all about the controller - the drives were, essentially, identical. Even among DEC controllers, there's not one low-level format. If you wanted to migrate an RD51 from an RQDX1 to an RQDX3, you'd have to low-level format it. You can exchange drives between a uVAX-2000 and a uVAX w/RQDX3... that format _is_ identical. Other than that, you pretty much have to look up the controller specs and possibly (probably?) reformat. I have never heard of a single PC controller that "knew" DEC's low-level format. What folks typically have to do is take a working machine and save off the disk from a running OS. There are many ways to do this, either imaging a disk over a serial or network link, backing the drive up to tape or to a SCSI drive (and then dumping the backup from a "modern" machine that can directly read the backup), or even just cloning the MFM drive to a spare MFM drive and sticking the spare on the shelf. It's easier to make a suggestion if it's known exactly what hardware resources you have on hand. All I can say from what you've posted is that you very well might have what you need on hand, but a spare drive or two that you know is safe to reformat might make things easier to juggle - you could practice installing an OS (*BSD, VMS...) and save the forensic recovery of anything interesting on your old drives until you are more familiar with the systems. If you don't have a tape drive or a SCSI controller, consider Kermit... it may take a while to move many MB over Kermit, but you can set it up and go do something else for hours/days. Also, there isn't *one* way to do this, so if you would list for us the resources you have, we might be able to make a suggestion that's more targeted to your situation. -ethan

Which I am not, but I've worked with ST412-interfaced hard drives at a pretty low level. [...] The ST412 interface (often incorrectly called the ST506 interface, but anyway) is a 'raw' interface. That is, the data lines are essentally is squared-up version of the signal to/from the read/write head. There are restrictions on the pulse rate, etc, but apart from that it's up to you (the controller) to decide on how you're going to encode the data, how you're going to mark the start of the sector, and so on. Anf there's no reason to assume that 2 different controllers will do it the saem way. In other words, there's no reason to assume a PC-based controller will recognise data written by a DEC controller. -tony