This Friday we put the heads back on the demonic drive, a Diablo disk we are repairing for a fellow Alto owner. This drive has not only fought long and hard against restoration, damaging heads, cartridges and egos, but has the uncanny ability to cause other, previously working, drives to fail when brought in contact with this evil device.
The heads were aligned and we confirmed the problems writing on this drive. It writes sectors which have a high chance of encountering read errors when the sector is read at some later time. Using my disk tool, if the exact same pattern were written to the sector multiple times, eventually the sector would read cleanly. Any variation in the pattern, even the nondeterministic variations on a real Xerox Alto due to other demands on the CPU, and there is no improved readability.
We examined the command signals for writing and turning on the erase head, which were all good. This makes sense because the drive would fail with swapped read/write PCBs from working drives, so the flaw couldn't be in the board itself.
We swapped a third read/write board into the drive, one from our working Diablo drive in our Alto. It produced much much better results in the demon drive. We brought the entire demon drive along with our good read/write PCB over to hook to the Alto, where we found that it was almost good enough.
We found it worked adequately most times when writing on the first half of the cartridge, but at high cylinder numbers it became much more prone to read errors after writing. Because the bit density increases as the arm moves to concentric tracks nearer the hub, we found the drive had circuitry that boosts the write and erase current when tracks from 128 to 203 are being addressed.
Again, this drive is right on the margin of working properly. Swapping among three seemingly identical read/write PCBs, we find that one of them produces behavior a bit better than the other two. We see a deficit in current through the heads, although the static resistance of the head windings are the same on all drives. Further, both the top and bottom heads work the same way.
True to the demonic nature of this drive, when we reattached our working Diablo drive back into the Alto we found that the contact had once again spread badness to the innocent drive. Our arm motor was no longer seeking.
Of course, once we took the drive out and did some detailed investigation we found that it was working properly again. We know of no mechanism that would leap across an air gap to a powered down drive and damage the arm motor solely because a card was in the demon drive earlier or the cables had been attached earlier to the demon drive.
This is once again a very striking coincidence. We suspect we may have a slowly failing rotary arm motor or drive electronics, something we will have to watch and fix once it stays broken long enough to track down.
As for the demon drive, we will continue with additional tests next week until we figure out the real issues and appropriate ways to resolve them.
The heads were aligned and we confirmed the problems writing on this drive. It writes sectors which have a high chance of encountering read errors when the sector is read at some later time. Using my disk tool, if the exact same pattern were written to the sector multiple times, eventually the sector would read cleanly. Any variation in the pattern, even the nondeterministic variations on a real Xerox Alto due to other demands on the CPU, and there is no improved readability.
We examined the command signals for writing and turning on the erase head, which were all good. This makes sense because the drive would fail with swapped read/write PCBs from working drives, so the flaw couldn't be in the board itself.
We swapped a third read/write board into the drive, one from our working Diablo drive in our Alto. It produced much much better results in the demon drive. We brought the entire demon drive along with our good read/write PCB over to hook to the Alto, where we found that it was almost good enough.
We found it worked adequately most times when writing on the first half of the cartridge, but at high cylinder numbers it became much more prone to read errors after writing. Because the bit density increases as the arm moves to concentric tracks nearer the hub, we found the drive had circuitry that boosts the write and erase current when tracks from 128 to 203 are being addressed.
Again, this drive is right on the margin of working properly. Swapping among three seemingly identical read/write PCBs, we find that one of them produces behavior a bit better than the other two. We see a deficit in current through the heads, although the static resistance of the head windings are the same on all drives. Further, both the top and bottom heads work the same way.
True to the demonic nature of this drive, when we reattached our working Diablo drive back into the Alto we found that the contact had once again spread badness to the innocent drive. Our arm motor was no longer seeking.
Of course, once we took the drive out and did some detailed investigation we found that it was working properly again. We know of no mechanism that would leap across an air gap to a powered down drive and damage the arm motor solely because a card was in the demon drive earlier or the cables had been attached earlier to the demon drive.
This is once again a very striking coincidence. We suspect we may have a slowly failing rotary arm motor or drive electronics, something we will have to watch and fix once it stays broken long enough to track down.
As for the demon drive, we will continue with additional tests next week until we figure out the real issues and appropriate ways to resolve them.
ENHANCEMENTS TO IBM 1130 CONSOLE PRINTER (1053) EMULATOR
I received a number of good suggestions from readers of this blog, almost all of which I incorporated into a new version of the PC1053 emulator device. One I chose not to add since it would give different behavior than a real 1053 console printer and one I dropped after testing because the effect was not discernable.
The device will not simulate the actual time that a long operation (tabbing or carrier return) will take place, rather than a fixed representative time as originally designed. It is based on the high speed return feature built into the 1053 console printers used with the IBM 1130. These will take a bit over a second to return from the maximum distance of 120 columns. Tabbing occurs at a rate of 40 columns per second.
Tab stops can be set and cleared by the operator at the PC terminal emulator by issuing new commands TS xxx and TC xxx to set or clear tab stops at column xxx. This allows the user to programmatically set the tab stops from a PC file such that they are remembered across sessions.
One suggestion was to mimic the autorepeat key behaviors found on newer Selectrics and modern terminals, where a key such as space initially fires once, but with an elongated push, it will begin to produce multiple repeating spaces until it is released. Since the 1053 console printer does not behave this way, even though it would be handy, I am not going to build this into the emulator.
My first take at the design would have the column indicator, a three digit display, leap instantaneously from the current position to the next tab stop. There was a suggestion to have the digits change at the rate of movement of the carrier, providing a ripple effect on the display as it moves.
At first I was building that into the device so that it changed the numbers on the column display as it sat in the state machine for the tab or CR movement. However, I discovered that the numbers changed so rapidly that one could not see much other than a blur. A tab of 60 columns occurs in 1.5 seconds, thus the one's digit changes in 25 milliseconds and the tens digit changes each 250 ms.
I relaxed the realism a bit, doing a quick blur of the column display after the tab operation has completed. It still gives the impression of quickly tabbing across, a flickering rather than instant change, but doesn't attempt exact timing on the display; only the feedback signal to the 1130 has exact timing.
On a real 1053, if a CR is requested when the carrier is to the left of the left margin, it will return all the way to column 1. I handle the left margin by spacing over after each \r is sent to the terminal emulator, such that the text prints at the appropriate offset from the left edge.
I mimic this behavior, where CR from a column before the left margin will return to 1, but once the carrier has advanced past the left margin, a CR brings us back to the margin. It took a bit more code to make this happen, but it is a more realistic behavior.
My testing showed all actions I could test with buttons and commands were working properly. Tomorrow, I will have to dummy up a way to inject tilt/rotate and other commands the same way that the 1130 will, to verify the rest of the code.
No comments:
Post a Comment