In this day and age, "Building Your Own Computer" means heading down to your local CompUSA store, selecting a bunch of macroscopic components like motherboards and video cards and the like, plugging them all together, and voila -- a home-made computer. While this is certainly quite valid, it's nowhere near as fun as actually constructing by hand those individual macroscopic components.
Another thing about computers today is that they've all gotten so unbelievably complex from a programming perspective that they're no longer fun anymore. Literally, your choice of base software for the "home-made" PC is either Windows, Linux, or BSD. Writing your own software involves learning someone else's libraries, and those libraries are 99% of the time inappropriate for the task you're trying to do. As a result, what should take an unbelievably short amount of code now takes pages and pages and pages of boiler-plate, just to satisfy the API requirements of some over-generalized library interface. Don't get me wrong -- this is all quite required for mission-critical and business systems. But when I come home after a long day of work, the last thing I want to be is some kind of system administrator or project manager.
The Kestrel is a:
It isn't based on the x86-architecture because x86 is too complex, both from a software point of view and from a hardware perspective. Therefore, do not expect to be able to run Windows, BSD, or Linux on it. It won't. At least, not without a software emulator. Future generations of the Kestrel might be able to run Minix, however.
The Kestrel is based instead on the 65816 microprocessor. In particular, I'm using the 40-pin plastic DIP version, which is nice and easy to build stuff yourself with. Sockets are cheap and plentiful. (Future generations of the Kestrel may be based on PLCC-variants of the 65816, such as the 65C265, or even the Terbium 32-bit processor, when it condenses from the vaporware phase.)
The Kestrel is not a fast computer by today's standards. The current clock-speed limitation is at 4MHz, determined by the latencies of the address decoding logic, in conjunction with the RAM access speeds. However, you'll be amazed at just what you can do with 4MHz with careful coding techniques. Indeed, after watching a number of demos for the VIC-20 and Atari 800, both of which run at less than 2MHz each, 4MHz is positively fast enough for nearly anything you can do with your normal PC, productivity-wise. It is demonstrable that nearly all productivity software spends the overwhelming majority of its time waiting for the user, rather than doing actual number crunching. Indeed, the Amiga demonstrated just how powerful preemptive multitasking was at 7.15909 MHz -- it took a 16MHz 80486 running PC/GEOS before PCs could even compete with the Amiga's multitasking performance.
There are several generations of the Kestrel. There is the entry-level Kestrel-1, which was originally a single-board computer housing only 32K RAM, CPU, and some I/O. It had the same circuit complexity of the Atari 2600, sans TIA and ROM chips. I've proven it to work, but it wasn't reliable in communicating back to the PC due to reasons that still baffle me (my ATmega16s can talk back to the PC without problems!).
For this reason, I abandoned the project and am now working on the Kestrel-2. The Kestrel-2 exploits the processor's full addressing capability, is intended to use a USB peripheral interface to the host PC for its primary console, and I'm striving to add about 3 to 4 expansion slots to it. It will also have some kind of ROM on board, so that a host PC isn't required to boot the system. Forth will be its operating system.
The Kestrel-2 also was to have a 640x480 video interface of some kind as well. However, everything I've looked at seems awfully expensive. As a mental exercise, I tried finding the absolute cheapest solution to generate reasonable video on a VGA display. Resolution wasn't a criteria anymore. The solution came to me as I was running the numbers on what an ATmega32 could reasonably be expected to put out. Therefore, I'm currently working on a system employing a handful of ATmega32 chips to display 160x100 resolution bitmapped graphics on a VGA monitor, with a 256 color palette. One ATmega32 is responsible for generating 160x100 monochrome video, while the second ATmega32 is responsible for keeping up with the first in pushing color bytes out its I/O ports. Realizing the bus interface for this is ideal for use with the 6522 VIA chip used in the original Kestrel-1, I'm seriously also considering resurrecting the Kestrel-1 design to drive it (only significantly modernized and with provision for a real ROM chip to house its OS) as a cheaper, more entry-level kit to use it with. The Kestrel-2's ambitious goals may put the cost to a homebrewer outside of his or her budget. After all, this is just a hobby!
Although the video chip has enough internal memory for only a 160x100 display (a true 2KB, not 2KiB), I'm adding provisions to the chip so that you can "stripe" the chip either with itself (a la Atari 2600 style, using raster compare interrupts) or with other slave chips to achieve a perceived higher resolution. The former depends on the CPU to stuff video memory fast enough to achieve the desired effect, while the latter literally gangs multiple chips together to produce a real, honest-to-goodness higher vertical resolution (and twice or more the video RAM as a result too). Indeed, the above-described color-generator ATmega32 is an example of just such a slave chip. This should give the Kestrel-1 about the same amount of overall graphical power as a hybrid between an Atari 800 and a VIC-20, if I'm correct. I've never written a demo before, but if I get this working, I'll do my best to show it off on the Kestrel-1!
Some day, when I can afford an FPGA development environment (especially one that will work under Linux), I will be able to realize the Kestrel-2's video output goals. Until then, it'll just have to wait, or, make do with the Kestrel-1's video system.
Once I implement the ATmega32-based video system described above, I'm also planning on a sound synthesis chip (also to be implemented in some kind of ATmega device). I'm going to try to strive for the same overall capabilities as the 6581 SID chip. However, I cannot guarantee this -- the SID did a lot work for the CPU, and moreover, many have reported to me that simulated SIDs just don't sound like the real chip. I personally cannot tell the difference, not having a real Commodore 64 or 128 next to me to test with. However, running the numbers for a 48000 sample per second system with external, 8-bit, R-2R DACs, and a 12.8MHz clock (same as the video chips), the microcontroller can spend 226.5 clocks between audio samples. That's a lot of clocks for doing things like wave table lookups -- I predict that I can pack quite a few voices in the chip! As with the video chips, I may choose to use two -- one for left channel and one for right. I'm hoping for 4 voices per chip -- about 56 clock cycles per voice.
Here's to keeping the homebrewing hobby alive -- here's to the Neo-retro Revolution -- Here's to the Kestrel!