1401 work, Alto Diablo tool work and a discovery about our Alto cartridge

Today I spent some time during the day with the rest of the 1401 Restoration Team at CHM. The systems are in pretty solid shape right now, but we did have a few defects to work on. We fixed a problem in a 729 tape drive, repaired the 083 card sorter, and improved the opening and closing of a cover on a 1403 printer.

 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.

Testing new circuits to level shift signals for Diablo disk tool

XEROX ALTO - DIABLO DISK TOOL CREATION

I rewired the disk tool driver board to use one bidirectional level shifter chip, containing four independent circuits, for the three timing critical signals, plus swapping in CD4050 chips which operate at higher frequencies than the original CD4504 choices.

Ken is picking up a couple of extra disk cartridges from Xerox PARC, one of which I will use to test out the disk driver role. I am working toward using it on the next Alto restoration team meeting, probably on Friday.

With my new components in place, I did some stress testing of signals through the extender board. I still have to tweak the terminator resistors on my side to clean up the incoming signals a bit more. That done, I had good enough results at 3.2MHz to move forward with the board.

I don't have enough resistors to terminate all the incoming lines, requiring a trip to Anchor Electronics tomorrow before I finish off the board.

High frequency testing of the disk drive level shifting circuits

XEROX ALTO - DIABLO DISK TOOL CREATION

I have some Sparkfun bidirectional level shifters that claim to support high frequency signals, which I decided to check before I tested the simpler resistor voltage divider network. I drove them with a 2MHz signal from the Digilent Analog Discovery module, using +5 and +3.3 power supplies.

Using the AD to generate the square wave signals for testing

The Digilent is not ideal as it provides only a 4V swing but that should still show me the effect on waveforms as it is shifted through these devices. To produce a similarly proportioned level change, I set the lower voltage to 3V. I don't care about propagation delay, but significant malformation of the pulse form will produce problems in reading and writing on the disk head.

The output waveshape followed the input very closely up to 2MHz, but did round off unacceptably up at 5Mhz which is far beyond the 1.6MHz operating rate of the disk drive interface. The artifacts I saw were ringing at the upper and lower flats of the signal, but very sharp rise and fall times with essentially no change in pulse width.

Just to be certain they work properly as uplevelers, I swapped the input and output, set up the Analog Discovery to produce a lower voltage swing and looked at the high level output. My first attempt, providing a 2V input swing with 3V low power produced just a 2V high side swing, with 5V supply, which is wrong.

Four channel up/down level shifting board from Sparkfun

This might be due to the limitations of the Analog Discovery, producing a 0 to 2V swing instead of 0 to 3.3V as it should be. The high side should still have pulled up to +5V, not lingered down at 2V. I will check over my wiring and retest later today.

I discovered that the +5V reference voltage was not connected properly. Retesting, I found that the signal did not get higher than the input value when running at 2MHz, but at substantially slower speeds, for example 100KHz, the signal pulled all the way up to 5V. The capacitance in the leads, MOSFET and the relatively high 10K pullup resistance results in this frequency limiting behavior.

I wired in a 1K resistor in parallel with the onboard 10K, thus increasing the draw on the power supplies but also hopefully hastening the pullup effect. I turned it all on and tested again. At 1MHz, this gave me very nice 5V signals with full pulse width. Still, at 2MHz, the rise from 4 to 5V was slower and the effect was a shorter on pulse.

I learned a bit more about the Analog Discovery, including the fact that I could set up the waveform much more granularly, so I then did my final testing with 5V or 3.3V swings on the signal and a frequency of just over 1.6MHz.

I believe I can drop the resistance further to get acceptable operation at 1.6MHz, with the circuit pulling 10ma from the rails. If this is in spec for the devices on the board, and safe for connected disk drive circuits, then I can ensure good high speed pull-up by adding parallel 500 ohm resistors.

Using a 500 ohm parallel resistor does produce exactly what I want - essentially identical input and output waveforms, if you ignore a bit of ringing caused by the rough breadboard testbed I set up. I tried it for both up and down shifting of levels with excellent results both ways.

Uplevel - yellow is 3.3V input at 1.6MHz, blue is 5V output

downlevel - yellow is 5V input at 1.6MHz, blue is 3.3V output

I did more work on the new FSMs - 'update data record of sector' and 'update label and data records of sector' - including better integration of these multiple FSMs sharing the Read Field and Write Field FSMs that do the work on the individual records of a sector.

Once all the coding work is complete, it will be time to test it all out including regression testing of the read sector and write sector machines. Since the update machines involve a mix of reading and writing, depending on the record in the sector,

I will make use of the data I set up in the testbench where I originally tested by read field and read sector logic. This way, I can see that it is properly reading the records before the write gate switches on and I begin 'writing' transitions to the disk.

I would need to build only two more major FSMs - 'read a cylinder' and 'write a cylinder' that will step through all 12 sectors of the current cylinder for each of the two heads. These will take at least 80 ms to complete, two disk rotations, plus the need to wait for sector 0 to arrive at the start.

Since on average we wait 20ms for our intended sector to come under the head, for a randomly issued read or write, it would take an average of 566 ms to read a cylinder in 24 separate IO commands, versus just 103 ms average to do this with the full cylinder FSM.

That comes to just 21 seconds for all 204 cylinders, ignoring the seek time to step 203 times. A seek of one track takes 15ms, so about 25 seconds would capture or write an entire cartridge. Reading an entire cartridge using individual read sector commands (4,896 invocations) would take about two minutes.

I am not convinced that this is a priority, since an entire cartridge can be read in 2 minutes without this work, only a 5.7x speedup on an already acceptable time. Thus, I will instead work on the final linkage of the read, write, seek and update machines to the transactional registers coming from the PC, so that this will be ready for use on the Diablo drive.

MISC TOOLING

I picked up two components that fit together to allow me to hook my 136 channel logic analyzer onto a SCSI bus and capture the signals during use. I have a couple of SCSI based 9 track tape drives that I would like to interface to my fpga based unit that adds peripherals to my IBM 1130 system.

However, I don't have any logic to drive a SCSI interface and I couldn't find any open source, no cost logic that I could leverage. This tooling will help me design my own SCSI driver for the tape drives.

Continuing work on disk driver tool

I am helping my wife with a fundraiser for Villa Siena, by building a mock Bavarian building front to be used as a backdrop for guest photos at the Oktoberfest fundraiser. Lots of sawing, measuring and so forth, but it is coming together well.

The sides of the building are eight feet tall the roof adds another four feet - hard to lift it up that high! Will be doing some of the assembly flat on the ground, then rotate the completed unit upright ninety degrees. It has to come apart for transportation, which complicates things a bit.

XEROX ALTO - DIABLO DISK TOOL CREATION

I wrote and tested the two new state machines, Update Data Record of Sector (UDS) and Update Label and Data Record of Sector (ULDS), which will leverage the existing Read Field and Write Field logic. The alter the preamble and postamble timing to handle the switchover from reading to writing.

These both begin by reading the first record of the sector, the header field. UDS will also read the second (label) field while ULDS will write new contents for that record. Both of these will write new content for the third record (Data).

I am seeking blank or sacrificial cartridges for the Alto that I can use to test out the write and update functionality in the real world. We have a couple of potential sources, but at worst case I will just have to use one of my spare fpga boards and connect my driver role board to my emulator role board. This way, I could mount cartridge contents on a PC, access it from my driver as if it were a physical Diablo, and see what happens as I read, wrote and updated portions of the virtual cartridge.

Building up the two new FSMs, both of which drive the Read Field and Write Field FSMs, means more muxing of fields since an address, preamble, count or trigger for those two machines can be produced by three or four of this higher level FSMs. It may be that the emulation role could involve adding more of such driving FSMs, thus this has to be generalized neatly.

I also set up a testbench to verify the ability of my level shifting circuitry to handle the incoming and outgoing disk head signals, which operate at over 1.6MHz. I set up my Digilent Analog Discovery to generate a square wave at that frequency, 0 to 5V swing, passed it through the circuitry to shift it down with 0 to 3.3V then display it on my oscilloscope.

As I feared, this circuit will NOT pass the high frequency signals I need. My second experiment will be with a simple voltage divider, which should definitely work right as long as I choose resistor values wisely.

