I worked through the wiring, shortening the cabling from the display panels as well as changing to thinner wire gage. After shuffling the logic around in the display driver logic module, I was able to verify that the Extension register is being displayed properly. The black plate signals are no longer visible on the display panel, which is appropriate, but they should be delivered to the black plate via its special cable.
The right hand display panel is the most complex as some of the logical rows of lights are split across different sections of the display. For example, an upper right (2R) row of five lamps displays the flag, tags and modifiers of the instruction while the row of three lamps displaying the index register just below (3R) are combined as a single logical row of 8 lights on the chip. Even more complex, the first row (3L) of six status indicators such as parity and shift control have the carry and overflow lamps from the bottom right (6R) interspersed to form a single logical row on the chip in the pattern AABABAAA. This panel also originates a cable to drive the main black plate lamps such as run and keyboard select.
I was able to clean up a few cold solder joints, get my display logic delivering the right signals to all the rows and lamps, and replace two bad LEDs. Now, all the panels are working correctly and I can finish the physical attachment of everything into the display pedestal enclosure.
I have epoxied the two panel parts together into a single long unit, having arranged the spacing to best fit the front panel. Somehow, my light panels have a spacing of 2.5" between the centers of the end of the T-clock lights and the beginning of the Op Reg lights, but the plexiglass panel with the cutouts through which they shine has the spacing as 2.75". To accommodate this, I have shifted the right hand panel so that the T-clock side lights have the plexiglass cutout to the right side of the lamp while the op-reg side lights have the cutout to the left side of the lamp. Since the lamp opening is wide enough to accommodate this 1/8" displacement, the discrepancy has no effect.
My current plan for mounting the light panels inside the enclosure is to make some L shaped wooden stops that hold the panel from moving backwards and hold it from moving to the side. These stops will be held in place by wood screws coming up through a hole in the bottom of the light pedestal box.
I formed the stops for the light panels and glued them into the L shapes. After predrilling a pilot hole in the wood for the attachment screw, I epoxied these to the sides of the light panel assembly. A short slot will be cut in the bottom of the enclosure under these wood stops, allowing me to affix them with a wood screw and slide the to fine tune the positioning of the panels. This will secure them, aligned with the plexiglass panel they sit behind.
 |
| Display panel assembly sitting inside pedestal enclosure for testing |
I created some wooden supports to sit inside the pedestal stands, giving me a more solid mount for my continuing work until I am ready to permanently mount the pedestal on the 1130 frame. I have a bit more work to form some channels for my cables that run inside the stands, but soon these will be installed and the enclosure much more solid.
 |
| Main black plate with lights on left hooked up for testing |
 |
| Testing configuration running 1130 programs to validate display lights |
I had observed that the lamps are very 'blue-white' in color compared to the yellow cast of the incandescent bulbs used in an IBM built 1130. My solution will be to place a yellow plastic film between the lamps and the plexiglass panel, shifting the hue of the lights sufficiently to appear more realistic.
I made a short video ( Video of display lamp testing ) of the pedestal display lights and the main plate lights operating, by running a small program that normally drives the console typewriter. It loops waiting for a response but without the typewriter powered on, it cycles checking status of the device. I haven't set the proper parity in memory for all of that program yet, which causes it to register parity errors when running. By activating the CE 'parity run' switch, I am allowing it to operate while ignoring the parity errors. At one point at the end, I switch off the parity run switch and the system freezes as it should.
The 1130 is running at the same speed as the IBM built machines and is cycle accurate, with the display lights showing exactly the status that would be seen at every step and phase as the machine runs.
COMPUTER HISTORY MUSEUM ACTIVITY
I visited with the rest of 1401 restoration team briefly on Wednesday, just four days before the opening event of the new exhibition space where the machines will be demonstrated. The four tape drives on the right of the exhibition space, those attached to the CT 1401, were not yet cabled. I worked with some of the team locating and stringing the cables between the drives, including putting the proper floor tiles with cutouts underneath each drive.
The 1402 card reader on the DE 1401 is getting read check errors, indicating that the holes being read by the first set of brushes don't match the pattern sensed by the second set. A 1402 expert was working on this, without a resolution as of 4PM when I left the museum. One of the tape drives on the CT 1401 would not load tape - it didn't sound as if it were starting the vacuum pump. That could be any number of issues, beginning with faulty switches that indicate the capstan roller is retracted all the way, through various electronic circuits and up to the pump and vacuum system itself. This will have to be debugged further on a future date, as we ran out of time to dig deeper.
The physical exhibit room looks great, with big posters, wall sized pictures of the 1401 and other effects in place. Some of the docents who will give the demonstrations were practicing, using other museum staff as a stand-in audience. While I will be giving demonstrations myself, I haven't yet listened to the entire talk nor received copies of the script. Once I am back from my remaining trips for the year, I can get up to speed.
A few of us discussed whether it is possible to build a tester for the circuit cards that might be along the lines of the old vacuum tube testers - plug in a card, set various switches and connections based on the particular card type, then push a button to run the tests. We think there is enough commonality to the pin assignments that this may be possible - however, detailed research is necessary.
It would seem useful to equip this with both regulated voltages and adjustable 'margin' voltages, to allow the cards to be placed into their worst case condition. The setup should be able to measure both correct function and delay time, as both are important factors in a good card. Scope connections also make sense. This is something for us to noodle on over the coming weeks.
1054 AND 1055 PAPER TAPE PERIPHERALS
I am continuing the design of an interface for the 1054 tape reader and 1055 tape punch for the Computer History Museum. The reader is fully tested and adjusted, but I have not yet tested or adjusted the punch. I have a prototype electrical interface to an Arduino microcontroller which will manage both devices and permit connection to external systems.
 |
