Sunday, August 20, 2017

Test generator installed in disk emulator version of disk tool, starting to debug


I updated my built-in test generator, which had been built to create input for the ReadClock and ReadData lines while I was testing the disk driver version. It now produces input for the WriteDataClock line.

I also added logic that will turn on the WriteGate signal for a portion of each sector when I push either of two buttons on the fpga board. One button will begin writing only for the data record, while the other will write during both the label and data records.

I wired these generated signals to the inputs they will drive and began some testing. I first loaded the board with the XMSMALL disk image, ran without any updates and verified that the image in memory remained untouched. Second, I would triggered an update of the data records of sectors, uploaded the memory image and checked to see if I had altered just the intended words.

The file upload from the memory is not working properly. I can see the ReadClock and ReadData produced by the disk drive, which match the image I downloaded, but when I upload I get zeroes. I can see the WriteGate condition flick on when I push the buttons, but without a way to pull the memory up to a file, I can't determine whether it worked properly.

I did make changes to the logic involved in memory access in order to add in the sector updating/writing logic, so that is the first place to look. I might need to organize some diagnostic output that can be captured on the logic analyzer if I don't see anything obvious. 

Saturday, August 19, 2017

Logic complete for disk emulator version of Alto disk tool


I ran quite a few simulations of the logic to watch the WriteDataClock line, get in sync with the clock pulses (entrainment) so that it can detect data bits, detect data bits properly, and switch on the sync state when it sees the first non-zero data bit value.

It worked well for various offsets, random variations, slower and faster rates. That code is locked into place. I turned to the logic to drive the deserialization - picking parallel 16 bit words from the serial bit stream encoded in the WriteDataClock input from the Alto.

It has to stay on the word boundaries, find the right pattern and signal when each word has been extracted. Those words are picked up and written to memory during write or update operations on the disk, plus an extra checksum word is sent at the end of a record which allows us to detect if we mangled the data stream.

This too needs a simulation that can present a longer bitstream after the sync word, more than two entire words, with a mix of 0 and 1 bit values. After I put that together, I ran the simulation, fine tuned the logic and ended up with machinery that will successfully look for the sync word and then extract words from the stream as long as it is allowed to stay in the synchronized state.

Moving up one layer in functionality, I need to finish the UpdateRecord machine that handles writing one record of a sector. All it has to do is:
  • watch WriteDataClock for the sync bit
  • extract each word from the deserializer
  • writing the word to the proper place in memory
  • accumulate the running checksum with each word
  • compare the extracted checksum to the calculated one
This machine is only triggered from the higher level UpdateSector machine if the WriteGate signal is turned on while the GenerateSector machine is in the preamble phase of a record. The UpdateSector machine follows GenerateSector in lockstep, but is setting up the addresses for memory control and counts that will be needed if the WriteGate goes on to update each record.

By late afternoon I had all the logic in place, but as yet untested. The emulator should work properly at this point. There is only one area where I deviate from the behavior of a real Diablo drive and that is when the Alto is writing to the drive, a real drive will echo the data back on ReadClock and ReadData, but I don't. One might have a diagnostic program that attempted to look at the ReadGate enabled stream while it is writing with WriteGate on, but due to a time delay this is nontrivial to do.

I began to mull ways I could simulate or build in a testdriver to do some testing without having a real Alto connected. This took some time. My earlier testdriver for testing the disk driver produces bits that look like the serial stream in from a disk.

I have to blend it to a shared clock and data line, to be routed into the WriteDataClock input. Too, I need a control that lets me trigger the three flavors or writing - write entire sector, read header then update label + data, or read header + label then update data.

I won't finish this today but I am planning the necessary changes and should get this together tomorrow. This is a internal test generator, only being used for debug. 

Friday, August 18, 2017

Xerox Alto work, donated Hawley mouse, and work on some other components


We received a donation of a Hawley (mechanical) mouse for use with our Alto system, provided by Dave Redell. It was very clean cosmetically, but had a few small internal issues. This mouse turns mechanical encoder wheels with multiple 'fingers' riding on the wheels, but one of the fingers was bent out of contact. 

The finger was easily corrected. We then tested the mouse operation and found it failed to work well with horizontal movement, but was great when moved up and down. Some investigation inside the mouse turned up some stuck bearings. They responded well to a light machine oil and some manipulation.

The mouse is a delight, smooth moving and very precise. The major downside of these mice is lint and dirt, which clogs the inside after it is used awhile. Regular cleaning will address this problem.

We turned our attention to the other Alto, belonging to Bruce Damer and his Digibarn collection. Having finally repaired the power supplies, we did a full load test on all of them. Some of them had capacities of 12 to 15 amperes, but the main 5V supply we tested to the 60A capacity of Marc's HP Electronic Load.

Next up was the CRT. The display was actually wired to hook to a more modern Xerox system, such as a Dandelion, which uses a remote peripheral bus that is completely incompatible with the Alto. Ken Shirriff investigated to find that the new protocol is implemented by a board that hooks to the original vertical, horizontal and video lines which are what our Alto wants.

Ken built a cable that interfaced the new display to the original Alto display connector. We hooked up the CRT test tool loaned to us by the Living Computer Museum. The screen stayed black, but when the power switch is flipped off the pattern from the test tool is visible, bright and clear, as the monitor image collapses.

We moved the monitor to the workbench and began tracing signals to find the fault. First up, we monitored the display sweeping and doing flyback. Next we traced the video input signal through the amplifier stages all the way to the connector that leads to the CRT itself. The signal is fine, which means we have a more subtle problem that is blocking the electron stream from hitting the phosphors on the tube face.

We ran out of time, but the next time we get together we will trace through the voltages and signals on the various grids and other CRT elements. Likely we will find one of the grids is markedly more negative than the prior one, due to some component issue. We expect that when the power switch is flipped off, some voltages decay faster than others, unblocking the stream for a brief time so that we can see the pattern on the screen.

We looked over three disk drives we have on hand (other than the drive in the Alto). All three have crumbling foam at the point where clean air is forced through the cartridge. Crumbling bits of foam will lead to head crashes, as we have already experienced. Next session, we have to clean and replace these foam gaskets. 

Thursday, August 17, 2017

Disk emulator role of Alto tool now handling read operations, working on write/update


Today I set up and validated the basic engine producing the ReadClock and ReadData signals that are emitted by the drive whenever the ReadGate is active - the disk continually rotates under the head and the bit patterns from each sector sequentially stream out through those signals.

Following that, I modified the logic to become the generator process that will build up a sector image. This begins at each sector mark and
  • counts off words of zero as preamble padding
  • emits a sync word for each of the three records
  • fetches data from memory to load the serializer for each word of the record
  • calculates a running checksum of the words for each record
  • loads the serializer with the checksum value at the end of the record
  • emits words of zero as a postamble padding
  • cycles bad to do preamble, sync, data words, checksum and postamble for the next record
Since a sector is comprised of three records - header, label and data - there is an 'inner' process to actualy emit the preamble words, sync, data words, build the checksum, send out the checksum and produce the postamble. It is called from the master generator process, given a count of words, memory starting address, and preamble count.

