Driver board PCB designed, prepping for manufacturing and components ordered

ALTO DISK TOOL

I did battle most of the day with the DesignSpark PCB tool attempting to get a good quality board designed. A reasonably large board, 4 x 6", less than 40 components, and building it as a four layer board, which shouldn't be challenging. However, I may have to hand route everything.

I finally spotted a problem, that the ground and power planes in the four layer board weren't being used for ground and +5V. That cut down on routing and had the added advantage of handling the fairly beefy current requirements of the peripheral driver chips, which can sink 150ma per signal line when it has a logical 1 value. The worst case is during a seek command, with multiple track lines active plus the strobe.

The next step was some intelligent placement of the components, knowing how they need to be routed, to minimize crossing paths and conflicts. The pull up and pull down resistors that form the terminator for the input signals were the major factor in congestion, thus they were the major focus of my work.

I also moved the filtering capacitors and the peripheral driver chips to make more room for signal paths on the board. The result was a good clean routing with no manufacturing check conditions. With that complete, I produced the outputs needed for board manufacturing - gerber and excelon format files for the various layers and drill holes.

I will order two boards and enough components to build 4 or more boards- connectors, chips, resistors, and capacitors, which will let me complete the boards once everything gets here.

The foundry I chose, 4pcb.com, has a free service to analyze the files for manufacturability issues. I made use of it and found quite a few niggling errors and one significant one that slipped past the design checks of the DesignSpark PCB software. Time to iterate until I get satisfactory results from the foundry's free check software.

Write sector confirmed to work with new driver board, time to convert it to a PCB

ALTO DISK TOOL

I set up the contents of cyl 0 head 0 sector 7 from the archived disk image, loading it into RAM, and then issued a WriteSector transaction. The sector read back in without checksum errors. I ran the tool to ReadEntireCartridge into RAM and dumped both the RAM and validity check vectors out.

Unfortunately, there is a complication with the Digilent utility that does the upload and download of RAM. It advances the RAM address registers Reg1001, Reg1010 and Reg1011 while it loaded RAM, but does not reset them. Thus, when I thought I had dumped RAM out, I was beginning in RAM at the wrong point, producing garbage. The validity bit vector contents use their own address registers, Reg10001, Reg10010 and Reg10011 so that they worked properly.

I had to fire up the testbed again, ReadEntireCartridge again and then dump this with the RAM address registers at 0. That would allow me to post-process the file and compare the archived disk to the bitsavers image.

I found that the file read from disk was about like the last time and that the sector I had written was retrieved with zero errors, as an exact match. This completes the checkout of the new board, which I can now use in all further activities.

It is time to turn the driver board into a PCB, eliminating any point to point wiring. I will fire up a PCB design tool, draw it out and submit it to a foundry to produce several copies.

Tomorrow it will be time to resume studying the exact conditions under which sectors get a temporary or permanent checksum error - looking for anything that can be mitigated, corrected or anticipated in the pursuit of an even lower error rate. 

New driver board seems to be working properly; built logic to write an entire cartridge in one transaction

ALTO DISK TOOL

Today I switched back to testing the new driver role board, since the logic analyzer connections and setup are mostly intact. The goal is to verify that the unit with the new board still seeks, reads and writes correctly.

I verified that the SelectUnit1 signal works, in that the drive won't turn on FileReady or ReadyToSRW unless I am selecting it, nor will it respond to commands. I also stepped it through the binary powers of cylinder address to verify that each Trackxx signal is correctly wired. I watched the heads move to the commanded values 1, 2, 4 . . . 128

Next up, I did a read of Cylinder 0, Head 0, Sector 0 which completed reporting no detected checksum errors. I also did a ReadEntireCartridge transaction and watched it walk through all the sectors, retrying on those that have problematic signals with intermittent or permanent checksum errors.

All the above looked good and I monitored the WriteGate to be sure we weren't turning this on inadvertently. It is time to capture the cartridge image as a test of the recovered data images, comparing it to the bitsavers archive version and to previous recorded images. If that passes muster, the final test is to write a sector from RAM and verify that it is read back properly; the board will be fully tested.

The captured disk image and checksum information was captured and then compared to the archived versions to see whether we seemed to be more or less reading properly. The results were quite good, similar to what I experienced with the original board.

The final test, therefore, will be to load a specific sector's contents into RAM, write it to the disk, and then read it back to verify that this works. I will undertake this tomorrow.

I did want to create a WriteEntireCartridge function, analogous to the ReadEntireCartridge but that writes an archived pack image downloaded into RAM onto a blank or scratch cartridge. We have various images from archives that it would be great to have on a disk, such as the Smalltalk system.

In most cases, we will just use the disk emulator role and not need a physical cartridge, but there is something satisfying about running the Alto from a real disk. This cartridge writing function will be a tool used only a few times, invoked as transaction code 5.  Testing will be difficult, as I need a known blank or sacrificial cartridge.

The logic was completed and synthesized, using the ReadEntireCartridge logic as a template, so that it has decent chances of working correctly on the first try, but can't try it until I have a sacrificial cartridge installed. 

Making progress on emulator role of disk tool

ALTO DISK TOOL

I worked my way through debugging the hangup of the state machines that should be continually 'reading' the contents of the current cylinder and head, making bits available to emit whenever ReadGate is on. I went through several rounds instrumenting the fpga until I found where it was hanging.

Looking at the code, my mistake glared out at me. In one step of the state machine, I wait for the SectorMark to go on, indicating we are at the beginning of a sector to be emitted. It was here I was stalling.

