Setting up emulator role testbed and building out test mechanisms

ALTO DISK TOOL

I am using a short breakout board from Digilent to give me access to all forty of the IO pins that exist on the FX2 connector of the fpga. I use these 40 pins to drive outputs and receive inputs from the Alto (or the Diablo for driver mode), with the custom PCBs I made used to convert voltages between 3.3 and 5V, provides terminator and pull-up resistances, and drive outputs with over 100ma apiece.

Short breakouit board

FPGA board

I don't need 5V nor the high current support for my testing, thus the short board allows me to wire up the input and output signals to the other IO pins of the FPGA so that I can drive my logic within the same board.

The PMOD connectors support 28 such signals (plus 4 that are shared with LEDs). Since I only use 15 input and 12 output signals for the emulator, the 28 PMOD signals are sufficient to driver/check all the signals.

I spent the day assigning the PMOD pins for each of the active input and output pins on the FX2, but didn't wire it up because I will be bringing the FPGA board to the Alto session tomorrow to do the archiving and other work. However, with the assignments known, wiring will be quick and I can set up all the test mechanisms that will drive the testing.

Tomorrow we will use the disk tool to archive all the cartridges on hand, then write over the previously erased cartridge to give us the 'games' archive image with a plethora of games that were used on Altos. 

Building out testbed to work on emulator role of Alto disk tool

ALTO DISK TOOL

I worked out a method to inject the proper signals to test out both reading and seeking operations of the emulator role, using loopback from diagnostic output signal ports back to the relevant input pins. Although it was my day to join the 1401 Restoration team at CHM, in the late afternoon I coded up the mechanisms to produce the signals that an Alto would.

When slide switch 2 is turned on, with the emulator board attached, the emulator testbed will loop back SelectUnit1In and ReadGateIn which will cause SectorMarkOut, SectorNumberOut, FileReadyOut and Ready2ReadWriteSeek to be generated if a virtual cartridge is mounted on the emulator.

If I push button2 while a virtual cartridge is mounted and switch 2 is on, it will trigger a sequence of loopback signals to drive a seek. That is, the loopback will deliver TrackNumberIn and StrobeIn. If the emulator responds correctly, I should see AddressAckIn and Ready2ReadWriteSeekIn respond, with the new cylinder value I injected in TrackNumberIn appearing on the seven segment displays.

Independently, I will loop back HeadIn based on switch (1) just to verify that the Head value in the seven segment displays changes appropriately. I don't have an easy way to test writing to the emulated disk, especially to update some but not all records of a sector.

All drive boards and cables working correctly, buffed up documentation

ALTO DISK TOOL

Board 2 with the new Diablo cable was not working properly, not reacting to when I turned on the SelectUnit1 signal via the slide switch. That signal is driven by one chip on my driver board which began to work when I pressed down on the leads. This tells me there is a bad solder joint there which I need to correct. When it worked, the file was extracted flawlessly.

After closely examining both boards 2 and 3 under the microscope and redoing any connection that was not clearly perfect, I retested the two with my new cable. Board 3 still does not select the disk with SelectUnit1 and let the FileReady signal activate, but board 2 now works perfectly. The extracted file matches 100%

Back to the microscope and the continuity tester for board 3 - this one is annoying me. The problem has to be in the lines for SelectUnit1 or the incoming FileReady signal, so it won't take too long to check it out (again).

Well, I had checked that the lines had continuity from input and output connectors and that the solder connections on the eight pins of the chip looked good, but I obviously didn't look to closely at the chip itself. It was soldered on upside down (not rotated 180 degrees but with the face downward on the PCB). Doh.

Chip mounted with bottom face upwards

It was a quick matter to remove the chip with a hot air rework tool, clean up the pads and solder on a new chip, this time oriented correctly. With that done, I took it over to the testbed and attempted to use it to read the cartridge image again.

