On Sat, 11 Sep 2004, Tom Jennings wrote: What can the actual drum clock be... I dunno... another reason to slow the drum; see below further... 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... SMPTE can resolve 30/100 of a second, BTW - 100 'subframes' per video frame at 30fps - the highest video rate SMPTE was designed for. And yes, the FM needs to be consulted. [Aside: I always wanted to have a manual entitles: "The Book of Armaments"] Sorry. Digital Audio Workstation. I lapsed into AudioSpeak by habit. Yeah. I'd intercept the 'lift' line and do that manually. before spin-up, if this is at all possible. On a system this old, with (relatively) large data tracks, I think that there would probably be recognizable pulses at slower speeds... Anyway, just Thoughts... Cheerz John

On Mon, 13 Sep 2004, Paul Koning wrote: I was (mistakenly?) assuming that we were trying to recover data from a *drum* ... if this is a platter, and the heads are spaced courtesy of Mr. Bernoulli - then slowing down the rotation would in fact be a Bad Idea... Cheers John

Not all. William Donzelli aw288(a)osfn.org

John Foust wrote: Certainly, if the original hardware can't reliably recover data stored on disks or drums, this is a good way to go. The more information you have, the better chance you hace. Well, 300kb/s would suggest that if it went 10101010 then you'd have a 150kHz signal. Now, possibly it uses some kind of self-clocking or NRZ code, so it may be 300kHz. I'd say that 8 bits of resolution would be plenty, and perhaps four times the data rate, so a sample rate of 1.2MHz might well be adequate. That would be well within the range of (relatively) cheap A-D converters. Obviously, the higher the resolution, the slower the conversion. Most A-D converters (and I'm sure many, if not most of you know this) use "successive approximation" to derive the correct value - get a D-A converter and a comparator, then loop through "toggle the MSB, is it too high or too low? Toggle the next bit, too high or too low?" all the way down. You get "flash" converters for video (or you used to) which were 32 or 64 individual comparators and voltage references, and some encoding logic to give you a binary output. Overkill really, but very, very fast. If you found a fast 6-bit flash converter cheaply, that may well be enough resolution for your track scanner. We're not going for Dolby Digital quality here... Gordon.

On Mon, 2004-09-13 at 10:36, John Foust wrote: I do not consider myself a magnetic-media expert, but I've made a number of (low-density) controllers and en/de-coding schemes, and repaired others, and read a lot (in one ear out the other probably). I figure there are a few failure modes that would be easy for amateurs (like me) to recover, like low-gain, dissipated magnetics (grain randomization, etc), and such, that would be amenable to software repair. Data sleuthing like that being done on "Archimedes Method" palimpsest (on TV last night, BTW) is way out of my league, but at least the raw data would be there for future generations, etc. Secondary issues might be, for example, the data on my LGP-21 platter is fine, but the surface, now 40 years old, has changed physical structure, however subtlely, and say, ruins heads/ruined by heads. So it's OK for a day, week or month, then becomes bad. I think this is even likely. It could be that, after bring-up, data snapshot and recovery, the platter could be cleaned, re-polished, heads examined (including mine), and simply put back into use. I'm thinking that a light, in-place cleaning might be a good idea (using 70's tech cleaning aids for Eagle-type removable packs, down through the head hole in the case) before spin up, but of course there's the danger of doing harm. It's all a gamble, and without a budget and even much time I'm not sure how to approach it.

On Thu, 2004-09-16 at 12:43, John Foust wrote: Not this thing! Or should I say, a clean, room, OK, but not a CLEANROOM. The memory is not sealed. The heads are on little lucite blocks held to the top of the memory with two screws. No gasket, even. The heads 'crash' on the nickel-plated-steel platter, and lift when up to speed. I assume dust just gets flung to one side centrifugally. The San Diego 'Computer Museum of America' has an LGP-21, it was apparently running when donated, and the disk surface on that thing looks AWFUL, all scratched-looking, but we're talking 60 - 80 bits per inch here, so as long as you don't score head windings in half it probably just makes a wee noise and moves bits. Contemporary densities being readable with the naked eye... :-) I assume you are otherwise correct, the track is likely very narrow, and hard to hit when a head is replaced. I think the manual actually tells the recorded track width though. I realize I haven't put up detailed photos of the innards of this thing (like the memory details), I will do so in the next week.

John> At 04:00 PM 9/15/2004, you wrote: John> With platters, there are clean-room issues as well as very John> difficult alignnment issues - imagine how difficult it would be John> to re-align a read head with the concentric bands on a platter John> that may have been slightly misaligned from its original hub. True for moving head disks, but possibly not for head per track devices. For example, head alignment of a DEC RF11 (512 kbytes per platter) was done by eyeball, lining up the heads with engraved circles on a glass or plexiglass alignment platter. paul

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. 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. (It could never be big enough! :-) 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. 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 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.

On Sat, 2004-09-11 at 14:46, Peter C. Wallace wrote: 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). 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).