Fine tuning of plan for sector updates on the disk tool

XEROX ALTO - DIABLO DISK TOOL CREATION

I had to do some deep thinking about exactly how to handle the case where I am updating an existing sector, which means that the header and optionally the label records are read, then the controller has to switch over to writing to write out the data (and optionally the label) record on the remainder of the sector.

This has two complications. First, the timing of the clock transitions when we begin writing are extraordinarily unlikely to match seamlessly with the clock transitions that were previously written on the disk. Second, the write pole is forward of the erase pole on the disk head, thus when we begin writing the space where we first write transitions has not been erased.

If the new clock transitions begin right after the previously recorded transitions of the postamble of the prior record, then will appear to be a 1 bit value and not a clock transition. Thus, if this happens at any time while the controller is trying to read, incoming data is corrupt. If it happens when the controller should be seeing a preamble of zeroes before the sync word, we get a false start to the record.

It takes about 2 microseconds for the erase pole to get to the point on the disk where the write pole had been when switched on. There will be remnants of the transitions written prior to this pass, until the erase pole reaches them. For that 2 us interval we may get false transitions.

There is no way to smoothly switch from reading old transitions at the end of one record and start writing the preamble of zeroes for a new record. If one were to look at a sector at the gap between one record and the next, when the latter record was written as an update, we would see:

• an interval of transitions every 600 ns, representing the postamble words of zeroes for the first sector
• an interval of 2000 ns when the erase and write gates are turned on
• the new clock transitions every 600 ns but not on the same schedule as the old transitions
• a few words of zero 
• a sync word of 0000000000000001 to start the next record

One could just start new clock transitions right when the write and erase gates are switched on. If so, there is a 2 us interval where there may be confusing overlap of transitions. Alternatively, one could wait the 2us before issuing any transitions, so there is a gap with no clock transitions.

The Alto always works on word boundaries, so the way it handles this cutover is the first case, producing some overlapping but not synchronous clock transitions. When the sector is first written, there are five words of zeros after a record, called the postamble, then three words of zeroes as a preamble before the sync word that starts the next record.

To handle a switch from reading to writing between records, the alto switches off reading but counts three word times (still in the postamble) before turning on the write and erase gates. The next word, word four of the postamble, has its first 4 bits corrupted by the distance between the poles on the head, but is more or less where the original postamble word was placed.

The controller continues writing the last postamble word and the three preamble words, then the content words of the record. When reading the sector in the future, the read gate is turned off after reading each sector, then delayed 4 word times to make sure the head is well past the corrupted section before it begins reading preamble words looking for the sync word.

I will change my write logic to begin with clock transitions immediately after turning on the write and erase gates, since this is how the Alto handles the disk. The remnant transitions only occur during the first word of switch on, but all the reading logic ignores data for quite a bit of time past that point.

When writing the first record of a sector, the write and erase turns on and 34 words of zeroes are emitted before the sync word. When reading the first record, the controller waits for the equivalent of 21 word times before it starts reading the transitions - far far past the corrupted first preamble word.

Similarly, when writing a new record after reading a prior record, there are three postamble words from the original version of the record, one corrupted word and a final good postamble word. The preamble of three words is written too.

Thus, when reading a record that was 'updated', the delay of four word times puts the head past the corruption point and lets it see about four words of newly recorded clock transitions before the sync word.

I will make the change to how I start up writing a field, to create clock transitions immediately after turning on the write and erase gates. That will let me build the Update Sector FSM properly, according to the scheme described above.

Found and fixed a bad chip in Xerox Alto II, writing sectors working in disk tool

XEROX ALTO - DEBUGGING AND RESTORATION

Today we dug through our logic analyzer traces to look for clues, while also changing our connection method to pick up the microcode address field. Previously, we had the ROM board on an extender so it was hanging outside the card cage. We put a clip around one of the ROM chips and picked off the ten bits of microcode address.

The new method used a specially made cable, replacing a short bridge cable that linked the ROM card with a control card in the next slot. Our special cable provided a set of pins onto which we could attach logic analyzer probes. This let us keep the card in its normal position and use the extender card for other purposes.