This time it worked perfectly, extracting the entire cartridge and that image compared word for word with the known contents. Now I have three good boards and two good cables. I will be delivering a set to Al Kossow for use in archiving all the Alto cartridges he has.

I spent a bit of time updating the documentation to deliver with the tool. It should be usable immediately but I will go over its use one time when I deliver it.

The remaining time on Tuesday I put into planning for testing of the emulator role functionality for the tool. First come the schemes for how to drive the tool without a real Alto computer, then the mechanisms to implement the schemes, and finally the instrumentation needed to debug the tool as it attempts the various actions driven by the schemes. 

Doing some cleanup of logic and chasing temporary cable issue

ALTO DISK TOOL

Video of tool seeking to read cartridge in a single transaction

Disk tool ready for use

I did some cleanup on the testbed and the fpga logic and discovered a flaw in my disk driver tool functionality. I am working to resolve it, which shouldn't be too long because the flaw can't be too subtle or complex.

It appeared that I when wrote the disk image to the cartridge, I may have stuttered or repeated the second head information on both sides of the cartridge. Or, my reading is always looking on one head and disregarding the head signal.

I will try some experiments to manually read a sector, controlling the head signal. I also  put the scope on the head control signal going into the Diablo drive to observe whether it worked or did not. At the same time, I moved over to board 1 and my newly built PCB to Diablo cable. I verified connectivity and saw the head signal switching back and forth as it performed a ReadEntireCartridge.

With the extracted disk image file converted over to an archive format, I did a word for word comparison to the written image and had zero disagreements. This tells me that either board 2 is failing or its connector to the PCB to Diablo cable was loose. I will switch over to these and see how they perform.

Board 2 and its cable were reconnected and I attempted to read the disk again. I found that the ready status was intermittent and jumped around when I lightly touched the connector. I decided to remove and replace the connector on the cable.

In addition, I did some checkout of board 3, which I suspect was really the defective cable causing symptoms. I will put the rebuilt cable on board 3, verify its operation. I know that board 2 works properly when the cable is good. Alas, board 3 is NOT working properly.

I swapped the cable back to board 2 and tried one last time, since it was late at night. It still didn't work properly. I removed the new cable and rigorously checked each connection, which proved to be flawless. At this point, I don't know what is wrong but I will dig into this and figure it out.

Testing emulator role

ALTO DISK TOOL

I have built three disk driver role PCBs, bench tested them but decided to run them with the tool and disk drive to be sure they all are working up to snuff. Serial numbers 1 and 2 worked fine, but number 3 didn't perform the ReadEntireCartridge transaction when I pushed the button. Back to the bench for more testing.

Next up is testing and completion of the disk emulator role, which uses a different emulator role PCB to interface the signals to the FPGA. The boards themselves provide a hardwired two bit 'type' signal that informs the FPGA which board is plugged in.

My 40 pin IDC connector on the end of the Alto to tool cable came off, because I didn't secure it well enough. In addition to attaching a new connector on that, I am building another Diablo to tool connector with a connector, for use on the copy of everything I built for Al Kossow to use in archiving various media held at the CHM.

The ribbon cables used with the Alto have a ground plane bonded to the back of the cable, consisting of a fine wire mesh the width of the cable and a rubber cover. To attach IDC connectors, I have to first peel the rubber backing away, then remove the mesh wire ground plane, and trim the sides to fit into the connector.

Ribbon cable with mesh sandwiched underneath by rubber layer

I spent the afternoon thinking through how I might test the emulator role, given that I didn't have an actual ALTO computer on hand. Along with injection of test signals in specific sequences, I had to plan for monitoring various internal states on the logic analyzer which means that the signals must be brought out to the connectors on the FPGA board.

Fortunately, testing the read capability of the emulator is pretty simple. The tool operates by simulating the rotation of the disk cartridge at the same rates that exist on the physical drive. This means it emits the SectorMark and SectorNumber signals as they would occur. In addition, it is reading the RAM contents for the sectors on the current cylinder and head, giving a serial bit stream as it would appear on a real drive.

