Bits of progress week ending May 25, 2014

DISK DRIVE EMULATION

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.

IO SELECTRIC REHABILITATION

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.

DIGITAL GAME MUSEUM

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.

GERMAN MUSEUM 1130 SLT CARD SUBSTITUTION

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.

SLT card recreation, IO Typewriter work and 1401 study, week ending May 31, 2014

DISK DRIVE EMULATION

Still working on the quality of the SPI link transfer between Arduino and fpga. More tweaks done but still it appears that the main problem is missed or doubled clock edges. This is partly a signal quality issue and partly an algorithm issue.

IO SELECTRIC REHABILITATION

I received both boxes of miscellaneous Selectric parts purchased on ebay and these give me the missing springs and other items to continue reassembly and adjustment of the typewriter mechanism.So far I have replaced one of the missing springs and replaced a broken indicator that shows the column at which the carrier is sitting on the plastic scale on the front cover of the typewriter.

The rotate tape is now attached and the shift mechanism is partly reassembled. It required me to take apart some of the mechanism in the carrier, in order to get to the rotate drum directly. I have this reattached the mechanism and hooked up one end of the tilt tape, but have not yet hooked the tilt arm the carrier head.

SLT CARD RECREATION FOR TEKNIKUM 29 MUSEUM RESTORING 1130

I put together a power supply to give me the three voltages I need for SLT debugging - +6V, +3V and -3V - from the variable bench supply I owned which only offered two adjustable levels by itself. This card takes the 14V AC from the bench supply and produces the +6V. I then adjust the two sections of the bench supply to output +3 and -3 levels.

In addition to the test circuits, I needed a legitimate driving signal and a conforming SLT load for the outputs, to ensure that my circuit worked properly, obeyed the threshold voltages for switching and delivered adequate output levels under load. I took some example circuits for the driver and load from the documented test setup that IBM used to validate the operation of their logic circuits.

A full set of components are on order to build a complete prototype card - not on an SLT card but otherwise complete and ready for comparison to a live card. My simulation of the circuit we believe is on the card swings the output signal between +3 for logical one and -3V for logical zero. SLT logic uses ground for logical zero, not a negative value. However, this version of the card replaces other cards when the 1130 has a large memory configuration, requiring the memory to be moved to a different frame than its original placement. To span that longer distance the signals would run over coaxial cable.

I don't find any other place where IBM uses this pair of voltages and therefore have suspicions that something is wrong with the schematic. I will continue to stare at the pictures and try various alternatives until I get reasonable behavior. I also sent a detailed email to the museum with a standard SLT and-or-invert circuit they can use to test their cards and validate designs.

LEARNING 1401 PROCESSOR OPERATION

I began this week to set up some instructions and single cycle them through a 1401 system at CHM, allowing me to watch the operation and to reinforce my reading of the logic diagrams and training materials. A programmer would not need to know the level of detail I will need, because they don't need to understand how the various registers and circuitry changes in each cycle as long as the instruction does what it is defined to accomplish.

Just as an example, all numbers are stored in memory in BCD format and use the zone field of the low order digit to represent the arithmetic sign. However, the process of addition or subtraction involves converting the numbers from BCD (a decimal digit) to bi-quinary, and older mechanism simialr to an Abacus which represents digits as a units from five values (quinary) from 0 to 4 plus two values (binary) representing 0 or 1 fives. Thus, a seven is a 1(base2) and 2(base 5) while a 3 is 0(base 2) and 3(base 5).

The adder circuitry takes the two quinary values, producing a quinary result and possibly a carry. The carry is added along with the two binary values to form the new binary result, plus any carry is recorded as an overflow by the hardware. Being a bit more precise, the adder circuitry takes the two quinary values and the overflow from the addition of a prior digit, yielding a quinary result and the overflow to the binary section.

None of that is visible to the programmer nor does it show on the operator panel. All that is visible is the result of the addition translated back to BCD. An addition or subtraction operation proceeds in a non-obvious way. The low order digit is fetched from the A and B fields, taking a total of two execution cycles, for the sole purpose of examining the zone bits (B and A bits). If the two fields, A and B, are the same sign and we are adding, then the result will be the same sign as field B and addition will proceed in what IBM calls a 'true add'. However, if the two fields have different signs, we have to convert the B field to its tens-complement value before adding. Then, depending on which field is larger, retranslate the result back by another tens-complement.

Tens-complement takes each digit N and replaces it with 9-N, finally adding a 1 to the low order digit of the resulting field. The processor will walk backwards to lower addresses of the B field until it finds the word mark, converting each digit, then jump to the highest address (low order digit) of the field to resume doing the addition or subtraction.

Whether or not we took time to do the tens-complement of B, executing an addition proceeds by alternating fetchs of the A and B field values, bumping the addresses downwards (adjust by minus 1) and storing the result of the adder operation into B. These pairs continue until the word mark is reached on field B. If field A is shorter, once we hit its word mark the processor just plugs a zero in as the BCD value for the A field. Effectively, this extends the number with zeroes on the left to make it the same size as the B field.

At the end, if we did a complement add instead of a true add, the processor has to walk through the result to see if it has to be complemented again, then sets the zone value for the low order digit position of the B field. A particular position in the A and B fields might be fetched several times during a single addition. The zones may be compared to set the overall sign of the result, the fields may be examined to test a result for complementing, the field may be tens-complemented, or the fields may actually be added.

Doug Martin and I will spend some time on Monday cycling through instructions and confirming our understanding of the system. We are documenting this in order to build some training materials.

Mixed work week ending June 8, 2014

1401 PROCESSOR STUDY

Spent some time on the 1401 at CHM stepping through instructions to solidify my understanding of its flow and steps in processing. As well, collected some key documentation to peruse over the coming weeks. One key aspect of the machine that is invisible to programmers and not displayed on the operator console is the way that arithmetic operations take place.

The 1401 translates the digits of a number to bi-quinary format, takes the tens-complement when subtraction is required instead of addition, adds with two parallel mechanisms operating on the quinary and the binary data independently, and then recomplementing and retranslating to produce a BCD encoded digit as the result. Only the BCD digits appear on the operator console.

The use of what IBM insists on calling qui-binary for arithmetic in the 1401 is an interesting oddity that is partly an ease/cost of design choice and partly the persistence of historical choices and experiences which today are almost completely ignored or unknown. Because I wanted to understand why the designers took this approach, I undertook some detailed research.  Nothing I could find directly answers the question of why the 1401 has a hidden conversion to qui-binary for arithmetic, but there was enough information to come to a very reasonable conclusion.

The 1401 was developed at a time when we were much closer to the mechanical and relay based calculator era that was supplanted by digital computers. Understanding the context of those times really illuminates these design decisions - as the most mature and complete theory, engineering art and industry practices of the times came from that era.

Most of the work on encoding numbers electrically came from the communications field and to a large degree the most advanced efforts of the time were the domain of the US telephone industry (e.g. Bell Laboratories) and the corresponding institutions globally (e.g. the Dollis Hill research institution of the UK). Mechanisms like Teletype and Telex were widely used. Calculator companies such as Burroughs and Marchant developed products to assist people doing calculations (the people having the title of computer, not the hardware that assisted them which were calculators or similar names).

Most of the calculators and communications devices handled numbers digit by digit, usually in decimal at least as far as the user interface. Internally, they were stored and manipulated in a variety of schemes, mostly not in decimal. However, they were not encoding the value of an entire number, they encoded the value of each decimal digit independently.

Reliability of the relay based calculators was a challenge, which didn't ease when machines shifted to vacuum tube electronics. Each relay or vacuum tube was relatively large, power hungry and costly, in addition to contributing another part which could fail, thus designers sought to minimize their numbers through clever engineering. Error checking was simplified if a set of wires would always have one and only one "on" or at logical 1 in a binary sense. Any other case, zero turned on or more than one turned on, indicated an error had occured.

You could imagine converting each digit to a set of ten wires, representing each of the ten values 0 through 9 of that digit, with error checking to ensure that only 1 of 10 was active. However, that might drive the use of ten relays for each digit. Other encoding schemes reduced the parts count but still had the property of checking for one and only one active wire.