The key to everything is the serializer, which is loaded with words by the generate record logic at the appropriate time. It gets a request for the new word from the serializer after that process has shifted out each bit of the word to become ReadData pulses. The generate record logic just passes the appropriate new word to the serializer - zeros for padding, a sync word pattern, memory contents for data words and the checksum result - as the requests for new words arrive. 

I worked out from the serializer, making sure it was shifting out bits when the ReadClock pulse occured and had it ready for the ReadData pulse. Too, it had to issue the request to load a new word when it output the final data bit. 

With the serializer proven out, I then debugged the record generator, ensuring it fed the right values into the serializer. The scope shows a plausible stream of bits for the sectors but just to be sure, I will set up triggering for one specific sector number and carefully inspect the bit patterns to be sure they match what should be read. 

These match the patterns I should see, including proper checksums. I varied the cylinder using seeks and altered the head between upper and lower surface, further validating that the data patterns being emitted are correct. 

With the bits streaming out of the emulator properly, available for the Alto to do a read, it was time to build up the logic that supports writing or updates. When the Alto turns on the WriteGate signal, it will be producing clock and data pulses on the WriteDataClock signal line. 

FSMs must do a sync to the incoming stream to establish the clock vs data boundaries, since the input from the Alto is a combined signal that always pulses for clock bits but the span between clock bits will pulse only for a 1 value bit. This will occur when the GenerateRecord process is beginning its sync word phase, if WriteGate is on. 

Sync allows me to deserialize the incoming data bits, producing words. It will be slightly tricky to spot the edges of the incoming signal and determine the time of the start of a bit call, 600ns long. 

The required actions are:

  •  Pick off edges and match bit cell train when we are looking for a sync
  • Turn on sync state when the first '1' data bit is seen
  • Start deserializer
  • Feed deserializer with bit stream
  • switch off memory reading logic and begin UpdateRecord machine
  • As the deserializer fills, write that word into memory
  • Keep a running checksum of the data words
  • At the right time, compare the deserializer output to the calculated checksum
  • Flag errors in writing the records
  • Loop in higher level UpdateSector logic to track postambles and preambles
  • Higher level UpdateSector fires off UpdateRecord to regain sync and repeat
One possible error situation is an overrun, where my GenerateSector machine is ready for data words while the Alto has not yet issued the sync word. I may have to put in hold-off logic to force synchronization. The Alto is juggling various tasks in addition to the disk sector and disk word microcode tasks, thus the actual start of an activity has some jitter from sector to sector. 

I have a completely populated and wired board for the emulator role, consisting of the circuitry to shift levels between the FPGA's 3.3V needs and the TTL relatively high current signals between the Alto and a real Diablo drive. What is still to accomplish is to build the female socket into which the Alto's cable will plug.

As expected, aligning to an async incoming stream of WriteDataClock, determine which pulses are the clock pulses and attaining synchronization is difficult. First is entrainment, where I determine the start of the 600ns bit cell. This begins when WriteGate goes active and depends on the fact that the preamble is many words of all zero data bits.

After entrainment is achieved, the logic has to accommodate jitter, based on the real edges, to stay entrained. That means we can pick off data bits reliably. Sync occurs when the first '1' data bit arrives. The next bit cell is the start of the data words of a record. When the checksum has been read and compared, we drop sync but keep entrained unless WriteGate drops.

With the entrainment and deserializing logic built, the challenge was testing without a real async and jittery input stream. I turned to the Xilinx simulator and attempted to create a pulse pattern with plenty of jitter and edge cases, to see if my logic will properly entrain and extract data bit values as well as detect a sync state.

I am now working through the logic and the simulator results, fine tuning to yield reliable entrainment and then sync detect. It is now early evening and nearly time to shut down for the day. Since I have a session with the Alto tomorrow, the weekend is when the next burst of progress can take place. 

Wednesday, August 16, 2017

More code conversion and programming for the UofM card archiving task


I had volunteered to bring my Documation card reader and a copy of Brian Knittel's PC interface to the museum and archive almost 80 decks of cards that represent some experimental data from 1970. I captured an exact image of every card, lossless because it doesn't assume any particular encoding just captures all 960 hole positions per card.

I sent them to U of M along with the Deckview program (also from Brian) to allow them to look at all the card images. I described the file format, which is a binary file with a 16 bit word per column, thus 160 bytes per image. The column image has rows 12, 11, 0, 1, through 9 in the leftmost 12 bits and 0000 as padding.

I received an email asking why they aren't in Excel or CVS (sic) format as that is how they want them. I guess they don't have any programmers available there, so I dashed together a quick Python program to deal with the decks.

Almost every deck has a header card, which has a pattern of holes punched that forms big letters M, T and S each spanning six columns. The holes themselves that make up these characters are almost never a valid character. There is some other data to the side, including the MTS Job Number that can be tied back to the listings that wrapped the decks.

First card as captured
The remaining cards are numeric characters or spaces in Hollerith , apparently (by inspection) these are four column numbers, 20 to a card, right justified. Thus the number 639 would appear as " 638" while the number 1015 would be "1015" in its four columns.

Second and all subsequent cards seem to be 20 four-column integers

I really can't tell if these are indeed four column integers (what Fortran programs would code as an I4 format) or some other division into fields, thus dividing these into 20 fields by commas is pure guessword.

My quick program changed all non-numeric, non blank characters to asterisk, which only occur on the header card. The other cards had a comma character added after each number except for the last on a card. Viola, Comma Separated Values (CSV) that can be ready by Excel.

I hope this is the last I hear of this effort - a couple of days reading cards, each twice to ensure the data was captured correctly, plus all the dialog and now the data conversion.

Tuesday, August 15, 2017

Seek logic proven out in disk emulator version of the Alto disk tool


I altered the VHDL for the seek simulation to avoid a race hazard in the way I set the timer value for the next countdown in the FSM, then tested again. I first forced the time for the arm movement to zero allowing me to verify the settling delay of 14.4 ms will work properly.

It was essential to first change the button signal to a one-shot otherwise the Strobe line is held on, the seek state machine hangs till that drops, which elongates the seek to the time it takes the button to mechanically switch on and off. With the one shot I removed that factor.

I now have a 15 ms seek time, which is basically the settle time, regardless of the span of the movement. Once the rest worked and I had validated the calculated difference in cylinders on the logic analyzer, I added in the arm movement delay.

It now appears to produce the correct time delays for various seek distances. I did uncover one defect in my simulation. If the Alto sets the requested cylinder address to the address the drive has already attained, the ReadyToSWR line should not go off at all. It is a no-op in that case. For any non-zero distance, the line should go off after it sees the strobe leading edge.

My logic to control the ReadyToSWR signal needs refinement, therefore I devised a change, compiled it and tested again. It now appears that I have exactly the behavior I wanted. All the times are right on spec and the related signals work well.

I moved on to working up the logic that produces the signals that would be seen under the read head. That means at each SectorMark, we begin with the 29 words of zero, see the sync word, shift out the two words of the header record while accumulating a checksum, shift out the checksum and then insert ten words of zero before the next record in the sector.

Writing from the Alto will be compared against the continual read process above, to sync up against, then we will aggregate and write the header words, etc into memory and validate the checksum sent to us. The write logic need do little except look for sync words at appropriate times, fetch the words from the Alto, build the checksum and store away the words. Much simpler than the read process.

