Kestrel Computer Project

I have many fond memories of hacking, both hardware and software, with my Commodore 64. After unboxing my Amiga 500, I remember feeling somewhat bummed that I couldn’t hack in the realm of hardware as much as I could with the Commodore 64. However, the software capabilities and the ease of use of its operating system made up for that. Between the C64 and the Amiga, I was deeply involved and invested in the Commodore market, oblivious to the innovations of other contemporary computers.

It turns out, however, many other competing markets offered platforms with equally impressive, if simply different, innovations. More mature and much wiser today, reviewing the retro-computing landscape offers a new palette of features, to me at least, from which I can use to help shape the Kestrel platform to become something new and unique unto itself. Indeed, when I first started the Kestrel project back in 2004, I often described the project to people by asking the question, “What if engineers from Commodore, Apple, Atari, Acorn, and others, all got together in a single room, knowing that this would be the last hurrah for their respective 8-bit platforms, and combined their expertise to come up with the ultimate home computer?”

The list below summarizes some of the most interesting ideas from each market or specific computer. Over time, as the Kestrel hardware and software evolves, you might see one or two of the ideas listed below shine through. Or, you might see something else all-together. This list cannot be considered exhaustive.

Atari 800

This machine would be a footnote in the history of computing were it not for one thing: its chipset implemented what we'd call the "Unix philosophy" right in hardware. The video display and its respective memory fetch were handled by two separate circuits in its chipset. Disk I/O used hardware not too different from ordinary RS-232 communications. Etc. The machine hardware demonstrated a great deal of modularity which game vendors did not ignore, leading to some truly impressive graphics for a machine introduced in the late 70s. Moreover, since Atari's offering came after the PET, its screen editor improved somewhat on Commodore's. The OS offered some unique features of its own as well, such as symbolic device IDs.

Atari ST

This machine is a text-book case study in using (mostly) commodity hardware to create a long-lived, fan-supported platform that successfully transitioned from a closed-source offering from Atari to an open-source, community-maintained architecture. With relatively modest hardware, you can imagine that the software took most of the burden for innovation here. Still, the interplay worked, and today, the ST community thrives in a way that the Amiga community does not.

Commodore 64

The C64 offered a single text, the Commodore 64 Programmers Reference Guide, which provided all levels of knowledge for using the C64. This included hardware details, including schematics, register definitions for the chipset, and so on up to the calling conventions of the KERNAL.

Commodore Amiga

The Amiga's hardware, having been engineered by the same people behind the Atari 800's hardware, exposed a similarly modular hardware architecture that made it at once somewhat confusing to work with, but also incredibly flexible. Graphically, it snowed the Atari ST because of its unique design and integration with the host OS. In terms of audio, while cutting edge in 1985, it was quickly surpassed by the ordinary IBM PC/AT with a simple Sound Blaster card. Still, that everything was driven via DMA channels (**25** to be exact!) allowed the Amiga to perform feats of multimedia magic that no other computer could pull off until the late 90s rolled around with 25MHz 80486 processors. The Amiga platform also had one of the best programmers reference manuals I've ever seen regardless of platform. Three volumes existed, one for hardware reference, one for symbol definitions, "autodocs" (Amiga's equivalent of printed man pages) and other reference material, and finally, one for a tutorial on how to invoke the system services. Speaking of the OS, it was the first I've used to successfully integrate a command-line and graphical environment in a more or less seamless way. ARexx could be used to script multiple applications not otherwise aware of each other (something you **still cannot do today** under either Windows or Linux without some kind of development environment installed).

Commodore PET

First home computer with a usable screen editor and a surprisingly sophisticated operating system. KERNAL offered a set of I/O interfaces not seen again until Plan 9 from Bell Labs, although the core abstraction differs; KERNAL treats everything as a GPIB device, while Plan 9 treats everything as a file(-system). Regretably, neither Commodore nor its community exploited this facility to its fullest potential, so has gone largely unnoticed.

CP/M

This receives mention for being the simplest possible resident, disk operating system that could possible work. The philosophy that makes CP/M work also went into making the Atari ST work (GEMDOS and TOS, together, comprise a port of CP/M-68K, in fact).

Jupiter ACE

Perhaps the simplest possible computer to still be called a computer with any kind of graphics or expansion capability, the ACE was also unique in being the only home computer to successfully pull off bundling Forth in a consumer-friendly package.

Tripos

This OS is surprisingly capable considering how simple it is architecturally. Offering preemptive multitasking in a single address space, it offers many usability benefits to the user, like the ability to have multiple virtual sessions in use at once with a small memory footprint. Tripos forms the user-facing DOS of the AmigaOS environment, thus influencing its shell syntax (for the better in my opinion).