Bell Labs used schemes for relay based systems such as this bi-quinary coding for digits which they also termed a 2 out of 5 code. There are five wires and relays used to represent any digit, the wires representing 0, 1, 2, 4 and 7. The reader can convince themselves that with these weightings, you can have exactly ten 5 bit long values that have only two of the bits at 1. 11000, 101000, 01100, 10010, 01010, 00110, 10001, 01001, 00101, and 00011 stand for 1, 2, 3, 4, 5, 6, 7, 8, 9, and 10 although the last is actually a sum of 11 (4 + 7) which is taken to encode zero. Any single relay intermittent error would be detected because their would be more or less than two of the five bits turned on.

Later work at Bell Labs led to bi-quinary as an encoding where the wires were placed in two sections, each of which could have only one wire active. The error checking was easier (e.g. less hardware) than verifying two were active as in the prior paragraph. There was a tradeoff between error checking hardware and the digit storage hardware. This is much like an abacus, where one section has two wires - one means there the digit is five or higher, the other wire means the digit is less than five. The other section (lower section of an abacus) has five wires, representing 0, 1, 2, 3 or 4. Thus, a digit of 7 has the 'five' bit of the upper section plus the 'two' bit of the lower section. Here the analogy to an abacus breaks down because they can have up to four beads 'on' in the lower section.

Coding a decimal value with ten unique wires allows checking that only one wire is active, but bi-quinary requires only seven unique wires and can still use a circuit that verifies one-and-only-one active. Most of these implementations use the section with two wires (the 'binary' side) so that one wire is 'no five' and the other wire is 'five'. The five wire section is a quinary section where each wire is binary and only one of the five can be on at any time.

Arithmetic involves not only magnitudes but also positive and negative signs. To implement this with an adder, whether in relays or electronically, generally involves taking the complement of a number, and allows for both addition and subtraction with a single adding circuit. http://en.wikipedia.org/wiki/Method_of_complements Engineers have to design circuits to complement a number if needed to perform subtraction or to represent the value as a negative number.

A scheme invented at Bell Labs made the circuitry for complementing digits easier if each digit is in a four-bit binary encoding as its decimal value plus three. In other words, the digit values are 3, 4, 5, 6, 7, 8, 9, 10, 11 and 12 to encode 0 through 9. They called this 'excess three' coding. It allows the complement to take place with less hardware. Just invert all the bits and you have the nines-complement of the digit.

The Univac I employed the excess three method to represen decimal numbers. Unfortunately, the programmer and operator had to recognize that a 6 displayed on the panel was a decimal 3, not a six. This confusion was an infamous lesson of history that led most computers designers to hide internal details of encodings such as this from the operator and programmer, allowing them to see a 3 when the value was intended to be a 3.

IBMs early steps into computing included some relay based systems such as the Harvard Mark I http://en.wikipedia.org/wiki/Harvard_Mark_I and SSEC http://en.wikipedia.org/wiki/IBM_SSEC and then extensions of their electromechanical accounting machines. That led to all electronic machines such as the 650, 701 and others.

The IBM 650, an all electronic machine, implemented bi-quinary representation for decimal digits which were visible on the operator panel. This was the classic approach where the first two values indicate presence or absence of a five, the next five values are 0 through 4. Forming the nines-complement with this bi-quinary encoding meant flipping the binary section values and symmetrically flipping the quinary section - the four wire value becomes the zero wire value, the three wire value becomes the one wire value and the two wire value stays as it is. To illustrate, the decimal value 2 is encoded as 01 00010 in bi-quinary. Its nines-complement is 7, which is encoded as 10 01000 so that we flipped the binary value 01 to 10 and routed the value of the quinary bits to form 01000. Anything where the quinary section has the two value, e.g. where the quinary is 00100, does not change at all in complementing. 10000 becomes 00001, 01000 becomes 00010, 00010 becomes 01000 and 00001 becomes 10000. You can visualize this as the mirror image of the quinary pattern if that makes it easier to grasp.