Monday, August 14, 2017

Debugging seek timing simulation


Testing resumed today, both with the oscilloscope and the logic analyzer. With what I have completed, I can check out everything related to basic operation, virtual disk spinning and seeking. This includes the signals FileReady, ReadyToSWR, AddrAck, LogAddrIntlk, Sect1, Sect2, Sect4, Sect8, and SectorMark.

It is important that they are the proper length and occur in the appropriate relationship to each other during operations such as seeking to a new cylinder. My test setup used a button on the fpga board to simulate the Strobe signal coming from the Alto, but alas it does not have a one-shot so that it repeatedly triggers the seek logic while depressed.

I added a stage in the seek logic that will not wrap up unless the Strobe line is logically 0. This does work although the button remains on long enough that I still could get additional cycles. Not with seeks that are valid, because my simulation of the time delay of movement adds many milliseconds to the seek process, long enough for my stab at the button to have switched it on and back off.

The time for a seek is not being properly set, thus I have to dig deeper into the logic that calculates the seek distance (number of cylinders to travel from current to new position), then waits 0.6 ms per cylinder moved. At the tail end of a movement there is a 14.4 ms delay while the heads settle into position.

I exposed the calculated number of cycles on a connector, hooked to the logic analyzer, and tried to capture it. Too, both the calculated distance and the calculated number of cycles are displayed on the seven segment displays as a quick aid. I found some flaws in how I was handling this and reconfigured the logic.

Somehow I get a delay of 200 ms minimum whereas I should have 30 us before an ack, 5 us for the ack, 600us for each cylinder moved and 14.4 ms for settle time at the end. That is, just over 15 ms not 200. Undoubtedly another case of VHDL that looks straightforward but doesn't work as intended.

Sunday, August 13, 2017

Disk emulator testing and further design


The disk emulator is now spinning up virtually when an image is downloaded to its RAM and the command is issued to turn on the drive. It goes ready and should be producing sector marks, rotating sectors at the proper rate and otherwise acting right. I hooked up the scope and did some initial testing.

The emulator was behaving correctly - all the signals I monitored did what they should. Sector marks arrived every 3.33 ms, with the sector number cycling between 0 and 11. The drive showed it was ready to seek, read or write.

I pulled a wire to cause the Strobe signal to go active, but with a cylinder request of 255 which is invalid. As expected the logic responded with a Logical Address Interlock condition since only values between 0 and 201 are valid for seeks.

I will set up the logic analyzer allowing me to check the timing of all the signals involved in a seek. Too, I have to see that all the lines respond as they should.


I popped open the scope and discovered that I had a wire loose. Soon fixed and my horizontal scan is back in operation. Unfortunately, still have the interference between the digital and the analog sections, causing dashes across signal traces and smearing sideways of digital characters.

Hmmm, guess there is something else to find and repair but I was close. The chip I replaced is indeed the switcher that determines whether the CRT horizontal plate amplifiers are driven by the digital or the analog side. I am seeing mixing of both - digital signals on screen at the time of the analog sweeps and analog signals interfering with digital signals.

Since my switching chip was blown out, but now works properly, I have to assume that the event that caused its failure also took out one or more other components in attached circuits. Time to study the schematics and look for candidates to investigate. 

Friday, August 11, 2017

Building disk emulator functionality to replace disk drive on Alto


Given the disk crash we had on our spare drive, which we anticipate is repairable with sufficient cleaning of the heads, and a crash that another Alto owner suffered last week, I decided to move forward with the disk emulator version. This version will attach to an Alto disk controller card and respond as if a real Diablo drive and cartridge were present.

I had worked out some of the logic simply to test the disk driver version and thought through most of the functionality in the past. I will fork off a version of the tool and begin logic development. In addition to different logic loaded into the fpga, it needs an alternate plug-in board that routes signals through output drivers and input level shifters.

The emulator board will require a female connector to which the disk controller cable will attach, but will implement terminators on board rather than requiring a specific connector for an external one.

It will drive 11 output lines and shift 15 input lines from the TTL voltages of the Alto to the 3.3V of the fpga board. By comparison the existing driver board implements 15 outputs and shifts 12 inputs.

The difference in counts, otherwise symmetric, is due to the elimination of the Erase Gate input signal for the emulator. Since we know that an Alto ties Write Gate and Erase Gate together, whenever we see the Write Gate line we know the value of and needn't sense Erase Gate.

Before I did anything, I backed up the current state of the Disk Tool project. I then found a way to copy it to a new project, the disk emulator. Only when I knew that changes to the emulator won't impact the disk tool at all, was I ready to begin writing VHDL.

I built a couple of the emulator boards assigning fpga pins as input or output, using the level shifter or driver chips and routing it to the appropriate pin of the connector that will hook to the Alto disk controller cable.

The logic is interesting working this way. Essentially I will have a continuously running process that "spins" the disk producing SectorMark, another that runs continuously to produce the clock and data bits for each sector as it passes under the virtual disk head. The outputs ReadClock and ReadData are gated by the ReadGate signal but otherwise being continually generated by the reading process.

Only when the WriteGate signal is activated will I block the reading of words from memory, decode the WriteData&Clock signal to form words and stick them away. Not sure how to handle the writing side, likely another process synced with the continually reading process. This will be the only tricky part.

The Alto will be giving me padding words, sync words and other content while the WriteGate is on, thus I have to shadow the Alto to know which are data words for the header, label and data records in the sector.

Thursday, August 10, 2017

Replaced my horizontal switching chip in Tek 7854, still not working (but different)


The new IC is installed on the PCB but placing that back into the scope is more trouble than I expected. The board is small, very roughly about 2" x 6", and is inserted through a cutout behind one of the four plug-in sockets in the lower bay of the scope.

I noted where the six coaxial cables and one other connector are inserted, but the bigger issue is the 9 slender wire rods that must slide through holes in this board. Each is a rectangular copper wire about 3" high standing off the lower common board and onto which my board must slide to make its contacts.

With the holes about 1/64" in size and spread across the board, I have to finesse nine separate wire rods into the holes simultaneously before I can slide the board down to its final mounting position. The slightest bend or miss-positioning of one is enough to block the entire board from sliding.

Fortunately I can look from the underside to see how these nine rods are touching the PCB. Thus it is just barely possible that I can use tools to hold the rods in position, with the board slightly tilted, moving forward so that earlier rods stay in holes but new ones are maneuvered to their holes.

The layout is one hole in the upper right, three along the left side from mid to mostly top, the rest down low and to the right. They are not as aligned as it sounds, except for one group of 3 and another of 2. This will take very good lighting and lots of patience.

Thursday morning I set up the lighting and lined up my tools for the first attempt. Placing the board over the pins was not difficult once I had tools that could reach the pins individually. I placed all cables back as they were originally and buttoned up the scope.

Now that it is installed and cabled up, it is time to test this scope out. The key will be ability to use both left and right timebases to sweep across the screen and to view un-distorted characters from the digital section. 

Drat! Not only did this not fix the original problem, but now I have no horizontal defection at all in analog mode from either B plug in. The digital mode characters still shake. The one ray of light is that the horizontal mode switching now works properly, choosing the left or right B plug in and alternating or chopping.

