Clock design notes #4 - ripple counters

Ripple counters are used extensively in my clock. I use them as a prescaler for the mains frequency, and also for the various counters in the time and calendar "modules".

A ripple counter is an asynchronous counter. An external clock signal is applied only to the input of the first stage. The output of the first stage feeds in to the clock input of the second stage, and the output of the second stage feeds the next stage, and so on and so forth for as many stages as required. So as the name suggests, any changes that happen to the output state of each stage within the counter are going to ripple from one stage to the next - something like a line of dominos falling over.

This is basically the opposite of a synchronous counter, whose outputs all change at the same time based on a clock signal which is applied to all stages simultaneously. This results in an instantaneous change to all outputs at the same time in line with the clock signal.

I chose to use ripple counters instead of some other kind of synchronous counter (like one built from master-slave JK flip flops) because they are easier to implement with fewer transistors, and my clock doesn't have such an operating frequency where a synchronous counter might actually be necessary. For example, a modern CPU in a computer has an operating frequency somewhere in the multiple gigahertz (GHz) range (1GHz is 1 billion hertz... or 1 billion cycles per second), whereas my clock is timed from the AC mains frequency, which will be 50 or 60 hertz (hz) depending on where it is operated. So a little bit of delay here and there is not really detrimental to its operation - theres a relative eternity for things to settle down and work itself out (20ms per cycle at 50hz vs 1ns at 1GHz, several orders of magnitude).

So what is a ripple counter? It can be (as in my case) a series of D type flip flops cascaded together, and a D type flip flop is basically a series of SR latches.

So .. what is an SR latch? It's a very simple latch with two inputs, S (set) and R (reset), and two outputs, Q and the complement of Q (often referred to as "not Q"). The two inputs can be used to switch between two states: Q high and not Q low, or Q low and not Q high. In order to bring Q high, you must place a high signal on the set input. To bring Q low, you place a high signal on the reset input (not Q is always the opposite). Importantly, and as a latch, it holds the last state you applied even after you remove your input signal. Setting both the set and reset inputs high at the same time is an invalid input state, and at that point both Q and not Q will be low. As you'll see below, the topology of the SR latch circuit is symmetrical, so you can arbitrarily assign set and reset to either of the two inputs, the only rule is that Q will be the diagonally opposite output to the set input, and not Q will be diagonally opposite to the reset input.

You'll see them represented like this in my schematics, made easily out of two 2-input NOR gates:

You wont always see the inputs and outputs labelled in my schematics, and you might not always see the two outputs of the latch being used, but you will see this kind of circuit topology very frequently. I use a forward slash to indicate an inverted signal (i.e. the complement).

The explanation above is a bit brief, so I present to you a video by Ben Eater who explains this in more detail, and provides some practical examples to show its behaviour. It's a good video, and he has plenty more covering a project to build a small computer of sorts on a series of breadboards. Well worth watching his videos if you are interested in digital electronics, I highly recommend you check his channel out - you will learn a lot.

Moving on, three SR latches make a D type flip flop. In my clock I use D type flip flops with up to three inputs: clock (always), reset (always), and preset. Flip flops tend to be "edge triggered", that is, they will change state on either the rising or falling edge of the input clock pulse - which one depends on its construction. You may also be able to configure a flip flop to invert its state each time the clock input is pulsed, but this is not always the default behaviour. In my case, since I am using NOR logic, my flip flops will trigger and invert on the falling edge (high to low) of the input clock signal.

Setting the reset pin high will cause it to reset to a default state, in my case, Q being low. It's worth noting that while the clock input triggers on the falling edge, the reset input triggers on the rising edge.

In between resetting a D type flip flop and the next clock pulse, you can also feed in a preset signal. If the preset signal is high, the flip flop will start with Q being high, and the next clock pulse will transition Q to low. If the preset is left low, or no preset input is provided, the flip flop starts with Q low and the next clock pulse will transition it to high. A "full featured" D type flip flop will look like this in my schematics:

But once again, the inputs and outputs wont always be labelled, I've included them here to show you where those inputs are located. And as you can see, it's nothing more than three SR latches crossconnected in a specific way.

I don't have a particularly good video in mind to provide a link to to give a better explanation of the D type flip flop other than Ben Eaters video above, but I do have a link to a web page with a simulator that you can play with. It's not an exact representation of what I have here, but its pretty darn close and the operation is exactly the same. The only thing you need to do is set the D input to what ever the "not Q" output is before clicking the clock button, and you will see that you get the required behaviour which is to invert state on every clock pulse (you can see in my schematic above, not Q is tied to one of the inputs of GATE4, and that in the web based simulator, the same input to GATE4 is just a toggle).

There's also a mountain of additional reading on flip flops on this Wikipedia page.

Getting to the point where this all relates to a ripple counter... With the above theory in mind, recall that I have configured my D type flip flops to invert state on each clock pulse, and that they do this on the falling edge of the clock pulse.

If we start with all ripple counters in a reset state, such that Q is low for all outputs, and then feed a clock pulse in to the first stage (referred to as the "least significant bit") of the ripple counter, its Q output inverts to high on the falling edge of the clock pulse. On the next clock pulse, Q inverts back to low at the falling edge of the clock pulse. That output is also connected to the clock input of the second stage, so on the first stage output transitioning from high to low, Q of the second stage then inverts from low to high. We have just counted from 0 to 1 to 2. Now, the next clock pulse to the first stage inverts its Q output to high, and with high Q outputs on our first two ripple counter stages we are at binary value of 3. A further clock pulse to the first stage inverts its output to low, and that high to low transition causes the second stage to invert its Q output to low, and with the second stage output tied to the third stage clock input, that high to low transition causes the third stage to invert from low to high. We've now counted  0, 1, 2, 3, 4 (in binary, with the least significant bit on the right: 000, 001, 010, 011, 100).

But words aren't always interesting, so here's what is known as a timing diagram to visualise all of what I wrote above, plus a few extra clock pulses so you can see how it continues on:

As you can see, after the 8th clock pulse transitions high to low, all 3 stages return to low Q output state. It's no coincidence, a 3 bit counter can count from 0-7 which is 8 different values.

Bear in mind that this is just for demonstration purposes. Recall that a ripple counter is an asynchronous counter, so the outputs do not all transition instantly at the falling edge of the clock, rather, the falling edge of the clock is only when the "chain reaction" will begin, starting with the first stage and "rippling" through the counter as each stages output transitions from high to low, but only as far as the first stage that transitions low to high (because further stages will only be clocked when the preceeding stage transitions from high to low). The above diagram would indeed be accurate for a synchronous counter. Just a limitation of trying to draw it up in a spreadsheet I guess. But we are talking on the order of nanoseconds here, so it might be reasonably fair to say they do change "pretty much all at the same time".

If that still isn't enough to satisfy your understanding, I also provide a logicly file where you can see it in action for yourself. Heres a screenshot if you want to reconstruct it in the online demo:

If you look through logicly's options and ensure that the "Limit Propagation to Frame Rate" option is checked, then you may actually be able to see the ripple effect in action.

As I mentioned at the start of the post, I'm using ripple counters throughout my clock. In fact there will be 7 in total. I also use a lone D type flip flop as a toggle for leap year handling.

The day of month counter is the only counter in the clock which accepts a pre-set value. This is so that each time it is reset it can be set to start counting from 1 instead of 0 like all of the other counters.

And finally, if you were wondering about transistor counts as per my recent posts, a D type flip flop with no preset input takes 14 transistors to implement or 15 with a preset input, but there is also some additional reset logic to go along with these counters, so more detailed counts will be provided in future posts when I discuss their specific design and construction.

Clock design notes #3 - 16 segment decoders

In the last post I covered how I came up with the logic for some 7 segment decoders. In this post I will brush over the process to make 16 segment decoders to display month and day of week names. I say brush over because it's very much the same process, and I'd just end up repeating myself otherwise, but there are a couple of specifics for the 16 segment decoders so they deserve their own post.

