Ideas for a simple, but somewhat extendable computer bus

[allison]

On 11/20/2017 01:52 AM, alan--- via cctalk wrote:
>
> If you ever look at how interrupts are implemented on STD bus, you'll
> run in fear.  There are only two options, chain the slot to slot
> interrupt line (assuming all slots are filled downstream of the CPU)
> and share the one request signal - implementing any CPU-specific
> interrupt requirements like an vector placement for x86 - or you can
> home run IRQ lines independently of the STD bus signals.  Most cards
> did the later or just put all peripherals that will ever need IRQs on
> the CPU card itself.

The chained interrupt was not bad as it was consistent with the z80 (bus
origin).  You post an interrupt and
the cpu grabs the address vector off the bus during the Interrupt ACK
cycle.  The bus assumed the IEI, IEO
of Z80 peripherals.   If you using other peripherals you have to have
logic you equivocate that or force RST-7.

the elephant in the room for STD is that the bus controls are z80
signals and timing including the short M1 state
and refresh (if z80).


>>STD bus is pretty antiquated.

Name a bus that isn't 20+ years old or more.  Many PC either do not have
a bus or its functionally specific
such as memory, disk, Ethernet, or USB.   Those that had buses are old
and how many PC buses are there
over the years?

Ethernet is as much a bus these days as any.  Its fast, can address
a lot of stuff despite a high cost to get on the bus or off... and its
what nearing 40 years old?

Most CPUs on the chip level are antiquated. so a bus thats old sorta fits.

The same thing for S100.  S100 started as a split data bus plus all the
raw control signals the 8080 spat out
including a ttl version of the cpu clock.  Ignoring timing S1000 has had
the widest variety of CPUs applied
from 1802 though LSI-11 and TI9900 and even as recent as 486. 

most of the console machines (Atari, TRS80, Apple, Commodore) don't cont
as they were largely single
processor and single master.  The exceptions that will pop up are
tightly integrated (Visual 1050 and C124)
so that the bus never sees the differences or likely anything out on the
bus needs to know.  In most cases the
bus is a simplified version of the CPU control signals.

One of the hardest bus issues is what are the advanced controls needed
for data bus direction vs any read/write
signal to the memory or IO on the target card.

Goes back to the origin question of why all those when many of the
processors and their intrinsic peripherals
are mutually exclusive?  If the bus is a tool for training people about
shared buses with multiple CPUs  it would
seem keeping it simple so that other issues of the system level can be
studied such as atomic operations for CPUs
that don't have them and mutual exclusion or interlocking to prevent  a
cpu from stepping on anothers in-process
work.  Then there is memory management if there is global memory on the
bus as an example of resource sharing
and allocation.

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.

Allison

>
> -Alan
>
>
> On 2017-11-20 00:54, Chuck Guzis via cctalk wrote:
>> On 11/19/2017 08:11 PM, Ken Seefried via cctalk wrote:
>>
>>> More importantly, the vast number of compatible I/O cards that were
>>> produced.  Much alternative history to be pondered.
>>
>> So we agree on parallel standard buses, that STD bus is a strong
>> contender with varied processor base.
>>
>> There *is* STD32, but it's a bit of an abomination, like EISA.  It
>> extends the bus to 32 bits and retains compatibility with 8-bit STD.
>> But there's a price to be paid--special connectors (like EISA) and more
>> complex interfacing logic (to accommodate the older STD).
>>
>> Finally, it's pretty much a sole-source standard--Ziatech came out with
>> it, and to the best of my knowledge, is the only firm that ever produced
>> STD32 cards.
>>
>> --Chuck