Something more pernicious is happening here. The digital mode sweeps, thus my new chip is at least connecting the digital left and right signals to the horizontal defection amplifiers. The analog left and right signals do not appear to be switched, however.

I will need to do some scoping of these signals, I guess, to figure out what is happening. Working hypothesis is that additional failed components are affecting the scope, with a less likely but small chance that my replacement chip is failing too. Something is wrong but I will put this aside for now until I am ready for the more involved digging necessary.

Wednesday, August 9, 2017

Exhibited Alto at VCF West, finished reading U of M card decks


I used my setup to begin reading the remainder of the six boxes of card decks from research conducted in 1970 and punched from the MTS timesharing system at UofM. I had some balky behavior for a time until I corrected a loose connection and tightened the power supply wiring. 

Documation reader, interface electronics behind and PC capturing card images on right


We brought the Alto to the Vintage Computer Festival West 2017 event at CHM over the past weekend. It took a few hours to load three cars, drive over, unload and set up in the festival exhibit area. Luck smiled on us - everything worked just fine for the two days of the show. 

Our Alto in our exhibit area, just before teardown at the end of the show
I was also committed to two panels to take place at the event. One concerned restoration of older equipment at the CHM, covering the 1620, PDP-1 and 1401 systems. The other was a presentation of our restoration of the Xerox Alto and a live demonstration. 

This did require us to haul the machine up onto stage and use a camera to show the screen image on the projector for viewing by the audience. We had a few gremlins interfere but overall it was a success. 

We also had the fortune to meet with and listen to the panel of original Xerox PARC researchers who went on after us. They shared stories of their time building and working with the Alto, plus answering audience questions. 


The custom IC that switches the horizontal signals and manages blanking during digital display intervals is now in my hand, having arrived from Rhodes a few days ago. Soon it will be back in the scope and I can check whether the problems went away.

Thursday, August 3, 2017

Dive into the Telex tape drives to assess the restoration work ahead, plus prep for VCF-West exhibit


I put some time into the documentation and exploration of the two frames I have. There are a few challenges ahead. The main one is that the model 266 is a dual frame unit, A and B, with one tape transport in each frame. However, the vacuum and air pressure for both transports are mounted in frame B, as is the main input power connector, while the integrated control unit is in frame A.

What I received is frame A but no frame B. No place to connect the power cable nor any supply of vacuum or air pressure. The second frame I have is a model 6 drive that fell off a forklift and has quite a bit of damage. This unit has a transport and a set of vacuum/pressure pumps for itself. It is NOT, however the B frame that is part of the model 266.

Therefore I have bought the typical "Pile-o-parts" and not a unit that would ever have worked as it was sold to me. The damaged model 6 frame was obvious but the lack of the essential B frame for the purportedly working model 266 is a challenge.

I believe I can cannibalize the vacuum and air pressure unit from the damaged model 6 and use it to somehow complete the function of the 266 A frame. I can't, however, restore both to operation until I get additional vacuum and air pressure sources.

The tape transport uses a 3/4 HP motor to drive a vacuum pump operating at 30 inches of water and a pressure blower delivering at 50 inches of water. I don't know the flow rates, just the static pressure when these are operating in an idle drive. 

The frame of the damaged unit is severely bent and part of the supply reel holder is damaged but probably fixable. The cards and other components inside don't appear damaged. Certainly it serves as a source of spare parts for the A frame if I can get that working, but I had hoped to come out of this with two complete drives. Still, for $100 it is hard to complain too loudly. 

The input power cable is a large four pin connector for 3 phase 208/230V, although it has nowhere to attach inside the A frame. The good news I discovered is that nowhere inside the tape units is 3 phase required. The integrated control unit uses single phase, the transport in the A frame uses single phase and the transport in the missing B frame uses single phase. 

By attaching each of those three loads to a different pair of input phases, they save money on wire by dividing the load. However, I could easily wire all three loads across 220V single phase. The power for both A and B frames together and in operation is a bit below 3KVA or under 14A. Actual power used may be less depending on the power factor. 

The motors inside are all single phase, the vacuum and air pressure use a 3/4HP single phase AC motor. The capstan and both tape reels use a DC permanent magnet motor operating at 45V. Mainly this unit requires 5V, 15V, -15V, and 45V plus some AC to the blower/vacuum motor. 


We are exhibiting the Alto at VCF-West at Computer History Museum this weekend. We will set up on Friday evening and check everything out. I put some time into preparing my reverse wifi router, because the LCM built bridge for Alto networking requires a wired ethernet cable. We will pick off the wifi in the museum with my unit and deliver internet access through its attached ethernet cable.

Ken is preparing signage for our area while Marc is working on the final presentation material for our panel presentation and on-stage demo. Marc is going to display a sample logic board under plexiglas and I will bring a sacrificial disk cartridge for display purposes. We will meet tomorrow and wrap it all up prior to load in that evening.

Wednesday, August 2, 2017

Archiving more cards at CHM


Today at CHM I read and saved some more decks of cards, then emailed them to the professor and his grad students. The temporarily lost box 1 of 6 was found and delivered, so I fired the system up and started reading. 

I found that periodically the setup would hang up or begin misreading. Often it would stop with an error that the PC side program had sent a command 10 times without any response. There are quite a few places that could be having problems:

  • Documation card reader
  • Wiring to the PCB that drives the reader
  • USB module hooked to the USB
  • USB drivers on the Surface Pro notepad
  • Flaw in the program (but has worked well other days)

Sometimes it seemed that I had to reboot Windows to resume operation, other times it seemed to be related to heating (e.g. duration it was powered up). Sadly it doesn't reset itself reliably. We removed the card cage cover on the card reader and placed a muffin fan to provide more cooling, but it didn't seem to help.

The setup will read and verify reliably for intervals, then start malfunctioning before it reaches the interface timeout situation. This will slow down my progress archiving the decks, as I was only able to read about a dozen decks today. 

Tuesday, August 1, 2017

Picked up tape drives, read some old card decks for University of Michigan


My friend Marc is buying a mainframe printer, using a moving band of type. The IBM 3203 was a derivative of the 1403 printer, using similar cartridges with the chain of type. Dataproducts built a plug compatible version which is the actual printer that we are retrieving. It had an integrated controller and will connect to a mainframe via bus and tag channel cables. It also has a powered stacker. 

The printer was located a few hours away in Sacramento, which meant a minor road trip in a lift gate truck. When I got there, I decided to pick up two 9 track tape drives, Telex 8020 model 266 units. The first drive is in good condition and has the control unit built right in, while the second drive was damaged during shipment and has never been used. I suspect it can be restored to proper operation, but at worst case it serves as spare parts for the first drive.

One of the two tape drives I bought
My drives came with a tape tester, schematics, training manuals and other materials that will make it easier to restore them to operation. The one hiccup is that these drives require 3 phase power, which I don't have in my home. 


A researcher at the University of Michigan contacted the Computer History Museum concerning some decks of cards that represent experiments done in 1970. They asked if the museum could help read the decks and provide files of the content, allowing researchers to include those results in new research projects.

The best way to read them was with my Documation card reader and the adapter designed by Brian Knittel that reads the cards into PC files. I moved my setup to CHM yesterday and began reading decks. 

