[libre-riscv-dev] [OT] Moribundity
hendrik at topoi.pooq.com
Thu Aug 1 20:51:39 BST 2019
On Thu, Aug 01, 2019 at 11:58:56AM -0700, Samuel Falvo II wrote:
> On Thu, Aug 1, 2019 at 10:23 AM Luke Kenneth Casson Leighton <lkcl at lkcl.net>
> > it's *known* for both being utterly simple and small yet
> > extraordinarily complex at the same time, so don't beat yourself up
> > about it, ok?
> Thank you. I try not to! But, sometimes, the depression just becomes too
> much to handle.
> What follows is not intended to be taken as a pity-party, nor is it written
> while I was depressed. I'm just trying to be as honest and as objective
> about my projects as I can be.
> I do get impatient with myself for not having made any progress, though,
> even when not in a state of depression. I have a number people who follow
> my progress on both Hackaday as well as on Mastodon, and I increasingly see
> them exploring other options which increasingly obsoletes my project (as if
> it weren't already obsolete in terms of feature set, now their prices are
> starting to come down to my ideal price point too). Popular projects like
> the PineBook64 have lead me to question whether I can make anything
> resembling a lasting contribution in the very niche I find myself most
> Please don't take this the wrong way; but, I've been asked before, "Sam,
> why don't you just use EOMA68?" Product-wise, it's brilliant. I love the
> very concept behind it, and would love to see it spread. From a technical
> point of view, though, *at the time I was asked, *I felt it was
> self-limiting for my needs at the time. The 68-pin and immutable interface
> (since it's a ratified specification with actual hardware in production)
> lead me to feel constrained in what I can do with an EOMA68 computer. For
> example, one goal that I had was to help a musician friend of mine build
> out a completely open source digital audio workstation to replace his
> ProTools commercial workstation. That will require 32 channels of 192kbps
> stereo audio (so, about 3MB/s throughput from the ADCs to memory, plus
> another 3MB/s from memory back out to the DACs), plus I figured another
> 30MB/s for video to drive the (S)VGA monitor. This is a specialized
> requirement, but I feel my open source computer should be able to handle
> it, if suitably expanded by motivated individuals. If NuBus (1970s) and
> MCA (1980s) can handle 40MB/s throughputs, I should easily be able to match
> that performance with today's technology.
> I could build a specialized version of the Kestrel and somehow package it
> into a PCMCIA slot, thus using some of the GPIO pins as a high throughput
> SPI interface to/from the DACs/ADCs. But, this seems to defeat my
> understanding of the EOMA68's value proposition, which is that a single
> card can be used in a variety of enclosures, and as well, that a single
> enclosure can be used with a variety of cards.
> This also helps explain how I arrived at the idea of the Backbone backplane
> bus idea -- basically, exposing Wishbone to the outside world and capable
> of handling 50MB/s traffic at a minimum specifically to handle the
> aforementioned usecase (plus some slop to handle video framebuffer access
> and bus arbitration overhead). I felt that EOMA68's form factor and lack
> of bus access impeded both casual and more specialized/motivated hacking,
> respectively, and so I dismissed it as a viable solution for the Kestrel.
> There remains also the matter of being able to expand RAM as my friend's
> needs demanded.
> Today, as I type this, I see the EOMA68 spec has evolved and reads to be
> much more flexible; it looks like the LCD signals are at least up for grabs
> by alternative, high throughput bus interconnects given a compatible base
> system and compatible chassis. So, maybe EOMA68 is the right way to go
> these days, and Kestrel will just never be relevant. It's really
> frustrating and depressing to see a project you've worked so long on and
> hard for just evaporate into uselessness right under your eyes. It's quite
> hard for me to come to grips with that reality.
I understand and sympathise. Decades ago I almost wrote and Algol 68
compiler. That was in the eary 1970's. I say almost, because the
whole thing is still somewhere on my file system, almost working.
Funding ran out before I quite finished the code generator, and the
machines and OS's I've had available since have all been incompatible.
Recently A new implementation of Algol W became available. I had
written my compiler *in* Algol W, so it briefly breathed new life into
the project. However, the sad truth is that in the 2010's no one is
interested in Algol 68. So I gradually gave up on it.
I think I have come to grips with the reality, but I still shows up
from time to time in my dreams, and then I wake up and can't get to
sleep again, pondering how I *should* have tackled the project.
> Samuel A. Falvo II
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
More information about the libre-riscv-dev