One of the seven model 729 tape drives had been sporadically unloading the tape when it was made ready, something that could be triggered by shaking the drive or walking heavily alongside it. Today, it became a solid problem, one we could trace down.
I found a logic input to a gate sitting at ground, but it was an IBM type N signal which is ECL with a typical 0 value of -0.3 to -0.4V and a typical 1 value of 0.4 to 0.6V. Ground is in the forbidden zone, between -.4 and +.4V. No properly working source would drive a line to 0V.
We identified the cards in the signal path that were the source for this signal, reseated the card and resolved the problem. The drive now works properly with no spontaneous unloading.
The card sorter has a single read brush that is moved on a threaded rod to place it in one of the 80 column positions as cards move under it at right angles. The brush was bent up and due for replacement. With a new brush in place and adjusted, the sorter sorted again.
XEROX ALTO - DIABLO DISK TOOL CREATION
Ken Shirriff, computer archeologist and cryptanalyst, continues to tease information out of our logic analyzer traces collected last friday.
He determined that the drive read sector 0 of cylinder 0 correctly, with proper checksums on all three records of the sector. The data being written into memory matched the instructions that the Alto then fetched and tried to execute as the boot code.
The instructions being executed were not the boot sequence, and seemed a bit nonsensical. We were preparing to check for problems with memory, instruction decode or other aspects of the execution when Ken noticed something about the data that was being fetched.
The values matched the pseudo-random sequence produced by the Diablo Exerciser utility program - it begins with the same seed value and outputs the same sequence every time. It is used to 'wipe' a disk, putting gibberish on the cartridge to overwrite any prior contents.
Therefore, we conclude that our failure to boot from this cartridge is indeed due to lack of boot code in sector 0, because it had been wiped using DiEX. This presents some opportunities and challenges.
The obvious challenge is that we currently have nothing to boot onto the Alto, at least not this cartridge. The opportunity is that this is now a good pack to use as I debug my disk tool, since I won't be jeopardizing any good data.
Ken has gotten a couple of additional cartridges from Xerox PARC, which may contain bootable software, but we are also receiving a cartridge with diagnostics from Josh at the Living Computer Museum, which is what we will use to boot from initially.
It is critical that we retrieve the existing content of each disk cartridge and archive it before we do anything that might write on or corrupt it in any way. I am working to have my tool ready to read the cartridges this Friday, starting with the 'wiped' cartridge we have, then when we are comfortable with its readiness, pulling data from the cartridges we got from PARC.
With assured data on hand, I can then test the ability to read, write and update the primary cartridge. The ultimate goal is to take an archived cartridge image and write it to the primary cartridge, converting it back into a bootable disk.
I picked up 100 pairs of resistors to use as terminators for incoming signals to my fpga extension boards - the best choice for cable compensation turned out to be 120 ohms to +5V and 300 ohms to ground. I installed pairs on all nine input signals on the board, a somewhat tedious process on the prototype board which has seen quite a few modifications already.
I built up FSMs to drive the transactions from the PC, where the user can command the fpga to read a sector, write a sector, update only the data record of a sector, update both label and data records of a sector, seek to a target cylinder, plus later to read or write an entire cylinder at a time.
This included FSMs to produce status back to the PC, in support of the transactional protocol and to reflect various error conditions if they occurred. Not all the error conditions are reflected at this time, but eventually will be.
I hope to be able to begin simulating the proper operation of this logic, triggered the new way, which will be the critical path to Friday's test session. I was able to fire off transactions one at a time using some temp code linked to the simulated buttons.
Write sector works just as expected, but read sector is a bit off in my first tests. I need this to work properly before I can test the mode switching 'update data' and 'update label and data' transactions. It may be a misalignment of the bit stream from the testbench, but I have to pour over this very carefully tomorrow.
One last test before I went to sleep - trying some seek operations. The state machine worked fine, the logic dropped the 'strobe' signal once the 'disk drive' responded with 'address ack'. The 'drive' had dropped the 'ready for seek/read/write' until the end of the simulated head movement, when it went back on, releasing the machine and signaling completion.
The transactional mechanism, using the registers written and read from the PC, was also tested for the seek operation. It looked solid as well, at least as simulated on the testbench. Tomorrow, when I finalize testing of the modified extender board, I can hook things up and see if I can command the appropriate actions from the PC.
No comments:
Post a Comment