Dinghy index concept papers

Caterpillar draft

This sketches what the dinghy architecture could look like.

The paper Values Palette discusses design
values around which a computer system could be built.

In this design, we will pursue these,

    The Bus Is The Computer

    Pure Async

    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

    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

    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.

        Modern coldfire processors go up to 300MHz. Are they similar enough to
        68k chips?

    It would be wire-wrap-able,

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

    A challenge: it is not clear that you can reliably source 68k chips. Some
    places are selling them, but we don't know of anyone producing them. (If
    you know more, please let us know on #dinghy.)

Node design

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

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


Async interaction

    An earlier edit of this page posed this problem, "Problem: how to allow
    seamless interaction between a core and a card running at a different
    clock speed?"

    Dave Park has given detailed feedback to this,

        "From 000 up to 030, the 68K bus design is 100% asynchronous and speed
        differences and bus width differences are very easy to accommodate.

        From 040 up dynamic bus sizing goes away, and the bus becomes
        synchronous, which results in 3x higher instructions per clock.

        So if raw throughput isn't the highest priority, any pre-040 IC is

    He also has some advice about mental modeling of coldfire kit,

        "If you like multiple busses including serial links like SPI/I2C, the
        Dragonball CPUs run at 33 or 66MHz, have a pure 68000 core, and also
        have a lot of accessories on die like UARTs, GPIO, etc.

        The early Coldfire chips are fully 68K compatible, and are basically
        super Dragonballs.

        Coldfire V2 and onwards broke compatibility enough to be no fun.

    I replied,

        "That sounds quite valuable, and I can see why embedded people would
        jump at it. For the dinghy project, I was really hoping to make the
        system discoverable, and too much SoC gets in the way of that."

    He corrected,

        "Aye, but the upside is that on the Dragonballs, that is HIGHLY
        configurabe, can be enirely unplugged, and is mapped HIGH in the
        memory map so it is out of the way of the very desirable "large,
        continuous area of flat memory" that is desirable for simple tasks."


        "there are millions in the chain. I just bought 1,000 dragonballs last
        week, new in tray. $2.25 each."

        "The 33MHz ones are LQFP so easy to work with. The 66MHz ones are BGA,
        so I have to fire up the pick and place machine to play with those."

    He also responded to my inquiry about chip robustness,

        "68SEC000s are used in cubesats with some regularity."

        "The cores that are fully static are also very small. They're not
        hardened as such, but they're tolerant of radiation enough that if
        you're still alive they're still working."


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.