Rotating memory data recovery

From: Tom Jennings <tomj_at_wps.com>
Date: Wed Sep 15 14:12:39 2004

> On Sat, 11 Sep 2004, Tom Jennings wrote:

> > I was assuming PC audio cards would not be fast enough.

> On Sat, 2004-09-11 at 19:24, John Lawson wrote:
> What can the actual drum clock be... I dunno... another reason to slow
> the drum; see below further...

It's 80KHz. So you think that slowing the motor speed say 4X will not
affect the head outputs more than proportionately? I'm a bit wary of
this, partly out of ignorance (relatively speaking; I know the physics
involved, and I know electronics, but I know enough now that I know I
don't know more than I do know -- now). IOTW, there's always Another
Factor, like relying on the slope of the signal off the head, etc etc.





> > The disk has one (or a few) timing tracks. I assumed I would record the
> > timing track plus a data track; hence all recordings would have a
> > reference.

> If you could trigger a simple pulse to SMPTE converter, and if the data
> rate of the "index" pulse is slow enough, then your synce problems get
> solved...

Well I was an idiot writing before I went back and re-read it all.
There's three timing tracks, one of them though is the sector address,
and the timing pulses are all derived.

> [Aside: I always wanted to have a manual entitles: "The Book of
> Armaments"]

(It could never be big enough! :-)

> >> if you
> >> could get a 'whole drum after this pulse' (sort of like capturing one
> >> video frame) sync set up, then you could record each track onto a similar
> >> parallel track in the DAW....

Physical geometry is 32 heads * 128 sectors, logically juggled to
re-create the LGP-30's 64 * 64. There are six spare tracks with spare
heads over them.

THe simplest thing (sic) would be to brute-force record 32 tracks at
once. Assuming the data isn't totally awful, sync could be derived
easily from the captured data set.


> > Another choice is to simply disable writing electrically, and use the
> > computer itself. The biggest worry (at this point) is head/platter
> > issues. THe heads contact at rest, then lift. The mechanical issues
> > exist no matter the data-recovery method.
>
> Yeah. I'd intercept the 'lift' line and do that manually. before spin-up,
> if this is at all possible.

There's a transistor clamp that drags write current to ground, a diode
per head, in each head block. Easy to block writing with a few clip
leads.

Umm, the heads have no lift mechanism! They run on the nickel surface
until it's up to speed.


> > Well the problem as I see it is deterioration of the magnetic
> > surface/circuit, and changing motor speed won't improve that (probably).
> > Lost data is secondary to a lost timing track! That would be ruinous, I
> > have no idea how I'd re-create that. Certainly, I need a copy of that.
>
> On a system this old, with (relatively) large data tracks, I think that
> there would probably be recognizable pulses at slower speeds...


Well there's two things about the memory data: the timing tracks are
utterly critical of course, but there's only three of those. So I should
capture those in excruciating detail.

All "data" data is relative to those timing tracks obviously. So if I
captured the timing tracks now, and for some reason had to re-write them
-- or another LGP-21 were found, wiped, they could be re-written with an
external PC and simple hardware interface. Of course the "data" data
would be lost, but the machine could be made to work.

So unless someone wants to loan me a 32-channel X 8-bit A/D system, at
this point I think I will simply disable writes and bring the machine
up, and find some way to record the three timing tracks at sufficient
resolution to re-create that data. After reforming caps, power supply
checkout, etc etc etc.
Received on Wed Sep 15 2004 - 14:12:39 BST