The Spikeputor

I am building a computer featuring a 16-bit RISC CPU made of transistors for learning, fun and art. It will be pretty large.

Similar projects worth following
After taking the MITx course "Computation Structures", I realized how relatively easy it would be to build a CPU. Armed with a beginners knowledge of electronics and the concepts introduced in the course, I designed and started implementation of an NMOS logic-based RISC CPU. Wall-mounted, it will take up an entire wall. For extra retro-computing flair, the I/O will be handled by an old Apple II plus I had sitting in my closet. I'm physically building it out of pegboards, protoboards, 2N7000 transistors, resistors (mainly SIPs, but a few discretes here and there), LEDs, a few HP-5082 display chips, some electroluminescent wire, and lots of lovely colored jumper wire. My goal will be to be able to execute simple programs and visualize the computation as it happens.

The Spikeputor will be a fully functional computer with a CPU made exclusively from NMOS logic using about 5,000 MOSFETs (2N7000), resistors, and LEDs to visualize the logic. HP-5082-7340 Hex Display chips will be strategically added to display the numeric contents of the outputs of the major CPU components, although if you read binary, the LEDs will provide the same information. Electroluminescent wire will be added to visualize the logic pathways between the major components. The clock will be adjustable from maximum speed (predicted to be in the tens of thousands of hertz range) down to single step (design TBD). Since the primary driver of the Spikeputor is to visualize computation, speed was not a concern, although some steps will be taken (a clock tree, e.g.) to enhance the overall performance.

The initial CPU design was inspired by the Beta CPU, introduced in the MITx course, "Computation Structures" (highly recommended!) The Beta has a load-store, 32-bit RISC architecture. To save space, transistors, and the creator's sanity, the Spikeputor CPU was reduced to 16 bits. This necessitated several other major design changes, mainly centering on the fact that 16-bit opcodes could no longer support the inclusion of constants within the opcode.

Spikeputor CPU Design Features and Major Components:

  • 16-Bit Address space
  • Register Memory: Seven 16-bit registers, plus one register hard-coded to zero.
  • Multi-function ALU
    • Addition and Subtraction, supporting 2s Complement negative numbers
    • Comparison (Equal, Less Than, Less Than or Equal)
    • Boolean Logic (AND, OR, XOR, Identity)
    • Variable Bitwise Shift Right or Left with or without Sign Bit Propagation
  • Control Logic implemented with simple logic gates (no microcode or ROMs)
  • Additional registers for Program Counter, Instruction, Constant, CPU Phase, and a few required status flags
  • One-word opcodes for operations between registers
  • Two-Word opcodes for operations between registers and 16-bit constants
    • ALU Functions (see above)
    • Memory functions: Load, Load Relative to PC, and Store
    • Conditional (BEQ, BNE) and non-conditional branching with branch point storage
  • IRQ and RESET handling (including automatically using register R6 as the Exception Pointer)
  • Direct Memory Access (DMA) for all I/O


To be able to execute more than just trivial programs, the Spikeputor CPU will interface with high speed static memory chips (Fujitsu MB81C67 or similar). In addition, a mirrored write-only "screen memory," also made from (roughly 5,000) transistors, will be created, providing a 48 by 18 array of addressable LEDs. ROM may be added in the future to provide for a low-level operating system. Until then, the I/O controller (see below) will do the heavy lifting.


All I/O functions will be facilitated via custom software and hardware running on an Apple II Plus computer, vintage 1986. A custom peripheral card called BIAS (Board to Interface Apple to Spikeputor) will be designed as part of the project, as well as the software on the Apple to provide keyboard input, screen output, and long-term data storage and retrieval. The I/O controller will have direct access to the Spikeputor memory and will halt the Spikeputor CPU during all read and write operations.


The Spikeputor will be assembled on a series of mounted solderless breadboards. Each major component (ALU, Register Memory, Control Logic/Program Counter/Status Registers, and Screen Memory) will be laid out on a 4 foot by 6 foot pegboard. Each pegboard can contain a nine by six array (54) of breadbaords with some space left over for some smaller circuits as required. Each of the four pegboards will then be wall-mounted, with space below the installation for a desk with the Apple II Plus.


