Bits of progress week ending May 25, 2014


I constructed a new shield that holds a voltage level adjuster for the four signals, accomodating the 3.3v CMOS logic levels on the fpga side and the 5V signals of the Arduino, plus buffering the signal that comes in from the fpga (MISO line of SPI protocol) with a tristate buffer so that it floats at high impedance while the SD card shield or the Ramboard shields are actively using the shared serial (SPI) link. At the same time, I created more reliable connections, replacing the push in pins that were used to connect to the Arduino headers.

The entire stack is assembled, but I need to route a source of 3.3V power to the bidirectional signal voltage adjuster shield as it needs both power supply voltages to work properly. Due to a fault in the design of the SD card shield board,  the 3.3V pin on the Arduino board is not actually connected to anything, I had to wire up a link to provide that reference voltage to the board assembly. The source of the 3.3V will be the fpga board.

Stack of shields and Arduino for the virtual 2310 disk drive
Power now routed and wiring of everything double-checked. The final issue was a bad trace on the shield board I built upon, which blocked the MISO input from the fpga. Once fixed, the link was somewhat more reliable and debugging could finally shift to protocols.

The initial poll from the Arduino should receive a Seek request from the fpga asking it to preload cylinder 0 contents into the fpga sector buffers. That occurred by my protocol was inconsistent between the two sides as to one step where I confirmed receipt. I matched them up and reran. Sometimes I got errors that showed that I still had a signal quality problem - a signal of x55 was received as xD2, which means that the clock and signal state got out of sync or the state machine got confused.

Time for the scope until I see clean it up enough for reliable operation. Since this unit is designed to operate at 8MHZ yet exhibits these problems when slowed down to 4MHZ, I will begin by using my signal cable and testing termination schemes to clean up the signal. The SPI bus has several devices connected to each signal wire, which makes termination a bit trickier than for simple point to point runs. However, the transmission line problems appear to mainly be a problem on the runs to the fpga board, which all run between a voltage shifter component on the level shifter board on the Arduino and the fpga pins.

The fpga board introduced a 100 ohm resistor in series with each pin. This works well as a source termination for the MISO line that originates on the fpga, but is not good for the three incoming signals from the Arduino, the SCLK, SS and MOSI lines. The only effect that SS has on operation is to tell a particular slave when it is safe to come out of high impedance mode on the MISO line, because it is time for this slave to use the shared SPI bus. SS is less impacted by reflections as long as it reaches a steady state before the clock begins running. SCLK and MOSI are the essential signals that need clean lines.

I can put source termination on the 3.3V output of the voltage shifter for the signals originating in the Arduino. If I use 100 ohms for these and my token ring cable that has an impedance of 150 ohms, I should be close to balanced and get better signal quality.

With these terminations in place and the scope set up to measure the signal as close to the fpga input as I can get (the input pin on the fpga board), I saw SCLK, SS and MOSI signals They looked better, not ideal but better. MOSI and SS were fine, but for some reason SCLK is not rising to full voltage, instead getting to just a bit over 2V. This can definitely account for the problems I am experiencing.

If I monitored the MISO signal at the input to the voltage shifter on the Arduino, I might see nice clear signals. However, until I clean up the clock, everything else is suspect because it occurs based on clock edges.

During protocol testing of the virtual 2310 disk drive

I did some signal cleanup and tightened up the logic in the fpga for signal emission and detection. The week ended at this point, but I will continue next week and finish this peripheral.


What an enormous pain in the rear to try to get two cords strung in opposite directions but wrapped around pulleys that counter-rotate on the same shaft, plus get to metal tapes strung and connected. Knots pop off pulleys, the cord anchor falls off its hook under the carrier, and the pulley shaft has to slide back and forth to engage or disengage the teeth of one pulley with the operational shaft.

I am now up to six hands necessary to handle the cords, and another 6 to 8 to get the tapes in place properly since there are springs pushing adjusters off the ends of their rails and tensile springiness of the tape popping it up out of its anchor point.

The degree of fussiness and fiddling is extreme - it is like trying to herd ten angry cats in one direction (that they don't want to move towards) when they are individually bolting in random directions at frequent unpredictable times. Each day another element pops off or starts acting up, so that I feel that I slid another ten percent backwards instead of making progress.

Make that 20% backwards as of Wednesday evening. The last of the cord anchors popped off, couldn't be reattached without removing the entire pulley assembly. With that, one spring had to be detached and then tossed into a space warp - well, the last part is what happened, not what was intended. It disappeared without a trace. I hope I can make it past this pit of frustration and sequential failures to get this working again. All intellectually easy and simple work once the darned cords and tapes are attached successfully.

I began to very slowly and carefully hook up everything. Each time I would run into a challenge or sense that things were starting to fall apart, I would stop and do something else for a while.

Since this mechanism is a correspondence format typewriter, I jumped on an ebay offer of a type 987 typeball, an APL ball in correspondence arrangement. As well, I did find an auction of a collection of parts that included springs and other items that I can use in the maintenance of this and other selectrics, all for a very low cost.

I am avoiding the mechanism for a few days until I feel calm and have particularly steady hands, where I can attack the escapement plus carrier return cords as one integrated set of connections, and also the rotate tape installation.


The web site of the digital game museum makes use of a licensed 'product', a set of scripts and templates that implement the magazine-like look and feel of the site under Wordpress. One goal for the site is to pick a new look and feel, switch over, and end up with open source or self-developed code to displace the licensed product currently used. That has the side effect of allowing movement to a different git source control repository, long blocked due to the implications of having licensed product code held there.

Much of the collection is being photographed which will allow for a very substantial and attractive web site. The test/development server environment is ready to duplicate all the content of the live site. Mentoring and getting everything set up for the coming months of updates consumed quite a bit of my time this week.


I believe that the schematic is properly captured for the card and values selected for all but one part. I began building key circuit sections on breadboard to allow me to test it with appropriate voltages and driving conditions. I need to drive the circuits with -3, +3 and +6V power supplies, but have only two set up so far.

No comments:

Post a Comment