For those wondering what I've been up to in my ever-so-copious amounts of spare time, I've been hacking anew on the Kestrel-2 using my Nexys-2 FPGA board.  I didn't want to announce it until I was confident that I could "complete" (for some definition of complete) the build.  I'm now at that stage where I'm confident I can complete it in a reasonable time period.

Specifications

• KCP53000 CPU at 25MHz.  This provides an RV64I instruction set architecture for you to play with.  (WORKS)
• MGIA provides 640x200 bitmapped, monochrome graphics.  (WORKS)
• 32KiB of actual ROM.  This means more space available for OS and programs loaded from SD card.  (WORKS)
• 48KiB of block RAM.  Two bits of the GPIA's output register now lets you select which 16KiB page of memory to use as the MGIA frame buffer.  (NOTE: This, unfortunately, needs to drop to 24KB if I were to port the design to the Terasic DE-1 board that I have.  It's FPGA just doesn't have the block RAM resources that the Nexys-2 does.  Sorry.)  (WORKS)
• GPIA for, among other things, talking to the SD card, detecting VSYNC from the MGIA, and controlling the Nexys-2's 4-digit, 7-segment LEDs (though, if I can't afford it any more, this last feature is the first to go away).  (WORKS)
• Two PMODs reserved for SD card interfaces (versus Kestrel-2's one).  (Planned)
• KIA cores for using a PS/2 keyboard, and perhaps in a later release, the mouse.  Strongly considering getting another PS/2 port for the board, so I can have both keyboard and PS/2-compatible mouse.  (Planned)
• 16MB of "expansion RAM" allocated for experimentation with accessing external static, pseudo-synchronous, or synchronous RAM resources.  (Honestly, it's really however much memory space you need; the "CPU" module only exposes a 25-bit address by default, but with some editing of the Verilog files, it can be widened as far as you need.)

Purpose/Mission

Frankly, to explore how to talk to external RAM chips reliably, thus opening up the opportunity to realize my ideal Kestrel-3 concept again.  Nothing more than that; inasmuch, I figure 32KB of ROM and 48KB of RAM ought to be way, way more than enough for my needs.  Hence the DX part of the 2DX badge: it's a Developer Architecture.

Indeed, the Kestrel-2DX is the "test mule" I've always wanted, but was never able to get off the ground.  Except for some reason, I'm now able to get it off the ground, and I'm frankly quite ecstatic about it.  Maybe this is a sign of things to come wrt to the Kestrel-3.

Where is the Repository?

I'm maintaining development in a Fossil repository independent of my mainline Github account, on account of its still extremely experimental nature.  I didn't want to get any hopes up by announcing, "Oh, hey, look what I'm doing!", only to get distracted with life, and have it fall into disarray, disuse, and eventually be removed in one of my famous fits of fury.  Also, I find working with Fossil far easier and more productive than with Git + Github combination.

When I'm happy with the result, I'll merge everything back into the official Github repository as an official version of the Kestrel-2 lineage.

Why Fossil?

Considering that Fossil is a single binary, compiled using little more than a plain-vanilla dialect of C and some POSIX libraries, I'm seriously thinking of moving all of my Kestrel-related material into Fossil instead of Git.  My reasoning is as follows:

1. To get Git working, you need to port a C compiler, then Perl, Python, Bash, plus a litany of dependencies: for Perl, for Python, for Bash, and then you need the Git-specific dependencies.  It's probably easier to port Linux and its userspace as an entity than it would be to port Git to a foreign, brand-new platform like the Kestrel.  Meanwhile, the footprint to get Fossil ported to the Kestrel-3 remains daunting; but, it's substantially smaller than Git's: a C compiler, and a POSIX environment.  Thus, it should be markedly easier to get Fossil working on a future Kestrel than it would be to port Git.  This would directly enable continued Kestrel development on Kestrel platforms.  Eat your own dogfood, as they say.
2. I enjoy working with Fossil far more than I enjoy working with the Git + Github dichotomy.  No, installing Gitlab or Gitorious will not help; the dichotomy remains even with these self-hosted options.  Having the ticket system and wiki tightly integrated into the tool is wonderfully liberating to me.
3. Fossil has auto-sync features built-in.  With Git, I must constantly remember to push and pull, particularly between the forks that I maintain.

I could go on, but other reasons I like working in Fossil tend to be more contentious, as the bi-annual resurgence of Fossil-vs-Git articles demonstrates on Reddit and other sources.