The files consist of six boxes each having several decks of cards, but initially one of the six boxes is missing. I opened box 2 and read all 9 decks. I emailed the files and some explanation to the UofM professor and grad students to be sure they are happy with the results. It took a bit more than a half hour to process a box, thus I can finish up the other boxes on Wednesday. 

Each card deck has a header card which has MTS punched as visible characters (you can see the letters holding the card up, with each letter taking several card columns to express). It also has some other data on the card which may be identifying information such as the punch file ID when this was punched by the Michigan TimeSharing System (MTS). The following cards seem to be four-column numbers packed across each card. 
Header card
Data card

Sunday, July 30, 2017

Found bad custom chip part in 7854 scope and replacement part is amazingly available


I can see that the Display board is generating the XYINH signal that should block the analog scope signals from being displayed during the digital interval, however the characters are smearing because the analog signals are not inhibited.

Further, in looking at the way the characters are distorted, it is strictly in the horizontal direction. The top and bottom of the character is never affected, but the left to right placement of the pixels is impaired. That suggests that the flaw is in the Horizontal Amplifier circuitry, which is not acting on the XYINH.

Looking at the horizontal circuitry, I see one place where XYINH is fed into a custom chip that is the channel switch. This chip is available on ebay as New-Old-Stock just in case it appears that problem is there. It will have to come from the island of Rhodes, meaning several weeks of transit time, but is reasonably priced all in all.

When checking out the rest of the scope, I observed that only the B horizontal plug-in is working, the A plug in does not cause traces. Swapping the actual plug-in modules made it crystal clear that the problem is in the horizontal switch circuitry, just where my other problem is manifesting.

The circuitry in question is on board A9 inside the main body of the scope, not on the plug in boards on the side. It is behind the plug-ins, which suggests that access a real pain. However, when I began disassembling I found that it was brilliantly designed for easy access.

Card A9 exposed behind metal plate
Card A9 seen from underneath
A metal cover plate blocks each of four possible card positions, with the card itself designed to fit through the opening exposed. I only had to remove a bunch of coax cables and one small connector, take out two screws and it slide right out.

Card removed through opening
Access from behind plug-ins
The switching chip is right at the beginning of the circuit path on the board, routing two sets of horizontal signals from the A and B plug-in positions, switching with the Benable signal and blanking with the XYINH signal. This is pretty clearly the part that is fried, so I bought the NOS spare from ebay.
Suspected chip circled at left
New Old Stock chip to replace on card

Saturday, July 29, 2017

Ups and downs with Alto demonstration, finished the Heath C-3 Condenser Checker restoration


The last of my replacement parts arrived today and I soldered everything together. The chain of higher wattage 22K resistors were placed on the selector switch. The octal socket for the magic eye tube was wired up. New tubes were then placed into sockets. Finally, I fired it up to check the voltages and gross behavior. 

The magic eye glowed properly, voltages seemed sane, so I moved on to check some components. The resistance test range was close to the resistor value and can be calibrated by moving the dial on the pot shaft if I wished to. The capacitance check worked well for a .1uf capacitor, as did the leakage test. 

I then put in a 16uf 450V electrolytic and did some capacitance and leakage tests. It worked exactly as it should for both capacitance detection and leakage testing. The tool is now properly restored and ready to use with those suspicious power supply capacitors. 

Restored C-3 Condenser Checker

We attempted to clean the heads on the disk drive, using Kimwipes and isopropyl alcohol. The bottom head is easily visible but seeing the top one involves mirrors and awkward angles. It seemed that the head was okay and they landed okay on the cartridge that originally had the problem.

We then wanted to write our demo image on one of our three writeable cartridges - those that don't have historical data from PARC - but immediately the drive began cycling the solenoids in a loud clicking manner that we associate with head crashes. I immediately switched off the drive and removed the cartridge.

We can barely see what appears to be packed in oxide on the upper head, thus our earlier cleaning was insufficient. Inspecting the pack shows signs of a crash as well, brown rubbing on the oxide in a ring. No aluminum substrate exposed and no apparent ridges, thus the pack is probably still usable once the cause of the crashes is corrected.

We decided to switch the disk tool over to the drive attached to our Alto. This has good heads and we placed one of our good cartridges in the drive to write the demo image. Using the disk tool, however, showed a troubling sign. Rather than seeking crisply and regularly through all 202 cylinders, the drive would advance slowly and irregularly.

I believe this may be a grounding issue where the drive with our head crash is well grounded through the signal cable but the one in the Alto is not. Poor quality signals could account for the failure to 'see' the ready signals that follow each seek. Further, this likely means that the data being written or read would also be suspect.

I did a ReadEntireCartridge and processed the captured image. Comparing this to the image I used to write the cartridge earlier showed many small errors across the disk. Whatever signal fault exists with the tool attached to this drive, it must be corrected to get reliable operation.

We booted the disk image I had written, got a Alto Executive prompt which seemed promising, but found that while most programs seemed to work, SIL did not. We ran the scavenger program which clears up problems on disks by finding mismatches between the disk directory contents and the chaining information in the label records of each sector.

If found quite a few problems, many in SIL related files, and attempted to fix them. It also found problems in the high-res picture we display late in the demo, which was missing the bottom fifth and had an obvious bad stripe in one spot up higher.

To proceed with our demo and other activities today, we switched over to doing a copydisk over the network from the same image placed on the LCM bridge. That worked and we could move ahead with our taping and demo practice.

 We videotaped the demonstration with wide shots in the afternoon. Once some screen closeups are taped, to be used as insets or spliced with the main taping, a complete video can be edited together to share the demonstration on YouTube.

Finally, we worked on the presentation we would give as part of our panel at the Vintage Computer Festival West conference next week. We spent hours tightening it up, rewording and strategizing on how to squeeze it into the slot we have available.


I have a Tektronix 7854 scope, which is a mixed analog and digital scope that timeslices access to the screen between the two sources of display information. It displays characters on screen in the digital mode, but they are distorted while the beam is sweeping from the analog side. The logic should be switching the analog off while displaying digital, and vice versa, but it appears something is going awry.

I began scoping the various signals involved in this timesharing of the CRT. The first three I could measure had an easy to reach set of testpoints at the top edge of the card. The next few are internal or the testpoints are so far down the card that they are blocked by adjacent cards. I pulled the card and stuck some probes on the points I need to monitor, then reseated the card.

All the control signals appear to be switching as they should - at least their relative timing and shape are correct. My next set of tests, after pulling the card again and changing probes, is to see if the vertical and horizontal outputs of the analog section are indeed going to ground during the digital interval.

Tektronix scope being debugged
There is an Intersil DG181 DPST switch that grounds both lines when in the digital interval, but if that is failing then the analog signals will interfere with the sweeps from the digital/character generator section. I will watch the sweep outputs to see if they are non-ground level during the digital interval. This will have to occur tomorrow as it is too late to continue out in the garage tonight.

Thursday, July 27, 2017

Fixed triple power supply from a flea market


At a flea market, I came across a triple power supply for a very attractive price. When I brought it home, I noticed that a switch on the first section, which changed the meter between voltage and current readings, was mechanically broken. I also heard some rattling inside.

The switch was a common small switch that I had sitting in my back room, so it was a quick fix. The rattling sound was a heat sink with four power transistors, powering the third section which could deliver relatively high current but lower voltage than the first two sections. I attached it to the standoffs, which was all that was required. 

