On Friday we put the microscope, so to speak, on the Diablo disk drive we are repairing for a fellow Xerox Alto owner. It was set up on the workbench hooked to my FPGA disk tool in order to read and write to the drive in a controlled way.
First, we took a disk cartridge that was written properly on our Xerox Alto primary drive, inserted it in the demon drive and read the image to the FPGA. The archived image matched exactly with the image we had written, confirming that the demon drive is:
- Properly aligned to address tracks 0 to 202
- Able to read successfully
I then took the image and wrote it from the disk tool to the cartridge in the demon drive. When we attempted to read the image back that was just written, the reading attempt encountered a huge number of checksum errors.
The drive cannot properly write data, but can read it just fine. The same disk heads and windings are used for both reading and writing. We swapped all the circuit cards from a working Diablo drive to determine if we had failing logic on those cards, but the results were unchanged.
These swaps eliminated the vast majority of the parts in the demon drive, leaving us a very few remaining suspects. The heads themselves might be bad, however since they read properly and both the top and bottom head produce the same failures, this is unlikely.
The disk drive has logic to verify that appropriate current is flowing in the erase windings and the read/write coils - further reducing the chance that the heads or cabling between circuit board and head are defective.
The signals for writing - Write Gate, Erase Gate, and Write Data+Clock - are all delivered directly from the interface cable to the board that we swapped. The possible failure points seem to be:
- connector from the interface cable
- signal traces on the backplane from connector to PCB
- bad power levels or quality
- common flaw in both heads on this drive
We checked the power quality. The drive takes in +15V and -15V, delivered by very expensive HP power supplies on our workbench and from the Alto power supplies when cabled up. The behavior is the same on workbench and Alto, so we can eliminate the 15V supplies.
Onboard the Diablo drive, +5V is generated to power most of the circuit board logic, except for the op amps handling analog signals. That power was almost identical in voltage and noise to the power on the correctly working drive we used as a reference.
Diablo drives operate at several densities - the Alto version uses the high density (2200 bit per inch) version. If we somehow had standard density heads, that might match the symptoms, if the head is unable to produce sharp enough flux transitions.
We used the stereo microscope to examine the heads, looking for any sign that they are different from the high density heads we use in the other drives. No visible difference existed, but that is not conclusive.
When a properly written disk cartridge is booted on the demon drive, the Xerox Alto monitor will try to rewrite some sectors to adjust timestamps on file access. This corrupts the cartridge and causes the cartridge to become unusable quickly.
Taking a cartridge which was corrupted by the demon drive, we watched what was being read by the heads as the cartridge spun around. We saw that the signal was weaker and less distinct, so much so that the limiter and clipper circuits could not restore them to full ranges swings between the op amp rails.
Next session, we plan to swap to a different set of spare heads, to eliminate them as the cause. We will swap the remaining two boards that should have nothing at all to do with read/write operations, just to eliminate all possible circuitry on boards. Then, we will instrument the drive to see what it is doing during write operations. Hopefully we will find the smoking gun and get this drive repaired.
ORIGINAL FORTH EXPLORATION
Bob Flanders and I have been examining the running FORTH on the 1130, looking to validate its operation and learn to use it. Ken Boak studied the scanned pages of code that we used for this restoration and came to the same conclusion that this is a complete version of original FORTH.
Ken chose to name the antique version of FORTH as Proto-FORTH, which I love. It captures the flavor of a predecessor, different from but clearly the sire of all the FORTHs to come.
It became clear that any numbers being entered are interpreted as hexadecimal values. Thus, when I type 10 to the interpreter it stores hex /0010 in the word, which is decimal 16. The internal character set used by FORTH has the digits stored as hex values 00 to 09, then the first six letters stored as 0A to 0F. That is handy, because a valid number has no character higher than /0F and matches the hex values directly.
If characters other than space are entered and don't match a word in the dictionary, it is stored as a literal hex value if it is legal hex, otherwise the interpreter reports an error with a typed ? mark.
The Enter key and Backspace are not implemented in the system as it comes up, thus if you try to terminate a line with a CR or Enter, you get a ? error. Some verbs such as REPLY will return the carrier to the left margin and type a prompt, otherwise the verb $ will do a return and type OK.
Bob Flanders and I will try to put together a forth verb that will convert the top of the stack into a sequence of four characters, then print them on the console. That will make life easier as we continue exploring original FORTH.