It starts once again by working out a truth table to determine which segments need to be on for any given input value. To help make this process easier, I whipped up a little "character builder" in a spreadsheet, and by setting different cells to 0 or 1 I could turn different segments on or off, and the resulting string of 0's and 1's would go in to the truth table, e.g.:

Unlike 7 segment displays, the segment names you see here may not be standard, they are based on my chosen display from Kingbright, so adjust accordingly if you use different displays.

By fiddling with the character builder I assembled all of the characters necessary for month and day names and planted them in to their respective truth tables, then converted it all in to k-maps with minterms figured out to suit.

The truth tables and k-maps are a bit bigger and more numerous this time around, so instead of posting images here I'll link you to another spreadsheet that contains all of the workings. I've been "strict" again with the month and day of week names in that values beyond those which are required will result in a blank display. e.g. the month counter will be 4 bits, but for values 12-15 my decoders do not produce any output (December is month 11 with January being month 0 - everything in my clock is indexed to 0).

You'll notice in the truth tables that typically segments a and b are the same, as well as e and f, and occasionally some others. So when I did my k-maps, I combined some segments in to the same k-map as they share exactly the same logic to turn them on and off.

To help minimise transistor count I loosened up some of the minterms to overlap with others where possible (the more cells you match the fewer inputs you need to AND and thus the fewer transistors needed), and fed the output of some NOR gates via an inverter in to other NOR gates to minimise some duplication. Perhaps there is room for more optimisation, but I think things are pretty slick as they are and I'm happy with the results.

And like with the 7 segment decoders, the final step was to translate this to logic and simulate it in logicly, and as before I've shared the logicly files for my decoders: day of week decoder, month decoder

Here's a sneak peak at the month decoder, it's by far the biggest of them all, but it does what it says on the tin:

You might need to use a little imagination to see the output on the right, or reference the light bulbs against the segments in the datasheet linked above. But with all zeroes on the input it is displaying "JAN".

And here's a count of transistors and gates that each decoder uses:

• Day of week decoder: 91 transistors, 54 gates
• Month decoder: 201 transistors, 101 gates

I don't think theres much else to say, so this is a nice short post. If you want some additional detail and background on how this all came together, check out my post about the 7 segment decoders.

Clock design notes #2 - 7 segment decoders

This time I promise to talk about something more technical, so I'll cover how I designed, from scratch, the BCD (Binary Coded Decimal) to 7 segment decoders that will drive the clock display, and also the day of the month display as part of the calendar.

I had originally intended to have an n-bit ripple counter feeding a decoder that could translate that n bit value in to outputs for two 7 segment displays. It seemed like the nicest and most "pure" solution, and I had begun designing things this way, but it started to get very complex vey quickly - a lot of gates using a lot of transistors, and I started to worry that I wouldn't be able to fit all of the decoders for the clock and calendar on to a single board each, and this is something I am trying very hard to achieve (i.e. one block of functionality per board).