Now on to the 1401, a magical blend of these historical experiences and technology antecedents. The 1401 is a character oriented machine, much like the calculators and then electromechanical accounting machines of its ancestry. The BCD encoding for each character represents decimal as a value comprised of the valid combinations of the four low order bits, 0 through 9, and makes use of the A and B zone bits for signing and other purposes. The adder, however, operates using 'qui-binary', IBM's term for an encoding which differs from what they used with the 650 machine and what everyone else in the industry calls such coding mechanisms.

Qui-binary has a two wire section, but that binary section encodes where the digit is odd or even. One wire means odd, the other means even, but they are labeled B0 and B1 in all the hardware documentation. They obey the exclusive OR property where they both cant be 0 and both cant be 1.   The quinary section that has five wires uses these to represent 0, 2, 4, 6 and 8. One and only one of the quinary wires can be active at any time or we have a validity error. These are the Q# signals. One can only assume that, since the binary section is not the larger weight, as it is in the 650, but instead contributes the smallest weight of 1 or 0, they flipped the terminology to qui-binary.

The programmer and the operator using the control panel of the 1401 sees only BCD coded digits. The arithmetic logic shows the resulting sum as a BCD digit. While executing, the machine does a translation from BCD to qui-binary for both of the input digits that are being added or subtracted. As appropriate to the arithmetic operation and the signs of the two fields, it may translate to the nines-complement qui-binary for one of the fields. The machine has two separate adders - one adds the binary section and one adds the quinary section, dealing appropriately with carries, borrows and overflows across those two units and with the digits that will be added after this pair of digits has been completed. The resultant qui-binary value is complemented back if needed then translated to BCD before it is sent to storage or made visible on the operator panel.

Perhaps they hid the use of qui-binary from the operator and programmer because of the recent industry experiences with 'excess three' on the Univac I, or more likely it was to provide simplicity for the potential customers who were almost universally familiar with electromechanical accounting systems and had no prior experience with computers. This also hides the details of complementing numbers when they are negative. All numbers are represented by their absolute value in decimal, with a sign associated with the low order digit that indicates if the number is positive or negative.

SLT CARD RECREATION

I received the last of the components needed to build the complete breadboard version of the card. I began assembling one stage in order to do some scoping of its operation.

I applied power but turned my little 6V regulator to a smoking ruin by bridging its ground wire to the ground of the regulated dual supply giving me +3 and -3. Some internal issue with the transformer hookup inside my power supply interacting with the regulator design. I need to find a new way to deliver the three SLT voltages and do my testing - also I will swap the transistors just in case I damaged them during the incident today.

My new power supply arrived but I ran out of time Friday night before I could do the testing. More importantly, I received an email from the museum. They had built a recreation and it is working satisfactorily, giving them an 1130 with working memory and processor. At this point, their needs switched to some code to toggle into the processor to work on the 1053 (console typewriter of the 1131). I sent them material to help them get the typewriter up and working properly.

I am also going to advise them as they work on the typewriter, given the almost certainty that it is gummed up with solidified lubricants so that it will be jammed or won't work properly until cleaned. Once the typewriter is cleaned and adjusted offline, it will be time to run the diagnostic loop I provided that types a given set of characters at a steady pace.

DISK DRIVE EMULATION

I did some testing but neglected to update one part of the fpga files which invalidated the work. I will try again before the weekend is out. With the correct fpga logic I tested, discovering that the clock pulses were not emitted to the fpga properly. The method I have been using, where I partially manage the SPI link myself and it is partly managed by the SD Card library, does not seem to work well. Likely the library is leaving the link or the SD card hardware in some state that causes problems for my direct use of the SPI hardware later during the program.

I decided to rewrite the program in the Arduino to completely remove the SD card library. Once I am directly managing the SPI link I should have more consistent results. I am about half done as of the end of Sunday but should be able to resume testing soon.

IO SELECTRIC RESTORATION

Both rotate and tilt tapes are back in place on the carrier. I also reattached the tilt arm from pulley to the golfball mounting post. Remaining to do for the carrier is finding and installing a c-clip on the tilt arm, connecting the carrier pull string, adjusting the string tension and then placing the springs on the tension adjuster.

