I found a special at Frys on a 14000 BTU portable AC, bought it and will figure out installation into my workshop so that I can begin cooling this afternoon and resume work. Once again I run into a situation of extremely limited inconvenient access just to get the dryer exhaust hose on its fitting now that it is taped to the AC exhaust line. Once done, I fired it up along with the other 8000 BTU portable and had them begin cooling down the workspace. It got tolerable inside with an outside temp of 95F, although when I fire up the 1130 the temps begin to climb back up from its 4500 BTU heat output.
1053 CONSOLE PRINTER RESTORATION
I fired up the diagnostic and could see that the times when the typewriter is not actually typing characters, the solenoids are visibly firing away with tilt and rotate codes. This means that my problem is in the triggering of a print cycle, an adjustment I should be able to make.
I looked into the adjustments necessary to get a good trigger of a print cycle - these involve the latch trigger and trip lever assembly that should release the clutch latch for every activation of the selection magnets. Before I adjust these, though, I need to monitor the feedback signal from the typewriter back to the IO adapter logic in the 1131.
If the adapter is firing the print solenoids far too early in a cycle, the clutch isn't yet ready to be released. However, this would be very early indeed since the design of the typewriter is to allow to take another rotation of the cycle if the next character was requested, not having to wait for the cycle clutch latch to stop first.
This makes the more likely issue something in the cycle clutch mechanism or the adjustment of the trip lever. If I have sludgy lubricant here, that may cause the periods of missed cycles I am observing. It is not evenly spaced among characters, which you might expect if the trip lever was borderline. Instead, it will fire off a string of characters and then sit while another string selects but doesn't take print cycles. The problem has to be something that sticks the machine in a 'no print cycle' mode for bursts of time.
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
In thinking about the task of tracking the lines being printed on the 1132 printer, I was faced with the challenge that I couldn't tell what address a cycle steal operation is requesting, nor the device making the request. With either of those facts I could sort out what the eight printer hammer firing words are for each character, but it was ambiguous otherwise.
What I will see is an interrupt on level 1, followed by an XIO Read whose data word is the next character on the print wheel. The software takes that, figures out what columns of the print line should have that character printed, and sets up eight words beginning at location 0x0100. The printer will fetch the eight words, set up the hammer circuitry and then fire as the wheel reaches the proper point.
If there was no disk drive, the eight cycle steal operations would be for locations 0x0100, 0x0101 etc and I could just watch as the printer picked up its list of hammers to fire. I can tell for sure that we are in a cycle steal operation because the X0 clock goes on at the start and I can tell it is not for me because CS Level 1, assigned to the SAC Interface, is not active. However, it could be either CS Level 0 or CS Level 2.
Further, if neither Interrupt Level 0 nor Interrupt Level 1 is activated, then I can tell that we are in a CS Level 2 which is for the 1132 printer. The problem arises because the way I tell CS Level 2 is active also raises in IL0 or IL1 is active. Thus, if a disk sector is ready to send or receive words for an IO operation right at the time that IL0 or IL1 is active, I will be blind to which device is doing the cycle steal.
I could fetch the eight words as soon as I saw eight fetches by another device - if it was the printer, I will get the hammer order words and can mimic the print line results. If disk access is underway at this time, I will be fooled and pick up invalid hammer order words. Without a new signal line from the 1131 to the SAC box, carrying the state of CS Level 2, I can't definitively snoop on cycle steal fetches.
Rather than string a new twisted pair from the 1130, I could find a way to check the address of the cycle steal. Assuming I can snoop on the address bus from my interface box side, I could watch for the eight special addresses 0x0100 through 0x0107 and raise a signal for a match in that range. Any address in that range during a cycle steal is certain to be for CS Level 2 and the 1132 printer.
This is predicated on the exact circuitry used for the Channel Address In lines from SAC box to 1131. If these are simple wired-or junctions as is common in the machine, then I could watch the level of my open collector driver outputs and see if they drop to zero, meaning another device has put up an address for cycle steal. If there is a buffer in the way, it will block my visibility of the other drivers of the Channel Address In bus.
After reviewing the ALDs, I found my proposed method won't work. The input bits for the channel address are gated with a Chan Add Write signal in an AND gate before they contribute to the wired-OR memory address bus. Any logic to spot addresses from 0x0100 to 0x0107 would need to be done locally inside the 1131 and still requires that a signal line be added to the cabling.
Another idea I am evaluating is the possibility that I just assume the disk is not causing the cycle steals - that I trigger on the XIO read for a character from the printer emitter wheel and then snag the next eight cycle steal results while Inh CS Req is on, under the assumption that it is the proper words.
The result of picking off the wrong words as hammer firing bits is that my copy of the print line will be mangled on any print line in which a disk sector is read or written during IL0 or IL1 processing and at the time I am looking for the printer CS accesses. This should be infrequent enough to be tolerable, with the PC file containing a good copy of the printout other than rare lines with garbage characters in the line. Thus, I will NOT be adding the CS Level 2 signal or the CS address match logic as of yet.
Something is wrong with my updated Python program, resulting in a hang on the USB link. I did some debugging once the workshop got cool enough. There is something awry in how I moved the virtual 2501 card reader logic over to the new threaded parallel approach, but I could bypass it for now. I found another problem with the threads stepping on each other and fixed that.
The box loaded memory just fine in its new parallel process, which I used to run the 1053 diagnostic.
I will continue with development of mirror devices, testing of the virtual 2501, creation of the virtual 1403 printer and other items I plan for the interface box.
1131 PROCESSOR REPAIR
Yesterday I was working on the assumption that continuity was broken due to my resistor panel wiring, since one of the lamps (Disk Unlock) on the left side of the main panel was lit. Most of the lamps were wired to the +12V supply which also provided power for the console buttons and switches.
However, it turns out that this one lamp is powered separately from the disk drive circuitry and using a different voltage. Checking voltage to the lamps and switches quickly showed that +12V was missing. When I looked at the power supply, its fuse was blown. A quick trip to Frys netted me the replacement fuse which I installed. The processor now works properly.
If there was no disk drive, the eight cycle steal operations would be for locations 0x0100, 0x0101 etc and I could just watch as the printer picked up its list of hammers to fire. I can tell for sure that we are in a cycle steal operation because the X0 clock goes on at the start and I can tell it is not for me because CS Level 1, assigned to the SAC Interface, is not active. However, it could be either CS Level 0 or CS Level 2.
Further, if neither Interrupt Level 0 nor Interrupt Level 1 is activated, then I can tell that we are in a CS Level 2 which is for the 1132 printer. The problem arises because the way I tell CS Level 2 is active also raises in IL0 or IL1 is active. Thus, if a disk sector is ready to send or receive words for an IO operation right at the time that IL0 or IL1 is active, I will be blind to which device is doing the cycle steal.
I could fetch the eight words as soon as I saw eight fetches by another device - if it was the printer, I will get the hammer order words and can mimic the print line results. If disk access is underway at this time, I will be fooled and pick up invalid hammer order words. Without a new signal line from the 1131 to the SAC box, carrying the state of CS Level 2, I can't definitively snoop on cycle steal fetches.
Rather than string a new twisted pair from the 1130, I could find a way to check the address of the cycle steal. Assuming I can snoop on the address bus from my interface box side, I could watch for the eight special addresses 0x0100 through 0x0107 and raise a signal for a match in that range. Any address in that range during a cycle steal is certain to be for CS Level 2 and the 1132 printer.
This is predicated on the exact circuitry used for the Channel Address In lines from SAC box to 1131. If these are simple wired-or junctions as is common in the machine, then I could watch the level of my open collector driver outputs and see if they drop to zero, meaning another device has put up an address for cycle steal. If there is a buffer in the way, it will block my visibility of the other drivers of the Channel Address In bus.
After reviewing the ALDs, I found my proposed method won't work. The input bits for the channel address are gated with a Chan Add Write signal in an AND gate before they contribute to the wired-OR memory address bus. Any logic to spot addresses from 0x0100 to 0x0107 would need to be done locally inside the 1131 and still requires that a signal line be added to the cabling.
Another idea I am evaluating is the possibility that I just assume the disk is not causing the cycle steals - that I trigger on the XIO read for a character from the printer emitter wheel and then snag the next eight cycle steal results while Inh CS Req is on, under the assumption that it is the proper words.
The result of picking off the wrong words as hammer firing bits is that my copy of the print line will be mangled on any print line in which a disk sector is read or written during IL0 or IL1 processing and at the time I am looking for the printer CS accesses. This should be infrequent enough to be tolerable, with the PC file containing a good copy of the printout other than rare lines with garbage characters in the line. Thus, I will NOT be adding the CS Level 2 signal or the CS address match logic as of yet.
Something is wrong with my updated Python program, resulting in a hang on the USB link. I did some debugging once the workshop got cool enough. There is something awry in how I moved the virtual 2501 card reader logic over to the new threaded parallel approach, but I could bypass it for now. I found another problem with the threads stepping on each other and fixed that.
The box loaded memory just fine in its new parallel process, which I used to run the 1053 diagnostic.
I will continue with development of mirror devices, testing of the virtual 2501, creation of the virtual 1403 printer and other items I plan for the interface box.
1131 PROCESSOR REPAIR
Yesterday I was working on the assumption that continuity was broken due to my resistor panel wiring, since one of the lamps (Disk Unlock) on the left side of the main panel was lit. Most of the lamps were wired to the +12V supply which also provided power for the console buttons and switches.
However, it turns out that this one lamp is powered separately from the disk drive circuitry and using a different voltage. Checking voltage to the lamps and switches quickly showed that +12V was missing. When I looked at the power supply, its fuse was blown. A quick trip to Frys netted me the replacement fuse which I installed. The processor now works properly.
No comments:
Post a Comment