Mystery IC: Allen Bradley 314B102
Paul Berger
phb.hfx at gmail.com
Fri Dec 18 15:42:32 CST 2015
On 2015-12-18 5:00 PM, Brent Hilpert wrote:
> On 2015-Dec-16, at 10:26 PM, Mike Ross wrote:
>> On Wed, Dec 16, 2015 at 8:01 PM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
>>> First crack can be picked up here:
>>> http://www.cs.ubc.ca/~hilpert/tmp/WIOSelectric.pdf
>>>
>>> There are a few areas and pins I couldn't discern from the photos.
>>> Mostly around U1 & U6 as the lens angle and lighting is hiding some connections around those.
>>> If you take another photo or check some of the connections marked in red I can update the schematic.
>>>
>>> I've labeled the host interface connections as per the most likely scenario:
>>> D0-D6: in correspondence to the 'normal' PROM addressing, so D0 is likely the ASCII LSB.
>>> nSTB: this should be the print-strobe input, looks like active-low.
>>> BUSY/RDY: haven't examined the logic enough to say whether this active-high or -low for whichever way one chooses to interpret it - BUSY / READY / ACK.
>> Amazing work Brent!
>>
>> I've wired the thing up in accordance with your schematics and here
>> are the results:
>>
>> On power-up the line we believe is Strobe is high; all others are low
>> - and I'm monitoring the printer side of the interface here.
>>
>> I cat file.name > /dev/lp0
>>
>> The printer prints a character; Linux is waiting. The line we presume
>> to be Busy/Ready flickers briefly high as it is printed.
>>
>> I toggle the local/com switch from com to local and back to com:
>> another character is printed. Linux waits. I can sometimes continue
>> this process one character at a time by toggling the local/com switch.
>> At other times toggling the switch sends Linux straight back to the
>> command prompt.
>>
>> The characters printed are pretty exclusively semicolons underscores and 8s.
>>
>> The carriage never advances; all characters are printed at the same spot.
>>
>> Further observations:
>>
>> - If I initiate the print with the Strobe line disconnected Linux
>> returns to the command prompt instantly and nothing is printed.
>> - If I disconnect the Strobe line after printing has started Linux
>> returns to the command prompt instantly after the com/local switch is
>> cycled
>> - If I disconnect the Busy line prior to starting to print nothing is
>> printed until I connect the Busy line
>> - If I print a character by cycling the local/com switch with the Busy
>> line disconnected a *second* character is printed when I reconnect it.
>> - Busy flickers high every time a character is printed. The status of
>> the Strobe line never visibly changes; it always appears high. Might
>> put a scope on those...
>>
>> There's clearly something funky going on with signaling - timing or
>> active high vs. active low. At no time does the printer *ever* print
>> more than one character without some manual intervention.
> Hard to say from this distance what's going on, with all the unknowns involved (lack of familiarity with the selectric mech, the connections to the selectric mech, the intervening drivers, etc.)
> I take it you mean you simply cross-connected directly to a standard parallel port.
>
> Just some thoughts/suggestions:
> - If the strobe pulse can't be seen (visually) perhaps it's too fast for the requirements of the mechanism/interface.
>
> - When the cat returns, perhaps Linux is seeing the interface as continuously ready (or ready too quickly)
> and dumps the the data out at far too high a rate.
>
> - Try doing all the signalling manually: set up a character on the data lines by connecting to gnd,
> then manually take the nSTB line to gnd.
> Try both printing characters and controls like CR & LF.
>
> - I notice there is one line from the proms that feeds back into the strobe/busy logic. I wonder if that might be
> distinguishing printing operations from control operations and setting up different ready/busy indication.
>
> - Perhaps this interface needs some tailored semantics, like a throttled character rate, or the data lines have to
> transition to all low or all high between each character/operation.
>
> Can someone with experience answer a couple questions about the raw selectric mechanism interface?
>
> - How many signals (solenoids/magnets) are there for the tilt/rotate/operation selection?
> I take it the parameters are:
> tilt: 4 values,
> rotate: 11 values (-5 thru +5)
> plus shift to rotate the ball 180 degrees,
> but how is that actually set up or apportioned on the T/R/O solenoids?
>
> - Does the selectric mechanism print a character immediately upon the T/R/O selection being set up (in parallel) on the solenoids,
> or does one set up the T/R/O on the solenoids and then trigger another solenoid to initiate the action?
>
There are 7 only 6 are actually used to select the character the 7th is
to maintain odd parity check contacts below the selection mechanism are
wired so that the signal goes true when an odd number of magnets are
picked, I don't remember the polarity of the signal off the top of my
head, but I doubt this adapter checks them. Of the 6 that are actually
used to select the character, two are for tilt (T1 and T2) three for
positive rotate (+1, +2 and +2A) and one for negative rotate (-5).
There are also two magnets for shift shift up and shift down, one each
for functions installed up to four: Tab, Carriage Return, Line Feed,
and Back Space ( not all typers have all the functions installed) and
finally there is a magnet to release the cycle clutch. The basic
operation is pick the selection magnets and then the cycle clutch feed
back contacts tell you when you can release the magnet and set up the
next character, properly timed you can have it print at full speed
without the cycle clutch latching up, but that is hard on the mechanics
they seem to survive better at a slower speed.
The shift magnets operate on their own releasing the shift clutch to
make a half turn to rotate the ball 180 degrees.
The function magnets release a clutched cam on the operational shaft the
initiates their function, there are also feedback contacts for these
functions and for shift.
Paul
More information about the cctech
mailing list