As of friday evening, I had the carrier pull string attached and the c-clip installed on the tilt arm. I have to apply the proper tension to the carrier string, which will need a second person helping me in order to get everything tensioned properly while simultaneously holding and tightening the takeup pulley.

Limited progress week ending June 15, 2014

LITTLE TIME FOR 1130 PROJECT WORK THIS WEEK

With the testing and repair of many game consoles for the Digital Game Museum in prep for a big party they are co-hosting in Sunnyvale - the Atari Party - I didn't have much time to spend on my project this week. The party is an event on Saturday where the designers of Pong and of the trackball will speak, plus enthusiasts and collectors will have more than 100 machines there ranging from Arcade to game console and home computer.

DISK DRIVE EMULATION DEBUGGING

However, I did spend some time redoing the code for the disk drive emulator, removing the SD card library which seemed to trip up my use of the SPI link to communicate with the fpga. Almost ready to resume testing with this change to see how the SPI signals behave and the Arduino communicates with the 1130 fpga.

SELECTRIC 963 TYPE ELEMENT (1130 CONSOLE BALL)

I had a search on ebay looking for someone selling a golfball type 963 which is the arrangement used on the 1130 and S/360 consoles. It is BCD arrangement and has capital forms of letters on both sides of the ball. One was miss-listed as an APL ball and I was watching it when I found the seller had relisted it changing the description to "rare EBCDIC 963". I also noticed it had a 'buy it now' button for $30, which I jumped on. The ball I had been using was the same as the 963 except that it had lower case style letters on one side and upper case on the other. This alternative ball would produce funny output if the program used the lower case character code; that problem goes away with the 963.

1401 STUDY

I spent about two hours working on parts of the logic diagrams and in hand cycling some instructions. We thought we had a failure to debug, as one of the demo programs suffered a process check in a multiply instruction on the Connecticut machine but we couldn't reproduce the error to diagnose it.

GAME CONSOLE LOT FOR DGM DONATION

It was a large lot sold as not working/for parts and often goods sold like this can be put back into operation - especially when it is many units. The first box I began working on, an Atari 2600 console, seems pretty solid so far. I see the processor working, composite video entering the RF modulator unit but until I string up controllers, a game cartridge and a monitor to this, I can't check it out further.

However, the Atari 800 I tried next turned out to have had some parts stripped from it - which violates the spirit of 'for parts' in the description. I am willing to take the risk that a fix is impossible or too expensive, but wouldn't have bought a lot if it were "partially stripped junkers" because that has me paying to haul away someones trash. I hope this stripped machine is an anomaly, since most of them appear complete even if not currently working. Both of the Atari 800 models were stripped of RAM, but the model 400 and 800XL appear intact.

It is going to take me a bit of time to work through these machines, with the Atari consoles prioritized so that they might be used at the Atari Party this weekend at the Sunnyvale Public Library. After that, I will probably work on the Commodore 64 and 128 systems, then move to some of the others.

As of Wednesday I had four of the VCS/2600 consoles working well and was at work on the next one. Soon I will need to turn my attention to controllers, doing some repairs and cleanup to get them working well with the consoles.

By Thursday evening, we are up to six of the VCS - 2600 working well, plus two VCS 2600 Jr models that work very well except they produce PAL format video (European standard) rather than the US style NTSC. Hooking it to a NTSC television gives a black and white image with lots of buzzing rather than audio, but the game itself is visible and plays correctly. The museum will add a PAL monitor to its collection which will support these plus any other PAL versions of other consoles that may be donated.

The Atari 400 is working properly too, after sorting out the proper power supply and doing some cleanup inside. One of the problems affecting it is oxidation on the contacts of several game cartridges - a round of cleaning those should get everything humming along.

I ran into some problems with an Atari 5200 system, not sure what the problem is but it could be a bad RF modulator. This may be a system that requires parts to fix - put it aside until the Atari party at the Sunnyvale Public Library is over. I focused on testing and collecting power adapters and controllers for all of the consoles that are already working. Might look at an Atari 7800 if I get a few minutes.

