6 Dec
2010
6 Dec
'10
9:29 p.m.
On 12/6/2010 7:14 PM, Brent Hilpert wrote:
Yeah, the display works and adjusting the "decimal point" wheel moves
the decimal point on the display. That's about all it does now.
On 2010 Dec 2, at 11:46 PM, Josh Dersch wrote:
Yeah, I'm excited about it. I love Nixie tubes, but this is a very cool
display in its own right :).
Got myself a Friden 1162 desktop calculator.
This is from about
1968-69 and has a neat-O keen CRT display and uses a
magnetorestrictive delay line memory. Kinda cool.
A very neat find, CRT-display calcs of that era are rare compared to
the Nixie-display models. Of all the calcs I have collected, I still
have yet to personally come across a CRT-display one.
Mine has taken a fair amount of abuse over the
years, and is
currently not working properly -- at the moment it powers up (with
nominal voltages, etc) and displays a normal display of all zeros,
but as soon as a key is depressed, the screen goes blank and never
returns.
The 1162 has a rather interesting keyboard encoding mechanism (you
can see a decent overview of the device & the keyboard mechanism
here: http://www.oldcalculatormuseum.com/friden1162.html) Close
investigation of the keyboard mechanism on my specimen reveals that a
few of the plastic "fingers" that are positioned on the rods that
move the magnets to/away from the reed switches have snapped off.
>
> The bad news is that even with the mechanism fixed, the machine still
> exhibits the same problem. I'm wondering if it's the delay line memory
Generally, in such calculators, an operation initiates a state-machine
sequence. Some condition terminates the sequence and returns the
machine to the idle state. The behaviour is suggestive of the
state-machine hanging up somewhere, but that's not very helpful as
there can be a lot in-between sequence start and termination.
Often, all the keys will get OR'ed together to produce a signal which
triggers an 'operation' flip-flop, which is then reset at the end of
the operation. The display working suggests the clock and a lot of the
timing is working.
In my experience:
- you may get lucky and solve the problem in a general cleanup
and inspection of the machine,
- again with luck, a little bit of inspired tracing around
keyboard/operation start/terminate circuitry or timing circuitry
will find the problem,
- you'll need the schematic to track it down in depth,
If you can't obtain the manufacturer's schematic,
reverse-engineering is the option.
My own preference (from multiple experiences) is to do some cleanup
and inspection, and then go straight to reverse-engineering - a long
process but you have some greater surety of eventual success and you
have the schematic for the next time it breaks. Here's my little tale
of the first time I did this:
http://www.cs.ubc.ca/~hilpert/eec/misc/ftf/index.html
That's very cool. I like the idea of building a logic-level
simulation. I'm hoping I won't have to reverse-engineer the whole
thing, but doing it by hand might be a useful experience...
Rick Bensene's writeup suggests the 1162 is an SSI-implementation of
the earlier discrete EC-130. I believe there is more info about the
EC-130 out there, perhaps including the service manual. It may provide
some insight into the 1162.
I'll see if I can track that down as well. I've read through Rick's
stuff a few times -- he's got a good resource for this stuff. I should
bug him and see if he has any info...
The EC-130 (and by extension the 1162) is one I have wanted to RE and
produce a simulation of, both for the vector display and because the
arithmetic technique used is different than most.
There was an EC-132 on eBay just this week, I was really tempted to bid
on it... but I have to fix this one first :).
- Josh