I know in the project description, I describe the Kestrel-3 as eventually being as powerful as an Atari ST or Amiga 1200. That's a very long-range vision -- the end-goal. Getting there, though, I want to take small, incremental steps. This may not be immediately obvious to the casual reader of just the description.

One of the biggest influences on my embarking on this project, so long ago, is the Jupiter Ace computer. When I first encountered the Ace (in emulation), I was surprised by how, well, comfortable the computer was to me. It just felt right.

Which is strange, because in my youth, I've dissed computers like the VIC-20 or ZX-81 for being too simplistic. Real computers had a real bitmapped video mode, after all. The built-in language, which is to say, a real version of BASIC, allowed for powerful screen editing. Yet, here was this Z-80-based contraption that was as simple as you can build and still be called a computer, with only 2KB of RAM, and ... I liked it.

I attribute this change in attitude to greater wisdom acquired through my years since then.

Needless to say, the Kestrel-3 environment, currently only in emulation right now, has attained a milestone that I'd set for myself back in 2007. My computer can finally now compete with the Ace on its own terms: it's monochrome, it runs Forth natively, and it feels every bit as comfortable to me as the Ace did when I first played with it.

Is it perfect? Nope. But, that's not the point. It'll evolve over time. Though there are many things I want to change about it, I have to admit that it already has some nice features of its own: 640x480 true-bitmapped graphics (vs 256x192 theoretical resolution on the Ace), 16MB of RAM (in emulation; real hardware might have more or less, depending on what's available; versus 2..48KB in the Ace), and a 2 to 6 MIPS, 64-bit RISC-V processor at its core (depending on instruction mix; I'm guessing an average of 3 to 4, since Forth uses 64-bit words so frequently; vs. around 1 MIPS for the Ace).

After I update the documentation for the project to reflect its current reality, motivated people will probably want to try it out. They might not like it, particularly if they're not already familiar with older versions of Ting/Muench's eForth; it's definitely not ANSI Forth compatible. One concern that was voiced already was that 6 MIPS wasn't fast enough for a 640x480 bitmapped screen. I think this is true for many kinds of gaming purposes (certainly not all), but not necessarily for productivity. That said, the indirect-threaded Forth overhead is immense, and I really think this version of Forth is as slow as BASIC.

I only ask that folks keep some sense of perspective: running GEOS, the Commodore 64 or 128 took about 1 second to render a 8x8 pixel, tiled bit pattern on a 320x200 screen, let alone the time it took rendering text, scrolling, etc. This is with a CPU that is only 0.5 MIPS best-case, and with only an 8-bit data path. A 640x480 screen requires 4.8x as much memory, and thus, 4.8x as much memory bandwidth. With the CPU averaging 4 MIPS (a factor of 8x better than the C64) and considering all video rendering is done in high-level Forth and not in assembly language, video update performance is actually just about on-par with what I'd expected: it's about the same speed as C64 GEOS.

In other words, processor performance has more or less scaled with bitmapped memory requirements, yielding a net unity in performance gain from the C64 to the first-generation Kestrel-3. This is "good enough" for me to commence working on the actual FPGA logic.

Some things I'd like to work on in the future include, but isn't necessarily limited to, the following. Please note: these are not promises, nor are they in any kind of order. These are just things I'd like to work on at some point when I feel the software/hardware ecosystem is stable enough.

• Adding support for color bitmapped graphics (replace MGIA hardware with CGIA).
• Change firmware over to use interrupts.
• Support hardware timers in Forth, and start to provide an event-driven API for interrupt-driven hardware.
• Replace indirect threading with subroutine threading or native-code generation. This should yield substantial runtime performance gains.
• Support for more than one (preferably removable) storage device in Forth. I'm just not yet sure how this will work yet.
• Implement CPU instruction and data caches, allowing me to couple to cellular- and/or SD-RAM. This will let the CPU speed elevate from 6 MIPS to around 50 to 80 MIPS with the hardware available to me as I type this.
• Implement a memory management unit, so that I can run Harvey OS (a GCC-compatible port of Plan 9 from Bell Labs), Linux, and/or a BSD variant.
• Write a very simple clone of Pac-Man. I think this will have adequate performance with what I have now, since you only really update the sprites, and not the full screen. Plus, it's a nice show-off application for Forth.

Anyway, it's bed-time for me and I'm running out of thoughts for now. So with that, good night, and I hope I can keep enhancing the Kestrel in a way that makes people excited for personal computing again.