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.
Hi Carl,
ReplyDeleteThank you for mentioning my coining of the term "Proto-FORTH". I'm glad you liked it.
I had a spare Saturday morning available yesterday, and having found the scanned listings on SV-Fig, I thought I'd spend a few hours trying to work out just how this thing works.
The interpreter has just 29 primitives coded, and these have been chosen carefully, so that an assembler can be easily booted. The first 30 lines of the "forth" listing are this assembler. Once a simple assembler has been written, it makes defining the rest of the language a whole lot easier.
I puzzled why the "OR" instruction was one of the primitives - an unusual choice? Then I realised that OR was used every time Chuck wanted to assemble an instruction.
For example - here are the hex op-codes for some commonly used 1130 operations
.LD C000,
.ST D000,
.ADD 8000,
.SUB 9000,
.MUL A000,
.DIV A800,
Chuck then defines the various registers
.X1 100 OR,
.X2 200 OR,
.X3 300 OR,
.XIO 800 OR,
With just these 12 short phrases he can already build up a large subset of the 1130 instruction set.
By line 40 of the first page of listing, Chuck has a working assembler, so he can start to define the more common words such as DUP, DROP, SWAP, etc using the newly created assembler.
This is the fascination of how Forth is built up layer by layer.
By the bottom of page 2 of the listings, most of the common Forth words needed have been defined, and Chuck begins thinking about the main task in hand - which is to get the disk fully integrated into his system.
It would be great to have a machine readable (text) version of the listings - as being able to annotate with comments would be very useful in this piece of detective work.
When you think that all that exists here is about 2400 bytes of 1130 assembler - and a lot of that is the EBCDIC character conversion table, plus 220 lines of protoForth, listings - then rebuilding an understanding of 1968 Forth will take a fair bit of mental agility.
What would also be helpful is to define the Forth virtual machine model - from the various registers used and stack held in memory.
I have started to make some notes on the primitives, the dictionary format and anything else I can glean from working through the listings.
I am happy to share these notes with anyone who may wish to pitch in.
Hi
ReplyDeleteIt just occurred to me that if one wanted to see a printed number, one could stop the computer and look at it on the light panel.
Anyway, just a thought.
On the Diablo ( I have a Diablo 30 but only spun it up a couple time and not had time to do much more ) I was thinking, have you checked the RPM of the spindle? Mayby it is just spinning too fast. That would be consistent with reading well but poor writing. Also, try to degauss the heads.
On my Diablo, I have a disk that had a deep crash. The heads were OK after cleaning. No damage that I could see and seem to fly without issue.
The problem is I'd like to recover the data on the working part of the disk. It is code and stuff for the Nicolet 1080 that I have. It is not likely to be read by anything but a digital scope or the Nicolet because of the unusual sector size( 3000 octal of 20 bit data ).
My question is, have you ever heard of someone filling in the rut so that one can recover the rest of the data?
Dwight dkelvey@hotmail.com
Hi Dwight. I replied separately by email but for other readers, here is the summary.
DeleteGood idea to check the disk speed, we will do that on the next session.
Yes, we have thought about ways to recover data from damaged cartridges. We can read the data on either side of the damage but would miss dozens of tracks by keeping the edge of the head away from the bad spot. Filling in and polishing the damaged spot is a way to reduce the lost portion of the pack contents, but would take extreme care and some careful and precise measuring methods to ensure the resulting surface is safe for the flying head.