Date : Wed, 08 Mar 2006 16:08:44 +0000
From : Fragula <fragula@...>
Subject: On topic ST412/506/225 MFM/RLL drive cloning
Hi Jules!
Jules Richardson wrote:
> Hmm, that might work for cloning drives, and I've not actually tried it
> - what I really need though is a way of getting data off ST506/412
> drives onto modern media for archive purposes and back again. Problem
> there is that there's no standard as such for ST506/412 drive layout
True, well partly. Let me dig a little deeper. Its been a while, but
this stuff was trivial only, and still doing this sort of thing
regularly up until only 10 years ago.
First we confine this to mass produced ST-506 interfaced standard drives
(i.e. seagates etc. and their re-branded DEC, whatever, variants.),
which is 99% of what we are actually going to meet. The "Washing
Machine" drives will require a seperate think.
Problem is there are several standards, but not ones that matter tmuch
to us at the mo, but, as far as the controller is concerned, they
consist of maybe a few information blocks (or maybe a whole track)
stored on the drive, This can be from Nil (0 zectors occupied!) to a
BIOS readable parameter block, to one spooky RLL drive that appeared to
contain "pokeable" parameters and firmware for the controller on the
first two tracks, and started its useable space on the next free track.
But thats ok, if you can ID your first "user" block in a dump and work
out the offset. - and there is a way to get the machine to trial and
error this.
Then a number of sectors:heads:active_tracks arranged in a pattern, the
only other real variation normally(1) is the sector skews, which are
variable, but getting that wrong normally just means that the read is
less efficient.
(1) some controllers can set aside "redundant" sectors or a per track,
per zone, whatever basis, but these are rare.
The driver software absolutely *needs* to know heads:tracks:sectors
params for the drive. if you are lucky, a Seagate/Shugart standard
parameter block will be at the start of track 0. But then maybe not, so
read the label/Google that info for that make and model.
After that, if you ignore the track start/end markers (which the
controller does by default) and don't care too much about read speed,
physical/logical sector numbers (the controller reads these, to a
standard usually, so just take those for granted) there is just a bunch
of "data" addressed by track:head:sector.
This may contain a partition table. Hopefully one you can figure out.
But if you are just blindly cloning the whole drive, who cares?
Another caveat: Not all MFM controllers are equal. Its too long ago to
remember numbers off the top of my head, but I went through quite a few,
before ending up with my favorite two.. On is *i think* a Seagate 8 bit
board, a "something-02", the other is a 16 bitter, that works in 8 bit
slots after fiddling with the jumpers, made by a company called DFI, who
are still going making PC motherboards. It's a dual purpose RLL+MFM
controller, has a nice BIOS which allows you to read all sorts of
nonsense from the drive, do extensive diagnostics non-destructively, and
generally have lots of fun. But with application of Brain, even the
Seagate is O.k. (and works in 16 or 8 bits slots too.
CERTAIN controllers (actually I think one was a Xebec, now I've come to
mention it) were completely pants. Had a "one touch" (zero control,
other than the hh:ss:tt params) formatter, so would not have been usefull.
If the data stuff is read from the drive in the right order, to a raw
file on a Linux box, it can often (should it be a supported filesystem,
ADFS should work.) simply be "mounted" read-only (R/W can be done with
some trickery and risk) to read files off.
> so drive format is tightly coupled to the controller
Not usually. Its just the variance in the first couple of tracks. These
can be trimmed or edited to get a more standard image file.
The actual low-level formats are fairly standard.
> was formatted, and just hooking any old drive up to a PC MFM/RLL
> controller doesn't get you anywhere in 90% of cases :-(
I won't argue that its 100% successfull, but I've had *much* better
stats than that, more like a 90% success rate, though TBH I've only done
a few MFM/RLL drives using this method, so maybe its 75% or 80%. (3/4 or
4/5 successes)
Given a choice between loosing i.e. The Last Sequent Balance O/S in the
world, or attempting a rescue, I'd attempt the rescue.
OTOH its not a completely trivial job.
> Not like the nice world of being able to hook up an old SCSI drive for
> archive purposes!
OLD SCSI drive? THERE'S NO SUCH THING, almost.
> Although SCSI-ST506 bridge boards tend to either be
> SASI,
Ahh.. Holy war material. I'm convinced both the ACB-4000 and the Xebec
are SASI, but ICBA arguing that point, as SASI is just the old name for
SCSI really, and Coincides most notably with that marvelous party piece
(I've done *it* twice!) that spectacular, change to the TERMPWR line. So
far no equipment has actually been killed during the making of these
events. Well apart from the SCSI cables.. Not even the TERMPWR fuses.
:-/ I guess the values could have been calculated better.
> or even when they are SCSI the board's firmware is pre-CCS
That could be a problem. But pre-ccs still has the most basic of
read/write commands. its the sensing, formatting etc. the enhancements
that "cause" the problem when the host adaptor fires commands that the
convertor board just doesn't now how to handle. We should be able to
dumb down our host adaptors more to deal with old drives, use seperate
formatter software etc. rather than trying to smart up the adaptors.
Oh.. one thing that maybe someone else could tell me about is WTF is the
difference with "Eight Bit SCSI" and "16 bit SCSI". I think I've only
met one type personally.
> and so
> Linux drivers barf in trying to talk to them!
Possibly, being too Fn Smart for their own good. Someone should give
them a lobotomy. Back to Basics.
> Been there done that
> enough times! I've got a homebrew parallel port SASI controller on the
> desk here but haven't had the time in months to write any drivers for it
> :-(
Cool!
> There's been talk of sampling the raw data signal coming from a '506/412
> drive at 20MHz or so and doing all the processing in software to extract
> real data from it
I will argue that, if you feel you need to do that, you are either doing
something badly wrong, (ST506 is ST506!) or are reconstructing data from
a disk that is already dead, rather than last legging it.
> (and being able to reconstruct a signal to
> subsequently play back to a drive if needs be)
There used to be a (*very* expensive) bit of commercial kit to do that.
A suitcase jobbie. I'll try to remember who made it.
, but I'm not aware of
> anyone who's done it yet. Designing something that works at those sorts
> of frequencies is beyond me,
Err. 20MHz isnt' that high a frequency.. Just pretend it is DC that
needs smoothing, design something (i.e. a fuzz face ;-) that will
spatter any noise it gets on its supply lines, and use the output of
that into a shmitt trigger, Reduce fuzz face gain to "taste", look at
the time-between-transitions (counters w start/stop)
> All the classic computer enthusiasts just bury their heads in the sand
> about the problem and hope it'll go away. It's not so bad if install
> media is around on floppy to rebuild a system when a drive goes pop, but
> for a lot of oddball systems the copy on the hard disk is the only one
> that exists any more!
To be precise, One, and only one, Sequent Balance 8000! Actually I think
its an actual SCSI drive. BICBW. I truly hope I am not!
Cheers!
M.