In today's world of Wintel-dominated PCs, you own neither the hardware nor the software running on it. If you're concerned about this truth, would you perhaps be interested in helping an underdog try to change that?
I know I discussed the history of my Kestrel-2/EX project elsewhere, but I'd like to revisit that subject again from a different angle. If it can be said that you or I are one in a million, then as of this writing, there are approximately 8,000 people just like you or me on Earth. So, what is "the Kestrel," and why is it important to, I presume, us?
Let me ask you more directly some questions which I already know my own answers for. Are you fed up with implicitly accepting End-User License Agreements as a necessary precondition for using equipment or software you paid good money for? Tired of being an e-waste generator every three to five years? Are you old enough to remember when protocols were enabling instead of constraining?
If you answered yes to any one of these questions, you might want to read to the end of this article. I can't be completely sure; but, I think, you might be interested in what I have to say.
Contemporary retro-inspired computers frequently extend their basic architectures to support things like faster CPUs, higher resolutions, more colors, better sound, and so forth. This is great news for people who desire to continue using these architectures. This will open up possibilities never before accessible on those platforms. However, they retain one fundamental flaw: they emphasize games and entertainment over any other kind of title.
Look, let's be serious about this: nobody is going to be making a page layout or EDA product for the Spectrum Next.
Part of this is due to limited address space of the processor. While these platforms offer extended amounts of memory, accessing it often requires bank-switching mechanisms at the very least and DMA-mitigated block transfers at the very worst. If you're the kind of programmer who thought Intel-style segmentation was a pain, just you wait until you have to deal with the equivalent of a direct-mapped, paged memory management unit without protection bits and with granularities measured in 8KB to 32KB chunks! Oh, did I mention that you had to manage these settings yourself?
Another part of this is due to marketing/placement of the product. Few are going to consider a Spectrum Next or C64 Ultimate a suitable platform for seriously recording their monthly expenses or tracking inventory, especially when you can get a Chromebook for cheaper and just use Google Docs. At best, you might find MIDI synthesizer apps for these platforms, especially since machines like the C64 Ultimate have dual SIDs.
Finally, it takes courage to engage with developers to migrate software to your platform. Sometimes, that courage is directly measured in actual dollars. Making the computer itself is the simple part; convincing others to actually use it is the hard and expensive part. Who wouldn't look at the current PC market, and admit to themselves that it's near impossible to compete: not on price, nor on performance? And they'd be right.
Although the Kestrel takes a lot of inspiration from the retro-computing movement, it focuses on being a more viable target for new productivity applications. I'll explain how later in this article; first, I'd like to discuss more behind my motivations.
You know things are outright stagnant when one of the industry's most respected computer scientists and engineers admits publicly that Systems Software Research is Irrelevant. You wouldn't think this has any impact on day-to-day users, though; I mean, who cares if your OS is a microkernel or modular monolithic these days? And, yet, we see people complaining to this day about how their operating system has adverse and undesirable effects upon them.
I don't want my OS to be like windows (for example) but as a windows user for
(almost) my whole life I can't help but notice that I often do things the way
windows does it (or at least close to windows).
. . .
But in general an OS indie scene would be beneficial to the future of operating
systems I think. And I don't count (most of?) us to those indie developers.
ReactOS may be big enough but it's just a windows clone so there are no innovations.
-- https://forum.osdev.org/viewtopic.php?p=242987#p242987
The perceived stagnation in the market has motivated a few others to move on without the benefit of academic or commercial support. Besides my own project, consider this quote from @willflux@mastodon.social:
I've just realised it's one year since I first wrote about 🏝️ Isle.Computer. I
believe the case for simple, open hardware is as compelling as ever.
. . .
Isle is a simple, modern computer -— an open design that encourages tinkering,
experimentation, and doing your own thing.
. . .
Why call it Isle? Aren't islands isolated and cut off? To some extent, the
isolation is the point, a refuge from the complex, bloated, engagement-driven
technology that we live with every day. But islands are also a place of
experimentation and evolution. Look at Darwin's finches, the Komodo dragon,
and the coco de mer. I hope to inspire an archipelago of small computers, each
with its own personality and style, but with enough common ground to share
designs and ideas.
Some might look to free/open-source software and hardware design as an alternative vector for making an honest living at sustainable rates (both prices and timelines). This potentially promises freedom from large-scale, commercially motivated enshittification, while simultaneously solving real problems that people really have, and not the perceived or synthetic problems invented by marketing departments just for the sake of upgrade revenue. There seems to be an interest in "Shareware 2.0."
The reason we want normal people to pay for their Free Software is because we
want normal people to direct the priorities and direction of projects. Not
programmers, not business gurus and certainly not hedge funds and billionaire
monsters. Who pays chooses.
-- https://masto.hackers.town/@doctormo@floss.social/116696200590196603
Can libre hardware help with the current economics created by PC and memory manufacturers? I think it can! Despite the higher costs we can expect from open-hardware computing platforms (remember: lower manufacturing volume), we have the flexibility of recycling hardware that commercial vendors don't have which might in some cases make up for that price difference. Let's face it -- there really isn't any shortage of RAM, especially if you're willing to go back to previous PC architectures and raid them for their RAM sticks. But this will require memory controllers that are compatible with them, along with a universal interconnect to put everything together. Of course, the smaller memory compliments of earlier PCs also implies limitations on both software size, and actual working set size. Wasteful coding techniques not accepted here.
Speaking of interconnects, people are getting right upset over a number of recent anti-features of current ports. Interconnects need to be able to seamlessly support heterogenous blends of technology. Remember when USB Foundation came into existence, and they had competition from the likes of FireWire, External SATA, etc.? The USB port eventually won because they were able to deliver on one of their biggest promises: one port and one cable to replace all others. Then as FireWire died off, but the need for high throughputs remained, USB filled the void with USB type-B connectors and USB-2.0 spec. Then, along came "charger-only" cables. Now we have USB-C connectors as a return to a universal port design; but, we still have at least 2 to 3 different kinds of cables, and they're not compatible with each other. Charging-only, data-capable, Thunderbolt-capable, etc. And let's not forget the most user-hostile feature of them all: USB-PD DRM.
I get it; it's not intended to be a form of digital rights management. It's actually intended to prevent counterfeit hardware from powering official hardware. After all, you just can't trust 20V to be 20V when the buck converter is made in China, amirite? It's time to bring back basic, dumb, and universal charging cables.
Last but not least, there are social and political reasons to consider supporting libre hardware PC designs, even if they aren't Intel/AMD compatible. How many times have you seen Microsoft basically purchase projects only to shelve it, delay it, or severely distort it later on? (Example: Bars-and-Pipes.) How many times has Intel felt threatened by an open standard only to replace the whole thing with a closed/tightly-controlled standard of their own? Here's look at you, UEFI. Long live OpenFirmware.
Maybe, just maybe, we should take a page out of their own playbook and apply it to our own community. Consider the following views I discovered on my fediverse feed:
We've come to the limits of the FOSS and libre software movements. The political
and ethical limits of these movements have become clear, and they no longer
serve the needs of the workers,
. . .
It is clear to me now that open knowledge sharing under capitalism, under
oppression, is naive. Indigenous groups know this and have known this for a
long, long time. I hope, with recent events, the rest of us are now ready to
learn this lesson as well.
-- https://lyk.so/collective.html
and
Imagine there was a software collective. A group of people that collaborated
on different projects, helped each other, and built a better future together.
What would you do? What would you work on? What would you contribute?"
Whether you agree with these views or not, you cannot deny that there is a growing movement of people becoming antsy over the current socioeconomic situation surrounding the modern PC ecosystem. More and more people want real solutions.
It is high time we bring back the pioneering spirit that brought us advanced visions like the Amiga or like the Archimedes, all while restoring the ethos of openness that the early home computing market provided. So, let's think big, while acknowledging what we can and cannot do as individual open hardware/software contributors. What follows is my vision, informed with what I know I can do with the tools and knowledge I have.
Bluntly, I'd like a machine that doesn't rely on existing PC supply chains whatsoever, while still being useful enough to let me produce more libre hardware and software projects, to let musicians produce music, and video content creators create and edit their videos. In other words, let's pick up where the Amiga 4000T left off. What could such a machine look like?
Before discussing the conceptual design of such a machine, I want to point out this quote from https://permacomputing.net:
Most importantly, there is no permacomputing kit to buy. See permacomputing as
invitation to collectively and radically rethink computational culture. It is
not a tech solution searching for a problem. You are free to start your own
initiative and use the term permacomputing, however please make sure you
understand the purpose and ethos of this project :)
What I am proposing below is intended to become a kit at some point in the future. So, am I suffering from some fundamental misunderstanding of permacomputing? Maybe; I'll completely own up to that. However, I like to take this quote in my defense:
Permacomputing is also a utopian ideal that needs a lot of rethinking,
rebuilding and technical design work to put in practice.
Emphasis on rethinking and rebuilding, here. Modern PC architectures are the way they are in large part because of how software for the PC is built. I firmly believe, unequivocally, that the entire stack, from application to underlying OS to the hardware it all runs upon, needs a hard restart.
This is why I offer the Kestrel platform as a foundation upon which one could build another personal computing future.
So, without further ado, let's day-dream up the power-user's Kestrel.
Let's work backward by imagining the most powerful machine in a family of computers. I figure this would be power-user's machine, something comparable to a low-end, portable workstation from System76. For grins, let's denote this architecture as a Kestrel-4.
This particular Kestrel-4 sits on the desktop, in a small pizza-box case. On the front, six front-facing slots: 2 for CPU+RAM modules, 1 shared memory module, a keyboard/mouse board, and 2 more for storage devices. Let's also give it 4 rear-facing slots: figure two for networking, and the rest for video cards. You have four monitors, after all. Remember: power user.
On top of the main unit, there is a port that lets you fit an I/O expander on top. Physically, it closely resembles the main unit. You get ten more slots out the back and the front in a similar configuration. Suppose you're a musician; you populate all slots with ADC/DAC units and maybe another CPU+RAM card.
You turn the machine on, and it boots into a menu not entirely unlike a Texas Instruments TI-99/4A computer. You select your OS of choice, then launch your digital audio workstation, and by day's end, you've produced yet another album. You shut the OS down, thus returning to the boot menu. Then, you power the whole machine off.
How would this machine work internally?
Let's look at our I/O requirements first. As a musician interested in production in your own studio, you're probably not going to settle for any audio stream less than 96kHz at 32 bits per sample per channel. Thus, our architecture will need to move 96000 x 4 bytes = 384000 bytes/second per channel. If we further assume that our ADC/DAC cards are single-channel (just to make math easy), we observe that we need 9 cards. Thus, we need at least 384000 x 9 channels = 3.456 MB/s throughput to drive all 9 cards at once.
But wait!! A proper DAW often processes input to produce output in real-time; thus we really need to double that throughput to fully support both ADC and DAC at its heaviest load. So, we need an I/O infrastructure that can handle 6.912 MB/s.
If we use software effects on each channel, we'll need to double that bandwidth again. (To support each of these streams per channel: ADC -> RAM, RAM -> software, software -> RAM, RAM -> DAC.) OK, so now we're looking at 13.9 MB/s. So that about covers the worst case I/O demands for the DAW; but, we're still not done. This just covers the minimum needed for the audio I/O. We now need to consider the software itself. Unfortunately, I have no back-of-the-envelop heuristic for this calculation. It will depend on how many channels are in use, what effects you're running, and so forth. So, I'm just going to hand-wave it away and say, conservatively, we need 10x more bandwidth. I figure this gives the CPU 10 clock cycles for every byte read, processed, and output. This is almost certainly unrealistic; but let's go with it because it makes the math easier. Professional musicians-who-code-their-own-plugins, if you have a better heuristic than I do, I'd love to hear from you.
So far, we need to have an interconnect that can move 139 MB/s to keep up with the needs of a maximally loaded set of 9 input and output channels, running real-time effects processing in software for each channel in real-time. This sounds like a lot, but modern PCs can easily meet this throughput requirement. Consider, even the original PCI bus moved data at 132 MB/s, so modern systems like PCIe are more than up to this task.
So why don't we use PCIe? Several reasons:
PCIe is a genius evolution of parallel PCI; however, it is rather costly. Can we do better while still meeting performance requirements?
I think we can, or at least we can come really close; and, that capability is brought to you by another open standard (in the RISC-V ISA sense of open standard), RapidIO. Our complete system architecture would look something like this:
CPU+ ADC/ ADC/ ADC/ ADC/ ADC/ ADC/ ADC/ ADC/ ADC/
RAM DAC DAC DAC DAC DAC DAC DAC DAC DAC
| | | | | | | | | |
| | | | | | | | | |
+---------------------------------------------------------------------------+
| Switch |
+---------------------------------------------------------------------------+
|
| (top-side expansion port)
|
+---------------------------------------------------------------------------+
| Switch |
+---------------------------------------------------------------------------+
| | | | | | | | | |
| | | | | | | | | |
CPU+ RAM Kbd/ CPU+ Disk Disk Net Net Video Video
RAM Mouse RAM Card Card
The primary reason why I am interested in re-using RapidIO for this application can be summarized thusly:
Although RapidIO does have a standard for 16-bit ports, they're double-data rate, impedance matched, and run at breakneck speeds, making their use rather expensive. We can do better for our application: our interconnect fabric can consist of 16-bit, single-ended, full-swing parallel ports driven at a more reasonable clock frequency. Let's round up our bandwidth requirement again to 160 MB/s. It seems reasonable, then, that we can run each of our RapidIO ports at 50MHz DDR, and not run into significant contention issues, as it gives us 200 MB/s peak throughput.
What about our video displays? The calculations are similar. Let's assume the worst possible case, and say we want to display a 1920x1080 true-color image per monitor. Each video card would need to have its own local memory for this to be practical. So, the fabric itself invests no bandwidth overhead as long as the images are static. But if you want to update the entire display (which is not atypical for IMGUI-based projects), you'll want to push (1920 x 1080) pixels/frame x 4 bytes/pixel x 30 frames/second (minimum) = 248.8 MB/s per monitor.
Ideally, we'll want an even faster fabric. There's no question here. But I still think we can handle things at 200 MB/s, as long as you're willing to handle a slightly reduced frame rate. Remember that second CPU card in the expansion box? It is local to the ADC/DAC cards there. Like PCIe and HyperTransport, RapidIO is switched; traffic between the channel cards and their local processor need not interfere with the fabric located in the main unit. In fact, the two fabrics can function 100% independently of each other. That's the whole point of peer-to-peer operation.
This effectively doubles our aggregate bandwidth, even if an individual port isn't capable of more than 200 MB/s. This lets one CPU manage the audio while the other manages the video updates completely asynchronously of each other. Some coordination will be required (e.g., to update the waveform timelines as playback proceeds, etc.), but this can be done with simple message passing between the two CPUs. This can occur over the link between the main unit and the I/O expander, again, completely independently of other traffic on other ports. You'll need OS-level support to distribute code to these processing nodes. Thankfully, OSes like Plan 9 support exactly this feature out of the box. It is literally what Plan 9 was built for.
So while this system isn't completely up to our desired specs relatively to commercial PCs of today, something like this can be built with reasonable cost, using off-the-shelf parts today. Think about that -- with FPGAs, we can build a home-made, high-end DAW and never once have to rely on Intel, PCI SIG, et. al.
It's not cheap (compared to a COTS PC), but then, low-volume equipment never is. But if you're the kind of customer who supports freedom and maximum hardware repairability and long-term reusability, this might be the kind of machine for you. OK, so how do we get from nothing at all, to this?
What we've just outlined can best be described as a top-of-the-line, power-user's Kestrel. It is ambitious, and a lot of the design speculation I discussed previously has a lot of hidden assumptions. How do we validate our assumptions while spending as little as possible? We start small, of course, and build our way up. It's the same method today's PCs and Macs took. Your 200fps, 6-monitor gaming PC with DVD-quality audio has its roots in a PC design that was once so slow you could actually see it refresh text in real-time, and whose sole audio output consisted only of beeps and boops. People often forget the numerous missing links that existed between these two extremes.
So, what is the simplest configuration we can do today? That's what the Kestrel-2/EX aims to be. Imagine a Macintosh Classic, or an Atari ST, or even an Amiga 1000. A single processor, some reasonable amount of RAM, some basic mass storage, and an interconnect fabric built atop of RapidIO. Only, it won't be so rapid; remember, the whole point of such a machine is to be cheap! I like to call this adaptation of RapidIO to smaller, slower interconnects "SimpleIO."
.--------.
CPU+ ____| |____ Emulated RAM/
RAM | | ROM
| |
| |____ Mass Storage #1
Back- ____| Switch |
plane | |____ Mass Storage #2
| |
Video ____| |____ Keyboard/
| | Mouse
`--------'
The logical layout of the Kestrel-2/EX.
In terms of performance, we're looking for something that can update an 800x600 2bpp display at 30fps or faster. That's a little under 4 MB/s raw throughput into the video frame buffer. That is easily achievable using something on par with QSPI at 4MHz or 8MHz clock.
The host "CPU+RAM card" can be emulated via almost any modern microcontroller. The display controller can also be emulated using a contemporary microcontroller. The RapidIO fabric would be entirely driven in software; as you might imagine, the RapidIO switch itself these modules plug into can itself be emulated by a microcontroller. The keyboard and mouse interface can also be emulated as a RapidIO device. And so on -- you get the idea here -- a literal network of small but capable microcontrollers cooperating to give the illusion of a larger, more complete computer. Something that can at least equal or best a Macintosh Classic from 1984.
Like I said -- start small. Very small. Build up from there, step by step.
Will there be intervening "models" of Kestrels? Oh, I'm sure there will be! As I learn how to build things with newer technologies, and with using newer tools, you can bet that there will be newer, faster, higher-performance models.
But, won't this introduce more e-junk? Potentially; however, I think RapidIO comes to the rescue again. Remember that RapidIO is a switched fabric -- it is literally a special-purpose network protocol. Since it's defined in logical terms, similar to how IP is defined, it can be adapted to just about everything from a fiber optic link to something as slow as a string and tin can. If you have older, slower equipment, it is possible to build a "bridge" module that couples slow-speed devices to a higher-speed port (and vice versa). Thus, it should be possible to reuse your existing, slower hardware with all newer versions of the Kestrel as long as you have the right adapter(s). It might cost some latency for protocol adaptation, but it should function.
In fact, that's how I intend on evolving the platform: given a proven foundation, interface it with the newer, faster fabric. It should run at least as fast as the earlier hardware and without error.
Where possible, parts should be socketed to facilitate recycling.
My vision for the Kestrel/2-EX currently exists as a software emulator that runs under Linux. I'm still making small changes to it as I develop the Kestrel's first set of system software (a Forth environment).
Once I feel the system software is working well with a set of virtual peripherals, including mass storage which is yet to be defined, then I will move over to a microcontroller emulation of the system above. This should validate whether or not RapidIO/SimpleIO works for our needs.
At present, I am documenting my work with the software emulator on my YouTube channel.
Thank you for reading this far! It is really appreciated. But, now I just have to ask: Does any of this resonate with you?
If you're at all interested in making this vision of libre personal computing a reality, please consider signing up at my Ko-fi page and donating monthly. In a perfect world, I would make this my 9-5 job, selling kits and offering developer support where needed. Indeed, if only 200 people donated $90/month, that would let me work full time on this project. (I can dream!!) Point is, as long as I have to work for someone else, progress will be that much slower. Your contributions definitely help!
If you prefer updates via video, consider subscribing and watching my videos on YouTube.