I had to prepare a notch in the front lip of the pedestal enclosure, as the plexiglass panel has a plastic tab I epoxied earlier that is threatening to come loose and tear away part of the coloring and labeling. It is near the bottom right side of the panel, where there is more than just a simple black background. It would be almost impossible to repair the painted section adequately if it were to finish tearing off.
I cut the notch so the plastic tab can slide into the enclosure without having any force exerted upon it. I have to prepare the edge of the notch a bit still. The most critical remaining task is to drill partial holds in the plexiglass panel, glue acrylic rods in place, which will fit through holes in the enclosure lip and be fastened from inside.
The stands on the pedestal are a bit flexible due to the thin gauge steel I used to form them. I fashioned wooden supports that fit inside, leaving enough room for the signal and power cables but ensuring a rigid posture for the pedestal. The pedestal is standing high enough to fit the typewriter mechanism in place while testing. The wood will be underneath the table top when the machine is fully assembled.
I am still not sure how to properly attach the two side plates which hold the mode switch and emergency pull knob. I am epoxying a nut onto the back of the mode switch plate which I hope will allow me to secure the plate to a metal 'ell' screwed into the bottom of the pedestal box. I will need more than this if I want to keep the plate from rotating or tilting, but the first step is to assess the strength of an epoxied nut on the steel plate backside.
EXPLOIT NEW ALDS FROM TNMOC TO COMPLETE 1130 LOGIC
I captured imaged of most of the pages of the logic diagrams at the museum, as each serial number has some variation that exposes a bit more of the full design of the 1130. Individual machines only include logic for features and peripherals they have configured, which requires triangulation among multiple sets of ALDs before I could create the system configuration I wished.
This machine the Storage Access Channel feature, used to connect the 1133 box and many peripherals such as 2310, 1403, 2250 or 2420. While I don't yet have the diagrams for the 1133 itself and the features inside, the SAC is the programmatic and electronic interface to the 1130 proper and was essential to build if I wished to link devices emulating 1403, 2420 and 2310.
I went through and improved the way I supported different configurations. I was using various signals that were assigned in the top level 'backplane' module to configure the system, but I now use VHDL generics at the top of the module, of the form ConfigXXX, then check whether that was set as 0 or 1 to activate functionality deep down in each virtual SLT card.
I wrapped up the trip by verifying that I could get a clean synthesis of every valid combination of peripheral configuration but still will have to verify that the omitted devices don't cause unintended cycle steal or interrupt activation.
As well, I am checking signal connections and completeness, very important for the I/O device testing and overall system debugging ahead, where failure to link a cycle steal, interrupt or data movement line could leave the system vulnerable to plenty of bad behavior when it is running more complex work with multiple devices.
All this coding and checking was a perfect diversion during an 11 hour flight back from London to Los Angeles. Once through with that, I refined my Documation card reader adapter logic and started on the HP line printer adapter logic that will cause the HP printer to appear to be a 1403. Some of the functionality for the printer will be implemented in an Arduino controller that provides the 1403 operator interface and its carriage control tape.
I spent some time debugging the new configurabilty approach, finding and correcting any cases where an omitted peripheral leaves a cycle steal or interrupt line undriven. Because the activation lines are inverted logic in the 1130, a logical 0 for the line (default status for an undriven signal) activates the corresponding function. I also did some basic tests to ensure that the 1130 itself is still operating correctly after the adjustments I made to several modules.
DOCUMATION ADAPTER TESTING
I replaced the serial links for the Documation card reader with the token ring cables and took the time to document the connections well. Since the adapter electronics comprise two boxes, six cables, a restored 2501 light/button panel and two power connections, it may not be the most obvious unit to hook up if I try it months from now.
I first had to double check the serial link logic in the fpga adapter module, to be sure I was reading or writing the appropriate signals, before I could power up and begin validating signal integrity and then function. As I looked that over, it became clear that I could clean this up by reassigning signals across the two boxes.
One box uses my "outputs" board, which uses an MCP23017 multiplexor chip and is designed so that each of the 16 bits of a chip can deliver a logic level signal output, a power transistor output or a DPDT relay output. They can also be used as an input but this is suboptimal. The other box uses my "input" board which can have one or two MCP23017 and is primarily intended to debounce and sense the state of up to 32 input signals, but some of those could be used as outputs.
My inputs board has one output, to drive the "pick" signal that triggers reading by the Documation, with a auxilliary board with a power transistor to handle the current for the pick signal, otherwise it is delivering the 12 card columns, index pulse, and status signals (busy, ready, mock, hopper and error). My output board has an auxiliary board with debouncers to support the three pushbuttons on the 2501 panel (start, stop and npro). Both boards have open assignments, thus there is no need for the complications of mixing read and write in the same multiplexor chip and board type.
I am going to reroute the three buttons over to the inputs board and reroute the pick signal over to the outputs board. This will allow me to only do reading on two MCP chips of the input board and only do writing for the third MCP chip that is on the outputs board. I added another cable to run between the two boxes.
The documentation I had was inadequate, requiring a couple of hours to reconstruct what I had done. This won't do. I invested more time writing up everything. The last action I took on Saturday was to wire up the long cables (token ring cable type used) that are the peripheral connections of the card reader to the 1130 proper. One cable carries the two wires of the I2C serial link, a reset line and ground. The other cable carries 5 and 3.3 volt power for the adapter electronics.
The next step is to go through the Documation card reader adapter logic in the fpga, ensuring that the I2C protocol is correct to read inputs from two MCP23017 chips and write control signals and light lamps through the third chip. I have all the signals listed against the chip and port they are wired to, except that I didn't choose to open up the debouncer auxiliary board for my three buttons - Start, Stop and NPRO - to look at which output wire relates to each input. I may have to swap signals in fpga logic based on which of the ports are activated by each button.
Properly armed with good documentation, I updated the serial line state machine and related logic to read from the two chips and write my eight output signals to the third chip. It appears correct but live testing will be necessary to validate that I am able to read the correct signals and activate the lamps and controls for the card reader. I am delaying this test in order to get the display pedestal and the typewriter wired up at the same time. I can then do a more comprehensive test suite and eventually, if it seems that the logic is sound, hook in the Documation reader itself.
HP LINE PRINTER INTERFACING AS A VIRTUAL 1403
I have no logic diagrams for 1130 systems using 1403 printers nor do I have logic diagrams of the 1133 unit that contains its adapter logic, but I am fortunate in that it attaches by means of a 360 channel that is implemented in the 1133. The interface between the 1130 Storage Access Channel (SAC) logic which I do have implemented, and the 360 channel in the 1133, is easy to work out. The 360 channels are well documented in other places and the aspects I need for this project are pretty basic.
Thus, my 1403 adapter logic only has to tie to the SAC but it has no need to deal with any of the details of the 1403 printer mechanism. The SAC and 360 channel simply pass the XIO command and fields of the IOCCs to me and in turn I pass on data, status words (DSW) and interrupt/cycle steal requests. 1130 documentation lists the contents of those XIO, IOCC, and DSW fields when used with a 1403.
I will modularize this, since the same SAC is used to speak with tape drives, additional 2310 or 2311 disk drives, and potentially other peripherals which know how to 'speak 360 channel'. The 360 channel emulator will handle the specific timing needed to recognize when XIO or data is coming form the 1130 and to trigger reception of DSW, data and interrupt requests. The 2250 graphics terminal does not use the 360 channel function of the 1133, instead uses the SAC more directly, but I can map any emulation I do into the appropriate 360 channel actions in order to use my module.
Another module that emulates 1403 will speak to my 360 channel emulator. It will see the SAC device call from my channel adapter, match the area code sent to its assigned number (decimal 21 is used for the printer on an 1130), then latch in the IOCC command, modifier and address values. It then processes the valid commands such as Control, used for single line spacing, Initiate Write, used for printing a line, and Write which initiates a carriage skip operation.
MODIFICATION NEEDED FOR DOCUMATION READER
There are some changes I need to make inside the reader in support of my usage as an emulated 2501 device. The three changes are 1) remote activation of the reset button, 2) remote activation of the stop button, and 3) altering the error checking logic of the machine to permit the reading of cards with a diagonal notch on the right side.
The action necessary to make the reader 'ready' after any error conditions are cleared up is to push the 'reset' button on the Documation control panel. I can remotely activate a reset by inserting a relay into the wires coming from the switch. When the relay is activated, it will swap the connections to match what the machine would see if the physical reset button was depressed. The relay is mounted on my 'outputs' board in the black adapter box, with the wires running through a cable with a DB9 connector I am adding to the back of the reader.
 |
| Modification points to remotely "push" documation buttons |
The Documation does error checking at times equal to columns 0, 81 and 84 of a punched card, as a way of verifying that the photocells are working correctly and that the card is moving properly through the machine. If, at column 0, any photocell detects a lamp, it produces an error. If, at column 81, any photocell sees a lamp, it is also an error. finally, at column 84, the edge of the card should have passed and any photocell that does NOT see a lamp indicates an error.
 |
| Error checking logic in Documation reader |
 |
| Wired OR used to build 'one light' signal for col 0 and 81 error checking |
What will work is an open collector NOR gate, which will inject the error only for the case where it is not column 81 and the inverted photocell signal is off (e.g. it is on due to light shining on it). A 7433 is the ideal chip, although it may be hard to find; if so, there are other ways I can produce the intended results with about the same one-gate delay as the inverter I will be replacing.
No comments:
Post a Comment