System/1 Build Log

Home | Build Log

An ongoing chronology of System/1's construction, and any other related musings.

16th August, 2016

This entry was backdated.

There are a total of eleven control buttons I'm planning on including on my front panel — each of which requires a debouncing network consisting of two resistors and a capacitor — plus twelve indicator LEDs with their attendant resistors for current limiting. To make progress with prototyping the front panel control logic, and to test the new wiring harness/signal conditioning board, I figured I should wire a suitable set of these up on the same board as the temporary I/O registers.

This proceeded without incident right up until the time came to test my wiring by connecting the output of one of the RC networks up to one of the indicator LED inputs via a 74HC14 Schmitt-trigger inverter. Most of the time this resulted in the LED lighting when the button was held down, as expected, but sometimes the LED would only light dimly or would continue to glow dimly after the button was released. After an awful lot of double-checking my construction and measuring various unexpected voltages, I caught it in the act with the oscilloscope and found a whole whack of 80+MHz oscillation on both the input and the output of the inverter. This was somewhat less than ideal, obviously, and at this point I was somewhat stuck for several tinkering sessions until I finally noticed the repeated references to 4mA output drive currents in the chip's datasheet. Naturally, the limiting resistors I'd chosen (on a 'have plenty on hand, looks reasonable' basis) were driving the old-fashioned indicator LEDs with around twice that given the 5V supply...

Some dismal contemplation of the pain involved in having to rework the board with more appropriate resistors later, it occurred to me to do the calculations again assuming a 3.3V rail — as used by the test harness — and found that was theoretically just within the specification. And lo, turning the bench supply down to 3.3V and repeating the same tests for a while showed that the oscillations had cleared right up. A bullet dodged, at least for the temporary front panel; as long as I remember not to try running the system at 5V with it attached, things will behave themselves.

With that out of the way, I tested out the signal conditioning board; at first an unfortunately-placed solder bridge meant the synchronisation latches weren't running, but with that corrected it generated the right sorts of pulses when the various buttons were pressed. The only issue was with the toggles for the breakpoint controls — these are supposed to act as radio buttons, where either one or neither can be set but not both simultaneously, and in order not to confuse the breakpoint implementation logic they can only change state between word cycles. Instead, they seemed to change freely at any time, but would both appear to be deselected during a word cycle — not very useful! In related news, it turns out that double-checking the datasheet to decipher the stupid pin names on EAGLE's default symbol for the '173 would have been sensible before wiring the design up — I had the output enable and latch enable pins swapped. At least a couple of bodge wires sorted that out, and I could finally turn my attention to prototyping the control logic that implements the last few front panel features.

This was mostly uneventful; everything I'd already sketched out worked as intended, such as the run/halt logic and breakpoints, and a bit of experimentation confirmed that a sensible priority order for the various front panel states would allow the memory read/write buttons to automatically step through memory addresses with each press, which should make entering code/data and reviewing results a lot easier than juggling the read, write, deposit and next-address buttons by hand. In addition I noticed a simple change that would dramatically improve the appearance of the register display as the machine is running — instead of asserting the load signal (which blanks the display to avoid flicker and then latches the new value on the falling edge) for the whole of the word cycle in which the selected register is being updated, we can instead only assert it briefly at the end once the full word is in the shift register behind the latches. At first I thought about simply ANDing the existing load signal (generated by a 1-of-4 mux) with a signal that's asserted during the last bit of a word cycle, before I noticed I could simply feed that same signal into the mux's enable pin and get the same effect with no additional gates. A quick test showed that this did indeed make a considerable improvement to the display; it's now nice and bright, rather than often very dim due to being extinguished for considerable portions of the instruction cycle.

With everything tested and working on the breadboard, all that's left for the front panel controller is to make sure the last few changes are properly included in the schematic and then set about building the finished board. Looks like I can do it in thirty chips, which by sheer luck appears to be the practical limit for how many can be comfortably arranged on the board after accounting for connectors and only sundry bits and pieces. I just hope I haven't forgotten anything!