I'll cover ripple counters in another post, but I've opted for a solution that involves one counter per display with varying numbers of bits depending on the maximum value a display needs to show. For example, the seconds "unit" counter will be 4 bits able to count 0-15 but resetting at 10 (so, 0-9), while the "tens" counter will be 3 bits able to count 0-7 but resetting at 6 (so, 0-5). The "tens" counter for hours would be 3 bits as it only needs to show up to the 20's. As a result I had to come up with three 7 segment decoders, one to handle each of 2, 3 and 4 bit BCD values, but I'll cover the process for the 4 bit decoder in this post (it's pretty much the same for the others).

The first step was to nut out a truth table that would determine which segments will be on for each given input value, and this is what I came up with:

It also helps to have a diagram of the display next to your truth table as a reference. 7 segment displays have an industry standard layout with each segment labelled a-g, and laid out in the arrangement you see above. Also, I've opted to only decode values 0-9, ignoring values 10-15 which would otherwise (perhaps) decode to letters A-F for hexadecimal readout - in my decoder they will result in a blank display.

Through this truth table you can also "stylise" your digits. For example, some decoders may leave segment a off for the digit 6, or segment d off for digit 9, others might turn them on. It's really up to you at this point (I chose to have segment a on for 6 and d on for 9 as I like that style).

The next step is where you start to work out the logic that will drive the segments. The method I used involves k-maps. You can find more detail on these at this Wikipedia page, but I'll give a brief run through of how I worked with them here.

The best way I can think of to explain a k-map is a table with a number of cells equal to and representing the number of different values in a given sized binary number. A 4 bit binary number would have a k-map of 16 cells because 4 bits of binary can represent 16 different values (0-15). And we need one k-map per segment of a display so that each input value can be mapped against a segment to determine whether it should be on or off for that value. This gives 7 k-maps for a 7 segment display. So this is what I started with:

AB and CD represent each half of the input value, and the arrangement is done according to Gray code, which might look a little confusing at first, but actually starts to make sense after working with k-maps for a little while. Pay attention to the ordering of the input bits A-D. In the truth table they are ordered most to least significant bit, but in the k-map I've done them least to most significant bit. The ordering doesnt matter, but in the truth table I opted to represent it how you'd typically see binary, whereas in the k-map I did it for ease of recognition with the bits reading left to right.

The next step is to place a 1 in each cell of the k-map where, in this case, the a segment of the display should be turned on, and 0 where it should be off. To do this, take each value from the a column of the truth table and place it in the appropriate cells of the k-map to come up with something like this:

With the above k-map you then need to define what are called "minterms" (or "maxterms" if you're working complementary wise), and they are essentially formulas that match cells of the k-map. I'm not sure if that made much sense, but heres a couple of examples that might help make this easier to understand:

And lets see if I can try to explain how this works...

Taking the yellow example, we can see that two cells are highlighted, and the formula to match those two cells is A'B'C'. The apostrophe indicates the complement, so A' ("not A") matches on 0, whereas A would match on 1. Beginning with A', match any rows where A is 0, which is the top two rows. Next is B', so this would narrow the match to only rows where B is also 0, so this would match the top row only as in the bottom row, A is 1. And finally with C' we further narrow the match to only columns where C is 0. So in that case, we end up with the two left hand cells of the top row.

Moving to the red example, we see that we need to start by matching only rows where the value of B is a 1. Next we need to narrow the match to only columns where C is 0, and finally columns where D is 0. This results in the middle two cells of the left hand column.

I'll leave the green example for you to run over and see if you can figure out how it works (answer at the bottom of the post).

The final step in this part of the process is to work out all of the minterms for the given k-map, and this is what I came up with for the a segment:

The same process is repeated until you have mapped out all of the segments against their respective input values. I've shared a spreadsheet which contains all of the k-maps for the 2, 3 and 4 bit decoders with the minterms that I worked out that you can look over, copy, play with, and maybe you might even find some efficiencies that I could have made. I tried hard and went over them for several days to try and minimise them as much as I could, but everyone reaches a point where you think "good enough".

Some logic can also be simplified, for example, A'BD' actually matches two cells, one on either side of the map. It doesn't matter that it overlaps with BC'D', but it does save a transistor because to match a single cell you need to AND against 4 inputs. 😏

I haven't been able to properly represent instances where minterms overlap each other, for example A'B'C' and B'C'D both match the cell corresponding to value ABCD = 0001. A limitation of using a spreadsheet I suppose. But it should all be there and all be correct. Certainly I think so because ...

The final step was to translate this to logic itself, taking inputs and producing output according to the k-map. A piece of software I have been using to simulate a lot of the logic for my clock is logic.ly. It's a neat piece of software that you can also try on-line for free or download a 30 day trial for various OSes. It has so far proven to be rather valuable in testing out whether something I have come up with will actually work or not - before committing it to a mess of wires.

The minterms defined above can now be translated in to logical AND operations. For example, to match A'B'C', we simply need a 3-input NOR gate (remember, a NOR gate can be used to perform AND operations). In the case of A'B'C', if you connect non-inverted A, B and C input signals to the NOR gate, if all of those inputs are low the NOR gate output will be high. That high signal can be fed in to an OR gate (NOR followed by a NOT) to turn on the a segment when the A, B and C inputs are all low, including any other situations where it should be on.

After a little bit of analysis you might also happen to notice that some gate combinations are used several times over. In my case, CD' is used 4 times in the decoder, so I was able to build that as its own little block of logic which could be fed in to other gates. This actually saves me a further single solitary transistor. BD' is used 3 times, but with 3 transistors to implement a similar little block of logic as CD', and then 3 transistors used to accept its input in to the 3 gates that use it versus using 2 transistors in the 3 gates that use that combination, you only break even. The real savings are at 4 uses and above, but unfortunately we don't get that many opportunities in this decoder.

Anyhow, this is what I came up with for my 4 bit BCD to 7 segment decoder and, of course, using nothing but NOR and NOT gates:

As you can see, with a value of 0110 (6) being input in to the decoder, I am getting a 6 on the display.

Don't worry about trying to re-create this yourself (unless you want to try out my circuit above in the online logicly demo, which I don't believe can load files), I have also shared the logicly files for all three of the decoders: 2 bit decoder, 3 bit decoder, 4 bit decoder

The end result, including any optimisation that I could find myself, is that each decoder uses the following number of transistors and gates (inverters/NOT gates included):

• 2 bit decoder: 18 transistors, 14 gates
• 3 bit decoder: 58 transistors, 26 gates
• 4 bit decoder: 72 transistors, 30 gates

I think I'll leave it there for now. A similar process was followed to determine the logic for the 16 segment displays to display 3 letter month names (JAN, FEB, MAR etc) and 2 letter day of week names (MO, TU, WE etc). I'll cover this in another post.

Answer: ACD'

Clock design notes #1 - mechanicals and NOR gates

In this post I will cover some of the design and construction choices I have made. Hopefully it will give you an idea of how things are going to come together physically.

Circuit boards

There are examples of discrete clocks out there that can be built on a single PCB, such as this one. But I want something that will be able to stand on its own. So I plan to build my clock using several smaller boards. The boards will all stack together to form something of a brick, with headers and sockets forming a couple of busses between the boards.

There is also another advantage to using this method I have found, and that is I can build the clock in a modular fashion with each board representing a different "functional block". For example, one board will contain all of the counters for the clock, and another will have the decoders to drive the LED displays for the clock.

Initially I went down to my local electronics shop and found what looked like a nice prototyping board, so I grabbed one of them to do some measurements and test some theories. But it became quickly obvious that it wasn't going to cut it for my project as I wouldn't be able to achieve the increasingly apparent density of transistors per board that I will need. The largest problem is that holes are grouped in lots of three with a common pad between them. The way I intend to lay out my boards, which I'll get to a little later, sees a layout like this taking up 50% more space.

So I went to ebay, as one does, and started looking for an alternative, and I found something which looked a lot better. The most immediately obvious thing is that each hole has its own dedicated pad, which means I can choose the density and orientation of components that I need. As a bonus, it has a larger hole in each corner which will make stacking the boards and holding them all together with spacers all that more easier. They are also physically larger in both dimensions, so I have more space to fit things in. So I ordered a bunch of them, knowing that they are coming from China and would likely take a few weeks to arrive, but to my surprise they showed up barely a week later. In comparison I think they will be perfect for the job:

Board stacking

As mentioned above, I plan to build my clock as a stack of boards. I was originally thinking of hard wiring the boards together, but I thought that would be messy and less elegant, and would make maintenance and/or expansion harder.

Standard 0.1" pin headers and sockets would in theory work fine, but I need to get signals from one board, through one or more boards, to other boards in the stack. Standard headers and sockets don't have pins long enough to achieve that, and I would need to stagger them from board to board (because it would be difficult to install them within the same footprint) which would take up additional space that I need for transistors. And don't forget the extra effort to bridge all of the pins of these disparate headers.

To overcome this I'll be using some sockets with extra long pins extending out the back of them. As a proof of concept I ordered a couple of these to test them out, and with a little toying about I was able to convince myself that they would work, and also answer the question of how far apart the boards would end up being spaced: 12mm.

The body of the socket on these connectors is about 10.5mm high off the board, and the pins extend out the back of the board about 5mm. With 12mm spacing, the pins will insert a couple of mm in to their mating socket, and leave a 1.5mm gap from the top of the socket to the next board for solder and signal wires to live in. It will be a tight fit, but I think I've worked out how to make it .. work.

After ordering and receiving all of the required bits and pieces I did a fit test, and heres a sample of what a couple of boards stacked together would look like:

These 4 boards stacked together had a thickness of a little over 42mm, so as you can see, the more boards, the brickier this thing is going to get. I'm anticipating upwards of 8 in total - no one ever said this would be small or compact. 😄

NOR gate construction

All of the logic for the clock will be implemented using discrete NOR gates. There wont be anything close to an integrated circuit in this clock, except perhaps for the linear regulator in the power supply - but that will certainly be it.

Recall that a NOR gate output is high as long as all of the inputs are low. This is very easy to implement in circuitry, so lets run through it.

To start with, the high output state can be achieved by pulling the output pin via a series resistor up to the positive power rail, like this:

Where Q is the output.

On its own this doesn't achieve much, just a constant high output. But by placing a transistor in between the output and the ground rail, you provide a mechanism to control whether the output is pulled high or low. This would be achieved like so:

Where A is an input.

I will actually be using N channel MOSFETs because they will help to reduce the overall part count by cutting out quite a few additional resistors that would likely be needed if I used bipolar transistors.

So how does the above circuit work? Well, an N channel MOSFET will only allow current to pass from drain to source if its gate is brought "high". So in the circuit above, when the gate of the MOSFET is low, current flows from the positive rail, through the series resistor to the output pin where it feeds other parts of the circuit, thus it is "high" and sourcing current. If you apply voltage to the gate of the MOSFET, any current supplied by the series resistor is shunted down to ground, and any circuitry connected to the output pin also sees ground, so the output is now "low" and is sinking current. The series resistor is necessary in order to prevent the positive rail being shorted directly to ground when a MOSFET turns on, which isn't a nice thing to do.

The circuit above actually represents an inverter because its output inverts the state of its single input (low input = high output, high input = low output). You can turn this in to a NOR gate by adding more inputs as such:

Where A and B are both inputs.

Voila, a 2-input NOR gate. If you were to leave both the A and B inputs low so that both of those MOSFETs are not allowing current to pass, then the output will be high. If you turn on either or both of the MOSFETs, they will pull the output low. Add even more MOSFETs to build bigger NOR gates.

Something worth noting to be more "technically correct" (the best kind of correct), is that you shouldn't leave a MOSFET gate "floating", that is, not connected to either the positive or ground power supply rails in some way. MOSFET gates are minutely capacitive such that even touching one with your finger can be enough to turn it "on-ish", but it won't turn off immediately, and in a circuit this could result in "undocumented behavior". Julian Ilett, another YouTuber that I follow, has a video demonstrating this behaviour.

You can take care of this with a "bleed resistor" which ties the gate to ground so that it has some way to discharge itself. This can also be thought of as a "pull down" resistor, because it pulls the gate low. Conversely, you can also use a "pull up" resistor to pull the gate high so that it is always on and use another method, like a button or switch, to shunt it to ground to turn it off. Conveniently, the design of the NOR gate takes care of this, so I'll only need to handle "special cases".

And finally, this is how I will lay my gates out on the board, and I think I've come up with a method that is relatively dense:

This represents two separate NOR gates, a 2-input and 3-input. Here's a description of whats going on:

• The trace through the middle is the positive power supply rail, one side of the series resistors are connected to it (they will be installed vertically to save space)
• The traces coming off the series resistors adjacent to the transistors are the NOR gate outputs, and they are commoned with all of the drain pins of the MOSFETs that form part of each respective NOR gate
• The top and bottom traces are the ground rail, and the source pins of all MOSFETs will be commoned to the ground rail
• The unconnected pins in the middle of each MOSFET are the gates, and these form the inputs to each NOR gate.

With this layout I have common positive and ground rails between each row of MOSFETs, so I only need alternate their orientation from row to row to connect source and drain pins appropriately.

The specific MOSFET I have chosen to use is the 2N7000, and specifically a variant with splayed legs so that it slots in to holes on a 0.1" grid more easily. Heres a photo of a small batch that I ordered for testing:

Finishing up for this post, with my chosen boards and layout I've calculated that I should be able to build 13 rows with 33 transistors on each, giving me room for about 430 transistors per board while leaving a couple of rows of pads free for the headers and sockets needed for stacking, and I may be able to achieve slightly more than this if push comes to shove.

Discrete NOR logic clock - Introduction

A few weeks ago I was watching a video by a YouTuber called Fran Blanche about the Apollo Guidance Computer DSKY interface. She is looking to build a replica, and had an opportunity to inspect some of the real deal items in person to take measurements and notes. You can check out that video here.

My interest was piqued, and I started doing some reading about the AGC and found that it was built entirely using NOR logic. Apparently, at the time, NOR was the most reliable type of logic gate available. As a point of interest, schematics and other information for the AGC are also available on this website.

If you're not familiar with logic gates, there are several different types that perform different functions, and when combined together can make things as complicated as a CPU in a computer for example. See more about the different types of logic gates on this Wikipedia page. Scroll down the page and you'll find links to further pages describing each type of gate in more detail.

Also, NOR, along with NAND, happen to be what are known as a "universal gates", and basically what that means is that using nothing but NOR (or NAND) logic you can build any other kind of logic gate. There is a Wikipedia article which covers it all with examples, so I wont re-hash here.

But in a nutshell, NOR logic is an OR gate with inverted output (the N stands for NOT). With a standard OR gate, if at least one input is high then its output will also be high, otherwise it will be low. With a NOR gate, if one or more inputs are high the output will be low, otherwise high. Heres a truth table to demonstrate the different input and output combinations of a 2-input NOR gate:

A and B are the inputs, and Q is the output. Additional inputs can be added for more complex logic, but the basic truth remains that the output of the NOR gate is only high when all of the inputs are low.

Theory aside, why is this even a topic of discussion, and why did I make a blog about it? Well, after discovering the AGC was built using NOR logic, I thought to myself that it would be an interesting challenge to build something using NOR logic. And that it could be interesting to cover the process. And it has been said that if you really want to understand something, you should build it.

Now, I'm not going to build a computer to fly me to the moon, but I was already planning to build a clock (because clocks are useful) using CMOS (4000 series) logic, so I thought that this would be a perfect project to satisfy the newly acquired interest. And then I thought I might go one step further and build it entirely of discrete components, because that would be rather impressive looking. To put it another way, I will build it out of individual transistors rather than using pre-packaged 4000 or 7400 series logic chips.

And with that, here is a summary of the functionality that my clock will have:

• hh:mm:ss time readout using 7 segment displays, and specifically 24 hour time which is my preferred time format
• Calendar readout using a combination of 7 and 16 segment displays (e.g. FR 03 MAR)
• Leap year mode, which will need to be manually set during a leap year because I wont be counting years in my clock (I dont think it will be particularly useful) which will allow the calendar to properly handle the month of February
• Timing will be sourced from the mains grid (but not at mains grid voltage obviously) because mains grid frequency is relatively consistent at 50 or 60hz depending on where you are (some clocks you find around your house, e.g. in the oven or microwave, probably work the same way)

And that will be it. I think that represents the most useful information that a clock could display. As a "nice to have" and if I can fit it in without too much additional complexity, an ability to dim or blank the display during certain hours of the day would be a nice feature (e.g. to keep a room, like a bedroom, as dark as possible).

A lot of the design work was complete by the time I started writing this blog. But thats ok. Some of the parts I need are on back order and I might not get them for another month, and I am still sourcing some others, so that gives me some time to play catch up and document the design process and explain the operating theory.