Thus, as long as ReadGate is asserted, I should see the entire track streaming cyclically from the ReadData and ReadClock signals I generate. I just have to capture them and compare them to the downloaded disk cartridge contents and the expected behavior. The logic analyzer can show me if the data bits are arriving when they should in relationship to the simulated rotation.

Thus, simply by holding ReadGate and SelectUnit1 on, I can verify the emitted stream that the Alto disk controller will use to read sectors when it wishes to. Seeking and writing behavior will be more complicated to validate.

For seeks, a drive and its controller have a specified 'dance' to perform, signals offered in prescribed order with tightly defined durations and spacing. This means that my test methods must handle the CylinderNumber, Head, and Strobe lines in the required patterns and watch for the return signals from the emulator that acknowledge receipt and indicate completion of the seek operation.

Writing is an activity where the disk controller in the Alto would assert WriteGate and EraseGate, then emit pulses on WriteData&Clock to properly record magnetic flux changes on the right area of the disk track. My emulator should strip out the data from the clock and write the data into RAM at the proper location for the cylinder, head, sector and record.

I could grossly check this by downloading a known cartridge image into FPGA RAM, doing a 'write' of some alternative content for the sector, then upload the RAM to verify what was changed in RAM. There are three possible ways that the Alto will do writing: entire sector, data record of a sector only, or data and label record of the sector.

The first of the three is easy, as the data coming in to the emulator fully replaces the contents of the RAM for that sector number. The other two must be reading the record(s) that are not replaced from RAM, then switch to write the subsequent record(s) when WriteGate switches on.

The disk controller won't turn on WriteGate until the gap between the unchanged records and the following ones, thus the timing of what I produce to test this must be accurate. It must be at the proper time relative to the stream coming in from ReadData, ReadClock and SectorMark.

Thus, the update style writes will be the hardest to prove out in the absence of a real Alto to drive the tool. If I can validate everything else, I will then work on the complex testing needed for the updates. 

Appears I have significantly improved the disk tool reading capability, ready to begin archiving

ALTO DISK TOOL

I uploaded the data from the test of my newly crafted logic for recognizing incoming data bits and found that absolutely zero sectors encountered a checksum error while reading. That is a 0% error rate, all I could ask for.

The data appears to be a faithful copy of the disk cartridge, although it does not match word for word the archive on the internet which I assumed it was from. 135 of the 4782 sectors have differences between the two versions.

I repeated the run just to confirm that checksum processing is passing on all sectors. I had the slide switch set to stop immediately on the first checksum error while reading an entire cartridge, yet had no stops. The data was identical to that I uploaded on the first run.

In addition, with a method that appears to read perfectly, I will attempt to read some cartridges on the Diablo drive attached to our restored Alto on our next session this Friday.

When I tested the disk tool on the real machine's drive to write a known image to our erased cartridge, the resulting data did not boot properly on the Alto. I need to do more debugging to determine why my WriteSector and WriteEntireCartridge appears to be malfunctioning.

These are essential in order to take archived images and restore them to cartridges, opening up the restored Alto to all the saved software that is accessible, whether from Bitsavers, PARC itself, personal Alto cartridges owned by various former researchers, or from LCM in Seattle.

I will retest my writing method by loading the known image of the cartridge XMSMALL, which is what I think I have on hand, into the disk tool. Then, I will rewrite just the first 24 sectors since that first cylinder was accidentally erased some time ago. That done, I will again read the entire cartridge and do a comparison run. The first 24 sectors should be identical if I am writing correctly.

With all 24 sectors on cylinder 0 written from the backup archive image, I ran a ReadEntireCartridge transaction and uploaded the data I had read. Running the compare program of the archive image against what I read, those 24 sectors are an exact match.

I did see an anomaly where the data in the latter half of the cartridge, beginning with about cylinder 71 up to the end was massively different now. I don't know why this would be, unless it was some error in either the format conversion program or in the compare program, since I hadn't moved the arm from cylinder zero when I was doing all the writing. I also power cycled everything before doing the read of the whole cartridge.