The first batch of restored/tested consoles were delivered to the museum Friday night. I have plenty of controllers to get working properly, the 600XL, 5200, 7800 and a sears 2600 to work on, then I can dig into the remaining pile - three TI 99 computers, three Commodore 128 and 64 machines plus floppy drives, an Odyssey and an Intellivision console. All at a much slower pace as filler projects while I refocus on my own 1130 tasks.

SD card SPI fun, week ending June 22, 2014

DISK DRIVE EMULATION

I had to dig into research on the SD card use of SPI protocol because my first shots at accessing the card directly without use of an SPI library did not go well. As stated in earlier blog posts, when the library is used, my attempts to communicate with other SPI slaves, especially my fpga, suffered various impacts that appeared to stem from the library leaving the SPI hardware of the Arduino in an odd state but could also be interference by the SD card shield itself.

I discovered quite a few things about SD cards that reinforce my original desire to have independent SPI links for this unit, although that was frustrated by lack of any Arduino card that carries the essential clock line for the three other USART units out to a pin that I could access. Without the clock signal, SPI won't work well, so the USART, a facility that is a combination of serial port and SPI, in fact can only be a serial port (UART) on these boards.

SD cards must be 'woken up' by a string of clock cycles while the inbound (MOSI) and selection signal (SS) are held high. Since SS is high when the slave is NOT being selected, this violates the intent of the SPI protocol for shared slaves since a slave should ignore the signal lines unless its SS line is taken low. It takes 74 or more clock cycles to wake up the chip, putting it in its native, non-SPI mode. I don't yet know how long a period causes it to 'go to sleep' where it needs the initialization again, hopefully that doesn't happen once it is initialized in SPI mode.

Another oddity is that the SD card does not release the outbound (MISO) signal when SS is returned to high, violating the SPI specification. It takes another eight clock cycles before the card releases MISO to its high impedance state. This definitely hoses up any other slave, legitimately selected, that tries to send its data on the shared MISO line.

Finally, I don't know what state the MISO line takes when the SD card is in its native, non-SPI mode. Since any string of 74 or more '1's on MOSI will do this when another slave is active and SD has its select high, I can imagine this could be another source of problems.

I will continue a bit with my direct, non-library access to the SD card, where I might be able to control some of these anomalous effects, but if the card resets based on the data pattern from other slaves on the chip, I need to isolate the SD card from the MOSI line until it is actually being accessed. This would require a second selection signal, a kind of meta-SS, that switches MOSI and SCLK so the card won't see these until I turn on the meta-selection signal. It means additional hardware and some signal rerouting for my growing sandwich of Arduino and shields.

I think that the first USART, used for serial communications over the USB link and for flash programming of the Arduino, can be used as an SPI link. It would be very inconvenient as I use the serial link for the operator interface as well as for debugging purposes, but if the USART clock is accessible for that mechanism, it would at least allow me to isolate the SD card from the rest of the slave devices, using the SPI library for the card and the other link for well behaved slaves. I might need to use another USART for a direct serial connection in pseudo RS232 mode (TTL logic levels but RS232 protocols).

It will be easier to block the SCLK signal from the SD card unless some meta-SS is on for the SD card. I have spare enable gates on a 74HC125 on one of the shields. I began to modify the shield for the controls and to alter the Arduino code to enable/disable the clock passthrough buffer.

In addition, I recoded the relevant part of the SD card handling routines to conform to the way that the SD card actually works and to use of the new meta-select signal. I also worked on the code so that it handles fpga and ram slave devices per the SPI spec.

DIGITAL GAME MUSEUM WORK

I did some repair work on the four metal floor controllers for the Dance Dance Revolution game, as most have one or more positions that don't work reliably. This will be the core of the DGM exhibition at an upcoming Japanese culture fair. I began to check the condition and failure causes so that I can get these working well.

No work week ending June 29, 2014

NO TIME THIS WEEK FOR THE PROJECT

Work obligations this week left me no time to work on the project - hope things settle down for the coming week.