My latest round of signal captures during the read of a card by program from the 1130 has pointed me at some suspicious signal behavior that might be the cause. Specifically, I see the reset signal that clears the card data register is full on up through the first card column arriving, which keeps the data from latching into the register and ultimately induces the unequal comparison that triggers the error condition.
Digging further into the reset signal, I saw that a typo was leading me to drive the signal NotDCReset1 twice, once from the main control circuits as should be but also from the 2501 card reader adapter logic. There should be a local copy of the reset signal, which I have now restored. I also discovered an IBM combinatorial latch in their 2501 adapter logic.
The IBM combinatorial latches don't work reliably on fpga; the solution is to interrupt the circular signal flow with a latch that makes one signal registered so it only changes at the clock edge. I look over the IBM logic for gates that are labeled 'latch' but the Start flag does not label the set of gates this way. It is a particularly complex set of set and reset conditions, thus four gates not the archetypical two. I missed it up until now.
Tracking down the problem was very laborious due to the extensive use of inversion and complementary forms of gates, as a means of minimizing transistor count. Since DTL logic inverts the output of gates with its transistors, minimum parts count objectives lead to spaghetti logic diagrams where you may flip the meaning of a signal three or four times as it wends its way through various gates, also flipping the meaning of the gate between (n)AND and (n)OR due to the inversions. Since inputs can be inverted or not, in addition to the gates having straight or inverted outputs, it takes discipline to unravel the diagram.
Now, imagine that this has to be studied in the context of a set of signals varying in time, with the relationship between them set by my reader emulation logic to appear to be a physical IBM 2501 reader. Tracing through the byzantine diagrams is needed to determine what conditions are occuring in the adapter logic, particularly if it is not clear why some error state is reached at the end of some long sequence of conditions.
It appears that this unusual latch, consisting of four gates with the output of the final gate feed into two of the input gates to cause latching, can't be resolved even by my technique of registering the output of the final gate before it is fed back to the inputs. As I don't understand the exact structure of the lookup tables that implement the logic, I can't figure out why it isn't resetting with long lasting reset signals lasting multiple cycles of the registered feedback, but it is reliably broken.
I will replace this by an equivalent combinatorial latch in the same style used by IBM engineers throughout the 1130, since I know that these work properly once I register the output. I have tried to keep all the IBM logic identical to the ALDs, even if I had to introduce a hidden latch to register the combinatorial latches, allowing someone reading the ALDs to easily follow the implementation of the machine and troubleshoot its behavior. In this case, I will just have to document the IBM gates and my substitutes, allowing a reader of that module of VHDL to understand its relationship to the original machine.
My first test with the replacement latch introduced a new malbehavior - when I start up, after I clear the feed check with an NPRO cycle and ready the physical reader, it reads a card and goes to ready status on its own. It should be waiting for me to push the Start key. This is clearly related to my change to the start latch.
Turns out I pulled off the inverted state of the new start latch as the output, thus the turned-off latch was perceived as on by all the logic it fed.
Incredibly, the start flag was still on when I did a read by XIO, yet it should have been turned off by CB3 when the run-in operation turned on the ready flag. The four latches in that module are now replaced with a clean state machine, leaving the original IBM gates in place but they no longer drive any other logic. This time, the test worked better but it was clear that other combinatorial latches were still a problem
Based on this experience, I have substituted for all the other combinatorial latches in this adapter. Further, I have made a note to go through the rest of the 1130 and replace every instance of such latches. So far, the only remaining latches to replace are in the 1442 card reader and 1132 printer adapter logic, the latches I found in the processor, 1052 console, 2310 disk, and keyboard logic are all converted.
I now can do a read without experiencing phantom read checks or feed checks. I have to verify the correctness of a few of my substitute latches. For example, the feed check light should be on at power-up of the card reader, but it was off. Also, I don't seem to be triggering the cycle steal writes to memory nor the interrupt at the end.
A bit of study showed the conditions for resetting the hopper flag were incorrectly coded, and I found a couple of minor errors in the coding of conditions for the new substitute latches spread across a couple of dozen I had to design. I cleaned this all up and set back to testing again.
Testing with these changes gave very satisfactory results but still not getting the data transferred into memory nor the interrupt at end of operation. I took a dive into logic traces to figure this out. First, I discovered the issue stopping the 1130 adapter from generating an IO interrupt at the end of a read operation, corrected it and verified the fix with a test.
Next, I attacked the failure to store the card values into processor storage. I had to walk through all the signals and timing, both at high speed to see an individual cycle steal event and then slower to see the full cycle of the 80 card columns. Found and attacked a few minor issues as well as spotting a tendency for my interface box to intermittently send not ready or error information to the fpga, most likely due to vibration during operation of the reader. I can put in a debounce on these to insure that error conditions are long lived, as they would be if actually emitted by the card reader, rather than transient glitches.
Everything working well except for the not so inconsequential step of data being written to memory. The debouncing has rid me of the sporadic cases where the reader falls out of the ready state or is initially marked as busy blocking the first XIO instruction.
In addition, I tested the functionality when making the hopper empty, adding cards and pressing start to continue where the reading left off - working fine. The last card behavior was also correct - if the hopper runs out, the 2501 goes not ready.
If the start button is pushed without putting cards into the hopper (hopper empty state), the last card is 'read' from the preread station and the sense device operation will return the 'end of file' bit. If cards are put in the hopper and it is made ready before pushing start, reading continues where it left off.
Also validated was the reset of the status by a sense device to the 2501 with bit 15 turned on, allowing me to put the machine into a reading loop. The synchronization between the virtual 2501 and the real Documation seemed solid during this multiple-card continuous loop.
I did notice that the behavior when it runs out of cards while reading, a feed check condition, is not what I want. I will think about my attitude to how I reflect feed checks and hopper empty conditions to the virtual 2501. I may make a few design changes in the behavior if I find a strategy I like better.
If I could only get the card fields into core, I will be ready to run volume tests, validate the fidelity of the data read, and check the behavior under various error conditions on the physical reader.
So far, all the signals I am tracing so the data from the card getting into the machines B register (SBR) which should mean an automatic write of that value into core. Somehow that is not happening, perhaps it is a timing misalignment inside the 1130 processor logic. I have debugged the console bit switches and the console typewriter, which did not exercise the path for an IO device to write to core; the console switches have an independent path to memory and the typewriter only reads from core.
More tracing of the involved signals deeper into the machine should point me at the timing flaw or missing signal activation. It demonstrates that the issue must be in my core memory emulation logic, since the signals from the 1130 should definitely write the data value into storage.
The B register is definitely updated with the bit values intended to be written back to storage, but it is not occurring for some reason, leaving the original data in place. The CoreStack module is not requesting any sort of a read or write during the cycle steal, in spite of the storage control signals being activated.
The lightbulb finally turned on - this is the first time I had tested cycle steal reads or writes. To ensure I latch in the storage address for a memory cycle, I was latching when the T0 cycle began. Well, in cycle stealing operations, the memory cycle would involve X0, not T0. That caused my memory operation to hang waiting for T0, but when the cycle steal time ended, a real T0 came along and moved the request forward. All I had to do was update the latch to work on either T0 or X0.
That fix applied, I eagerly tested the reader again. Eureka - it is now reading in the 16 columns I requested from the card. I ran a test where I did two reads in a row, then dumped memory, which gave me exactly the contents I expected. The last test I ran in that batch was a last card sequence, to ensure that the card that we received was indeed the one that had been physically read before and was in the virtual preread station.
The outcome was not what I expected, however. The card in question began with "IBM 129 Keypunch Leasing . . . " and the contents of memory were " Leasing . . .", columns 17 and on. Something is going wrong, and it appears to be related to the count I read on the prior card, since it begins on 17.
Time to study my logic for pulling columns from the FIFO, to be sure that in any non-error situation, I draw out all eighty columns of data regardless of the count I intend to read. My suspicion is that the way I detect and respond to error conditions, which includes the hopper going empty, is the cause.
After making some adjustments to my logic, I will do some detailed logic analyzer tracing to see what is occurring - assuming the updates I just made hadn't already eliminated the problem. The issue appears to be failure to read the last few columns of a card, at a minimum the last column is flaky.
Now that the reader is working adequately, I am ready to test the program load mode -the way the 1130 is bootstrapped is via the Program Load button which triggers a special read from the card reader. Since it will be the first test of the program load logic, I am debugging the 1130 logic itself, the IBM written 2501 adapter logic, and my adapter logic.
The great news is that program load mode works flawlessly. I typed a boot format card - a one-card diagnostic - pushed program load and it ran exactly as intended. I dumped memory and found all but the last column of data was correct. Further, every program load ends with the read check lamp lit, although whatever signals that induces are too late to foul up the boot. Unfortunately, any more than a single card boot would fail due to the read check condition.
Undoubtedly the read check condition is a consequence of the failure of the documation to read all eighty columns correctly. Once I correct that issue, i am confident that the program load mode is going to work just fine.
Now I see that my interface loses columns; in my first looks I saw about a 30% incidence of cards with 1-2 missing columns. I will have to do something about this as that is far, far too high an error rate to tolerate. I will need to put something in the interface that is guaranteed to see every index pulse, record the card columns at the right time, and pass them over the serial link with an enhanced protocol that verifies receipt by the fpga side logic.
One approach would use an Arduino, exploiting its interrupt to ensure I see the index marker pulses. This would take a few days to create and test, but appears to be necessary. I will leverage the existing interface hardware to pass data from the Arduino to the fpga. It is an opportunity to skinny down the link to use just one input chip, as I can multiplex over 16 pins
The Arduino itself has 54 pins, plenty of connections to monitor and control everything in the interface and the reader. I will have some design work, some coding and some rewiring to do in the interface before I can resume testing.
On the other hand, there are possible changes I can make to make the interface more reliable without having to adopt a microcontroller in the remote end. During the time that a card has columns of data moving through the reader photocells, from a bit before column 1 until the end of column 80, I can focus the serial link on reading only one MCP23017 chip which will give me all 12 card row bits plus four extra bits.
That by itself might be sufficient if the problem is just bad luck with the timing of index markers relative to the serial link polling timing, if two index markers may blend into a single long one as seen by the fpga logic. However, I designed a bit of hardware to add a three bit counter that is incremented for each index marker received in the remote interface. Those three bits are transmitted along with the card row bits, allowing the fpga to determine if a new column is reported even if the index markers blur together on the 1130 end. As well, if the value jumps more than one, we know we had an unrecoverable loss of data and can flag a read check to the virtual 2501.
COMPUTER HISTORY MUSEUM - WILLIAMS TUBE PROJECT
Bob Erickson began the project to build a working demonstrator around an IBM 706 CRT memory unit, which houses two tubes as part of the Williams-Kilburn memory technology that was used in several machines during the tube era, including the IBM 709 for which this rack unit was built. Bob passed away recently, but Bill Newman will lead efforts to complete the project in Bob's honor.
Bill and Ron Crane are experimenting to validate the levels of signal that should be detected from the face of the CRT when phospors are being lit, using several scopes in our restoration lab. Based on these, Bill will refine the amplification system that raises the tiny signals to usable levels, then he will design all the driving circuitry. It will control the beam sweep, write and detect data at the targeted locations on the tube face, and provide an interface where digital addresses can be delivered and stored data returned to external systems.
If this succeeds, it will be the world's only actively working Williams-Kilburn memory device. A replica of the SSEM (Baby) at Manchester University was built a few years ago and run as a demonstration, but I believe it has become a static display at the museum.
The engineers who built the early computers using these tubes as main memory struggled to get these to work reliably, in systems such as the Manchester Baby and Manchester Mark I, Von Neumann's Institute for Advanced Studies machine, the IBM 709 (essentially an evolution of the IAS machine) and a few others. Contemporary alternative memories were mercury delay lines or fixed head drums.
Once magnetic core memory was perfected, the CRT, drum and delay line memories faded into history. Core gave way to semiconductor memories in seventies, but had quite a long run as the processor main memory of computers.
DISPLAY PEDESTAL COMPLETION
I had to trim back the light mask to clear some clear acrylic that I had glued to the back of the plexiglass panel, in one of my earlier attempts at fastening everything together, because I couldn't remove the bit of plastic. I had thoughtlessly glued it to the paint layer, not to the plexiglass itself, thus it would have ripped away some of the legend and black background if I tried to remove it.
Once everything fit without interference, I bolted the light mask into place. My logo header is fastened down and secured with lockwashers. The mode switch plate is now attached as well. The emergency pull switch plate is the remaining side, but I am having great difficulty getting anything to bond to the back of the steel plate, particularly because the nuts and angle bracket are stainless steel which inhibits adhesion.
I did test with some permanent magnets and found the plate will hold quite well, so that is the plan of attack. I will buy a magnet with a hole that can be mounted to my angle bracket that is already fit into the enclosure. While I am waiting for that piece, I can finish installing the circuit boards with the LEDs.
I thought of a way to minimize the flare of light that comes through the black background of the plexiglass - I will use a tube inserted over each LED to block any sideways emissions. When that is complete, there is some small fastening tasks then I can close up the enclosure.
TEKTRONIX TEST EQUIPMENT WORK
7D01 Logic Analyzer repair
I replaced the switch and put the unit back together - dozens of cables to connect and now ready for a quick test. I did confirm that the switch works, although with a bit of wiggle it can be made to fail but that is easily corrected by touching the switch again.,
The unit still has the other problems - does not record the second set of eight signals when in 16 channel recording mode and the readout information is missing at the top and statically 11111111 at the bottom., Since the static data at the bottom is also eight bits long when the machine should be in 16 bit mode, there may be a common fault that causes both symptoms.
7D15 Counter/timer/frequency measuring plug-in
I repaired the bad capacitor and put the unit into my scope, It appears to be working properly, although the "Source B" button sticks in a bit probably due to accumulated crud. I did some quick tests with the stopwatch and event counter functions, but will need to read the manual and understand the controls before I put it through all its paces.
CARD DECKS TO USE WITH PROGRAM LOAD ON THE 1130
I am converting various listings of bootable card decks into punched cards to make use of the system in a native way, whereas up to now I have used an FPGA utility to preload the memory with code each time I power up. Ultimately, a small boot deck will fetch the Disk Monitor System from disk, the most common way that 1130 systems were started, but I have quite a bit of work before I have the RK05 disk drives working as emulated IBM 2310 disk drives.
I punched a few of the one-card diagnostics, but these are very rudimentary and hardly worth running. I will punch up the diagnostics loader, which can load some great routines to help exercise the peripherals as well as the processor. I am using a hand operated keypunch, a Wright 2600, so this is a bit tedious starting with the conversion of a blurry listing into the plan for punching holes, then punching as many as 12 holes per column.
No comments:
Post a Comment