I started the short CE program to test the typewriter, verified that backspace and forward space was working when commanded by XIO instructions, then began the final reassembly of the typewriter, fastening the cover on it and replacing it in its nook on the 1131 table.
I had some mechanical challenges with the cover, but it is now in place and loaded with paper properly. Once I have my SAC Interface and new GUI working well, I will exercise this further to get it typing well. For now, it is good enough.
XEROX ALTO RESTORATION
Now that I am back from my trip overseas, I jumped back into the vintage tech waters by joining some team-mates yesterday for a session restoring a Xerox Alto. It was given by Alan Kay to Y Combinator who asked one of us to restore it to operation. Prior to this day, we had checked out and repaired the power supplies and the team coaxed the Monitor into operation.
During our workday, we provided power to the main Alto boards for the first time, when we tried to initiate a boot from a disk cartridge. To get to this point, we had to work on the disk drive - a Diablo Series 30 model 31.
The disk drive is a 2315 cartridge style drive, similar to the one in my 1130 system but differing in two important ways. First, it had the high density option which records twice the bits per track of the 1130, to double cartridge capacity. Second, it used packs with 12 physical sector marks per rotation as the Alto formats the disk into 12 sector tracks.
The cartridge is a single 14" platter in a case, which slides into the front of the drive. The drive has a pair of heads, allowing use of both surfaces of the platter. The drive mechanism forces open a door at the tail end of the cartridge so that the heads and arms can enter the cartridge and fly on the platter.
There is a spring loaded metal plate on the bottom of the cartridge which is forced open by the drive mechanism and through which air is forced to supply dust free clean air over the disk surface. The mating surface to this opening in the cartridge has a foam gasket to channel most of the air inside.
We first cleaned the drive and inspected the air plenum and supply of clean air. This is essential to avoid dust and other particles which can cause a head crash. The main air filter is a two part unit - a HEPA filter to eliminate very fine particles, with a plain foam strip in front to block grosser particles. The main foam strip was deteriorating, with the plasticizers turning it into a goopy material which would not pass air properly.
We removed the foam 'pre-filter' and inspected the HEPA filter. It looked very clean, as if it had been recently replaced with a new part. After cleaning out the air plenum we moved on to the foam gasket that mates with the cartridge.
As expected, the foam gasket had also become partially liquified. When compressed, it would not spring back into position. It was also beginning to be friable, breaking off bits that would be a hazard for the heads as they flew mere microinches above the platter surface.
We removed the foam, cleaned it up and put in a temporary gasket made from layers of soft weatherstripping, although we want to eventually replace it with a more suitable foam.
Next, we turned our attention to the rotary actuator that moves the arms in and out of the cartridge, to seek to one of the 204 cylinder positions. It moved freely and smoothly. The disk heads looked quite good, but we cleaned them with 99% isopropyl alcohol and lab quality wipes.
The disk cartridge was opened and the two surfaces of the platter were similarly cleaned with our 99% IPA and Kim Wipes. The cartridge itself was wiped down to remove any dirt it may have. Visually, the disk platter was pristine and the cartridge was quite clean in the condition we received it.
We walked our way through bringing up the drive in steps. We first ran a few startup cycles which we terminated before it tried to load the heads onto the platter surface, to ensure that we had good air flow and reasonable behavior.
Next up, we disconnected the heads electrically and took the drive to a full startup. The drive spins at overspeed during startup, for roughly 90 seconds, which is intended to purge the cartridge of any dust laden air and dislodge any particles from the spinning platter. It then loads the heads onto the surface and throttles back to its target speed of 1500 RPM. The drive completed startup and lit the "Ready" lamp.
We tried a few power up cycles on the whole system - powering on the Monitor and Alto, then loading the disk to its Ready state, finally pushing the red "boot" button on the back of the keyboard. Nothing happened, except that we had a nice white raster pattern to further adjust our CRT. We got the width, focus and some other settings optimized, but were seeing no signs of life. We also had no seeking on the disk drive.
We reached the end of the work day at this point, which was a good time to do some research in preparation for debugging the system when next we meet. There are a myriad of possible problems that could cause this behavior, among them:
- Alto CPU is not running
- Disk drive is now working properly
- Disk controller card is bad
- Disk cartridge does not contain a bootable image
- Configuration of the Alto is not correct to attempt a disk boot
SAC INTERFACE FOR ADDING PERIPHERALS TO THE 1130
Restructuring the GUI
I began today to debug my SAC Interface and GUI interaction, after all the code changes and the disruption of my lost PC hard drive> I set up several diagnostic LED signals on the FPGA board that will help me track down where I am stalling in the protocol between PC based GUI and FPGA.
The bitstream was loaded into the FPGA and I fired up the new GUI program to work on the sync issue. When I ran the old version of the GUI, it worked perfectly with my FPGA load. Next, I found the new version of the GUI code and gave it a shot. It resides on my recovered PC, not on the Linux based tablet where I ran the old GUI. Thus the problems could be PC and toolchain related, rather than my new code.
The new GUI, running on my restored laptop, times out in the routine that fetches status from the 1130, however the FPGA diagnostic LEDs imply that it is not seeing the transactions at all. Thus, the odds are highest that this is a problem in the WinUSB, PyUSB and wxPython library interactions, but it certainly could also be a flaw in my code.
I will change the fpga diagnostic LEDs to show me if the FPGA ever receives a transaction from the GUI on the PC. If I can exclude the FPGA entirely, I can concentrate all my investigations on the PC side. It is time to barbecue so the testing will resume tomorrow.
No comments:
Post a Comment