Since this logic supports two roles, a driver of a real disk drive and an emulator that substitutes for a disk drive, it has an incoming and an outgoing version of SectorMark. The emulator version is SectorMarkOut, while the inbound driver version is simply SectorMark. As you may suspect by now, I was waiting on the inbound SectorMark that will never arrive while in emulator mode.

After the usual lengthy run to create a new bitstream, I ran with the state machines hung in a different place, trying to generate the preamble. I needed to reload the serializer for each word, even though the contents didn't change, but I wasn't doing that during the countdowns.

My linkages to the serializer weren't working properly, which held up the state machine that emits ReadClockOut and ReadDataOut signals. Another round of synthesis and I was back to watching the behavior of the emulator. 

I am now seeing clock and data pulses emitted, but they don't seem to be in the proper relationship to the SectorMark pulse. Time to work out how to hook up the logic analyzer in order to debug this further. 

However, I want to go back to the driver mode, test out the new version of that board I built and make sure the tool is fully ready to read and archive all the cartridges we have on hand, including the personal cartridge of David Boggs which he has loaned us for this purpose. 

Getting all the data read and uploaded is a priority of the project, after which we can play around with some packs to install different software images such as Smalltalk. 

Ethernet board working in Alto, optical mouse working as well

XEROX ALTO II RESTORATION SESSION

Today we met to work on the Alto again. We had a guest, David Boggs, who is the co-inventor of Ethernet and the designer of the Alto ethernet controller board, accompanying Ron Crane. 

Ethernet efforts

We traced signals and worked on the board. I had brought an Ethernet transceiver, but we don't yet have the cable that connects the transceiver to the controller board. Therefore, we used Ken's testbed for his ethernet bridge, monitoring the packets sent from the system. 

By the end of the day, we had good packets, thus only the transceiver and cable needs testing to wrap this up. Of course, we have to test Ken's bridge once it is through development. 

Optical mouse efforts

The optical mouse we have came with the wrong connector on the cable, which was incapable to hooking to the Alto. Al Kossow had a broken mouse with the correct cable and connector for the Alto - he donated the PCB and cable from inside.

The broken mouse he had was the Hawley mechanical type, which direct soldered one end of the cable to the PCB, whereas the Lyons optical mouse has a ten pin connector on the mouse end. I unsoldered the cable and Marc soldered the new connector on. When I reassembled the mouse and tested it, it was working properly.

ALTO DISK TOOL

I finally found my working 500K gate fpga board and began to resynthesize my logic so that I could continue testing with that board later today when I returned home. However, events conspired so that I did not get to work on the debugging at all today.

Prepping for next Alto restoration session, debugging emulator function of disk tool

ALTO DISK TOOL

I made progress on the emulator role, which is now reliably modeling the rotation of the disk, emitting SectorMark signals and the proper SectorNumber values. However, I am getting nothing from the ReadData and ReadClock lines yet.

I saw a few polarity errors, where I was blocking the outgoing signals on the wrong condition of such states as SelUnit1 and FileReady, which I corrected. I still didn't see the read data emitted, which I traced down to a test bed flaw that was commanding continual seeks. This forces the ReadyToSeekReadWrite line off, blocking the read process.

ALTO II RESTORATION TASKS

I picked up a few items we need for our next stage of work on the Xerox Alto II we restored. One of the mice we have is the optical type, the Lyons mouse, but the cable on it did not match the connector on the Alto. As well, we are early in working on an Ethernet bridge but don't have ethernet working as yet.

Al Kossow had a broken Hawley (mechanical) mouse and donated the PCB with its cable to us. On the Hawley mouse, the cable is directly soldered onto the PCB but uses a ten pin Amp connector to hook the cable to the Lyons mouse.

I desoldered the cable from the PCB, soldered on pins and inserted then into the AMP housing. Hopefully it will work properly when we hook it onto the Lyons mouse tomorrow.

Al also loaned as an Ethernet transceiver, which  we did not have, so that it is easier to debug than our attempting to drive the controller card with a BeagleBone developed by Ken. Once we know the board is working and that we can study all the signal timings to make the BeagleBone unit work right.

Tim will bring over another transceiver too, just to be sure we have one that works properly. Both of them are set up to connect to a 75 ohm coaxial cable, the actual ethernet line used with the early 3 Mb LAN. We need a 75 ohm cable of at least a half wavelength and a terminator. Hopefully we will have a cable on hand. 

Switched over the 1200K fpga board as the other board was unusable

ALTO DISK TOOL

While waiting to find/buy a new USB cable with a better fit to the fpga board, I can't run the disk drive when the fpga is randomly resetting or emitting incorrect signals. I will switch over to debugging of my emulator role in the interim.

Unfortunately, the situation with the connection and the fpga board is bad enough that I couldn't get the board to respond even in emulator mode. I se up a few diagnostic signals and synthesized so that I could look again when I returned from my day with the 1401 restoration team at CHM.

I found another cable and had the same very erratic behavior with the board. Since I have another fpga board, I used that instead but it is the 1200K gate version, not the 500K gate variant. Something is wrong with the USB link on the 500K board.

I had to resynthesize for the 1200K configuration before I could test the new board. This also required some config changes to the UCF file because the 1200K version of the board hooks four of the LEDs to different FPGA signals than with the 500K board.

I began testing the emulator function, slowly working through the logic to get it working. Glad to be moving forward again. I also have a reliable board now which will let me hook up the new driver board and test it out.