CONSOLE PRINTER
Today I dug deeply into the logic for the keyboard interface. There is a large lookup from the 1130 character code (selectric tilt/rotate code for 1130 custom typeball) to yield the Electronic Typewriter equivalent printed character. I redesigned the movement portion of the logic, which is much more direct and clean now. Startup logic was needed to move the carriage to the left margin of the typewriter, as we won't necessarily know where it is along the platen when we begin. A complication is handled wherein the 1130 thinks the typeball is already in the proper shift case for the next character but our typeball and mapping requires us to shift the ET50 ball to print the same character - a hidden cycle.
Debugging proceeded reasonably well using the logic analyzer and Arduino as the standin for the typewriter. I discovered a number of flaws and combination conditions, corrected them, and continued testing. The 1130 adapter logic worked well, even forcing an automatic carriage return and line feed when I incorrectly raised the End of Line signal.
It is one of the interesting artifacts of the emulation that in some cases the typeball will spin both ways before printing a character. The 1130 adapter logic is 'shadowing' the state of the typeball, either upper case or lower case, so that it can issue a shift command prior to any character that is on the other side of the ball from its current rotation.
Some characters that are on one side of the 1130 typeball are placed on the other side of the ET50 typeball, thus the adapter may decide that printing a particular character requires rotating to upper case position, it moves the ball, then it sends the codes for the particular character. Our emulation routine does not see the particular character that will be typed when it is commanded to shift - all it gets is the shift command from the adapter. Thus, we have to first obey the adapter, then translate the character, and if we now need to shift the ball we take a hidden shift cycle before printing.
The adapter shifts the ball, we translate, we shift back, then we print - the ball will spin one way, then the other, then strike. Fortunately, most cases will be on the same side as the 1130 typeball, thus whatever shift was commanded by the adapter is the correct state for our printing and we needn't do another shift. It will, however, cause some timing differences for programs as the number of selectric print cycles will be slightly different on our machine due to additional shifts introduced by typeball differences.
I have a phantom race condition on startup, based on the order of assignment of logic to fpga cells, that in certain loads the typewriter starts up indicating it is over at the end of line, while other loads of the fpga will repeatedly start with the typewriter at the beginning of the line. I still haven't worked out a good solution to this - it is the interaction of various independent state machines and processes that causes the problems.
I may need to provide a more guaranteed handshake protocol between certain parts of the design, but at least three of them are fairly asynchronous - the carrier movement, the incoming emitter pulses recording positional changes, and the print cycle that spins the mechanism through a 360 degree action. Since the emitter pulses are changing the position along the print line, while the movement logic may be commanding forward or backward movements, there is some opportunity for race hazards and unstable signals being used to drive state machine changes. In addition, the print cycle is what kicks off the beginning of the physical movement (but ends well before most movements will be complete), thus this too may expose unstable signal values at key decision times. It is possible I may do a partial redesign of the basic structure of this logic, if I don't feel good about the condition after some more debugging and tweaking.
Once I have the basic typing and carriage returns working, I will shoot a short video of the typewriter in operation driven by the fpga 1130. Remaining to debug are additional functionality for realism, such as tabbing, tab set and clear, margin sets and the startup logic that places the carrier at the left margin, but once the essence of the interface is working properly, the remainder shouldn't be too difficult to finish off.
UPDATED 1130 LOGIC CIRCUITS
I made the decision to add in some timing changes that are in the 1130 "B" machine ALDs on bitsavers, which is a full speed more complete machine than the 1130 "C" for which I had all the ALDs. The "B" machine is missing all the ALD pages before KA101, which is why I didn't attempt to design from it, but the only areas that have caused me to debug tight timing issues and to modify the IBM logic slightly were related to timing similar to the changes I saw in the B machine to accommodate the faster memory cycle time (which I have been modeling all along). A few signals are delayed and in a couple of places they had to anticipate the state of a signal to make that condition available earlier than the real signal is generated.
I then had a bit of cleanup testing - I forgot to update the interconnection to one of the modified 'boards' which lead to the machine hanging at the end of an instruction. Once it was found and fixed, I have another issue where the CCC register (cycle control counter, used to control variable execution length instructions such as shifts but also to manage basic end of instruction detection) is being loaded with incorrect values.
Since I implemented a signal that gates the contents of the memory register (B reg) to CCC, with the name GateBtoCCCAdvanced, it is either occuring TOO early now or some other signal I had delayed in prior tweaks is now arriving too late. After some single step mode debugging on the 'console' of the 1130, I discovered the CCC was being set in T3, not the time this should occur, at it was a result of the Advanced signal I began using. It may be working well for loading the CCC with a shift count for the appropriate shift instructions, but it is also triggering a load in non-shift instructions at T3 which is BAD.
After some investigation into the logic, I found several errors in my implementation of the new card MB341 that produces the advanced signal causing the problems. It checks for the version of the shift instruction driven by a user provided count, which it then gates into the CCC. The logic checked for an op code of the form 0001x because shift right and shift left are 00010 and 00011. I was checking for 0000x instead, plus I inverted the logic at another point, causing it to assert the signal at the wrong time and in the wrong conditions. Fixed it and the advanced signals work well now.
KEYBOARD
I wired up the cables to and between the keyboard interface cards and ran some tests of its operation. The channels I tested in my quick trial are switching reliably and definitively. They are sensitive to ambient light when the keyboard mechanism is exposed, but once covered that is not a problem. I will walk through each channel in the dark tonight to validate the full correct operation of the new design, then fire up the link to the fpga and verify that the logic is decoding these correctly.
Once this is working into the fpga, I need to debug the keyboard adapter logic in the fpga, both my translation circuitry that maps keypresses to the 029 keypunch switch outputs and the logic in the 1130 that would be wired to the 029 keyboard.
I installed the auxiliary card on the frame behind the keys and will probably install the fpga next to it, extending rearwards off the left of the frame. It will be a convenient location just in front of and below the console typewriter, close to where the LED light panel cables come down from the pedestal and other connections get made. where they will sit in the final machine implementation. I have about 13" from the REST KB key back to the faceplate of the console printer, which allows plenty of room to house the boards and cabling.
CARD PUNCH (CHILLER)
I ordered the quick disconnect hose connectors, the Propylene Glycol coolant and the twist lock power connector, once I have them in hand I will give the unit a try. If it works okay the next step is to make fittings to route the coolant through the punch head, replacing the ammonia cooling system it now has.
It provides status via an RS232 link, which I will activate to monitor the temperature and other status of the cooling system, hooking it into the fpga for use with the card punch interface logic. Power required is 12V at 8A, which is easily supplied by an old PC ATX power supply. I had a spare one, which I set up to provide only 12V, which should be easy work given its capacity to power two 12V channels of 16A each.
The parts are all in hand. Without a liquid loop, but powered on, the unit passes its internal tests and is running its pump. I couldn't leave it on for more than a few seconds because the inlet and outlet are not connected, but generally things look good. Later I will create a closed loop of hose and fire it up to test circulation and perhaps trivial heat removal if I dunk the hose in hot water.
MAG TAPE DRIVE
The IBM 9348 tape drive, a 9 track tape reel based drive, arrived years ago very banged up due to inadequate packing by an ebay seller. I had deferred opening it up to catalog the damage, but began that process this weekend. To my surprise, the only internal parts that were affected at all by the twisted frame and dented in back and sides was the printed circuit card holding the SCSI connectors at the rear. It is a testament to how well this is built that the damage was almost exclusively to the outer skins - the 'tabletop' option for this drive that can alternatively be mounted in a rack.
The printed circuit card was bowed in an arc of about 45 degrees, but it appears unbroken in spite of this severe mistreatment. None of the circuit traces were broken, the multilayer board just seems to have bent, and all the installed chips and other components seem fine as well. I will remove the outer skin, straighten it as much as possible and reassemble, meanwhile I ran a quick status check by powering this up. The firmware reported successful completion of power on self test and good status. I put in a new blank tape I own, but it failed when trying to load, status E033. I did a drive test and it failed with error 60, drive lost tape tension. I did hear an odd sound as it detected the error. I will have to run some more detailed diagnostics built into the drive and look for the cause, to see if I can repair it without buying replacement parts.
After cleaning the tension arm again, the tape loaded fine a few times. I moved on to running a checkout diagnostic that would write data on the tape then read it back to verify correct operation. This test fails with error 5F. The most likely cause is dirty tape or dirty drive, corrected by cleaning the transport area. While I did some cleaning, I didn't have the TCE, similar to dry cleaning fluid, that is recommended. The manual explicitly warns against using isopropyl alcohol as it can damage rubber parts and the tape head. I may also have a bad tape that has deteriorated since manufacturing, but I should see signs of flaking when I inspect the transport further.
This tape drive sits on a differential SCSI channel and contains quite a bit of what IBM calls Licensed Internal Code in the controller and other logic circuits. IBM contracts and policies forbid reverse assembly or other actions, which greatly constrains what I can legally do with the drive. If I can make use of it by driving commands to the fully unmodified unit, or if I can totally replace all the IBM electronics with my own design, I would avoid the issue of the LIC entirely. The latter case is a huge effort and not justified for this project. I need to get a programming manual to learn more about the commands and responses defined for use of this drive, to evaluate the feasibility of using it without any modifications.
I will defer any further work on the tape until I am sure I know that I can interface to this and know how to control it, at which point I will get TCE, clean the heads and transport well and test out access from a computer to validate everything. If it passes all that, I will begin designing and testing an interface.
TERMINATOR BOARD
I began to cut the outlines for the terminator board to allow it to fit into the disk drive and its backplane connector, using my tabletop scrollsaw. It was a slow process, due to the hardness of the fiberglass in the printed circuit card, with the blade dulling rapidly and then smoking and finally snapping due to heat weakening. It took four of the thin blades to cut the basic outlines of the card. I will look at other blade types that might hold up longer when cutting the fiberglass based boards.
The shaping was a bit rough, which I cleaned up some, then mounted my DEC-style handles on the completed terminator board. A similar board was used to anchor the ribbon cables that would lead from the drive out to my controller/interface box. I have wired that cable card but just cut it to shape and installed the handles. Now that is done, I will protect it with silicon conformal spray and start into a prototype of the controller/interface.
However, my final check of the alignment of the pads, signals and orientations uncovered the fact that my layout for the bottom side of each card was wrong. I spent an hour carefully reviewing everything, redrawing the PCB designs and will produce replacement cards later this week, as these are scrap.
New terminator card produced, using the new double sided card blank that is 6 x 9 allowing me to cut the cards to the exact same size as the other DEC logic boards. The earlier cards were on 6x6 blanks, thus their handles were quite a bit recessed compared to the other cards in the cage. One unanticipated issue - my developer pan wasn't long enough to hold the board! I had an exposed board sitting with only an edge in the developer, the rest propped on the rim of the pan, while I scrambled to dump out the rinse water from my rinse pan. That quickly became both developer pan and rinse pan, using running water to rinse away developer then the long pan for rinsing the etchant later in the process.
I got a very good exposure, nice clean patterns, and am happy with how it etched. Before I drill the holes and begin cutting the outlines for the finger inserts and board edges, I will triple check the signal assignments against the other cards and the backplane. Assuming it is good this time, I can do the remaining steps to complete the terminator card. After completing the checks, I confirm this is a good board and tomorrow I will proceed through the cutting, drilling and assembly steps.
Since I picked up two more RK05 drives, which should arrive Friday and Monday respectively, I also should make two sets of drive to drive cables, each having a PCB on both ends. Four of a connector variant of the terminator board are needed, then I will take a fifth connector type board and run cabling to my own interface/controller. All of these will use 50 wire ribbon cables for the wires coming from the boards. I worked with the terminator board PCB but modified it to remove the resistor network packs and make use of a single 50 pin header to which the 50 wire ribbon cable will plug. The routing is done, images produced, waiting for me to make a PCB from them tomorrow.
MUSEUM WORK
I have collected documentation and have almost everything in hand that I need. The 1403 printer connector and interface logic is still an unknown, but that shouldn't be hard to come by at the CHM on Wednesday.
I now understand the logic family and electrical interface requirements to the 1401. IBM used several families of logic in this generation, one before the SLT I worked with on the 1130, but the bulk of the 1401 uses their CTDL - complementary transistor diode logic - that the rest of the world would call DTL. It is quite similar to the heart of SLT, although the logic diagrams (ALD) have a different format.
There are generally two voltage levels for logic signals - T and U - that are 6V swings around a reference voltage of either ground or -6V. These encompass the use of PNP and NPN based circuits. Knowing the levels, electrical requirements, termination scheme and protocols (minimum thresholds to be considered a valid 1 or 0 in U or T), I can create the level shifting required.
IO is relatively direct in the 1401 and the handshakes and meanings are documented. Physical issues and interaction with other devices are the main design choices I will have to confront. The IO devices connect via a unique 1401 connector that will be hard to duplicate.
I will visit the CHM tomorrow, spend some time talking to the Binghamton museum team about the approach of fpga modeling of ALD circuits. Hopefully I can advise and steer them, with someone local who has decent fpga and electronics design experience doing the bulk of the work.
CARD READER INTERFACE
I installed the outputs and 2501 control panel interface board in a plastic enclosure, along with its debouncer daughter card, wiring that box with the input box from the reader and will further connect it to the 2501 panel once that is reconditioned. Currently it is missing some glass blocks on lights, some switches, and had been spray painted a mustard yellow color.
I had a bad moment as I looked at my 2501 panel, since it had more button positions and lamps than I had designed into my interface. I looked at the pictures from my visit to Bob Rosenbloom's 2501, which matched the buttons and lamps of my panel. I was sure I had to find additional lamp driver, button debouncer and signal input lines, which meant an additional plug on my newly created interface enclosures. Some additional research, however, clarified the situation.
2501 readers came in A and B models - the B models had integrated control units to allow them to be attached to a 360 channel, while the A models had to be cabled to a processor that had an adapter (integrated controller) to manage the reader. The lamps and buttons were different between the A and B types. As a side note, the reader also had two operating speeds - 600 cards per minute and 1000 cpm - which yields four actual models. The A1 and A2, 600cpm and 1000cpm models without an internal controller, are the ones that are used with the 1130 processor as the adapter is built into the 1130 system. Models B1 and B2, 600 and 1000cpm models with integrated controllers, attached to 360 channels. The 360 model 20 used the A1 or A2 model, as it did not feature a full channel like its larger kin.
The adapter logic in the 1130 did not support all the lamps and buttons that were driven by the integrated controller of the 2501 B models. Thus, the A models had just five lamps and three buttons. Attention, Read Check, Feed Check, Ready, and Power indicators plus Start, Stop and NPRO buttons. The B models have additional lamps such as Validity Check and End File, as well as buttons such as End File. My implementation will be true to the A1 model - at 600 cpm it matches the speed of my Documation reader mechanism and the panel will tie to the adapter logic designed for the 1130.
I need to clean up the panel I have, strip off the yellow paint, restore it to black, get the lights and buttons in place, then wire it up. The last step before mounting this into an enclosure holding the documation reader will be to fix any switch or lamp block titles that are incorrect. Fortunately, Acetone seems to quickly strip the bilious yellow coating without removing the original surface, as can be seen in this picture after ten minutes work with a soaked cloth.
I was more worried about the buttons and light blocks, as these are some kind of plastic and might have been damaged by the solvent. Again, fortune smiled on me and I was able to clean the light blocks and buttons without any damage to the original surface or coloring. The only issue remaining is that the white paint used for the lettering on those parts is still stained yellow. I may find a way to remove the stain or apply new white coloring or might just leave it as it is. I am proceeding carefully on the final cleaning but I am simultaneously stripping down and converting the lamp sockets to LED.
At this point, I have a cleaned up panel, wired into the card reader interface boxes and ready to test. The remaining work on this is 1) retitle appropriate lamp cubes to replicate the legends on a 2501 (for the Read Check, Feed Check, Power, and Attention lamps), and 2) install the panel and documation reader in a faux 2501 enclosure. My buttons are all correctly titled. I have some emulation logic to complete and test in the fpga before tying together the 1130, documation, 2501 panel and reading some cards.
No comments:
Post a Comment