[libre-riscv-dev] [OT] Moribundity

[Hendrik Boom]

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>
> wrote:
> 
> > 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
> comfortable.
> 
> 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.

-- hendrik

> 
> -- 
> Samuel A. Falvo II
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev