13 Sep
2004
13 Sep
'04
8:04 a.m.
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 @ 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).