Rotating memory data recovery

From: Tom Jennings <tomj_at_wps.com>
Date: Mon Sep 13 15:04:58 2004

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

> > OK, I'm very close to needing to suck the data off the main memory of
> > this LGP-21 before I reform caps and all that electronicky stuff.

On Sat, 2004-09-11 at 14:46, Peter C. Wallace wrote:

> I would think that 16 bits is way overkill (the original read channel gets by
> with one bit) 8 bits ought to be good enough if you use most of the bits.
> 8bit 1 MHz A-Ds are cheap and simple to use.

You are of course right! I talked before I thought... the need to do
this has been in the back of my mind for so long I wrote before I read.

You are correct, the machine uses a simple amplifier and comparator, so
128 times as many discrete levels (8 bits) would let me correct for loss
of flux well enough; this isn't spook-level data recovery. (2X - 4X is
probably enough.)

The LGP platter has three timing tracks: more or less, bit time, sector
time, sector address. From the first two are derived 8 states with FFs.
The sector address is skewed (8" floppy style) via this 3rd timing track
bit-serial table.

So pre-turnon data recovery is a Big Deal, and now that the Time is Near
a problem I've worried about all along is more dear -- those timing
tracks are literally irreplacable and entirely ephemeral (Tony Duell may
be able to sympathize with this fear :-)

The chance at this point of the timing tracks being usable is pretty
good, no reason it's been anything other than seasonally-temperature
cycled (ie. slowly).

>
> Also since you have multiple passes available you could just use a comparator
> and adjust the threshold (even manually) every rotation (like a sampling
> scope) This way you only need to record (multiple) 1 bit streams _at_ 800 KHz or
> so - easily done with a PC parallel port (= 100KHz reading of shift register)

Good idea, but there's no way to externally know which of the samples
taken that way would be "good data".

Though -- there is an old trick for checking for arithmetic overflow and
range in intermediate results -- seeing that output remains as-predicted
with varying input. In this case, if the comparator has a 10%-wide
window, varying the input gain + and - 2%, say, should produce correct
output. Marginal checking, in other words.

Even this would become complex though, and all samples need to be
relative to some of the timing-track-derived timing.

I'm just not sure how much moon-landing effort I should put out in this
direction. It may be that I should simply ensure that writing isn't
electrically possible, and bring the machine up minimally (can't run
with write disabled, much).
Received on Mon Sep 13 2004 - 15:04:58 BST