Kestrel Computer Project

The Kestrel project is all about freedom of computing and the freedom of learning using a completely open hardware and software design.

Similar projects worth following
With each passing day, technically capable consumers of computing technology increasingly lose their rights with computer hardware. While some look to prominent Linux suppliers as an escape from the Intel/Microsoft/Hollywood oligarchy, I have taken a different route -- I decided to build my own computer completely from scratch. My computer architecture is fully open; anyone can review the source, learn from, and hack it to suit their needs.

From the main project website:

  • No back doors. No hardware locks or encryption. Open hardware means you can completely understand the hardware.
  • No memberships in expensive special interest groups or trade organizations required to contribute peripherals.
  • No fear of bricking your computer trying to install the OS of your choice. Bootstrap process is fully disclosed.
  • Designed to empower and encourage the owner to learn about and even tweak the software and the hardware for their own benefit.
  • Built on 64-bit RISC-V-compatible processor technology.

More precisely, the Kestrel-3, my third generation design, aims to be a computer just about on par with an Atari ST or Amiga 1200 computer in terms of overall performance and capability, but comparable to a Commodore 64 in terms of getting things to work.


This block diagram illustrates my vision of a Furcula-to-Wishbone bus bridge. The KCP53000 CPU exposes a Furcula bus for both its instruction and data ports. Once these buses are arbitrated to a single interconnect, the KCP53001 is used to talk to Wishbone peripherals and memory.

JPEG Image - 205.76 kB - 11/13/2016 at 15:59



This block diagram illustrates how the pieces of the CGIA fit together to serialize graphics data to the VGA port.

JPEG Image - 1.10 MB - 06/16/2016 at 18:57



Here, I draw a GEOS-inspired dialog box-like thing, interactively as you can see.

Portable Network Graphics (PNG) - 22.93 kB - 04/11/2016 at 20:23



Here, I'm writing software to draw simple boxes to the screen using the XOR operator directly on the framebuffer bitmap.

Portable Network Graphics (PNG) - 54.16 kB - 04/11/2016 at 20:22



Finally got block storage working inside the emulator, and along with it, a visual block editor. It's based on my own Vi-Inspired Block Editor (VIBE).

Portable Network Graphics (PNG) - 52.55 kB - 04/11/2016 at 20:21


View all 8 files

  • Development Plans Updated

    Samuel A. Falvo II05/30/2018 at 23:51 0 comments

    I've updated the Kestrel-3 development plans page.  These plans seem far more actionable to me than my previous set.

  • Ideas for Kestrel-3

    Samuel A. Falvo II03/14/2018 at 17:16 2 comments

    I'm recording some ideas for Kestrel-3 here before I lose them.  Standard disclaimers apply -- not all of these may see light of day, at least right away.  These are nice-to-haves.

    • DX-Forth 2.0
      • Support loading code from files.
      • Support for ALLOCATE and FREE for larger data-sets.
      • Dictionary between 512KB and 2MB in size (easy to use with JAL instructions).
      • Forth compiler that emits native RISC-V instruction streams, at last.
      • Arbitrary-length names for words (allows UTF-8 in names).
      • Remove 256 word dictionary limitation.
      • Significantly more ANS compliant than DX-Forth 1.0.
    • Port of the CoSy vector primitives to DX-Forth
      • Needs better web presence; Geocities-esque site layout is hard to find useful info.
      • Inspired by the K programming language.
      • Primitives useful for numerical and string processing.
    • Port of the CoSy UI
      • Depends on overall capabilities found in VertigOS.
    • VertigOS
      • Minimal GUI, enough to make a usable console (make it Intuition 1.3 compatible?  Make it GEM-like?  GEOS-like?  Mix and blend?)
      • Port of a clean subset of AmigaOS based on BOAR Project (written permission to port).

  • SVFIG Presentation on Kestrel-2DX

    Samuel A. Falvo II03/02/2018 at 16:23 0 comments


  • What About the Kestrel-3?!

    Samuel A. Falvo II02/24/2018 at 16:09 2 comments

    Ideation process is already under way.  I have to proceed carefully, as the initial version of the 3 will be a two-chip computer design.  More details will be covered in today's SVFIG presentation.

    For now, I'm going to spend time with the Kestrel-2DX and enjoy it for a while.  I haven't felt this much joy using a computer since I had my TRS-80 or Commodore 64.

  • Throwing In The Towel Once Again, For Now.

    Samuel A. Falvo II02/24/2018 at 16:04 0 comments

    From my most recent project log on the Kestrel-2DX project page...

    I'm throwing in the towel once more on the Kestrel-2DX project.  However, not because I'm aggravated, or feel defeated over some seemingly insurmountable technical issue (*cough!* Pseudo-SDRAM *cough!*).  Oh no -- this is far, far better than that.  I'm throwing in the towel because I've won.  The Kestrel-2DX, as I've come to envision the computer design, is complete.

    This computer is, bugs and/or feature requests notwithstanding, fully operational.

    For the last two weeks, I have spent zero time using my workstation PC for the purposes of Kestrel development.  My entire interaction with the Kestrel, backups notwithstanding, has been with developing software directly on the Kestrel, inside of DX-Forth.  It's even largely the reason why I haven't been making updates as of late.

    This has lead me to what I think is perhaps my first Law of Computing:

    You know you're finished when you spend more time with your project than you do with the tools to build it.

    I've been having a blast.  I spent the last week or so building up a set of slides to present at today's SVFIG meeting.  Despite DX-Forth not being a super-high performer, I'm planning writing a simple, terribly elementary game -- you know, the sorts of games one would write in BASIC on a Commodore 64 or Apple II.  I doubt it'll push its limits; but, it's all that I know how to do, and it should show nicely what is possible to accomplish with the machine to others.  I'm considering creating some videos along the way as well, so folks can see what it's like working with the system in real-time. 

  • Kestrel-2DX Forth Now Creates Buffers

    Samuel A. Falvo II02/05/2018 at 19:42 0 comments

    So, a wee bit of progress since I last wrote a log entry.  I can now CREATE a new word and ALLOT a buffer.  I can also comma-compile data into the dictionary space.  There are enough word header slots in the symbol table to create up to 256 words upon a freshly booted Forth environment.

    Since this is a 64-bit Forth running with a 16-bit dictionary space, I have four comma words: , (64-bit) W, (32-bit) H, (16-bit) and C, (8-bit).  Similarly, where required, I also have ALIGND, ALIGNW, and ALIGNH for aligning HERE appropriately.

    This doesn't sound like much, but it represents a surprising amount of code investment.  I had to make a word which properly constructed a RISC-V JAL instruction to use as a word's code-field, which proved to be an "interesting" exercise in debugging.

    I think my next steps include (in no particular order):

    • Adding flags field to word headers to identify immediate words.  This will let me implement : and ; sooner, since ; is an immediate word.
    • Adding CONSTANT, VARIABLE, and CVARIABLE as convenience words.
    • Implementing EMPTY to reset the state of HERE and the symbol table.  This will save me from having to BYE back to TIM/V and re-start Forth from a g command all the time.
    • Adding S" for use both interactively and when compiling, so that I can use BLOCK, UPDATE, S", and CMOVE as the most primitive way to self-host software development on the Kestrel-2DX, at least until the CLI editor is done.

    Of course, I'll work on a more usable command-line block editor once I'm happy with the interpreter.  It won't be a full-screen editor though, for the simple reason that  I'm already at 10KB - 11KB of code, which is regrettably larger than I would have liked.  (To be fair, 3KB of it is reserved space for word headers.)  I rather expect to max-out my 16KB self-imposed limit for DX-Forth code image size.  :(

    Until next time...

  • DX-Forth for Kestrel-2DX Now Prints Numbers

    Samuel A. Falvo II01/08/2018 at 17:55 0 comments

    DX-Forth now prints numbers.  Oh, you don't know about DX-Forth?  You should probably read up on the progress of the Kestrel-2DX then.

  • Kestrel-2DX Update: TIM/V

    Samuel A. Falvo II09/24/2017 at 18:19 0 comments

    In case you missed the good news, you might be interested in reading my recent announcement of TIM/V for the Kestrel-2DX.

  • Kestrel-2DX to be submitted for 2017 Hackaday Prize.

    Samuel A. Falvo II09/05/2017 at 03:00 0 comments

    For grins, I've decided to place the Kestrel-2DX up for the 2017 Hackaday Prize, 5th category.  To make this easier for Hackaday folks, I've created a new project dedicated to the Kestrel-2DX.  I will continue logging my progress with it on that project page.  So folks who are interested in the Kestrel, please do follow the Kestrel-2DX project page too!  Thanks!

  • Kestrel-2DX Runs its First C Program

    Samuel A. Falvo II09/02/2017 at 03:56 4 comments

    So, I decided to try getting my RISC-V GCC compiler working with my Kestrel-2DX again, and this time, for whatever reason, my mental model just "clicked" and things worked.  It was an iterative process to get this far; however, I'll describe things in the rough order I've accomplished things.

    Here's the C program I wanted to run:

    /* Invert the contents of the video frame buffer on cold boot. */
    unsigned long long *scrp, *endp;
    _start(void) {
        scrp = (unsigned long long *)0x10000;
        endp = scrp + 2000;
        while(scrp < endp) {
            *scrp ^= 0xFFFFFFFFFFFFFFFF;
        while(1) ;

    I was able to compile this into statically-linked ELF binary file with the following command:

    ./riscv64-unknown-elf-gcc -O1 -c floop.c -o floop.o -march=RV64I
    ./riscv64-unknown-elf-ld floop.ld floop.o -o floop.exe -nostdlib

    You'll notice that I have a custom loader script, which looks like this:

            ROM (rx) : ORIGIN = 0x00000, LENGTH = 0x8000
            RAM (rwx) : ORIGIN = 0x14000, LENGTH = 0x8000
            .text :
                    . = ALIGN(4);
                    . = ALIGN(4);
            } >ROM
            .rodata :
                    . = ALIGN(8);
                    . = ALIGN(8);
            } >ROM
            .data :
                    . = ALIGN(8);
                    . = ALIGN(8);
            } >RAM
            .bss :
                    . = ALIGN(8);
                    . = ALIGN(8);
            } >RAM

    RAM technically starts at address 0x10000; however, the MGIA fetches its video frame from that location, so we configure the linker to place global data variables 16KB away.

    Then, to pull out just the code and constant data, I used the following:

    ./riscv64-unknown-elf-objcopy -j .text -j .rodata floop.exe -O binary floop.bin

    At this point, I have a raw binary image.  A problem remains, however.  The constant data precedes the code; thus, I cannot just have the processor reset directly into _start.

    $ xxd floop.bin   # note data at offset $00, not $38 or something.
    0000000: dec0 ad0b ea1d ad0b 1000 0000 0000 0000  ................
    0000010: b707 0100 3747 0100 1307 07e8 83b6 0700  ....7G..........
    0000020: 93c6 f6ff 23b0 d700 9387 8700 e398 e7fe  ....#...........
    0000030: b747 0100 9387 07e8 3707 0100 2330 f700  .G......7...#0..
    0000040: 6f00 0000                                o...

    Thus, I need a bootstrap of some kind, and I need to place the C code somewhere away from address 0.

    So, I write a simple bootstrap routine in raw assembly to scan ROM for a special "resident" structure (an idea I learned from coding directly on and for AmigaOS); nothing fancy, just something that would let me find the address of _start.

            include "regs.i"
            addi    a0, x0, $200    ; Start at address 512
    L0:     auipc   a1, 0
            ld      a1, chkdword-L0(a1)
            lui     a2, $8000
    L1:     ld      a3, 0(a0)       ; Did we find the checkword?
            beq     a3, a1, yup
            addi    a0, a0, 8
            blt     a0, a2, L1
            addi    a0, x0, -1      ; Deadlock with all LEDs lit if not found.
            lui     a1, $20000
            sh      a0, 2(a1)
            jal     x0, *
    yup:    ld      a3, 8(a0)       ; Get startup procedure's *offset*
            add     a3, a3, a0      ; Get startup procedure's *address*
            lui     sp, $14000      ; Set up C stack pointer.
            jalr    x0, 0(a3)       ; Let there be C.
            align   8
    chkdword:       dword   $0BAD1DEA0BADC0DE
            adv     $8000, $CC 

    I then altered the C code to include the following at the very start:

    struct Resident {
            unsigned long long r_matchWord;
            void (*r_fn)();
    void _start(void);
    const struct Resident R = { 0x0BAD1DEA0BADC0DE, &_start };
    static unsigned long long *scrp, *endp;
    // ...etc...

    After recompiling as above, I now needed to embed the C code into the binary file my personal assembler produced.

    dd if=floop.bin of=rom.bin bs=512 seek=1

    Whoops, this has the effect of truncating the file; I have to re-pad it to 32KB before making the Verilog module with the ROM's contents.

    dd if=/dev/zero of=rom.bin bs=1 count=1 seek=32767

    There, I now have a completed 32KB image.  I rebuild the Verilog ROM module:

    make rtl/rom.v

     edit the resulting Verilog file because Xilinx's flavor of Verilog is retarded and won't accept the sane syntax that Yosys, Icarus, *AND* Verilator accepts.  One of these days, I'll fix my tooling to automate this.


    Read more »

View all 94 project logs

View all instructions

Enjoy this project?



f4hdk wrote 09/20/2017 at 21:09 point


I'm happy to see that you still continue with this project.

Have you seen my A2Z project here?

It is quite a similar project, a full computer based on FPGA, but it is much simpler than yours. I've also coded a homemade compiler.

  Are you sure? yes | no

Samuel A. Falvo II wrote 09/22/2017 at 16:56 point

I believe I've seen it when I first joined the Hackaday community; however, I regret that I haven't been following up on my interests.  Now that I'm fully employed, I tend to focus my free time on my family engagements and, only occasionally, on Kestrel stuff.  :)  Apologies.

You are much further along in your project than I am with mine, though.  Right now, my biggest difficulty is getting reliable SD card operation.  After that, I'll need to make some kind of bootstrap mechanism.  I'm hoping progress will be more forthcoming once I achieve those milestones.

  Are you sure? yes | no

f4hdk wrote 03/25/2018 at 06:36 point

I've seen your SVFIG presentation. Congrats for finishing the Kestrel 2DX !

But I have one question : why only 48kB of RAM? That is very small, very limiting. Why don't you use several MB of external SDRAM present on each FPGA board? With several MB, the computer would be much more useable (like A2Z : )

  Are you sure? yes | no

Samuel A. Falvo II wrote 03/25/2018 at 07:12 point

f4hdk - Thanks for the feedback.  Finishing the 2DX is a major achievement for me, and is an important stepping stone to achieving the Kestrel-3 design.

With regards to your specific question, though, I've explained this numerous times in the project logs and even in the video -- I was utterly and thoroughly unable to raise the PSRAM chip on the FPGA board.  This leaves me limited to just using the block RAM resources that are on the FPGA itself.    If *you* know how to talk to the PSRAM chip on the Nexys-2, I'd sure welcome a patch.  Because I tried, and I've failed, for about two years.

The Kestrel-3 design will target different FPGA boards with 1MB of external SRAM, a significant improvement in RAM capacity.  There is also 512KB of SRAM on the DE-1 board from Terasic.  That same board also has 64MB of SDRAM.  However, I refuse to even try to use SDRAM.  I've learned my lesson.  Avoid SDRAM like the plague.  But, again, if you have an SDRAM controller that works and is license-compatible with MPLv2 without me having to relicense the project as a whole, then I certainly will not turn away a patch to make SDRAM work.

  Are you sure? yes | no

JL9791 wrote 11/27/2016 at 01:20 point

I see you are still working with Forth :)  I came upon this by accident when researching stack CPUs
I would like to learn Forth someday, I like the simplicity of stacks (which reminds me of my Magic the Gathering days).

  Are you sure? yes | no

