Tuesday, October 17, Letter from Dick Oswald, Oct 25
Tuesday, October 31
Next scheduled (progress/problem) meeting is Tuesday November 14th.
|
I am calling a team meeting for next Tuesday, October 17 at 2PM at CHM. Al Hoagland has asked that we establish a timeline for demo capability for the new access control that Dick is designing. Al feels that the fact of accepting support money from IBM and Hitachi as well as increased scrutiny from CHM management will inevitably expose us to the need to keep things moving along at a predictable pace.
This may mean that we should recruit additional skills, such as perhaps electronics fabrication and programming. There is a talent pool among CHM volunteers just waiting to be tapped if need be. We should discuss this as a team. ... Thanks! Dave |
Meeting Notes - October 17th
- Attending: Al Hoagland, Dave Bennet, Dick Oswald, Joe Feng, Ed Thelen
-
Compressor Noise -
- The modern compressor connected to the RAMAC is causing more noise problems than expected. For the September Anniversary, to get the noisy thing out of the demo room, the group asked Dave Dial to get it moved to a little room off the lobby and to get the necessary air plumbing and electric power done -
Just fine, except the compressor noise filtered into the lobby and made life unpleasant there :-((
- And apparently there were building code complications also.
The noisey compressor is being returned to the "RAMAC" room. :-((
Dave is making a sound insulating box to cover this unit? The newly donated actual RAMAC compressor is less noisy that the current modern compressor? Quiet enough?
- Data Channel
- Joe Feng is pretty much in charge of the data (read/write) channel. Probably will use a PC to source and sink data?? Joe knows a Roger Wood who might be available and willing to help implement the I/O data channel.
- Joe Feng says that there is an effective "start pulse" and "end pulse" enclosing each character on the RAMAC - and that a fast enough UART could do the job serializing.
Joe Feng is concerned about an 80 KHz data rate UART for serializing the data to/from the RAMAC head. (Many UARTs use a much faster clocking rate to provide nice internal synchronizing, like 8x or 16x. Dick Oswald and Ed Thelen keep saying "no problem" - but we have not provided Joe a UART yet. We really should -
- Head Position Controls
- Dick Oswald is getting concerned about implementing the track/head position controls. PLD"s? Lattice, $5 for 4 units?
- 5 volt logic desired for interface with ADCs etc.
- "We the group" agreed:
- that we should use circuits using 0.1 hole centers. This allows
TTL (many circuits not being made any more), and easy soldering for us old timers.
- No one wants to deal with fine pitch and surface mounting.
- that positive decimal is the law of the land. Octal, hex, biquinary, 9's compliment, ... do not exist. ;-))
- No one wants to deal with fine pitch and surface mounting.
- Dick showed a diagram of a proposed preliminary interface control box, with:
- - two decimal switches for From Position,
- - two decimal switches for To Position,
- - some function switches, (?once, single internal step, ...?)
- - a pot for command rate
- The announced purpose of the meeting was to consider adding a person (preferably an IBM person, even better a RAMAC person) to construct the interface box to control the RAMAC head positioning.
I (Ed) showed the group the test box designed and constructed by part of the 1401 group to help debug the tape channel and act as multiple tape units if required. I had suggested the three members who did the work in an e-mail to the RAMAC group.
Dick Oswald and Ed Thelen are charged with locating prospects, having them talk with Al Hoagland for project goals and familiarity, and ...
- The defective track position pot can be a show stopper for an authentic simulation of the original RAMAC drive design.
- The students did a table lookup for position set points, but that is not the original system, and should be used only if despirate?
Dick Oswald's design (a reimplementation of the original drive logic) expects the track position pot to be properly functional - and Dick points out that servoing to the end of a position sensing makes a mess out of proper feedback.
Dave Bennet volunteered to work on this quickly.
There is some data on this problem and solution at White Paper.
- More frequent meetings
- "We the group" agreed to meet every other Tuesday to discuss progress/problems toward a goal of producing a "Complete Demo" in 11 months - September 2007.
- a) CHM has other uses for the room currently housing the RAMAC
- b) IBM probably wishes some more action to support lending Al the RAMAC
- c) Without a threatening end date, projects tend to resemble government committees, accomplish lots of talk.
- (OK, I added point c) above.)
The first few months of meeting dates (based on this meeting October 17th) are:
- 2006 - October 31; November 14, 28; December 12, ?26?
- 2007 - January 9, 23; February 6, 20; ...
Al Hoagland suggests that we keep minutes, time and date of next meeting, and get agreement/approval of the minutes of the previous meeting. Possibly e-mail can be used to shorten the cycle of agreement.
- The modern compressor connected to the RAMAC is causing more noise problems than expected. For the September Anniversary, to get the noisy thing out of the demo room, the group asked Dave Dial to get it moved to a little room off the lobby and to get the necessary air plumbing and electric power done -
From Dave Bennet 10/20/2006
|
Hi Team,
I had a very good chat with an engineer at Sensor Systems, heir to the Markite brand, and it is arranged that they will try to restore our track pot. I have an RMA authorization and this man, Willy Culkar, has agreed to be our interface throughout the repair process. He seems most interested in our project and wishes that his firm be identified as a contributor to our ultimate success. I think this is an auspicious start and can only hope that the outcome is as good. I will plan to go to CHM, probably Monday, to remove the pot and send it on its way. BTW I looked at the pot on the proto machine at Almaden and it is similar but not identical in physical form so that its use would be more of a last resort than a preferred path. Dave |
Letter from Dick Oswald, Oct 25
It should be possible to make the track pot work without the 80 tap, but the hardware
implementation would be complex and the track location accuracy will suffer significantly.
The way I see that might work is to replace the 20 tap resistor string and 20 position
analog multiplexer with a 40 tap resistor string 40 position multiplexer. In addition the 2
end point tap select multiplexer will have to be changed to a 3 and the standard off the
shelf logic parts for decode replaced by a special custom programmable CPLD to
accomodate the exceptions needed to then access tracks 60 through 100; (it is greatly
complicated by 100 not being integer divisible by 40 as it is with 20).
This in its self would
degrade precision by something more than a factor of 2 just from the larger resistor ratio
but the excitation voltage headroom limits will also reduce the allowable volts per track
scale factor by 2 and increase the max source resistance by a factor of 2. The net result
will be a reduction in accuracy of at least a factor of 4 and probably more like 6 or 7 at track
80 compared with the max at tracks 10, 30, 50--with the regular configuration using all
taps.
I don't know the linearity of our particular pot and thus what the track position error
budget actually is, but I suspect it is already near the about +/- 3/4 track out of 20 that
would be the usefull limits of the odd-even dual pitch rack hardware in good adjustment.
Its not like a track following servo where the pitch error would gradually change with track
number in the problem range and thus be tolerable, but rather when the absolute error
reaches a threshold, the detent will be 2 tracks off (if it even settles at the critical error)
and would probably make the selection of tracks between 70 and 90 very questionable
unless some kind of position check through the read channel, adjust and retry routine
were added.
The other possible way I can visualize to correct the track positions to detent centers is
to add a lookup table with an entry per track that would generate a correction of the null
locations with a DAC. But this requires addition of at least a non-volatile (probably flash)
memory and memory access logic which require a lot of extra parts and design effort.
Regarding another issue, is the moulded plastic on the pot really required and the only
way to get the structural integrity needed, or could an alternative mounting method and
flexible cable be used on a repaired pot? It would no longer be exactly original in
appearance, but without a "before" and "after" reference it would probably not be noticed,
and all the taps working is quite important for proper function and this would save a lot
of design and construction time in the electronics.
Dick Oswald
dickoswald@ieee.org or
doswald@psdc.com
Meeting Notes of Tuesday, October 31
The RAMAC track pot, which had been removed from the RAMAC,
was physically presented and discussed as follows
More on the RAMAC track pot - there are several possible
trades/comparisons.
And around the table we go -
We talked about the wave forms/protocol on the disk. Prreviously we had
thought about using a UART, but there is no "stop bit" that UARTs
expect - if there is no stop bit, the UART reports a framing error
and will likely get confused.
There is the thought that after the current data on the
disk is recovered, we can use any format we wish -
and adding a stop bit to the protocol might be a
reasonable idea.
There was a discussion of basic head alignment, top vs bottom head alignment -
Dave Bennet has some Beta video tapes of IBM history,
He *does not* want to do two designs and/or change designs in mid stream.
Dick wishes to attain about half track capability to minimize detent impact and wear.
Dick has purchased plenty of 5 volt logic (0.1 inch centers) from Mouser.
Mechanical Help - Grant Saviers still in South Pacific.
Electrical construction - the prospect would rather design than construct other's design.
If you have comments or suggestions, Send e-mail
to Ed Thelen
From: D Oswald [sdroswald@sbcglobal.net]
Sent: Wednesday, October 25, 2006 8:30 AM
To: Dick Oswald
Subject: Track pot
Present were Al Hoagland, Joe Feng, Dave Bennett, Dick Oswald, Ed Thelen.
The rubbery potting compound which contains
the leads was examined in detail.
Ed showed a disassembled cermet and a disassembled wirewound poteometer to give practical examples.
We all agree that if the missing
tap on the pot is broken at the presumed wirewound resistor of the pot, the required
spotweld would be "interesting".
cermet
wirewound
Al Hoagland
Last meeting we wanted a "total demo" in September. That means that we need to be ready a month
ahead of time (late June) and have papers and reports published and ready to distribute,
and well as head seeking and correct data channel (I/O) activity.
Joe Feng
- 10& of the RAMAC disk magnetic wave forms have been captured
- he has a couple of programs to convert the wave forms to BCD
- two basic conversion/detection schemes
Dave Bennet
- had 6 more copies of the 305 Reference Manual made by IBM Almaden. It is also on the website
here IBM-305-227-3533-1-mostlyRAMAC-CE-RefMan.pdf .
- currently having 6 more copies of the 305 Manual of Instruction made, also at IBM Almaden.
It is also on the website
here IBM-227-3534-0-305-RAMAC-r.pdf .
- The noisy compressor situation
He got a Beta VCR via e-bay from some guy in L.A.
He is now looking for another Beta VCR.
Dick Oswald
Drawing about complete - but wants a good determination of the capability
of the Disk Potentiometer. If the track 80 wire is not working, much more
logic to work around the defect, and about half the current accuracy of
head seeking.
Ed Thelen
Lots of documents on web site. If you know of others,
please let me know so that I can add it.