The power requirements, which will be discussed in a bit more detail in the project logs, will be somewhere on the order of 25 watts. The Spikeputor will run on +5V power, conveniently...

Read more »

  • 10000 × 2N7000 MOSFET
  • 200 × 830 Hole Prototype Board
  • 200 × 4.7 KΩ Resistors, SIP-8

  • Designing and Building Register Memory

    spudfishScott01/09/2019 at 16:17 0 comments

    From a functional standpoint, the only differences between the Spikeputor's Register Memory and the Register Memory of the "Beta" processor on which it is based is a decreased number of registers (8 vs. 32) and a decreased number of bits per register (16 vs. 32). Otherwise, the inputs and outputs are the same. RegMem has three register address inputs (Ra, Rb, and Rc), three bits each, a 16 bit data input (WDATA), two 16 bit outputs (RADATA and RBDATA), three control lines (RBSEL, WASEL, and WE), and a clock input. 

    Functionally, register Ra is immediately placed on RADATA. The RBSEL signal determines whether Rb or Rc is placed on RBDATA. WASEL selects whether Rc or R6 (used as the exception pointer on IRQ) will be written to, if WE is high, on the next rising clock pulse.

    The full schematic of the register memory is shown below, and includes some logic to handle the control lines, decoder logic to translate each of the address signals into enable signals for the writeback and output functions, load enable positive edge-triggered flip-flops to store the data, and tri-state buffers to select each of the two output channels.

    The flip-flops are modified from those described in the "Building Blocks" log entry to include a built-in MUX2, which selects between updating the flip-flop with new data (EN high) or previously stored data (EN low). Note that all of the tri-state buffers are implemented as a single transistor using source as the input, drain as output, and gate as enable. To overcome issues with the body diode in the 2N7000, each signal going into the tri-state must be a isolated from the rest of the circuit. This was done by simply putting an inverter in front of each tri-state input. Yann Guidon pointed out that I could have also used two transistors, rather than a transistor and an inverter. I had explored this earlier, but abandoned it for reasons I can't quite remember (might have had to do with a lower voltage output for that configuration). Since it spares a resistor, I'll likely use it for later additions to the Spikeputor CPU. 

    Since notQ is the actual desired value of the bit (because D is inverted before the tri-state), an LED was wired directly to that output to show the state of each bit. The two channel outputs actually come from Q, followed by an inverter leading to the tri-state buffers shown in the schematic. Note that for R7, the data values are hard-wired to ground, nor is there any circuitry for writing to or storing in R7, creating the "always zero" register.

    Each register is arranged in a single row on the pegboard, with one breadboard containing the decoder logic and bit 0 of the stored value, and five breadboards with three bits each completing the remaining 15 bits. The decoder also has three LEDs to indicate if the register is selected for writeback (blue), or channel A (red) or B (green) output.

    Decoder logic and Bit 0:

    Three bits of Register Memory:

    Because I had space, the Writeback Data MUX4 used to select the RegMem WDATA input was placed at the top of the RegMem pegboard. It is also five breadboards wide (three bits per board), plus an additional board for Bit 0 plus the rest of the logic to process the RegMem control signals. The WDSEL signal selects which input (PC_INC, ALU, or MEMORY) is used for WDATA. At the time of the initial design, the fourth input on the MUX4 was open. Since I had the space to accommodate it, I kept it open, initially grounding each bit of the signal, figuring I'd have another way to write a zero to a selected register. As it turns out, as of today, I think I'm going to need this open position to capture the current PC value to handle interrupts, but that's still being worked out. Bottom line: I'm glad I had the inkling to leave it rather than spare some transistors to build a MUX3 instead.

    WDATA Input from WDSEL MUX4:

    Since register R7 is zero only, it only needed two boards (one for each output channel) to lay out all of the associated...

    Read more »

  • Overall Design and Build Strategy

    spudfishScott01/08/2019 at 03:36 0 comments

    As mentioned in the Details Section, the Spikeputor CPU is modeled after the "Beta" CPU from the MITx course, "Computation Structures" (see this link to the Beta diagram). The Beta is a 32-bit RISC CPU with 32 registers (31 + 1 that is hard-coded to zero). I chose it as a model because, frankly, it was the only CPU I knew from the ground up and it seemed relatively simple and elegant, yet quite powerful. Once I did a quick calculation of the number of discrete components I'd need to fully implement the Beta, however, I knew that some compromises would have to be made. The main compromise was to switch from a 32-bit to a 16-bit architecture. At that point, I did NOT look at other 16-bit CPU designs. Instead, I took on the challenge of adapting the Beta to a 16-bit design with as few changes as possible. The biggest changes centered around opcode and instruction size. The beta always executed one opcode per clock cycle. The 32-bit opcodes were wide enough to accommodate instructions featuring up to three registers (five bits to address each of the 32 register locations) or two registers and a 16-bit constant. The remainder of the bits were more than enough to describe all of the instructions defined by the Beta's ISA (Instruction Set Architecture). 

    With only 16 bits to work with in a Spikeputor CPU opcode, the number of registers needed to be reduced to eight (three bits to address each of them, R0 to R7, where R7 was hard-coded to always be zero), leaving six bits for encoding the rest of the operations. Obviously, there was no available space for constants of any size within the opcode itself. Reducing the register count was acceptable to me. There'd be a code efficiency hit, but the transistor count for Register Memory was much more manageable. To be able to use constants, however, required a major change in the architecture. Instead of a simple one instruction per cycle design, a multi-phase instruction scheme was needed, necessitating several additional special-purpose registers, independent from the user registers. I envisioned three CPU phases. Phase information would be stored in a two bit CPU_PHASE register. In phase 0, the instruction would be read in to a 16 bit INSTRUCTION register. If the instruction called for a constant, the CPU phase would be updated to phase 1, the program counter incremented, and the constant read in to a 16 bit CONSTANT register. If a constant wasn't part of the instruction, the CPU phase would go directly from phase 0 to phase 2. In phase 2, the instruction would be executed, including updating the Program Counter to go to the next instruction or to branch to a new memory location.

    One other difference I chose with the Spikeputor CPU was to not implement a "supervisor" address bit, mainly because I wanted the flexibility to (eventually) use the entire 16-bit address space. Instead, to handle interrupts (which I still don't know if I'll even use, but still wanted to design), there would be a one bit IRQ_FLAG register to prevent the interrupt itself from being interrupted. The whole initial design looked like this:

    I'll describe each of the modules in greater detail in subsequent project logs.

    Since the Register Memory and ALU were most similar to the Beta design (something I gained experience with taking the Computation Structures course), I decided to dive right in to starting to build those first. As mentioned in the Details, I'm doing the whole project with solderless breadboards. I'm doing this for purely artistic reasons: I just love how they look, the air of impermanence they invoke, and their modularity. In addition to the schematic, I needed to plan out how the actual components would be laid out. Trying to use breadboard space most efficiently is actually another major design driver. Usually this goes hand-in-hand with transistor component efficiency, but not always. Sometimes, adding a few extra components actually makes it easier to lay out the boards...

    Read more »

  • Building Blocks 2: Multiplexors and Flip-Flops

    spudfishScott12/28/2018 at 16:35 8 comments

    From simple transistor-based logic gates, we turn our attention to the higher complexity components that make up the essential building blocks of the CPU: multiplexors, to set up the appropriate logic pathway for each instruction, and flip-flops, which become the basis of all of the registers. For this project, the overarching design principal for designing these components is transistor efficiency: We need robust, reliable components made with the fewest transistors. Since, with a 16-bit CPU architecture, each component is effectively copied 16 times for each implementation, even a design with one fewer transistor can make a big difference in the total number of transistors. It also provides increased flexibility for laying out the actual components on the breadboards. After a fair amount of research and building test circuits, the two-input multiplexor circuit shown below was chosen. Instead of the "classic" design with three NAND gates and an inverter (seven transistors), it uses single MOSFETs as a poor-man's tri-state buffer. This works quite well as long as the input signals are buffered, inverting them on input and once again on output, for a total of six transistors. This design can be easily extended to a four-input multiplexor (15 transistors vs. 17 using NAND gates).

    For the flip-flops, Wikipedia (borrowing from the TI 7474 chip) provided a nice transistor-sparing design for a positive-edge triggered D Flip-Flop for all the registers:

    I was also able to use an XOR gate design that required only five transistors, which considerably simplified the layout (and transistor count) of the ALU's adder function:

    Armed with these basic components, it was time to start figuring out how it would all go together to make the Spikeputor CPU.

  • Building Blocks 1: Simple Logic

    spudfishScott12/25/2018 at 20:00 2 comments

    When creating a CPU out of transistors, the first thing one needs to do is pick a design for basic logic gates. I chose NMOS logic with 2N7000 MOSFETs. MOSFETs are nice because they don't require any current limiting resistors at the gate, since current flow from gate to source is basically zero. This reduces the total number of components and simplifies the design. The schematics for an inverter, a NAND gate, and a NOR gate are shown below:

    The resistor value was chosen to keep the total power consumption of the Spikeputor in the light bulb range (25 Watts). Each logic gate in the CPU can consume V^2/R watts when all inputs are ON. That's about 5 mW per gate, and the Spikeputor will have on the order of 5,000 gates. Lower resistor values would speed up the gate switching time, but at the expense of greater power use. Based on modeling and measurements on actual circuits, I estimate that the maximum clock speed of the Spikeputor will be on the order of tens of thousands of hertz. Since the point of the Spikeputor project is to visualize computation, that's more than enough. Plus, getting up into hundreds of thousands of hertz clock speeds would require an order of magnitude decrease in resistance, bringing the Spikeputor total power consumption into the hair dryer range (250 Watts). Although all of these values are order of magnitude estimates, and we'll see the actual power consumption and speed as the thing gets built, I feel comfortable with these design choices.

  • Starting on Hackaday.IO: Current State

    spudfishScott12/18/2018 at 17:12 0 comments

    Since I started this hackaday project in medias res, as it were, I think I'll start with the current status and work both backwards and forwards. As of today, the register memory is about halfway complete (input, output, and three of seven registers, plus a zero register), and the ALU is 80% complete (just a few more shifters to install). Here's a video of the first Spikeputor "program", which is really just a hard-wired loop between the register memory and the ALU. Nonetheless, I have something that can perform successive additions on each clock cycle.