I may be experiencing a flaw in the function which reads the contents of RAM up into a PC file. I can check that by doing another run to read the cartridge, then comparing it to what I just saw. The new run was about the same as earlier today, with cylinder 0 an exact match but the roughly 130 sectors with minor differences were still there.

I converted and mounted the disk image I had just extracted on the ContrAlto simulator and was able to boot it up successfully. I am feeling quite good about the state of the tool today. I anticipate a successful session on Friday where we can archive all the packs on hand as well as writing the games image onto our previously erased cartridge.

Just before dinner, I converted the online archive image for XMSMALL into my format, loaded it onto the disk tool and then extracted it again. This will test whether the Adept functions are reliable. When I compared the archived image I had downloaded to the extracted image I uploaded, they matched 100%.

After dinner, the archive image was loaded again and I did a WriteEntireCartridge operation. This should leave me with a disk that is an exact sector for sector equivalent to the archive image. To test that, I would take the pack, perform a ReadEntireCartridge operation and process the file for comparison.

The data I read from the cartridge was compared to what I wrote, which was the XMSMALL archive image, and matched perfectly. 

Finished emulator board and tested a replacement method for clocking in data bits from disk

ALTO DISK TOOL

All my components came in, allowing me to solder up and check the new Diablo Emulator board. This one provides termination resistor networks for all the signal lines, both inbound and outbound to the ALTO, since the disk controller card itself provides none.

I verified every signal has continuity between inputs, chips, outputs and that all power and ground are good. The board is ready to use however testing is difficult since I don't have an Alto computer at home to hook it to. I will have to use a testbed for some testing and then bring it over to the home where we have the restored Alto system in order to test it in operation.

Worked through my replacement logic design, a new streamlined method for clocking in data bits to the deserializer from the ReadClock and ReadData disk drive outputs. If this dramatically improves the number of clean sector reads, it will prove that weaknesses in my prior FSMs caused the problems.

I ran a test but haven't had time to check the results to see if this works better than the old methods 

Logic changes and new microscope put to use

ALTO DISK TOOL

My new emulator PCB arrived, now I am installing the components but I had to order a few I was missing. I also took the time to go over several of the production driver boards to make sure everything is good. This included removing and reinstalling some parts whose alignment I didn't like as they sat.

I picked up a Leica binocular microscope mounted on a boom, which is extremely helpful in dealing with surface mount parts, soldering and rework. It is very easy to check that connections are good. In fact, the narrow soldering iron tip is enormous in my field of view and the thin solder itself looks like a thick pipe.

New microscope checking out driver boards

I devised an entirely new way to handle the ReadClock and ReadData pulses, which does not depend on timing at all, and am implementing it. This also changed the logic to turn on and sync to the read heads, and needed tweaks for the logic that shifted data into the deserializer.

Hopefully this will solve the read errors, otherwise I may have to bypass the data separator function from the Diablo drive to produce my own clock and data pulses. I am still, even after another week of looking, exactly sure what is the root cause of the errors.

I also worked to repair an FPGA board whose mini-USB connector was defective. It had previously been removed and I soldered in a replacement today. The only problem was that a trace had been broken to one of the connector pins. I have removed the protective covering over a portion of the trace that remains and will have to solder in a bridge wire to finish this off. 

Getting set up to test again

I have an FPGA board whose mini-USB connector was warped, needing replacement. Getting the five fingers lined up with the five narrow traces, plus soldering them and the four mounting tabs, was just too difficult to accomplish by the naked eye. 

My USB camera microscope with its 2D image didn't give me enough visibility, either, so I broke down and bought a used Leica stereo microscope on a boom mount. I have it and will begin to mount the replacement connector now that I can see the tiny parts. 

ALTO DISK TOOL

I hauled everything out of storage and began connecting up all the parts and monitoring leads, which will enable new testing to start tomorrow.