We noticed that the disk sector task is only called once, never again. There should be a wakeup every 3.333 microseconds as a new sector mark is delivered from the disk drive. No wakeup signals, so we put the disk controller card on the extender and began to debug with oscilloscope and analyzer.

We didn't see the sector mark pulses in the logic on the board, but it was passed through the board to a backplane pin. Tracing further, we saw the pulse entering the logic at the input to an schmitt trigger inverter, but no sign of it on the output pin.

We pulled the chip and tested it on the bench. It was a hex inverter chip and the one gate for the sector pulse was dead as a doornail. I looked through the schematics and noticed that one gate was unused. We didn't have a spare 7414 chip on hand, but could snip off the leads to the bad gate, bend up and solder to the leads for the spare gate and connect it into the circuit.

With that frankenchip in place, the sector mark pulses were passed into the logic, the disk sector task awoke every sector, and we were able to trace the boot logic reading the first sector from disk. The disk command block in memory was fetched and checked, then the disk word task woke up four times but nothing occurred past that point.

There are many possibilities at this point. We could have invalid contents on the disk. The read signals may be corrupted. We may have other hardware issues to address, but this will depend on a very detailed study of what is occurring.

We had run out of time at this point and had to make copies of all the logic analyzer data and go off to study it on our own, before we meet again for the next session.

XEROX ALTO - DIABLO DISK TOOL CREATION

My write sector FSM is now working perfectly on the simulator. Next up is creation of the two update FSMs, to update just the data record or both the label and data records of a sector, after reading the existing header or header + label records

Then there needs to be logic to cycle through all 12 sectors, reading or writing them in sequence. This will make disk copies faster to perform.

Beyond that, I need to couple these read/write/update sector machines to the USB transaction registers so that everything can be controlled by a PC remotely. That will set me up to test with a real disk drive, once we have a blank or sacrificial cartridge to use for the testing.

I can also use the mechanism with a good cartridge to read all the data from it and evaluate or save it on a PC, as long as I ensure that the write mechanism is tied off and can't be activated.

write field working and write sector function seemingly works as well

Final day of my holiday at the Del Coronado hotel, flying home this afternoon. Tomorrow will be spent restoring the Alto itself.

XEROX ALTO - DIABLO DISK TOOL CREATION

I am working on a better representation of the state machines I will code. The usual diagrams for Moore and Mealy machines don't fully express what I do in my compact FSM style.

The issue is that the normal diagrams show outputs as either a fixed value for a given state, or a value that blends the given state with some input signals. However, I have some values which are emitted only during the transition from one state to the next, in other words they persist only for the first cycle of that new state but if it remains in that state for subsequent cycles, other values are emitted instead.

The values in question are not a steady output of the old state nor a steady output of the new state. While they are a combination of input signals and the old state, they aren't emitted until the clock edge when the FSM enters the new state. These don't fit the usual Moore and Mealy notions and the existing diagramming methods

I decided to show the one-time values being emitted on the arc that shows the transition. Normally these arcs just show the conditions that cause the transition, but I will add some emission notation from the arc, similar to the emission notation that is used from the state nodes.

This new notation helped me firm up my logic for the write field FSM, which as I said yesterday is a bit complex since it coordinates with several other FSMs. I did waste some time with bogus error messages from the Xilinx tool, wherein the error is claimed against some signal quite different from the real source of the error.

I had my new FSM controlling the 'load word' signal, but hadn't removed the connection of that signal from the input button 1 since I was 'toggling' the button in the simulator. The error should have said multiple drivers for signal load word. However, it instead complained about multiple drivers for the tristate mem_OE signal, wasting my time hunting for the real problem.

I ran the simulation on my write field logic, which helped me spot some weaknesses in the serializer and how it interacts with this new FSM. With that cleaned up, I appeared to write the preamble of 34 words of zero correctly and then move on to read memory and write those words. This trace will take quite a bit of time to check over, as I have to count all the transitions to be sure that I am not dropping or adding any bit cell times during the transitions through this state machine.

I looked through this more carefully and it still looks solid, so I moved on to build the higher level write sector FSM which will call the write field machine three times. That too looks good, but I didn't have time to check as carefully because my flight home was landing.