Design study to add interrupt levels 0 and 1 to SAC Interface Box
The investigation for the possible modification of the 1131 to support my SAC Interface being able to sense and drive interrupt levels 0 and 1 was very tedious work. In order to repurpose signals currently on the SAC cable, I need to accomplish four things. I must interrupt the link between the driver/receiver and original circuitry, for driven signals I have to hold the original circuit inactive, I need to route the reused signal over to the new circuit and I must tie it in non-disruptively.
Some of these circuits use wire-wrap leads, which are easy to interrupt and to hold inactive. Others come from a cable that connects the signal to several different gates, which can be challenging. Some route the signal on traces on the backplane, which is hard to find and even harder to rewire.
The Block Channel Advance driven signal appears feasible to interrupt and use to request an interrupt. Both levels 0 and 1 have a reasonable place where I can add my re-purposed signal to a 'wired-or' that merges requests for that interrupt level.
The remaining signals - CPU Meter Out, CPU Parity Stop, and the candidates for the second driven signal are all messier, with no obvious route to reuse these. More work is needed, which involves the ALDs then careful examination of the backplanes and cabling.
Design study for broader scope of the SAC Interface Box
The fpga board has a full capacity of 100 input/output signals, of which 70 are used just for the 1131 signals. I am using some others for diagnostic purposes, and have just taken six more for my 1627 plotter replica. I am rapidly exhausting the signal pins but have the need for many more signals to handle all the real devices I want to attach.
The paper tape reader and punch will require another 21, the Documation card reader needs about 20, then there are devices with even higher signal requirements - multiple disk drives, a 9 track tape drive, and a 2741 terminal replica.
Some of these devices will have their own dedicated fpga or microcontroller board which can concentrate the signal requirements down, yet they all need communicate with the fpga board that is the core of the interface box.
I have two ways to proceed. One is to use sets of a few signals for each secondary board employing a high speed serial protocol like SPI. The total connectivity is still limited, especially for high speed, low latency requirements which would be bit serial over each link. A second method is to take most of the remaining signals on the main board and use them for a 16 bit parallel fast bus to a second board, which would have quite a few I/Os to the connected devices.
Testing of the 1130 using the 1627 plotter replica
I completed some hand code and tested it on the 1130 simulator, ensuring it would drive the 1627 plotter to make a certain pattern. I did some tweaking before I was satisfied with the pattern, and I had to adjust my assumptions about what bit corresponded to the various plotter movements. That successful program was then dumped to a file and transferred into core memory by my interface box, after which I tried out the plotter program on the 'real' plotter.
It didn't work, which is to be expected on the first test an a device adapter, so I began instrumented and debugging. I then found that my adapter logic was recognizing the IO conditions and triggering the response interrupt. There is also some ambiguity about whether my little hardware emulator box that sits between the strobe and the SAC interface box should be receiving inverted or normal drive signals. It was built to map the strobe plotter to the functions available on the Calcomp unit that IBM sold as the IBM 1627.
I am embarrassed to say that my interrupt routine changed the accumulator but didn't save/restore it. this didn't cause a problem on the simulator due to its high speed - it was already looping on a lockword when the interrupt occurred. On my machine the interrupt was occurring very rapidly relative to instruction execution. The machine memory cycle time is 3.6us and should have been able to execute many hundred memory cycles before the interrupt arrived.
Thus, my bad code exposed a timing issue which I need to investigate. I should be spinning in a countdown timer for almost 3 milliseconds before firing the interrupt. I had to put the scope on the lines to verify what was happening and the duration of the timer. It appears that my timer lasts only a few percent as long as it should. I will pore over the VHDL and think of ways I can narrow down the search or hopefully spot the problem directly.
Daylight was fading and so the testing came to an end for the weekend. This is reasonable progress when debugging a device adapter, even a simple one like the plotter. With the evening I can look at some of the design decisions and perhaps extend the functionality a bit.
Writing additional peripheral device adapter logic
I began implementing the paper tape adapter, allowing me to drive a 1134 tape reader and 1055 tape punch. The final implementation has to wait until I resolve the expansion approach (see topic above), but I got the devices installed in their UCWs with the proper area codes.
The remaining signals - CPU Meter Out, CPU Parity Stop, and the candidates for the second driven signal are all messier, with no obvious route to reuse these. More work is needed, which involves the ALDs then careful examination of the backplanes and cabling.
Design study for broader scope of the SAC Interface Box
The fpga board has a full capacity of 100 input/output signals, of which 70 are used just for the 1131 signals. I am using some others for diagnostic purposes, and have just taken six more for my 1627 plotter replica. I am rapidly exhausting the signal pins but have the need for many more signals to handle all the real devices I want to attach.
The paper tape reader and punch will require another 21, the Documation card reader needs about 20, then there are devices with even higher signal requirements - multiple disk drives, a 9 track tape drive, and a 2741 terminal replica.
Some of these devices will have their own dedicated fpga or microcontroller board which can concentrate the signal requirements down, yet they all need communicate with the fpga board that is the core of the interface box.
I have two ways to proceed. One is to use sets of a few signals for each secondary board employing a high speed serial protocol like SPI. The total connectivity is still limited, especially for high speed, low latency requirements which would be bit serial over each link. A second method is to take most of the remaining signals on the main board and use them for a 16 bit parallel fast bus to a second board, which would have quite a few I/Os to the connected devices.
Testing of the 1130 using the 1627 plotter replica
I completed some hand code and tested it on the 1130 simulator, ensuring it would drive the 1627 plotter to make a certain pattern. I did some tweaking before I was satisfied with the pattern, and I had to adjust my assumptions about what bit corresponded to the various plotter movements. That successful program was then dumped to a file and transferred into core memory by my interface box, after which I tried out the plotter program on the 'real' plotter.
It didn't work, which is to be expected on the first test an a device adapter, so I began instrumented and debugging. I then found that my adapter logic was recognizing the IO conditions and triggering the response interrupt. There is also some ambiguity about whether my little hardware emulator box that sits between the strobe and the SAC interface box should be receiving inverted or normal drive signals. It was built to map the strobe plotter to the functions available on the Calcomp unit that IBM sold as the IBM 1627.
I am embarrassed to say that my interrupt routine changed the accumulator but didn't save/restore it. this didn't cause a problem on the simulator due to its high speed - it was already looping on a lockword when the interrupt occurred. On my machine the interrupt was occurring very rapidly relative to instruction execution. The machine memory cycle time is 3.6us and should have been able to execute many hundred memory cycles before the interrupt arrived.
Thus, my bad code exposed a timing issue which I need to investigate. I should be spinning in a countdown timer for almost 3 milliseconds before firing the interrupt. I had to put the scope on the lines to verify what was happening and the duration of the timer. It appears that my timer lasts only a few percent as long as it should. I will pore over the VHDL and think of ways I can narrow down the search or hopefully spot the problem directly.
Daylight was fading and so the testing came to an end for the weekend. This is reasonable progress when debugging a device adapter, even a simple one like the plotter. With the evening I can look at some of the design decisions and perhaps extend the functionality a bit.
Writing additional peripheral device adapter logic
I began implementing the paper tape adapter, allowing me to drive a 1134 tape reader and 1055 tape punch. The final implementation has to wait until I resolve the expansion approach (see topic above), but I got the devices installed in their UCWs with the proper area codes.
No comments:
Post a Comment