Samuel A. Falvo II wrote 11/27/2016 at 01:32 point

Not having to name every intermediate computation is quite liberating.  But if taken to an extreme, it can also be quite confusing.  :)  The solution is to learn to hyper-factor your code.  A single function in C could well take 16 word definitions in Forth.  Naming procedures is a nice trade-off, because it almost serves to document why your code is the way it is.  Not quite, but good enough for most purposes.  :)  Plus, it really aids in testing code to make sure things work as you expect them to.

  Are you sure? yes | no

JL9791 wrote 11/09/2016 at 01:09 point

I have been following your project for a while, particularly because you selected the RISC-V ISA to build your CPU around.  I recently came across something I had forgotten about:  the now open source Hitachi CPUs (Sega Genesis, Saturn, Dreamcast) found here

Did you consider those as the brain of your Kestrel?  If not, perhaps they may be a good alternative. :)

  Are you sure? yes | no

Samuel A. Falvo II wrote 11/09/2016 at 01:16 point

Nope, and I have no intentions to either.  I've invested too much into RISC-V to change now.  Switching ISAs today would literally set me back two years of effort.  Besides, performance of RISC-V CPUs are quite good in general; that my own CPU is as slow as a 68000 should not be taken as an indication that all such CPUs are that way.

In the future, I'd like to one day hack a BOOM processor into the Kestrel, which would give it a 4-way superscalar CPU.  But, for now, I just want something simple enough that people can understand.

Another reason for adopting RISC-V is that it has learned many things from both the successes and the failures of past architectures.

Thanks for the link though.  You're not the first to suggest it.  :)

  Are you sure? yes | no

JL9791 wrote 11/09/2016 at 01:18 point

Sure thing.  Yeah, I was not suggesting you scrap all your hard work, just curious.  Glad you are coming along pretty well with it now after the..uh..hiccups :)

  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