Holy Nonads! A Nine-Bit CPU!

A journey to discover what it's like to build your own processor.

Public Chat
Similar projects worth following
I decided to build my own CPU, and use a very non-standard data and address size (9 bits)

Why nine bits? Why not? But also, it kind of forces me to do things myself , especially on the software side of things. The idea is mainly about learning what it takes to create something unique that can actually run software and do things.

This project is implemented on a (somewhat dated) Xilinx Artix-7 FPGA board, the BASYS 3 development board. The specs for this CPU of mine are decidedly retro - 100MHz clock ( 12.5MHZ instruction execution frequency), 9 bit address and data bus.  So only 512 bytes of memory.  But not bytes, since they're nine bits.

People will say you can have a 9-bit byte, and that 'byte' is a generic term for the smallest addressable quantity in a system.  Technically true, but still confusing.  Standards for IP packets avoid using 'bytes' for this reason and when they want to refer to an 8-bit quantity, they call it an 'octet'.  So for this system, the equivalent name I discovered was 'nonad'. 

So there you have it, a Nonadic CPU!

I'm not trying to build something groundbreaking or high performance, I am just on a discovery journey about the various stages computers go through when being created - from gates to gaming.

I've been posting updates to this project on my newsletter, The Mad Ned Memo . But because I don't want to spam everyone there with a million posts about this project, I created a blog here for those few who really want to keep up with the details.  

I'll try to update it as I go along this journey.  My goal would be to get some substantial thing running on my CPU.  Like a game, perhaps.  This involves not just the CPU design but other I/O aspects like video and some input processing, and of course a lot of software stuff.    We'll see how far I get!

NONA assembler for the QIXOTE-1. can compile .nas files into machine code, and then either stream it to the QIXOTE bootloader, or produce a $readmemb file that can be initialized in the Verilog code. Not super-proud of the code organization here, will refactor it maybe at some point. But maybe enough here for anyone looking to do something similar.

plain - 7.56 kB - 03/02/2022 at 13:28



A simple QIXOTE-1 program that displays a picture of Mario. PNG data has been encoded into the program using the png2nas utility. This code can be directly loaded into the QIXOTE-1 via the bootloader function of the nona assembler

nas - 3.39 kB - 03/02/2022 at 13:25


This is a little program to convert a .png image into a Nonad (9-bit byte). If you need to work with data from a png library, I highly recommend the Pillow Python package!

plain - 590.00 bytes - 03/02/2022 at 13:23


  • 1 × The QIXOTE-1 CPU Hardware Design
  • 1 × BASYS 3 FPGA Development Board
  • 1 × NONA Assembler
  • 1 × QIXOTE Bootloader
  • 1 × PNG2NAS Image Converter

View all 7 components

  • It'sa Mee, Mario!

    Mad Ned03/02/2022 at 13:43 0 comments

    So I finally straightened out what was what with my video hardware and software.  I had B swapped with G on the pinouts for the VGA connector, and also the MSB swapped with the LSB.  Along with some hardware bugs with the memory sizing and a few other programming mistakes.  After correcting all of it, this is the result!  It is a pretty faithful reproduction of the .png I started with - although the resolution I am using now makes the Atari 2600 look like a Retina display.

    Next Up:

    • Add in some missing ALU operations, like shift, that are badly needed.
    • Improve the speed of the bootloader - it's like my Commodore 64 cassette drive over here.
    • Start looking into, sigh, a bigger memory.  Sigh because it means redoing the CPU quite a bit., for timing and addressing reasons But hopefully easier the second time around.
    • Something has to be done about the software.  Assembly programming sux.  Maybe it's just my assembly language that sucks, I don't know.  But I miss being able to declare statements with expressions, subroutines, and stuff.  I think perhaps the next explorations for this project will be on the software side.
    • Video system as designed is rather slow - 3 I/O operations to write an x, y, and color.  I did that on purpose to keep my sanity, but now that it works, there's probably a better way..

  • Video Killed The Terminal Star

    Mad Ned03/01/2022 at 13:48 0 comments

    It's wrong in almost every way, but I'm excited to see my QIXOTE-1 processor executing a program that produces video (VGA) images! The system now includes a video buffer 512x512 9-bit color pixels (noxels?)  That can be written to via memory-mapped I/O from a program.  The video driver feeds a VGA timing circuit that produces a signal right off the BASYS 3 board.

    One thing you learn pretty quickly is about the inadequacy of assembler when it comes to writing video programs. It's making me think about a next-level software system, perhaps some kind of tiny BASIC of some sort.  It also is pretty good evidence of a couple of other things:

    • 512 Nonads ain't gonna cut it for very long as the maximum addressable space. I'll have to work on extended memory addressing soon.  That will bring back the ugly spectre of memory latency, as I will need to switch to a BRAM structure rather than registers to fit it on the chip.  This in turn will affect lots of timing and design of the CPU itself, so I am on the fence about whether this is going to happen for QIXOTE-1, or for a future project.
    • My serial bootloader is working fine after a lot of debug of failure of large programs to load.  It turned out my memory had been sized to only 128 Nonads when I started, and the bootloader was fine.  But it is slow, running at 19200 baud and also including some host-side sleep statements in my Python code.  I will probably have to grapple with async timing of this program to make it run faster, as programs get bigger.  (I plan to go into the design of the bootloader in my next Mad Ned Memo article)

  • We Join Our Project, Already In Progress...

    Mad Ned02/26/2022 at 15:47 0 comments

    In my newsletter The Mad Ned Memo, I covered the topic of why I wanted to build a nine-bit CPU, so I won't really go too deep into that topic here.  But suffice to say, I wanted to try building things with FPGAs, and was looking for a unique project to do.  (See the article, I found that to be harder than I thought..)

    In the follow-up part 2, we looked a little deeper into the overall design of the QIXOTE-1 CPU. My plans to build something really exotic were tempered a bit by the reality of not really knowing much about CPU design, and needing to follow somewhat conventional norms.

    This past week, I published Part 3 of the series - where things start to get real as I struggle with timing issues like memory latency.   I think the basic hardware situation is stable now, but I am moving into new areas such as writing a VGA video I/O system that will let the QIXOTE-1 output (low res) video. 

    Probably any new hardware-related will be put here, and not published in the regular newsletter. I'm taking a break there right now from the nine-bit saga so as not to completely bore readers not interested in the topic. But I will continue to post updates here, including what's going on with the software end of this project. 

    (Some of that software stuff will eventually make it back to a future edition of the Memo, but if you really want the latest on this project, this is the spot.)

