index concept yachts_and_racing_dinghies system_niches elements_principles designs journal



// Caterpillar draft

This sketches what the dinghy architecture could look like.

The elements-and-principles page lays out several values.

In this design, we will pursue these -

    1. The Bus Is The Computer

    2. Pure Async

And, a further principle,

    3. No FPGAs

We turn down some performance opportunities by avoiding FPGAs. But we
strengthen on trustworthyness.

What we end up with is a novel messaging-centric system design.


::: Message-centric system

Its novelty,

    There is no universal memory map.

    There is no general-purpose CPU.

    Processing work is done on "Workhorse" cards that sit off the bus.

Here are the layers,

    Bus: A bus containing a 68000 and some static ram. The chip is not
    general-purpose. Rather, it is there to coordinate secure messaging
    between bus members (cards). It will need some bootstrapping code, which
    would seek and link a baseline set of cards.

    Node: IO, workhorse chips, anything else. I will refer to these below as
    {Cards}, because they fill a similar role to cards you would find on an
    ISA bus or similar.

    Bootstrap: A special type of node that gets things going at power-on.

Any time you want to do anything, you add a node card. Want to do keyboard IO?
There is a card for that. Network? There is a card for that. Processing? There
is a card for that. Storage? Card. Video? Card.

At system startup, bootstrap instructs the bus to set up the initial
communication channels. For example, allocate a workhorse, installing a
termina process on it, and setting up channels between keyboard, terminal and
video.

To start a process, you allocate a workhorse card, tell it to reset, stream
code into it, then tell it to start. You can control its permissions by
whitelisting the types of messaging it is allowed to do at launch.

If you had a game with malware, it would be difficult for it to do any damage,
because it has no contact with the outside world, nor with other processes.

To make this platform successful, we will need to get the subtleties right in
the way we design the messaging architecture. Having done that, it will be
possible to reason about the operation of the system through a focus on
messages passing between nodes.

It should be straightforward to create a lightweight, single-process operating
system that would run in the bootstrap node, with a purely async system
interface to the bus.


::: Bus design

Current idea is that 68000 would make a strong foundation,

    Memory addressing. It has a 32-bit memory bus, giving room to scale up.

    Decently fast. We know that amigas and ataris ran well on this.

    Hardware still available. Modern coldfire processors go up to 300MHz.

It would be wire-wrap-able,

    See https://news.ycombinator.com/item?id=10121758


::: Node design

The only fixed design of the node will be its interface to the messaging bus.

The initial node could be as simple as the computer demonstrated in this
video,

    https://www.youtube.com/watch?v=nFIviiwPrLI

Problem: how to allow seamless interaction between a core and a card running
at a different clock speed?


::: Iteration Platform

Something I like about this approach is that you can start small, and then
iterate up.


::: Further thoughts

This design may suffer from poor IO latency. For example, video display. Novel
approaches may allow a path past this. For example, colocating a workhorse cpu
and Video Member, and then having a hardware compositor that converts several
signals into a single VGA output. In this way, you could have a simple
windowing system equivalent to workbench 1.3.