View all 5 project logs

Enjoy this project?



L W wrote 01/07/2019 at 18:33 point

Very cool! Can't wait to see how ti progresses. Have you got any clearer pictures up close? 

  Are you sure? yes | no

spudfishScott wrote 01/07/2019 at 18:47 point

Thanks! I'll upload more close-up pictures as I "catch up" in the project log with where I am now.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 01/03/2019 at 21:49 point

Oh, a MegaProcessor on Hackaday :-D
For MUX, you could use a "ladder/binary tree" system, which requires complementary control inputs but uses fewer transistors.
NMOS has some inherent drawbacks (power and speed). I've tried discrete CMOS for #Yet Another (Discrete) Clock :-)

  Are you sure? yes | no

spudfishScott wrote 01/05/2019 at 19:23 point

Thanks. I do know about the Megaprocessor. Although I found it after I started designing the Spikeputor, I decided to go forward anyway. The designs are different enough, plus I want one of my own! I'm pretty happy with NMOS, because I don't need the speed and the power requirements are reasonable (about 25 Watts total). Also, p-Channel MOSFETs are 8-10 times as expensive as n-Channel and using CMOS would double the number of transistors required.

  Are you sure? yes | no

Yann Guidon / YGDES wrote 01/09/2019 at 03:18 point

it's not as if you could have too many transistors ;-)

  Are you sure? yes | no

Peabody1929 wrote 12/18/2018 at 18:11 point

It looks like you are using EasyEDA.  Instead of breadboards, how about creating simple PCBs for different modules?  If one wire comes loose on a breadboard somewhere, it could take a LOOOOOOONG time to find it.

  Are you sure? yes | no

spudfishScott wrote 12/18/2018 at 18:26 point

Your point is well taken, and many of my friends think I'm nuts to not use PCBs. But I'm pretty committed to breadboards. I really like the way they look and they fit my artistic vision for the project. Interestingly, since things fail at the bit level, it has been simpler than you might think to track down wiring problems.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

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