Many successful large-scale projects don’t start out large: they start with a small working core and grow out from there. Building a completely open-source personal computer is not a weekend project. This is as much a retelling of events as it is background information leading up to a request for help. You’ll discover that quite a lot of hard work has already been put forth towards the creation of a completely open personal computer.
When I noticed the Kestrel Computer Project had been submitted via the Hackaday tips line I quickly tracked down and contacted [Samuel] and asked a swarm of questions with the excitement of a giddy schoolgirl. Throughout our email conversation I discovered that [Samuel] had largely kept the project under the radar because he enjoyed working on it in his down time as a hobby. Now that the project is approaching the need for hardware design, I posed a question to [Samuel]: “Do you want me to write a short article summarizing years of your work on Kestrel Project?” But before he could reply to that question I followed it up with another: “Better yet [Samuel], how about we tell a more thorough history of the Kestrel Project and ask the Hackaday community for some help bringing the project home!?”
[Samuel] was just as excited to tell the story of his project as I was to learn about it. This article is just as much his as it is mine, in fact if I knew how to add him to the by-line I would do it.
In 2007 software engineer [Samuel A. Falvo II] founded the Kestrel Computer Project. His very own open source, open hardware, full-stack personal computer project. He has been working on it in his spare time while documenting his lessons learned and accomplishments alike. Although as we’ll soon discover, GitHub wasn’t used from the very beginning of the Kestrel project, [Samuel] supplemented its absence with hand drawn schematics to fill in the history.
It all started with the Kestrel-1, back in 2007. The Kestrel-1 home-brew computer started like many at the time: a handful of chips seated in a typical breadboard with lots of wires going everywhere. It was intended to serve as a proof of concept for a more ambitious goal, a single-board computer with similar capabilities to the old 8-bit computers he grew up with. The original Kestrel-1 was designed around the 65816 CPU which is a 16-bit upgrade to the 6502. [Samuel] dialed-in the 40 pin DIP CPU to run at 4MHz and wired up 32KB of RAM along with a single VIA chip.
Those of you keeping up by capturing a mental schematic will notice the lack of ROM. It’s no accident you find it missing, (E)PROM programmers weren’t the cheapest item on the bench and because [Samuel] couldn’t afford one, he made due with what was available. He decided to place RAM in high memory, and I/O in low memory which greatly simplified address decoding by using a single 74ACT00. The system software would then have to be loaded into the Kestrel-1 through a special DMA circuit known as the Initial Program Load (IPL) circuit that was driven by a host PC.
This was prior to [Samuel] adopting the use of GitHub resulting in many of the technical drawings being forever gone, luckily [Samuel] was able to recall this schematic from memory and redraw it for the archives.
Unfortunately, the IPL circuit schematic has been forgotten. The IPL circuitry was controlled via a PC parallel port, with bits to control RDY, RESET, and BE (bus enable) signals. An SPI-like protocol allowed the host PC to stream in settings for address and data bus bits.
By 2011, FPGA development boards became more affordable and [Samuel] decided to implement the Digilent Nexys-2 board. This is when he realized the end goal of his original vision.
As development advanced he chose the Wishbone bus architecture as the standard interconnect, and began writing the Verilog for what would eventually become the video core: the Monochrome Graphics Interface Adapter (MGIA) in proper 65xx series ‘interface adapter’ form.
To confirm that the Wishbone interconnect worked [Samuel] developed a simple 16-bit processor just powerful enough to get the job done. At just 300 lines of Verilog, it was brutally basic HDL that he derived from an older design called the Steamer-16. [Samuel]’s S16X4 processor and later enhancements continued to be the core of the Kestrel-2 four years later. Despite the constrained instruction set, it proved remarkably agile especially when pit against the 65816. If you’re interested, [Samuel] wrote a datasheet that you can view in PDF form.
Over time, he built a Keyboard Interface Adapter (KIA) and General Purpose Interface Adapter (GPIA) for handling miscellaneous IO, then a bit-banged SD card interface built on top of the GPIA, and eventually system software and compilers evolved to run on the S16X4 family.
It was at this point that some crowd-pleasing talks started taking place where [Samuel] gave presentations on the Kestrel project using the Kestrel itself.
Unfortunately, due to the extremely reduced instruction set, the S16X4 has rather poor instruction density for a processor that can only address 64 KB of RAM. The system and application software had grown to such a size that, even considering overlays, it could not run application software more complicated than an interactive hello-world application or his simple slide show presenter. Access to more memory was needed, and that meant a more capable CPU with a wider data path.
After some research, [Samuel] determined that RISC-V offered comparable code density to the S16X4, while offering a 64-bit data path and processing capabilities. Combined with the instruction set’s liberal licensing, he knew it would be a winner.
Unlike the Kestrel-2, where the hardware was developed before any of its supporting software, the Kestrel-3 was to be emulated in software first. The idea is that it would greatly simplify debugging of system software, making hardware development easier later on.
The Kestrel-3’s development test-mule design is basically a repurposed Kestrel-2, but with a 64-bit RISC-V core for the processor, and equipped with at least 512 KB of static, asynchronous memory the goal here is a debuggable system.
As a believer in Kent Beck’s truism, “Make it work, then make it right, then make it fast”, [Samuel] is building the initial Kestrel-3 design deliberately around constraints typically found in off-the-shelf FPGA development boards. For example, many inexpensive boards offer only a 16-bit data path to relatively slow asynchronous RAM. Based on the selection of 70ns access RAMs combined with the bottleneck that a single opcode requires two hits to memory, he expects the processor to execute code no faster than 6 MIPS. This should be satisfactory for proofs of concept and initial development tasks, though, when you consider a Commodore-Amiga 500 or early-model Atari ST typically executed code closer to 2 MIPS, thanks to each memory cycle consisting of four clock cycles.
So, he wrote an emulator for the RISC-V instruction set, covering only the basics and modeling the Nexys-2 memory capacity of 70ns 16MiB of memory. Using this as a development platform, [Samuel]’s current goal is to get the power of a slightly accelerated Commodore 64 or 128. Keeping the processor design simple helps to achieve this basic goal. Simple, in this case, means no multiply or divide instructions, no floating point, no vectors, and no paging memory management unit (which are all intended future upgrades). The processor also only provides support for a single privilege level, machine-mode. In a very real sense, the processor is deliberately intended, or even crippled you might say, to more or less model a 64-bit 6502.
Once the development is further along the improvements will allow more sophisticated operating systems to run on the computer, such as Harvey OS, FreeBSD, or Linux. Of course, this also implies adding user- and supervisor-modes to the privilege stack as well.
Currently, [Samuel] is trying to port Oberon System 2013 to the Kestrel-3 in hopes of having a more or less stable, yet capable, system software base on which to build from. The Digilent Nexys-2 is no longer in production, so anyone wanting to play with actual hardware will need to adjust the design to their local FPGA development board of choice. [Samuel] has not yet chosen a replacement for his Nexys-2, although Terrasic’s Altera DE-1 has been strongly recommended.
Longer term, [Samuel] has entertained the notion of building a completely custom motherboard as well, most likely using the GNU gEDA toolchain, and employing Lattice iCE40K-series FPGAs almost exclusively, so as to exploit the recent developments in open source development tools for that platform.
As it stands now, Kestrel-3 remains a soundless, black and white computer thanks to its dependency on the MGIA core. However, plans for supporting sound and color, even higher resolution, graphics exist.
In terms of general purpose expansion, [Samuel] has some aspirations of using RapidIO technology on top of single or bonded SPI links in a form suitable and compatible with most Free and Open Source Software (FOSS) hackers budgets. It will not be named RapidIO, obviously, as that’d constitute a trademark violation. However, it’ll be an open evolution of the current set of open RapidIO protocol specifications.
Finally, there is “Ken’s Challenge.” A former coworker, suitably impressed with the state of the Kestrel-2, challenged [Samuel] to use the Kestrel-3 at work, for work, at the office for five whole business days. Using VNC over a TCP/IP/Ethernet link to let the Kestrel-3 serve as a glorified, graphical, dumb terminal definitely counts to meet the challenge, so that’s the route [Samuel] wants to take. There’s no financial incentive here; the reward being some impressive bragging rights. Obviously, to meet this challenge, the CGIA core will need to replace MGIA, and support for a mouse and a moderately performant Ethernet link will need to be added. Tunneling through SSH is a definite bonus.
If you would like to join in on the action and give [Samuel] a hand with the hardware or software you can pop over to his hackaday.io Kestrel Computer Project and check things out.
Right now, an emulator for the Kestrel-3 exists in a very basic form, and the very beginnings of an Oberon compiler has been ported, just powerful enough to produce ROM images for bootstrapping with. However, much more work is needed to complete the Oberon environment. In particular, [Samuel] still needs to work on implementing disk-resident object files, and a suitable linker to bind them into a bootstrap image. Once this is done, then the fun work begins: porting the InnerCore and OuterCore components of Oberon System 2013.
The CGIA design has not been fleshed out yet, but once a reliable-enough monochrome computer exists, this will be one of the next tasks to tackle (especially in consideration of “Ken’s Challenge”). Although 640×480 is decent for simple tasks, but particularly with systems even as simple as Oberon System, you really want a 1024×768 display with some color capability.
[Samuel]’s inexperience with audio is going to limit the appeal of the Kestrel-3 to the open source digital audio workstation field. However, if anyone wishes to help in this area, he’s open to contributions.
Support for RapidIO-like expansion capabilities won’t make too much sense with off-the-shelf FPGA boards; however, it would be nice to have for custom motherboards. We tend to see quite a few FPGA projects here at Hackaday and there has been an increasing community interest in the Lattice devices, as [Samuel]’s interest attests.