Kestrel Computer Project

I came across a research paper recently where on page 7, under Figure 1, one bullet reads as follows:

The components of an OCP server are not open source and must be procured.

For this to make the list of a professional research paper focusing on the value chain of "hyperscale", Enterprise-class computing hardware is significant.

It's interesting that if I scaled the Kestrel-3 design up to cover the needs of enterprise computing, it would cover the first three bullet points deftly. This technically means that a suitably designed successor to the Kestrel-3 is actually better positioned for service in the core of a "hyperscale" corporation's IT infrastructure than current OCP offerings would be.

While I doubt companies like Google or Rackspace would make attempts to use Kestrel-derived hardware, I can definitely see opportunities in companies looking to adopt more open infrastructure choices, but who simultaneously do not have or desire investment in the procurement process.

When I read articles like this, I cannot help but think about how I truly wish I could work on Kestrel full-time. *sigh*

At long last, much longer than I anticipated, I finally completed the over-the-shoulder illustrative chapter in the Kestrel 3 User's Guide. As I mentioned before, I removed the Machine Language Monitor and STS chapters, since they're no longer relevant now that Forth is in firmware.

Alas, this opens a gaping hole in the user's guide. If anyone can recommend a good Forth tutorial that is small enough to fit in a chapter (roughly 60 printed pages at 8.5"x11") and which is licensed compatibly with the MPLv2 license, I'd be very appreciative. I'd like to provide a narrative in the book, something like chapter 1, installation (done); chapter 2, getting started with Forth (missing); chapter 3, developing an application in Forth (what is chapter 2 now).

Anyway, per my previous log, having completed the book chapter, I'm moving on to drafting the requirements for the Kestrel-3's soft-core CPU. Following the model set forth in the Commodore 64 Programmer's Reference Guide, the specifications will appear as a chapter and/or as an appendix in the user's guide, along side its supporting peripheral cores.

Longer term, in between these two types of chapters, will lie chapters on assembly language programming for the RISC-V instruction set architecture. I'm not sure what this (series of?) chapter(s) will look like yet, though.

I was hoping to have a new chapter finished for the Kestrel 3 User's Guide done by yesterday evening. Well, the text at least; I still need to work on screen shots. Unfortunately, I had completely forgotten I had a dinner appointment with some open-source community friends of mine, and that kind of derailed my plans a bit. Tonight's not going to work either, as tonight is a martial arts training night. So, it'll have to be either Thursday or Saturday at the earliest.

I think it's high time I start becoming more serious about tracking my time, defects injected and removed, and other relevant metrics in an attempt to get better at both completing my tasks at my day-job as well as maintaining predictability on delivering Kestrel-related progress. I've written a blog article about it on my personal blog.

While commuting back and forth to work, I tend to spend that time working on the Polaris CPU's formal requirements specification. I need this formal requirements definition so that I can justify what goes into hardware actually maps to a real requirement of the hardware, and to catch defects in the design as early as possible. It's OK if I forget something; if I discover I need some feature which I forgot to document, I can always revise the document. At least it'll be recorded somewhere and tracked. This is important, because:

• This documentation is the source of truth for programmers references.
• This documentation can be checked against other artifacts, from design documents to actual Verilog code, to see if everything agrees. If not, that's a defect by definition, and warrants immediate repair.
• This documentation will directly inform the Polaris data sheet documentation.
• This documentation can provide the historical context behind a variety of technical decisions. It's value becomes most apparent if I happen to be challenged legally for something (worst-case) or if I give a tech-talk and someone asks a question on an obscure topic which I've long since forgotten about (best-case).

Of course, I'm not talking about writing 600-page, DoD-standard requirements specifications documents here. But it does need to be formal enough to allow tracing any given line of Verilog code back to a requirement.

Finally, if at some point someone is interested in funding the project, having enough data to provide an earned-value diagram or two, a formal requirements definition, and prediction intervals for delivery dates will almost certainly become immensely valuable for facilitating negotiations.

