System/1 Build Log
An ongoing chronology of System/1's construction, and any other related musings.
7th October, 2014 - Prototyping the flags register
The flags register is another part of the system where my original design notes don't hold up to scrutiny; although the 74HC74s in this one aren't having their asynchronous set/reset inputs fiddled with to quite the same extent as the one in the original ALU plans, I'm still not particularly confident that the scheme I had in mind would be totally reliable. In addition, I'd made those notes before I'd decided that some form of interrupt support would not be outlandish for the system, and the method I'd settled upon for adding an interrupt context meant I needed to support two sets of flags (so that the 'user' context flags can be preserved across interrupts despite being unable to push the register contents to the non-existent hardware stack).
Some thought and scribbling in my notebook on Saturday (during a train journey in the direction of much beer) brought me to the conclusion that I could use a 74HC173 for each set of flags, instead of the original scheme's two 74HC74s and a 74HC373 transparent latch (to hold the state of the flags after the computation cycle finished). The '173 has an enable input, which means it can simply be wired to the LOAD_FLAGS signal so that the register state only gets updated during appropriate machine cycles, without any annoying asynchronous behaviour threatening to bung a spanner in the works. As with the ALU, replacing the asynchronous set/preset malarkey with a couple of gates to 'forget' the state of the non-zero flag between operations would also be sensible.
Nothing in the actual flag generation logic is particularly tricky — the carry and sign bits are simply latched straight from the ALU outputs, and the non-zero bit is just the ALU output ORed with the last state of the non-zero bit — but before I commit anything to solder I want to breadboard it all up. Everything looks OK, and the condition evaluator copes with the most sensible combinations of condition codes (some condition codes don't make a lot of sense on the face of it, but there's nothing to be gained by moving to a denser encoding anyway), so I'm happy with the new design. Unfortunately this weekend is going to be stupidly busy, as I'm moving work's entire internet presence from one datacentre to another, so I won't get a chance to do anything more with System/1 until next week!