| 1055 punch in foreground and 1054 reader and its interface board behind it. |
I realized two fundamentally different and simplifying ideas to handle the adapter that sits between the Documation 600 card reader and the IBM designed adapter logic that believes it is cabled to an IBM 2501 card reader. The adapter logic has to drive the Documation to fill a FIFO queue and emulate a 2501 card reader to emit the proper signals to deliver the data from that FIFO exactly as if it were read by a 600 card per minute 2501.
The 2501 reader has a pre-read station, into which cards are fed by a read cycle before they can move on the next read cycle through the photocells and on into the 1130. One first 'primes' the 2501 by pressing start when the pre-read station is empty, which moves one card from the hopper into the preread area and turns on the "ready" light/status.
When the 2501 is in the ready condition, a read will feed one card past each station - a new card shuttles from the hopper to preread, while the preceeding card moves from the preread station through the photodetectors and onto the stacker. When the hopper is empty, the 2501 turns off the 'ready' condition even though there is still a card in the preread station. The adapter is poised for the 'last card' sequence.
This is the opportunity for the operator to do one of two things; more cards can be placed in the hopper and the start key pressed, or the start key can be pressed without any cards in the hopper. If no cards are in the hopper when start is pressed, the machine will allow a final read command, taking the data from that card but also raising the 'end of file' condition to the processor.
Thus, very long decks of cards can be run through the reader yet the software reading will see a continuing stream of data, punctuated by invisible pauses as more of the deck is dropped into the hopper. Yet, when that deck of cards is at its end, the last card sequence is triggered to alert software that the data file is at its end.
The Documation reader does not have a pre-read station. When a read is requested, as long as the hopper has cards and the reader is in the ready status, it will move a card from the hopper past its photocells and into the stacker as one single action. The last card of a deck would have already be read and delivered to the software before the hopper empty condition would be detected, making it difficult to flag 'end of file' with the last card. There is no 'run-in' sequence to move the first card from hopper to the empty pre-read station, either, since it has no analog of that station.
My solution is to use a two card deep FIFO and to track the state of the virtual pre-read station. Pushing the start button on the 2501 control pad signals my adapter logic to read one card from the Documation, assuming it is ready and has cards in the hopper. That sits in the FIFO as the pre-read, then the signals I send back to the 1130 adapter logic causes it to turn on the 2501 Ready light and condition, believing that run-in has been accomplished.
The software can issue a read to the 2501 and the IBM adapter logic believes the reader to be ready, with a card primed in the preread area, so it begins to empty the FIFO along with the various positional contact switch signals, emitter pulses and simulated photocell states - passing in the 80 columns just as the IBM 2501 adapter logic in the 1130 expected. it also triggers another read of the Documation, filling the end of the FIFO with another 80 columns of data, from the next card that is entering the virtual preread station. Thus, the data sent to the processor is always one card behind, allowing me to model the last card sequence, present the end of file indication and behave appropriately.
The adapter logic is timing accurate, simulating the rotational speed of the 2501 mechanism, the timing when various pulses are emitted and the time between card columns and from card to card, resulting in a 600 cpm delivery of data into the 1130. The Documation 600 is also able to run at 600 cpm, thus I can keep this generally balanced with one new card filling the back of the FIFO as each preceding card is removed to send to the software.
I have to simulate and then test this with real hardware, but it seems pretty straightforward in its new incarnation. The interesting challenge will be to work out the proper error recovery actions to take for each kind of error that can occur - failure to feed a card, logical error while the card moves, or hopper empty. I will map these into the most appropriate 2501 error condition.
I am a bit unsure of whether there are conditions that can occur where I may be reading from the Documation, detect an error during the card movement past the photocells, and leave the FIFO in a bad condition (e.g. not push in exactly 80 columns of data).
I want the recovery behavior to match what an operator would do on a real 2501 - when they remove the last card from the stacker and put it first in the hopper, I should do the same, when they just need the condition cleared so that additional cards can be read from the hopper, I should also do that. It may require a method of clearing out or shortening the FIFO, which I have to think through carefully, but if I am clever I can avoid the need for this entirely.
NEW FPGA BOARD PICKED UP ON EBAY
I saw an auction of a fairly high end fpga development board, one that has three SATA disk channels, 10G ethernet, sound circuit, HD video, twin PowerPC embedded processors, lots of DRAM, Compact flash, USB and many other IO options. I don't have a specific project in mind yet but I can use it for something I am sure, since I was able to buy it for $103 which is quite a bit below its selling price of 1,800.
 |
| Virtex II Pro development board |
AWAY FOR TWO WEEKS OF BUSINESS TRAVEL
I left Saturday for a pair of back to back trips, the first within the US and the second to the UK. I arrive home the evening before the US Thanksgiving holiday, thus won't get to work on the 1130 until the very end of that week. I will bring the Surface Pro on which I do the VHDL coding and synthesis, in order to work on other logic in spare moments.
I should finalize the card reader adapter logic to be ready for testing in the coming weeks, similarly for the line printer and disk drive adapter logic. All of this are complex because they will deliver timing and behavior accurate signals to the IBM designed 1130 adapter logic exactly as if the true IBM peripheral (e.g. 2501, 1403 and 2310) were attached. They must do this while driving the physical boxes I am using, whose behavior, timing and mode of operation is quite different in places.
As well, I can continue to clean up my VHDL code, slashing the number of warning messages from the synthesis tools to a minimum and tightening up the code quality. To the extent that I accomplish all this, it will require a round of regression tests to validate that previously verified parts of the machine still operate correctly. I intend to bring the main fpga logic card with me on the trip to accomplish some of these regression tests as I modify the code, although anything involving physical circuits and peripherals will have to wait until I am back home.
No comments:
Post a Comment