One Bit CPUs

I have been exploring one bit CPUs.
For the right application they may be worth knowing.

Similar projects worth following
Starhawk ( showed me a design for a discrete MC14500B clone he was building. The MC14500B is a one bit CPU used in PLC many years ago. So I thought I would have a look at the MC14500B and other 1 bit CPUs.

One Bit CPUs

There a a couple on the Internet I start with the MC14500B. This chip was used many years ago for PLCs but the documentation is still available:


I bought a couple of chips from ebay in case I decide to build a system.

This guy (name unknown) built a clone from discrete chips:

I got the schematic from the Wayback Machine:

Now I think the RR clock logic is flawed so here is an edited version:

The other one bit CPU that caught my eye was from Laughton Electronics:

I thought of this machine was a Finite State Machine (FSM) which would be difficult to program (binary FSM can get very complicated very quickly), but upon sleeping on it, it has more of a Subleq programming feel (or can be programmed that way). I suspect this machine does not make sense to most people!

There are others but these two seem to be the best.

How do they work? They only have 1 bit!

A basic one bit CPU will have an input port(s) and an output port(s). It will read the input port a bit at a time, process the bit (using stored data about previous bit reads) and write to the output port. The example below reads A and B and if both are high then turn on the Load (i.e. Load = A AND B):

 Here is the code:


So providing you only want to use logic to control something, they will work quite well (think of a set of traffic lights).

Not that fast and not very efficient at doing any mathematics.


  • The Laughton Electronics One Bit Machine

    agp.cooper6 days ago 0 comments

    The Laughton Electronics One Bit Machine

    The Laughton Electronics one bit machine is very likely the smallest discrete CPU that can be built (

    I have designed a simplified version that does not use the data bit in the instruction byte or requires the top half of the ROM to have jump on reset instructions:

    (Don't build this, it is not final!)

    The reset signal (RST) is clocked or synchronised (CRST) and turns off the address latch. The resistors set the reset address (0x00 in this case). As the clock is still running the instruction at the reset address is executed repeatedly.  

    My version will probably still need the deglitch (i.e. low pass) on the data line, (I am guessing that the ROM is generating address glitches).

    I have taken a Subleq approach here and have a specific I/O address for Low and High. Like Laughton I have added two memory bits.

    How does the memory addressing work?

    To understand the memory addressing consider typical set of instructions:

    In the above, the next instruction (address) is automatically done in a hardware.

    In the Laugthon machine there is no program counter so the next address must be explicit:

    The cost is that the approach costs additional memory.

    Here is the Laughton format:

    You cannot actually change the input address based on the input bit (as it could oscillate) but you can change the output address. Really, to avoid programming difficulties (in your head!) it would be best to keep for both input bit cases, the input and output address the same. It would also simplify programming if one of the jump addresses is the preferred "next" address (say jump on one).

    For my CPU, here is my programming template with some coding examples:

    Note: Each row is a byte in ROM (merged cells are duplicated, so each instruction is 4 bytes.

    You may see that a more sophisticated CPU would use the duplicated I/O address to extent the CPU I/O addresses and/or add OpCodes. 

    I am sure that many people look at the Laughton's machine (and download the image) but not knowing how to program it, just move on. The programming template makes it much more straight forward.

    OpCode Density

    The concept describes the amount of memory required to code something. Simple CPU usually have low OpCode density. Subleq for example is at least twice as bad as TTA (Transport Triggered Architecture), all other things being the same.

    Laughton's machine has two functions or instructions and has a higher OpCode density than my version (which is pure TTA). The MC14500B has 16 instructions and the code density would be in the order of four times less ROM space than my machine.

    So there is merit in considering an ALU in the bit path (at the cost of I/O addresses). For a single OpCode bit Laughton's approach is hard to beat.


    Spent half the day playing around with a strip-board version but decided I needed to get it working in TinaTi. Here is the working TinaTI schematic:

    At the top is a hardware ROM! Most the work was getting the clock timing right for the reset. Here is the timing diagram:

    Some thoughts on Laugthon's version. As it relies on slow ROM so it may not work with modern very fast PROMs. That is what the RC delay filter is for, to keep the data around so it can be clocked/latched. Anyway, in exchange for two additional chips, I don't have to program the top half of the PROM with reset instructions and the full IO address (8 bits) latched for the cycle. I was playing with a design that separated the two IO bytes but it was starting to get complicated. Overall, seven chips and a clock (i.e. eight chips) still makes a pretty small CPU.


  • MC14500B and MC14500 Discrete Clone Timing

    agp.cooper7 days ago 0 comments


    Ideally I would like the MC14500B and the MC14500 discrete clone to be compatible so that any circuit I build I can swap one out for the other.

    I looked at the timing signals of the MC14500B and I find the WRITE (pulse) signal is probably too slow for modern memory (and even old memory) components. These two reference resorted to shaping the write pulse due to the issue:

    Although I did look at merging DIN and DOUT of the clone to single DATA signal as per the MC14500B, this is not really a great idea. The separate data paths are better as the DATA signal conflicts for the MC14500B (i.e. two common outputs during the timing cycle) with the muliplexed Input Data signal (if the WRITE signal is used for data multiplexing, which seems to be the way this signal is used). The conflict does not seem to worry the MC14500B but a current limiting resistor in the Input Data multiplexer signal line would seem to be a good idea.

    For the clone I have stayed with the full cycle WRITE signal (as opposed to the half cycle WRITE PULSE of the MC14500B) and added a separate /WP signal for the Data Output Addressable Latch.

    Here is my schematic of the MC14500 Discrete Clone:

    TBC ... 


  • Analysing the MC14500B Discrete Clone

    agp.cooper08/12/2017 at 15:45 0 comments

    Pulling the MC14500B Discrete Clone apart and putting it back together

    In case you have not seen it, here is the video demonstrating the MC14500B clone:

    Here is the clone schematic:

    I have found that the clock logic is glitched and have edited the schematic:

    The actual MC15400B has the instruction latched but this is only necessary if the ROM space is interlaced with the input or output address. The clone also differs in that the Data signal has been split into Din and Dout. This is actually more convenient. Finally NOPO 0 and FLAG 0 have not been decoded. The on board clock is also absent.

    Here is the MC14500B block diagram and pin assignment for reference:

    Finally here is the Instruction Set:

    A working Example

    Here is a working example of the MC14500B by Nicola Cimmino:

    He has also put his schematic and other data on github:


    In this case, he uses an Arduino to program the SRAM.


    And finally an ultra simple version where the operator is the ROM :(

    And his video and schematic:


View all 3 project logs

Enjoy this project?



Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates