SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
Making good progress on the debugging of the 1053 mirror device, now that I included plenty of diagnostic information that I could watch on the PC as the fpga box did its thing. I started the ZDCIP standalone disk utility, which first types some instructions and choices on the 1053 console printer.
I could see that I was correctly setting up data characters, pushing them into the FIFO and popping them back out, because the values were visible while the activity was underway. What seemed to go awry was in the delivery of that retrieved word back to the PC.
Next, the PC was receiving empty buffer status but not handling it correctly. I need to tweak the Python program on the PC side to deal with this.
I then experienced the same problem again, with something locking up and forcing 0x03F0 on the inbound B bus, which is read anytime an XIO instruction or cycle steal looks to that shared bus. I think I triggered this by shutting off the 1130 before I had stopped the mirror 1053 adapter function.
However, even when I power cycled the SAC adapter, started up the Python program again and cycled the USB interface cord, the system still had the erroneous status on the bus. I am not sure how this could persist over the cold restart that I did. It might be a flaw in the USB driver in Linux on the PC or it might be something in the 1130 itself - this is puzzling.
I need to figure out ways this might happen, instrument some checks and figure out what happens, since when it reaches this wedged state with 0x03F0 forced on, I can't do any other testing. It is a priority problem.
HELP TO FELLOW RESTORERS
Today I was able to offer advice and suggestions to one friend, who is assisting a US based museum in restoring some 4381 and 360 systems, and to check out the 'normal' behavior of a part on a keypunch for another friend working on a keypunch at a UK based institution.
The 4381 startup is terminated when the -1.5V power supply detects over-current as it ramps up, protectively dropping all power to the system. It seems to be reaching a bit over 80 amperes when this happens. They were pondering ways of measuring the actual current draw to sections of the machine, but didn't have a good tool. We are looking at something under 18 thousandths of an ohm resistance. It takes a very accurate and precise ohmmeter to sort out the real resistance of the load.
Since the power is delivered over a laminated sandwich of power bars, one of which carries the -1.5V current, those bus bars having very low resistance but not zero, once can treat them as a resistor in series between the power supply and the load. Stick a sensitive voltmeter across the two 'ends' of the bus bar, nearest the supply and nearest the load, and you can determine the current. This is because the resistance of the bar can be measured, out of circuit, and once known the voltage drop measured is simply IxR. Thus, the current carried on the bus bar will be calculated as V/R.
The keypunch is not feeding well. It has a pair of'knives' that select just the front card and pull it down into the rollers, but one of the knives pivots left and right while the other is fixed in position. I verified from my 029 keypunch that both knives should pivot. If the knife is frozen and its front is not exactly parallel with the cards in the hopper, the 'high' end will push the cards backwards, such that they won't slide down the 'throat' that is carefully adjusted to be a bit over one card thick.
I then experienced the same problem again, with something locking up and forcing 0x03F0 on the inbound B bus, which is read anytime an XIO instruction or cycle steal looks to that shared bus. I think I triggered this by shutting off the 1130 before I had stopped the mirror 1053 adapter function.
However, even when I power cycled the SAC adapter, started up the Python program again and cycled the USB interface cord, the system still had the erroneous status on the bus. I am not sure how this could persist over the cold restart that I did. It might be a flaw in the USB driver in Linux on the PC or it might be something in the 1130 itself - this is puzzling.
I need to figure out ways this might happen, instrument some checks and figure out what happens, since when it reaches this wedged state with 0x03F0 forced on, I can't do any other testing. It is a priority problem.
HELP TO FELLOW RESTORERS
Today I was able to offer advice and suggestions to one friend, who is assisting a US based museum in restoring some 4381 and 360 systems, and to check out the 'normal' behavior of a part on a keypunch for another friend working on a keypunch at a UK based institution.
The 4381 startup is terminated when the -1.5V power supply detects over-current as it ramps up, protectively dropping all power to the system. It seems to be reaching a bit over 80 amperes when this happens. They were pondering ways of measuring the actual current draw to sections of the machine, but didn't have a good tool. We are looking at something under 18 thousandths of an ohm resistance. It takes a very accurate and precise ohmmeter to sort out the real resistance of the load.
Since the power is delivered over a laminated sandwich of power bars, one of which carries the -1.5V current, those bus bars having very low resistance but not zero, once can treat them as a resistor in series between the power supply and the load. Stick a sensitive voltmeter across the two 'ends' of the bus bar, nearest the supply and nearest the load, and you can determine the current. This is because the resistance of the bar can be measured, out of circuit, and once known the voltage drop measured is simply IxR. Thus, the current carried on the bus bar will be calculated as V/R.
The keypunch is not feeding well. It has a pair of'knives' that select just the front card and pull it down into the rollers, but one of the knives pivots left and right while the other is fixed in position. I verified from my 029 keypunch that both knives should pivot. If the knife is frozen and its front is not exactly parallel with the cards in the hopper, the 'high' end will push the cards backwards, such that they won't slide down the 'throat' that is carefully adjusted to be a bit over one card thick.
No comments:
Post a Comment