During the trip, I did some thinking about the approach I was taking to implement a monovelocity behavior for the Memory typewriter mechanism, in order to avoid the light strikes inappropriately used with some letters (e.g. E and K) because they sit in the location on the typeball that are used for punctuation on ordinary typewriter (correspondence) format type elements.
I need to recognize when the no-print solenoid is being activated by the typewriter logic board and cause the low-velocity solenoid to be simultaneously activated. This is because a no-print cycle requires BOTH solenoids to be activated; I can't simply disable the low-velocity solenoid or the typewriter will print unintended characters instead of spaces, tabs and other nonprinting actions. My first approach removed both low-velocity and no-print solenoids from logic board control, counted on the no-print line from the logic board to be driven down to ground when it wanted an activation otherwise floating at 24V.
This first approach was not reliable. While I have not had the chance to measure the actual behavior, I suspect that it needs the solenoid or an equivalent resistance in order to work correctly. Since I do want the no-print solenoid to fire, it can be left attached to the logic board. In this case, the logic board will really be controlling that solenoid. My circuit just has to recognize when the no-print solenoid is firing and drive the low-velocity solenoid at the same time.
I have a reliable means of sensing the activation of solenoids by the logic board, used to detect use of the carrier return, index and other solenoids. I will use the same approach to drive my circuit, so that when the no-print turn-on is detected, I immediately pull the line from the low-velocity solenoid down to ground which fires it. I thought through various options for the circuitry to put on my mini-board - schmitt trigger versus simple drive of the power transistor, for example - before I settled on my new circuit.
Ultimately, I used a simple pair of transistors, the first inverting the sense of the signal since the solenoid is fired by pulling its line down to ground, else it is at +24V. When the logic board pulls the no-print solenoid to ground, I want to simultaneously pull the low-velocity solenoid to ground, otherwise let it float to +24V the same as the logic board would have done. I am ignoring the logic board signal to fire the low-velocity solenoid, instead causing low-velocity to always mirror no-print.
I wanted to drop the voltage coming from the logic board to the no-print solenoid to a safe voltage by a divider network. My circuit uses the lowered level to fire the first transistor whenever the solenoid is off, buts shuts off the transistor when the solenoid is activated by the logic board grounding the no-print line.
I built another voltage divider to bring the typewriter's +24V supply voltage down to a safe level for the second transistor base; my first transistor will pull that base level down to ground. Thus, when the first transistor is conducting, it holds the second transistor off. The second transistor is hooked to the low-velocity solenoid, pulling it down to ground when the transistor is conducting.
As the logic board line to no-print goes to ground to fire that solenoid, it releases the first transistor, which in turn stops pulling the second transistor base down to ground. With the second transistor base free to pull up to my divider voltage, the second transistor fires and pulls the low-velocity solenoid down to ground, exactly the way that the logic board would have done things if I left it connected.
Since the low-velocity line from the logic board is no unconnected, if the logic board tries to type a character with low velocity, it has no effect. If it had been left connected, it would result in only the low-velocity solenoid firing, which causes a light typed impression. Since it takes both solenoids to block the typing of a character entirely, I needed to mirror the no-print solenoid action to the low-velocity solenoid to give me the desired blank space on the paper.
Everything was designed and parts values were selected during my trip, to allow me to quickly wire it together when I returned home. I soldered it up and began testing. I uncovered a mistake in the board, corrected it and prepared to test another time.
In parallel, I had looked at the main logic board (planar board in IBM parlance) and satisfied myself that the no-print control line, which pulls the solenoid to ground to fire it, could easily handle both solenoids. Thus, I moved the two solenoid leads to the one logic board output for no-print and tested.
This worked just fine, without a need for a separate circuit board. I ran tests to confirm that this printed all characters with high velocity and handled non-printing operations correctly. With this test, the console printer adapter logic and hardware is complete. I can move on to the physical enclosure and mounting of that 1053-like box onto the 1130 frame.
DISPLAY PEDESTAL COMPLETION
The link to the electronics in the pedestal box continues to cause problems due to impedance mismatch on the long cable. The mismatch causes reflections that distort the signals and confuse the gates with phantom signal swings. Part of the problem is caused by the Digilent board I am using. It has two ways to connect to fpga IO pins, the 40 signals on the FX2 connector or a number of "PMOD" connectors they created in order to host simple add-on units, with different impedances.
The PMOD connections have a 200 ohm resistor in series, placed there to protect the fpga from short circuits. The FX2 lines have a 75 ohm resistor in series. Connecting a typical coaxial line at 50 ohms characteristic impedance, similar to many ribbon cable and I2C cables, guarantees a substantial mismatch for the PMOD. The FX2 line is barely adequate at 75 ohms, which does not include the actual source impedance of the fpga output, making the actual driving impedance even higher.
The PMOD lines are hopelessly mismatched being well above 200 ohms actual impedance feeding into a 50 ohm transmission line. I am not happy even with the FX2 lines, but if I were to rely solely on the FX2 connections I would lose 28 input-output lines that are only accessible by PMOD connectors JA, JB, JC and JD on the board, meaning I need a solution for both types of connectors.
I found a reasonable cable that should resolve the mismatch problems for the several fast serial links I employ throughout the 1130. IBM's token ring networking was designed around 150 ohm cabling, which is perfectly suitable for my purposes. I bought 900' on ebay at a low price and had it in hand when I returned.
I wired up a length of the new cable between the display pedestal control board and the fpga extension board where the signals originate. The cable is rock solid and reliable now. The display is solid, free of flickers and starts up correctly from a system reset every time.
I did discover that somehow I have the assignment of signals to lamps swapped around a bit. I could see the low order eight bits of the IAR, SAR and ACC accurately reflecting the state of the 1130 as I stepped through some code. However, the clock states X0 to X7 are displaying in the spot that should show the high order eight bits of the IAR. At first blush, it seems I have cabled the LED control board in reverse order, plugging the right hand panel into the socket for the left hand panel, with the middle panel the only correct one at this point. The middle panel displays the low order eight bits of the six major registers IAR, SAR, SBR, AFR, ACC and EXT.
It was quite difficult to get the cabling put into place and secured with cable ties, causing the most straightforward solution to be distastefully difficult. However, I can more readily swap the panels logically, by changing the bit stream I emit from the panel driver logic. I will do this before retesting.
I will additionally use of one of the buttons on the fpga board temporarily to act as a lamp test function. This is not straightforward since the physical lamptest button is supported by the I2C link which is not active at this point in my testing. Thus, the lamptest signal is not visible at the backplane level of my logic where I would normally tie it to an fpga board button. I choose to make use of a spare bit on the Status lines that are driving my display board, hooking button 2 to that bit which is tied to the lamptest line on the display module.
I swapped the signals in the display driver logic module to adjust for the way I have cabled the physical panel modules to the control board. I ran a functional test to verify that all the lamps work, are hooked up correctly, and the cabling is intact. There are still problems to work out.
Firstly, the lamp test shows that the left panel, rows 2, 3 and 4 are not lighting, nor is the right panel in a few spots. These are likely caused by disconnected wiring, but could be shorts in the panels. Secondly, the sixth row, which is the accumulator extension register, has some lights displaying that are undoubtedly intended to be the lamps on the main black plate (e.g. Run, Disk Unlock, or File Ready).
I suspect that the black plate lamp signals can be swapped with some simple changes to the panel driver logic module in the fpga. I believe I will have to do some direct testing of the panels with an ohmmeter to diagnose and repair the sections that do not light with the lamptest button.
The LEDs are quite bright, almost too bright without the plexiglass panel installed. However, that means that I will have a very acceptable and easily viewed display panel when it is all closed up.
I have run out of time this weekend to test any further, but will have time during next week and weekend to wrap this up. As well, I can re-cable all the other serial links using my new 150 ohm cable that permits me to match the transmission line appropriately for reliable signalling.
TEST GEAR ADDITION - STORAGE SCOPE
I picked up a Tektronix storage oscilloscope on ebay, model 466 which is 100MHz, dual channel with analog storage. I keep encountering situations where the analog circuit issues need investigating, which is easy to do with regularly clocked signals using my regular scope, but for sporadic or one-time pulses, I really needed to 'snap a picture' when the event occurs. The price was low enough that I picked it up, rather than those portable digital storage scopes at similar prices which are reported to be much less capable. The only advantage those have is portability in a shirt pocket, but if they aren't usable, why transport them?
No comments:
Post a Comment