Testing showed that all sections worked properly, including their current limiting circuits and overvoltage protection. This will be a very useful bench tool that I acquired for $40 plus a few minutes replacing a switch and attaching a heat sink assembly internally. 

Wednesday, July 26, 2017

Restoration work on Heath C-3 and on a 1401's card reader


Most of my replacement parts arrived, including the 1626 tube, which I soldered into place. I do have two problems that will require more part orders. First, since I am reverting the design back to the 1629 magic eye tube from the 6E5, it switches the required tube socket from the six pin part I had to remove and an octal socket for the 1629.

Second, part of the first order was wrong. I remember that when I found the 22K 2W resistors on Digikey, I initially ordered 6, the quantity I needed. However, the web site popped up an alert telling me that for the same price I would get 10, because of the volume break at that number. I approved the change but didn't check closely to see that it had changed the type of resistor to a 1/4W 10K that I don't need.

When I was ordering the 22K resistors today, the same pop up was delivered but I cancelled out of it and manually ordered 10 of the desired part. It was now correct and will arrive later this week or over the weekend.

I am awaiting the new 22K resistors, the octal tube socket and the 1629 tube, after which I can wrap up this restoration and begin using the checker.


We have been fighting erratic reading on the 1402 reader that is part of our "Connecticut" system over the past couple of weeks, but today someone noticed that dust was wedged into slots in a plastic disc used with a solar cell to generate the timing pulses for the 12 card rows. With an air compressor and vacuum, the disc was cleaned and our reader is back to proper operation.

We still have a permanent error in core at one address (high in memory, fortunately). We will try varying the core unit voltage in both directions to see if we are right at the edge and failing on the weakest core, or if we have a more pernicious flaw in that core location.

If we can't get the core working, we have a spare 4K core unit that we can swap in. It is a major task, but much easier than disassembling and rethreading a core plane to replace a bad core. 

Tuesday, July 25, 2017

Wrote demo disk cartridges, practiced VCF-W demo and continued archiving PARC cartridges


We met today to work on the demonstrations we will give at Vintage Computer Festival West in a few weeks. Ken and I had built disk images using the LCM's Contralto emulator, which I wrote onto two disk cartridges using the disk tool. With those, we began booting and practicing the demonstrations.

Marc also recorded the demonstrations which he will post to YouTube in a few weeks.

In addition, I returned the batch of disk cartridges to PARC since we had archived them already. I took a new batch of 30 back to Marc's where we can read them all with the disk tool to ensure the contents are preserved for posterity.

I successfully archived four cartidges, giving us two dual-disk Mesa images and source code of Press, but while reading the fifth disk we had a minor head crash at cylinder 184. The disk surface doesn't look too bad so once we clean the heads on the Diablo drive, we should be able to extract the contents.

Sunday, July 23, 2017

Failed part discovered in C-3 Condenser Checker, improvements made


The main power is set by a voltage divider, with ground at the center node. There is a 47K resistor up to the side which feeds B+ to the 1629 magic eye tube. On the other side, there is a series chain of resistors which total 98K. This gives roughly 1/3 of the voltage to the B+ and 2/3 to the resistor chain that are on the selector switch which determines what negative voltage is presented across the capacitor under test.

The first 22K resistor in the series chain was wide open, which meant that the minus side of the divider was disconnected. This explains the values I measured and is consistent with the design flaw where the divider string uses mainly 22K resistors to drop about 100V per step. This is because the chain of resistors has about 4.5ma running through it.

That puts 1/2W on the resistor, its rated value, but if a capacitor is tested with substantial leakage current then the power on the resistor will temporarily be well above its rated power. Over time, the abused resistors change value or open up like mine did. The replacement components I bought are rated at 2W which gives a lot more margin.

The prior owner of this tester had substituted a different magic eye tube for the 1629 I used. It was a 6V type while the original has 12V filaments. He or she put in some large low value resistors to divide the filament voltage in half. I bought the proper magic eye tube therefore I removed this hack.

The circuit should be back to original design when I finish the restoration, other than any changes I need to introduce to deal with excess HV from the transformer. It should produce no more than 500VAC which when rectified and filtered puts about 450V on the low side filter capacitor, within its margin. Thus, I don't strictly need to introduce by pair of series capacitors to provide a higher voltage handling capability.

Instead, I added resistors in series from the cathode of the rectifier so that they drop the excess voltage. I measured the transformer output at 600V, about 1.2x the intended voltage. The appropriate resistance appears to be 29K which will dissipate about 0.6W. I chose to build this as a series combination of 1/2W resistors, values of 11K and 18K, to lower the power on the two resistors since they now split the total voltage drop.

I prepped the unit for the new parts, removing the old series resistor chain and 47K resistor that all had drifted out of spec or failed open. I also reversed the wiring changes introduced by the prior owner for the substitute magic eye tube, since I will have the proper one to insert.

The two filter capacitors I have are 500V rated units, adequate to the voltages I will see now that I am dropping some of the voltage from the transformer across the new 29K of resistance. These are compact modern electrolytics, which I relocated so that I made use of the ground tabs around the rectifier tube socket. The capacitors sit below the tube socket, as does the 11K + 18K pair of resistors.

I made use of a spare pin on the tube socket that is not connected inside the tube, spanning the 29K of resistance from the cathode pin 1 to the spare pin. The filter capacitor and wiring for the B+ line to the magic eye were moved to the spare pin to effect the voltage drop.

When I get my replacement components, I have to install the series resistance chain of 22K and 11K resistors onto the selector switch. I also need to put on the new magic eye tube grid and bias resistors and wire up that tube socket properly for a 1629. The last step will be to put the 47K resistor that completes the voltage divider, completing the divider that apportions my 650VDC as 210V for B+ and -440V for driving the capacitor under test. When I pop in the new tubes it will be ready to go.

Fixing up an old Heath C-3 Condenser Tester


I brought my C-3 over to test the capacitors we removed from the old Alto power supplies, but the unit failed in transit as the magic eye tube wouldn't glow. As the only output to indicate the results of a test, that meant the unit was unusable. 

I discovered several flaky things when I looked into the unit at home. It uses a transformer generating nominally 500VAC through a 1626 tube rectifier to produce both a high negative voltage for testing capacitor leakage current and the B+ voltage of 130 to 200V for the 1629 magic eye tube. It has a resistor that establishes the ground point and therefore divides the DC into the + and - amounts. The two sides have electrolytic capacitors rated at 8uf 475V.

Unfortunately, the transformer is producing more like 600VAC. Instead of dividing 660VDC into -450 and +200, already close to the capacitor rating, it is producing over 600V negative and my B+ was under 100V. I have one problem that is causing the current through the dividing resistor to be too low, which causes B+ to be too low, but that also exposes the other cap to way way more than its rating.

It is very hard to find capacitors at 8uf or higher with ratings of 675V or higher, thus I decided to put two 16uf 450V caps in series and include some high resistance bleed resistors to ensure voltage balance. The target current will be around 0.5 ma in the higher side, so that I will burn only 180mw with that resistor but ensure that two caps divide the voltage evenly. That means I need two 680K 1/4w resistors. The low side will burn about 60mw.