View all 3 project logs

  • 1
    Getting Started with FPGA Design

    Instead of exact build instructions for the QIXOTE-1 Nine-Bit computer, I plan to put together some hints here for people who wish to get started designing their own hardware, and/or experimenting with FPGA design.  For my project, I chose a (fairly old) development board called the BASYS 3.  This is a board made by Digilent for educational purposes, and a great starting device.   Commerical applications of this board are kind of limited, I would think most things you could do with this you could do better with an embedded processor system like Raspberry Pi.  And if you really wanted state-of-the-art FPGA capability, you'd probably opt for a newer, hybrid board that pairs FPGA chips with a processor/SoC. 

    Buf if you just want to experiment with FPGA hardware, this is still a great board to start with.  It has a bunch of stuff onboard that makes it easier to write starting designs that do something - like switches, buttons LEDs and programmable I/O ports similar to Raspberry Pi's GPIO.

  • 2
    Learn a Hardware Description Language!

    If you are new to chip design, then a starting point should be to learn a Hardware Description Language, such as SystemVerilog, Verilog, or VHDL.   My recommendation is to learn Verilog first, it is the far more popular choice for HW designers and is actually the base layer below SystemVerilog, so if you learn Verilog you can apply what you learn to SystemVerilog later.  

    SystemVerilog is mainly focused on extending Verilog's non-synthesizable capabilities for test bench development, so a lot of what is added there can't be used for FPGA design, anyway (at least, with the Xilinx tools).  And VHDL is in my opinion a more heavy-weight and some would say cumbersome language, popular in some quarters for designing IP blocks but probably not a great choice for beginners.

    There are some decent Verilog courses online including this one from ASIC world.  I can also recommend this book:

    It's not super in-depth, but Verilog By Example covers the basics of Verilog and some issues that are specific to using it for FPGA design, so its not a bad one to have.

  • 3
    Get Your Hardware Software Stack Together

    You'll need special software in order to program an FPGA system, and your best bet is to use the software provided by the chip manufacturer.  I have not worked with Altera chips (in recent memory anyway) so I can only speak to my current experiences working with a board featuring Xilinx FPGA chips.  

    For this, I am using the Xilinx Vivado software package. The free tier "Standard Edition" of this package is more than capable of doing all the things you'll need to get your first design running on FPGA hardware.  

    I am using the Windows version of Vivado, 2021.2.  If I was doing this for a living, I would probably to be honest look at switching to the Linux version, and possibly using the command-line interface to the tools with a separate editor, and some sort of Make-driven build process that can be managed and scaled. 

    For beginners though, the Vivado IDE provides some advantages, of dependency management, syntax/error checking, and tool flow integration that make it a pretty good starter choice.  I find the Xilinx tools at least on Windows to be slow, and the IDE can be clunky at times.  I also miss having revision system integration to git or similar in the tool, something I'm used to with other IDEs.

    But those are not deal-breakers, and so far I've been able to create by nine-bit odd CPU just fine staying within this environment. 

    And it is one-stop-shopping.  Vivado IDE will let you write code, simulate it, synthesize it, place/route, create bit streams for programming the FPGA live, or for configuring onboard memory.  The simulator and accompanying waveform viewer are basic but get the job done.  If you have a better / bigger simulator like Cadence XCelium, you can integrate it, but it is kind of overkill for the hobbyist.

    If you are building yourself a CPU, or embedding a prebuilt one in your FPGA, you will eventually have to think about  the software tool chain for programming it.  Xilinx has a MicroBlaze CPU that can be added to your FPGA and a comprehensive tool chain to work with it.  But if you wanted to do some FPGA/embedded CPU combo and were not crazy like me and designing one of your own, you would probably be better off getting a combo board that has an ARM processor with side FPGA and work with that.

    I will talk some about my software toolchain in my newsletter, the Mad Ned Memo, later.  Because I chose to go a totally nonstandard 9-bit route, things like ELF format, and standard embedded software tools are really not on the table for me, so I can't really provide a lot of useful info about the existing ones compatible with Vivado/Xilinx.

View all 4 instructions

Enjoy this project?



Ken Yap wrote 03/03/2022 at 01:01 point

I will be following with interest. My hunch is the CPU won't be a big issue, you can make it all consistent internally, but the supporting software will pose interesting challenges. You may have to go to the next step, 16 bit words, in the host software. I think you wrote as much.

  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