SPAM-1 - 8 Bit CPU with a Tool Chain Twist

8 Bit CPU with simulator and tooling, but where the assembler and other tooling is built using Google Sheets for maximum accessibility

Public Chat
Similar projects worth following
SPAM-1 : Simple Programmable And Massive - v1

Full details :

"Massive" in the sense that it's going to be built on breadboard.

Currently simulated in Logisim Evolution - transfer to hardware when detailed worked out including tool chain.

Be sure to check out the Assembler written in Google Sheets - I've not seen this done before - is it a first? My intention was to make the tooling as accessible as possible, with no need to have python or perl or whatever installed locally to assemble code. Much more visual. This is part 1 of the evolution - working out how to design a cpu and putting some tooling in place.

⭐️ I wanted to do things a little differently to some of the other efforts on the internet! I want the assembler and any other code I write to to be more readily accessible and instantly usable to others (like you) without installing python or perl or whatever first, so I've written the assembler in google sheets!I want to be able to run at least the typical demo programs like Fibonacci

  • I would like to extend it to play some kind of basic game (tbd)
  • It will have an assembly language and assembler for it
  • I might port C to it
  • I want to simulate it first
  • I want to build it physically, or a more likely a derivative

The Assembler is in Google Sheets ....

Graphics Interchange Format - 2.18 MB - 08/03/2019 at 19:59


  • 1 × Logism Evolution
  • 1 × Google Sheets

  • Still Here!

    John Lonergan02/08/2020 at 00:34 0 comments

    This project is still alive, I just got distracted by life and also because I started another project to test the chips I'd bought from eBay and AliExpress as I was a bit doubtful about them.

    The other project is an integrated circuit tester that has the uncommon feature that it can also detect tristate outputs.

    Back soon on SPAM-1 !

  • EPROM/EEPROM alternatives?

    John Lonergan09/16/2019 at 00:11 0 comments

    Ben Eater has just released his latest vid, this time he's demonstrating the build of a 6502 based computer. In this build he uses a 32k x 8 EEPROM, as he did in his earlier CPU series. 

    This reminded me of some research I'd done for memory for my own project SPAM-1 which I've attempted to write up here.


    It's fairly common to use an EEPROM in place of combinatorial logic for an ALU or control logic.

    A limiting factor with these devices is the address bits width and data bits width limiting the control space. For example if I wanted to use a ROM as an 8 bit ALU then I'd probably want to have the address space of something like 21 bits (2 lots of 8 bits for the arguments, 4 bits for the ALU operation selection, 1 bit carry in) and a data bus of 16 bits to allow for the 8 bit result plus flags like Carry, Neg, Zero, Overflow and comparison bits.

    One can find EPROM's that would fit that bill but these need a UV lamp, higher programming voltages etc, and so I wondered what else was out there. Also of potential concern is that EPROMs and EEPROMs are typically quite slow.

    Hunting around it seems that Flash memory is quite common and a lot faster than EPROMS or even EEPROMS. There are some rather large and cheap 16 bit data width NOR Flash devices that look really interesting: - some up to 26 bits of address space.

    I need to find a programmer that's guaranteed to program these things - which one !!?


    My research for SPAM-1 includes looking for a faster alternative to the usual program memory EEPROM so 32kx8 or 64kx8 would be fine for this applications. 

    The EEPROM is probably around the 120ns to 140ns mark however RAMs can be faster than as 25ns read cycle. 

    What I found my self looking at was various forms of non volatile RAM for the program memory. For example non volatile RAM such as a FRAM or an integrated battery backed nvSRAM.

    One additional potential advantage of using non vol RAM is not needing a regular EPROM programmer. Non-volatile RAM, behaves like RAM but retains the data when disconnected from power. So there's no need for a custom EEPROM programmer if you already have something like an Arduino with the 50 pin I/O (or an nano with a bunch of shift registers!) - you can use that to write to the NV RAM. Unlike an EEPROM there are no complicated JEDEC timing and control signal protocols, instead just manipulate the I/O on device like its a RAM. 

    Here's a scratch pad of my notes on the non-volatile RAM: 

    Some of the more recent devices don't come in DIP but one can use an "interposer" to adapt the chips back to DIP. Eg see these

    ROM alternatives:

    The M48Z35Y nvRAM is 32kx8 and £12 retail

    This comes in a 28 pin DIP package you can plug straight into a breadboard.


    CY14B256LA-SZ45XI This 45ns nvSRAM is 32x8 and costs about £10.
    It is SOIC-32 so needs an adapter to DIP-32.
    A SOIC-32 to 32 pin DIP interposer can be about £5

    There is a 25ns version for £2 more.

    If you can find the STK16C88 then this is already in a DIP package so no soldering!!


    FRAM is another special RAM type but is SMT only.

    Eg ://

    You can then pick up a SMT to DIP adapter for the FRAM for between $1 and $5, depending on your choice of FRAM.

    Using this adapter you can mount the FRAM on breadboard for programming and for use in the final circuit.


    So say you were running at 3.6volts then you might get one of these for £3.50

    ... and use a TSOP1 adapter like this for £5, perhaps ..


    If using 5v then its bit more expensive for the FRAM...

    Read more »

  • AliExpress?!

    John Lonergan09/08/2019 at 12:34 0 comments

    Wow stuff arrived in about 2 weeks not the expected 30-40 days

  • Clock Gating

    John Lonergan09/07/2019 at 11:54 5 comments

    I'd prefer not to mess with the clock. If I'm using a chip like the 8 bit register 74HC377 which has a LE (latch enable) and clock then I can bring LE high to disable the input to the latch.

    But what if I'm using 74HC574 which is also an 8 bit register which is similar to the 74377 but swaps the LE for OE (output enable). If I need control over whether data is clocked into this chip then the only option left to me is to gate the clock.

    One of the main things to avoid with clock gating is the problem of creating spurious clock signals. Whether there is a risk of this depends on the method taken for the gating and the relative timing of the raw clock versus the other signals with which you are gating the raw clock.

    Whilst a spurious clock may or may not be a problem when latching it is more likely to cause an issue with a counter, such as in the program counter or within a microcode circuit's timing. Having the counter advance unexpectedly and with an extremely short duty cycle would likely cause a malfunction including violating timing constraints of other components within the overal circuit.

    A common case is where the clock is ANDed with some other control signal - I need to do exactly this in a register file I'm designing because I'm using 74HC574 which doesn't have a LE input. I need the 74HC574 for it's tristate output which means I need to compromise on the clock gating. It a question of reducing the complexity. But now I'm worried about gating effects. A spurious clock might make me latch the wrong value. Surely an AND of a control signal and the clock won't cause a problem?

    The paper A Review of Clock Gating Techniques covers a few of the approaches to clock gating and the first option discussed is a "simple" AND gated approach. The paper demonstrates how the relative timing aspect can cause spurious triggers.

    However in the paper I wondered whether the analysis was correct, whether a hazard had been missed. Below I've highlighted the transition I'm concerned about in this extract.

    It seems to me that there is a risk that this transition might cause a spurious clock on Gclk. This might happen if the en went high moments before the fall of the raw clk. Whether or not this potential glitch occurs in practice depends on the derivation of the en. In a CPU the en signal might be generated from some combinatorial logic and is likely to lag the clk due to propagation delays, in which case the problem I'm concerned about wouldn't happen. 

    The paper same paper goes on to criticise NOR and also other techniques - worth reading.

    Timing matters.

  • Timing is Everything

    John Lonergan08/29/2019 at 14:56 0 comments

    Researching Propagation Delays

    One might at some point ask a question "what limits the speed of a CPU?". In most circuits the speed limit probably comes down to the well documented timing limitations of the components you've chosen to use. To be fair factors such as capacitance, or even inductance, damping out or creating higher frequency signals might complicate things but I haven't the experience to say the extent of the role that capacitance and inductance play in limiting home brew CPU speeds; CPU's that run 10MHz or less. My instincts tell me that capacitance and inductance are unlikely to be a huge concern unless attempting to run at higher frequencies and in any case these factors would probably by highly dependent on the specific layout of one's CPU.

    We know that running a home brew CPU in the 1MHz-5MHz range is entirely feasible and it's easy to find folk doing this, such as Warren Toomey and his CSCvon8.

    Why not faster?

    State changes in electronics are fast but not instantaneous. All electronic components have delays around the time needed to setup the inputs of the component and/or delays between an input changing and the output of the component reacting to that change. During these intervals the outputs of the component cannot be relied on to be have a stable and deterministic value and these kinds of delays put a hard limit on how fast one can run a given component.

    Timing diagram - propagation delay

    In addition, many components will state how long the inputs of the device (eg the data in of an latch) must be held stable prior to a trigger or enable signal. If the inputs are not held stable sufficiently long prior to the trigger then the data seen by the device is unpredictable; ie potentially random behaviour.

    edge timing pre and post

    When we put several components together in a circuit then the individual delays of the component sum up on the critical path of the larger circuit to further reduce the maximum operating frequency of the circuit as a whole.

    For example, consider the logic around an instruction that latches a constant from the program memory into a register. The program memory, eg a ROM, will have associated control logic around it and the output of the ROM will loaded into a register and all those components will have their own delays.

    For example, lets say the control logic, a 74HCHCT151 multiplexer, takes 25ns to stabilise the output enable flag on the ROM, the ROM, a AT28C256-15, takes 150ns to display the new data value and finally the register, a 74HCT374, takes 12ns to latch the ROM output, then the critical path through those components is 187ns. In this case then the fastest one could expect to operate this path would be of the order of 5.3Mhz ( = 1 divided by 0.000,000,187).

    And depending on the choice of components this max clock rate could be considerably less. For example, if instead we choose the slower AT28C256-35 ROM then we are looking at a tACC (time from address to data output stabilisation) or tCE(time from chip enable to data output stabilisation) of 350ns, which would mean a max frequency of no more than 1/(25+350+12) = 2.5Mhz approx.

    All the calcs above are approximations from the data sheets (which I may have misread) but the principal stands that longer delays in the individual components translate to lower operating frequencies for the CPU.

    If one uses a more sophisticated simulation or modelling tool than Logisim then the tool will probably calculate your critical path for you and tell you the timings. The critical path is the slowest path and thus the path likely with the greatest impact on speed.

    Most of the time I figure you can work it out roughly like I have above and then decide if you want to make adjustments to your design.

    One significant improvement to the 150ns ROM example given above might be have the ROM contain a simple boot program that copies the program code from ROM into a much faster SRAM chip at power-on and then run the program entirely from the...

    Read more »

  • Great Advice

    John Lonergan08/16/2019 at 00:26 0 comments

    Been speaking to Warren Toomey of Crazy Small CPU fame and The Unix Heritage Society.

    I strongly recommend you check out CrazySmallCPU and the Youtube playlist for the build. Also see CSCvon8 the 8 bit successor. There are some really interesting compromises in there that will probably directly influence my own build, in particular the ALU. 

    Many other have also used a ROM of some kind, typically an EEPROM, for the combinatorial logic of an ALU (and other components) but I've struggled a bit with most of them as they are typically 4 bit or don't support features like the full set of typical ALU flags out etc. I wanted an 8 bit ALU that would support exploring arbitrary arithmetic and also a full set of flags and compare and I also wanted more than just Add and Sub, I wanted a much more complete set of arithmetic and logic ops. The problem was I couldn't work out how to do it on the EEPROMs I was able to locate.

    Doing all that with a pair of 8 bit wide ROMs seemed complicated as well, but Warren identified a 2Megx16 bit wide EPROM that has all the data pins necessary for his (and my needs) and also has a wide enough address range to support 2 sets of 8bits of data in, plus 5 bits left over for ALU operations. Also they are also cheap , however hard'ish to find, need UV erasure and won't program using the Arduino that most folk use for the EEPROMs - so there are some other challenges.

    Anyway - that was incredibly useful to me.

    Also useful was Warren's recent blog post on control signal timing that covered in detail some questions I had. Ben Eater's series and others don't go into a great deal of info on this and I'm grateful for the experiences shared by Warren.

    Also useful to me were pointers about I/O which I will almost certainly implement.

  • Decisions decisions

    John Lonergan08/11/2019 at 13:22 0 comments

    Need to decide 

    • whether to further simplify 

    or go the other way and ...

    • add further general purpose registers 
    • and IO - IO might be achieved by memory mapping the devices, or by adding further special purpose registers etc

    Also ...

    • consider adopting a higher level language - ? something like ttlcpu ? 
    • deciding whether to use higher level instructions to drive the microcode or just put this complexity in the Assembler (or Compiler) instead

    And ..

    • working out how to integrate with VGA - probably using a NovaVGA and some shift registers as IO.
    •  working out how to integrate with input devices (eg a potentiometer if we were to implement a Pong game for instance)

  • Starting the hardware order

    John Lonergan08/11/2019 at 13:12 0 comments

    Made a start on ordering components for the hardware version.

    I live in the UK but found better prices on Mouser which has a UK site but ships from Texas.

    Also considering buying from Aliexpress as I'll get twice as many components for the same price if I go that route; for spares or extensions or other projects. I'd have to put up with month++ delivery times though. Hmm. I'll think about it.

View all 8 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