Ideas for a simple, but somewhat extendable computer bus

allison allisonportable at gmail.com
Mon Nov 20 13:37:41 CST 2017


On 11/20/2017 01:18 PM, Chuck Guzis via cctalk wrote:
> On 11/20/2017 05:40 AM, allison via cctalk wrote:
>
>> Creating a bus to accommodate any one cpu at a time is far more
>> straightforward and there are plenty of
>> examples than one that is running a mix of many cpus.
> Oddly enough, I'm in agreement. :)
>
> Today, it really makes little sense to have memory, CPU and high-speed
> peripherals on separate bus slots.   At least for the cases being
> discussed, memory is dense and inexpensive enough that there's really no
> good reason to put it somewhere else.
A good example would be a matrix of SBCs (with local memory, IO as
needed) that
communicate via common bus be it parallel or serial.  The key then is
addressing
and arbitration.  A protocol to hand packet communication is easy and
doing  either
a request/grant  master slave from the current bus master , token bus, or
CSMA/CD are all possible.

> Data transfer between peripheral devices and CPUs is a different matter
> and can be handled by existing serial buses--which is what I thought the
> original question was.
Likely true but IO can be local to a CPU or several and handled for
other CPUs
as "tasks".

Of course then the concept moves to system space where the SBC are
components and
programming is more complex in organization.  Likely more fun rather
than hammering
out hardware.  Then again I'd find that part fun as well.   

I did that back when with a S100 machine expanded with multiple
Z80s(local ram and MMU),
global mmemory and  8085s and 8749s to have intelligent peripherals and 
shared loading
and tasks.  An interesting experiment and some elements still are in
operation.   However
software development of the day (1980) was primitive and some concepts
were only
experimental.  Networking was one of the things most productive and lead
to many
hardware simplifications.  It proved that while CP/M was a good single
thread
development environment it had limits that only a new OS could
overcome.  The most
significant was resource management (memory, storage, and IO) followed
by task
and process management.  


Allison
> --Chuck
>
>
>



More information about the cctech mailing list