[Nosc] toy workstation (composite reply)

[Myron Plichota <myron.plichota@xxxxxxxxxxxx>]

I will post no further on this (off?) topic here. If anyone is interested in 
continuing this thread I request that we move it over to the largely inactive 
NOSC list at:

  Nosc@xxxxxxxxxxxxxxxxxx

Jeff's website has the subscription link and directions at:

  http://www.ultratechnology.com/maillist.htm

My interest in a big toy workstation is because I want to develop an 
integrated MIDI software synthesizer+audio multitrack recording studio. Too 
tiny a system just won't do because of the sheer size of the digital audio 
streams, not because I anticipate bloated code. These would ideally be held 
in RAM, not franticly streaming in and out of the hard drive(s). My integer 
DSP experience leaves me no doubt that even 32-bits is marginal for getting 
_true_ CD-quality end results after any significant processing. This 
technical concern warrants consideration of investing the extra transistors 
in a double-precision lookahead carry adder and shifter. This is getting to 
be a pretty big toy, but the toyness could be preserved by sticking to an 
essential minimalism.

Other people have different visions of sugarplums dancing in their heads.

> First, I say we design a small wearable computer that uses a one-handed
> variant of Dvorak key layout. Each machine should have intercomputer and
> interdevice connectivity using something to USB and a small VHF or UHF
> "packet radio" to facilitate radio networking.

An example above.

> When I first saw the uClinux project ( http://www.uclinux.org/ ) I started

Very cool. The M68K family is known to be an excellent CISC target for a 
virtual Forth machine, and probably even better as a Machine/ColorForth 
target than the Pentium instruction for instruction, although running at much 
slower clock rates. As a cautionary, Motorola (and just about everyone else) 
has a bad reputation for not delivering promised parts and/or discontinuing 
"mature" parts. I like it and would use it if it met my requirements despite 
my reservations about longterm availability.

> If we do something like you're suggesting, how do we guarantee the
> availability of the key components over a long period of time? If iTV was
> in production you'd be all set, as I assume they would freeze the chip for
> many years.

One solution would be to open-source the hardware similar to the GNU Public 
License. If someone came along and decided to second source a clone, so much 
the better if we could buy it from them cheaper than we could do it 
ourselves. Also, if our base design provided an SDRAM interface and someone 
enhanced it to RamBus for example, we would be entitled to full disclosure of 
the details under the license terms. All the while, we have access to the 
original design files and their descendents and are free to pursue our 
options at any time and for any reason. I know this runs counter to the IP 
business model held dear to many silicon design houses, but so be it.

Pardon my use of the term "we", I mean no presumption. At the same time, I 
know that there are several chip designers on this list that _may_ be 
interested in having a serious go at this. The expertise of the readership is 
impressive, and the software and network protocol gurus could vastly 
contribute by advising the hardware gurus on common algorithms that may 
warrant the inclusion of judicious hardware assists. Finally, PCB layout 
expertise would need to be donated in order to cross the finish line.

> It would be great if it could be based on a Forth CPU. As far as thrash out
> consensus goes, I'm afraid that will be difficult, unless the consensus was
> restricted to a simple list of requirements.

The Linux community is impressive any way you look at it. They have a 
different historical and future set of tasks than what I have in mind. Their 
work will never be "done". I hope only for a consensus on a minimal CPU 
architecture and instruction set and core hardware that a critical mass of 
people would actually be willing to spend their precious time and money on. 
The mission is to assure a longterm supply of simple and consistent hardware 
for us to freak freely with inventing cool software and non-core peripherals. 
It would also be nice to prove to the world that a bunch of Forth loonies are 
capable of securing their own interests in a pro-active sense.

I am not a commitee man by nature, but I have had the occasional pleasure of 
working on high-morale teams that had the right chemistry to work together on 
developing a winner. Consensus is never 100% in my experience, and 
compromises can be a sticky issue, but it can be done without winding up with 
a turkey if everyone is paying attention. I think that the lessons learned 
with different takes on the MISC Forth chips provide ample guidance for this 
particular stab at it.

The MISC Forth CPU idea scales well. Perhaps a family of chips that fit into 
different roles in a multiprocessor system while preserving an essential 
commonality would actually keep _everyone_ happy.

> You mention on your site that you've never heard of someone building a 386,
> much less a Pentium, computer by hand, probably because of the timing
> issues. I agree these are greatly alleviated by using highspeed serial,
> instead of parallel busses to communicate off-chip. But you still need
> agreement on protocols for the links.

Having an I/O coprocessor in the family would decouple the main processor 
from peripheral X and avoid turning the common serial I/O hardware subsystem 
into a monstrosity. The main CPU and I/O coprocessor software have to be "on 
the same page" re: the data going back and forth but the interprocessor comm 
link can be implemented in an arbitrary fashion. The I/O coprocessor's job 
would be to take care of the filthy details involved in talking to a USB 
keyboard and mouse for example, without the main CPU knowing or caring about 
USB per se. Consensus would only be needed in the basic topology, throughput 
expectations per channel, and minimum number of channels.

Myron Plichota

------------------------

To Unsubscribe from this list, send mail to Mdaemon@xxxxxxxxxxxxxxxxxx with:
unsubscribe NOSC
as the first and only line within the message body
Problems   -   List-Admin@xxxxxxxxxxxxxxxxxx
Main 4th site   -   http://www.