Boy, wouldn't that be nice? If someone could drop $450,000 on my lap, I'd be able to focus on the Kestrel's development full-time for three years with my current standard of living. But, on the other hand, if someone did want to drop that kind of cash for the project, I have to wonder where the strings are attached, and who will control them. This latter issue is the number-one reason why I haven't sought funding for the project. I want to make sure the core Kestrel project concept is as financially and legally unencumbered as I know how to make it. Once a baseline project is available, then and only then will I consider commercially forking the project for personal gain. (Of course, I have no control over what other people do, only over what I can do with it. If some company wants to fork and commercialize Kestrel before I've attained a baseline architecture, that's their responsibility to bear.)

The Forth environment has stabilized to a point where I feel confident about updating the Kestrel 3 User's Guide with new material on the Forth interpreter. Since writing is such a contemplative outlet, things will be somewhat quiet for a while as I rework the contents to reflect the state of the art. My apologies.

However, if you're interested in following progress of the docs, you can follow the User Guide's Github repository.

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.

I've integrated the block I/O wordset into the normal Forth runtime; in doing so, I've found a number of memory corruptions which I've subsequently fixed. (Took a few days to work it all out though!) In the process, I've integrated BLOCK words so that you don't need to manually initialize the editor or such. I'm sure other bugs exist; however, I've not found anything super-egregious yet.

I've also resolved the stack imbalance caused by processing unsupported keys on the keyboard.

As you know from last update, VIBE performance isn't usable on such a slow CPU; therefore, I've decided to replace VIBE with a simpler CLI-based screen editor interface. This will be less convenient to use in some ways; however, it'll be an improvement to the user experience overall due to greater interactivity. I will restore VIBE to a future ROM image only after I've sped it up. This will allow people to play with the environment in the emulator sooner rather than later, while freeing me up to change my focus over to writing Verilog for the CPU.

Please see the latest project pictures for the editor and its use in action.

It's still not quite right. I have a memory corruption issue that I simply cannot track down yet, but thankfully it doesn't manifest often. I know there's a stack imbalance bug with unhandled keyboard events, so I'm going to debug that next. (These may be related, but hard to say definitively.)

Screen update performance is abysmal inside the editor, but that's because I update the display with zero cleverness at all (as brute as brute force will let me). I hope to address that in a later commit.

Access to SD card is roughly 17kbps (yes, kilo-bits per second) by my calculations. It's pretty slow. But, it's about as fast, or maybe approximately twice as fast, as the Kestrel-2. Also, again, SD card driver is written 100% in high-level Forth, so you get all the interpretation overhead to slow things down.

Also, I have to manually type

0blocks 0editor MOUNT THROW

I've uploaded two screenshots of the Kestrel-3 emulator running a port of eForth 1.01 from back in 1990. This release basically will fork eForth, so that all future versions are specific to the Kestrel.

The port still isn't 100% complete; I still need to add some basic utility words and a means of accessing mass storage (BLOCK, BUFFER, LOAD, FLUSH, UPDATE, and a port of my VIBE block editor so users can more conveniently write programs) before I declare it "good enough" to move on to hacking on Verilog. But, it's at least complete enough for basic command-line usage, and even supports compiling new colon definitions. (Observant readers may notice no VARIABLE support yet as of these screen shots. It's coming, along with CREATE, DOES>, USER, and a smattering of other words.)

It's an Indirect Threaded Code (ITC) Forth, so runtime overhead is pretty steep. Byte-sized screen updates are pretty slow (which, due to how the MGIA addresses memory, is most of the time). But, if you can arrange it, cell-sized (64-bit) hits to video memory is surprisingly fast, considering the ITC overhead.

It does not have a built-in assembler; my plan was to put such an assembler on block storage, and the programmer can LOAD it in as needed for a project. However, a future ROM image might include an assembler as well. I reserve the right to change my mind on this decision though. I certainly have more than enough ROM space to facilitate the assembler. ;-)