[libre-riscv-dev] KCP53010 in danger

[Samuel Falvo II]

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.

-- 
Samuel A. Falvo II