On recommendations from others who have refurbished these, I am replacing the main voltage divider string of resistors on the 'Scale' switch with 2W units as the existing 1/2W parts are close to rating at the high setting and can be damaged when testing caps with high leakage current.

To wrap things up, I ordered new 1626 and 1629 tubes. I will do some cleanup of the unit while waiting for my parts to arrive.

Friday, July 21, 2017

Disk tool working, used to build images for demo at VCF West


I brought the updated logic to Marc's lab, set up the disk tool and successfully wrote cartridges and read cartridges from the Diablo disk drive. We are using the tool to build images for our upcoming demos at the Vintage Computer Festival West on August 5 and 6.

The rest of the day was spent working out the exact software images we needed after developing our high level script for the demonstration. We will show:

  • Bravo, the word processor that was written by Charles Simonyi before he left PARC to go write its descendant, Word, at Microsoft. 
  • Draw is what it sounds like, a generalized drawing program. 
  • SIL is a tool to draw schematics
  • Neptune is the ancestor of File Explorer or similar file management software
  • Ethernet which was created for the Alto and its use for FTP, network booting, file serving, etc
  • Smalltalk, the language and environment developed by Alan Kay to explore object oriented sw
  • Games such as Astroroids, Pinball, and others developed by students doing grad work on Altos

Thursday, July 20, 2017

Testing complete for relay tester, ready to ship

I have been on vacation for a week, no posts or activity but returned to the workshop today. 


We are going to exhibit the Alto at the upcoming Vintage Computer Festival West event, as well as hosting a few panels. I will be on two of them, one concerning the restoration of the Alto and another concerning restoration of the 1401 systems.

This will require development and scripting of demonstrations as well as our material for the panels, but at the same time I want to begin using the disk tool I built to archive the stash of cartridges from Xerox PARC. The tool will also allow us to create disk cartridges to support our demo activity.


Having located the proper code and identified a few tweaks to make to the wiring in the box, I began the adjustments today. As I had earlier written, the four or six sets of contacts in a relay could be identified with ordinal numbers starting from either end of the relay, but I chose the incorrect end.

Rewiring those connections will give me a box that works properly with the unmodified code developed by Stan, thus keeping the two relay tester boxes in sync as future changes are made.

I ran the tester through its various functions, using a relay from our spares stock and found that I still have one flaw. I can individually drive the pick or the hold coil in the relay under test. The Arduino pulls down a wire for each that is connected to the dual relay module inside the tester. However, the relay modules only click on when both pick and hold wires are activated, not individually.

We reasoned that this is due to a short between the two wires driving the dual relays. If they are shorted, then one is outputting high and the other low if I try to drive only one of the two coils. This produces an intermediate voltage, not 0 and not 5V, which is too high for the dual relay module to fire either relay. When both are active (low), the wires are down at 0 and the relay module will click on.

I opened the box to locate and correct the short. With that done, everything is working correctly and this is ready to be shipped to TechWorks! for use with their 1402 reader/punch. I wrote up a user manual and will ship that along with the box. Stan is going to set up a laptop to ship with the box, allowing this to be a turnkey test system.

Sunday, July 9, 2017

Finished construction of the permissive make relay tester


My grommet supply arrived today and I finalized the holes after selecting the ideal size grommet for the LEDs. I seem to always underestimate the hole size required to fit in the grommet, but eventually got it right. After installing the LEDs into the cover, I was ready for applying the insulation - a rubber insulator that is brushed on over exposed wire junctions to form a protective coating.

Unfortunately, two things went wrong today. First, my existing bottle of connector coating is partially dried out and almost empty. Second, when I got over to CHM to check for the updated Arduino code that runs this version of the circuit, I couldn't locate it. Stan will need to hunt it down tomorrow.

Frys did have the connector coating in stock, which I ordered for pickup in the afternoon.  After lunch with my wife and a friend, I dropped them off and rode over to grab the purchase at the store. After it was applied, I loaded the out of date sketch.

I can accomplish some testing of functionality using the old versions of the sketches provided by Stan, which proves out ability to pick and hold, rattle relays and test contact resistance. First I did a test with only the USB link powering the Arduino and its relay board. All the LEDs and the relay module fired properly and the sketch communicated with the PC.

Next up was a test with the 20V supply activated in addition to the USB link. That way I can see if the relays pick and hold using a red relay plugged into the socket. The relay magnets did seem to work fine although the first flaw was uncovered. When the tester believed it was using the green relay socket, my LED lit under the red socket.

The next flaw was uncovered when I noticed that my relay module was active initially, although I believe the code thought that both Pick and Hold coils were off. My LEDs light when the drive line is high, but the relay module is off for a high voltage.

I can fix both of these flaws easily. The relay module can be changed to use the NC contact to drive the LEDs and pick/hold coils - when the relay is off, the lamp and coil will be on and vice versa. I could move the two LEDs under the relay sockets allowing the proper one to light. Dealing with the pick and hold LEDs is more complex but I can just swing the pick and hold LEDs onto the actual relay socket pick and hold wires, adding a suitable additional resistor to limit current.

Next up, I added the 5V supply and tried measuring contact resistance on the red relay. I can't check circuits 5 and 6 as these are only on green relays, but I had some interesting readings for the others. I will have to check this with Stan tomorrow when I am retrieving the correct code.

The quality of the contact test readings is mediocre as I don't have the code that makes use of the voltage reference from pin A15, but I could check out operation well enough to prove that my wiring seems sound.

I will haul this into CHM tomorrow to check it out with Stan - who will be hunting for the updated code - and I can work out any wiring changes needed before closing everything up. 

Saturday, July 8, 2017

Built RF amplifier to interface digital VFO to Heathkit HW-100 transceiver


I tweaked what signals are displayed on the LEDs and that show on the seven segment display, otherwise no change to the disk tool as it is simply waiting for the chance to test with real drives, disk cartridges and Altos.


The digital variable frequency oscillator I built to improve the HW-100 tube transceiver produces a low voltage output with 50 ohm impedance. I had tried to leverage the existing tube amplifier in the analog VFO to try to boost the signal before it is mixed with the local oscillator in another tube.

The impedance match is wrong and the tube really needs a larger voltage swing, leading to poor results as it sat. I found a kit by W1AFFL that will boost and match impedance to the tube in the HW-100 from the 50 ohm low voltage swing produced by my digital VFO.

I completed the kit in my spare time today and will put it with the rest of the HW-100 project to resume work in the near future. I have to concentrate on the relay tester, 1130 light panel and Alto efforts first.

Friday, July 7, 2017

1402 Permissive Relay Tester construction nearly completed


I bored out the hole for the power cords, inserted the grommets and then tied the cord strain relief inside. Began soldering grounds together, the +20V to the two relay module contacts and the +5V to the 0.1 ohm resistor leading to the bank of resistors hooked to the individual contacts.

Beginning to wire up the insides of the tester
I had some wiring to accomplish between the relay module and Arduino, set up all the grounds from power supplies to Arduino and the two relay test sockets, solder up headers for all the contact wires from the relay test sockets, and finally hook up my four LED units.

The pick and hold coils circuits were wired to the relays, including the snubber diodes that will short the back EMF as the coils are released. I partially wired the two LEDs that illuminate that will show when the pick and hold circuits are energized. The ground connection to the Arduino was installed, but there was still quite a bit more to do by midafternoon, mostly involving wiring stiff wires to small header pin ends.

When dinnertime arrived, I had all four LEDs wired in, the relay module connected to the Arduino, and the only wiring left to do was to hook the twelve contact leads (6 each for normally open and normally closed sides) to the header that connects to the analog input pins on the Arduino.

Early evening brought completion of all the wiring. Two of the header strips were left detached, giving me more working room to install the LEDs, but they only need to be plugged into the Arduino to complete all circuits. I carefully tested everything for shorts while I was wrapping up, so that as it is ready to have power applied.

Final tasks that will wait until Sunday include

  • insulating all the bare metal soldered junctions, 
  • inserting the proper grommets into the cover, 
  • mounting the LEDs into the grommets,
  • install the headers onto the Arduino and
  • close up everything after testing
Too, I have to visit CHM over the weekend to pick up the current code (Arduino sketch) that matches the circuit. The major change is the addition of a 0.1 ohm resistor between +5V and the individual 33 ohm resistors feeding each contact.

The code adjusts the voltage measured on each contact (powered through its 33 ohm resistor) against the voltage at the junction with the 0.1 resistor. The contacts are connected to ground by the relay and any voltage above 0 at the contact is due to resistance in the contacts.

Thursday, July 6, 2017

Disk tool now working for both read and write; continued building the relay tester


Problem spotted and corrected. The deserializer emits a signal called gotword for the duration of the bitcell, 600 ns or 30 fpga cycles. In that time, my ReadField logic will take the extracted word, store it in RAM, adjust the address of the next word to be stored and loop back.

This takes less than 30 cycles therefore I was trying to put the same word away a second time, instead of waiting for our next incoming word. It was solved with a simple interlock keeping the state machine in the address manipulation state until gotword goes inactive before going back to look for the next word.

I now read the sector but get a checksum error on the first record (header). The data appeared to be shifted in correctly and at the correct time, but the error comes when the comparison between the incoming word and the computed checksum fails. I therefore altered the testbed to emit the running checksum value and watched that for signs of problems.

The checksum matches what was extracted from the bitstream, so the flaw is more subtle. I again changed the emitted signals to allow me to watch the state of the error flag during the test - another 30 minute pass through the toolchain - and observed the results.

What I saw at the time of the test and immediately afterwards was a good status for the checksum, yet the result when the ReadSector transaction completed was an error marked for the header record. I took another half hour, passed out the point in time when the error is recorded as a signal, and examined what was occurring around then.

The ReadField transaction is run three times per sector, at the request of the higher level ReadSector transaction. Each time, the parameters such as preamble size and word count are set up while triggering the inner transaction to run.

When the inner transaction returns to its idle state, the outer transaction should advance to set up the parameters for the next record and trigger the inner transaction to handle it. What I am seeing is that the inner ReadField transaction returns to its rfidle state as it should, sits there for only three cycles and then appears to kick off in another transaction.

This should involve the outer ReadSector transaction stepping from its rsread1 state to the rsset2 setup stage to trigger the inner machine to handle the second (label) record. The outer machine does NOT advance to rsset2; that only occurs at the next rfidle stage of the inner machine.

This means that the inner transaction tries to read the label record but with the long preamble and short word count that pertains to the header record. It fails to produce a good checksum and that is how I get the error status recorded.

I will confirm this with a change in instrumentation, twiddle my thumbs until the testbed is ready and see what is actually taking place. If this is the case, I have a problem with my ReadSector transaction not stepping properly to its rsset2 stage, even with three cycles of the triggering rfidle state from the inner transaction.

Since I did have the problem - the step rsread1 took just a single cycle thus really didn't read the header record - I modified the outer transaction to interlock better with the inner one. That is, kicking off each read step involves a wait step that insists that the ReadField transaction left its rfidle state before it starts looking for the inner to end with rfidle later.

I need to see that the ReadField transaction runs properly three times at the correct time in relation to the outer ReadSector steps, Once that works, I can check to see if the checksum verifies good reading and then verify the contents of RAM to match what my dummy data driver is emitting.

Both tests worked well. I even performed the upper level ReadEntireCartridge transaction which bumps through all the sectors, issuing ReadSector for each in order. The file produced looked good, but since I used contents of all zeroes in my dummy data, it doesn't absolutely prove out the logic.

Therefore, I planned to write some unique data values in each record, first with invalid checksums. I should see all my data captured in the file properly when I 'read' the cartridge, but each sector should reflect the checksum errors. After that works, I can add in the appropriate checksum values and test to see if my logic is now reading 'without errors'.

I had previously built a spreadsheet that is designed around the three record format of an Alto sector. I enter the data words I want and the spreadsheet displays the appropriate checksum. Since it gave me the correct values, I first verified the checksum failure for the two records where I deliberately stored a bad checksum.

I then corrected the data stream, waited a half hour for the toolchain to complete and verified that all worked properly. I found the data properly stored in RAM, matching the values I used, meaning I can consider the logic to read cartridges to be working.

I took a look at the WriteSector state machine to see if it could benefit from the improved interlocking I used on the ReadSector peer machine.  Indeed, it is amenable to the same improvement, which I introduced. Once I wrap up the reading tests, I can quickly do a WriteEntireCartridge to validate that the logic still works.

As of dinner time, both ReadEntireCartridge and WriteEntireCartridge transactions are working properly to the extent I can test them without a live Diablo drive or a real Alto. However, I am reasonably confident and look forward to the testing.


I found a good way to anchor the Arduino and relay modules down inside the box. I had to make some holes for power and USB cables to attach, stick in a barrier strip and add the four LEDs to the cover. Once done, I could wire up the tester and be ready to go.

I tried some acrylic glue to anchor the relay module inside the box, further fixing it firmly. With that done and proven out, I did the same treatment for the Arduino itself. A hole was drilled and covered with a rubber grommet for the USB cable that connects to and powers the Arduino.

I need to decide how to route in the power from the two power bricks - one at 20V and the other at 5V - which drive the relay coils and contacts respectively. I could just drill holes and knot the wire inside and out to anchor it in place, or I could attempt to install sockets on the side and matching plugs to the power cables.

Four LEDs have to be installed in the cover. There is one under each of the two relay sockets, to indicate which is active for testing. The other two are in the center of the cover and light to show when the pick and the hold coils are active. I have a grommet assortment coming which will allow me to mount the LEDs cleanly in the box. The grommets will also help with the holes for power cables or sockets.

I did find a reasonable grommet for the power cables to enter - sans sockets - and drilled a first hole. It is a bit too small in diameter, so it needs to be drilled out with a slightly larger bit. I will take this on tomorrow, then install the power lines and knot them inside for strain protection. I still need the mini grommets to mount the LEDs.

Tomorrow, I will grab four LEDs and wire them up, before beginning the final wiring of the unit. I decided against the use of a barrier strip, instead using point to point wiring. All these soldered junctions need insulation, which I will apply with my 'rubber in a bottle' paint on insulation.

The copy of the sketch that drives the Arduino is out of date, not including the improvements suggested by Ron Crane that improved the accuracy of the testing by way of a known voltage drop. I will need to find that code on the laptop at CHM where the original tester sits.