Re: Ideas for a simple, but somewhat extendable computer bus

[ben via cctalk]

On 11/20/2017 8:41 AM, Tapley, Mark via cctalk wrote:

On Nov 19, 2017, at 11:54 PM, Chuck Guzis via cctalk  
wrote:


So we agree on parallel standard buses, that STD bus is a strong
contender with varied processor base.


Catching up late, sorry if this is an old question, but what did the 
Digital Group computers use? My recollection is that they offered cards with 
6800, 6502, 8080, and Z-80 CPUs on the same bus, and that part of the system 
seemed to work reasonably well.  (At least, the Digital Group system complaints 
I read seem to center on the PhiDeck mass storage system not the 
CPU/memorylperihperal bus.)
There is a nice website at: http://www.bytecollector.com/dg_cards.htm 
which seems to show cards with not a whole lot of pins to connect to the bus - 
maybe 36 pins on the visible side, though the card is definitely 2-sided so 
probably 36 more on the back side?


I think they also had the chip that did the pdp8 instruction set too.
That also brings up the other point, what software did they have?
Ben.
I can see it now, a pdp 8 time sharing emulating a 6502 emulating a 8080. :)

Re: Ideas for a simple, but somewhat extendable computer bus

[Rob Doyle via cctalk]

On 11/20/2017 6:50 PM, Noel Chiappa via cctalk wrote:

 > From: Charles Anthony

 > a hybrid PDP-11 (16 bits) / PDP-15 (18 bits) on a shared bus (UNIBUS?)

That's a UNICHANNEL-15: it allowed devices on the -11 to do DMA directly into
the PDP-15's memory through the MX15-B Memory Multiplexer.

Odd factoid: this UNIBUS could run in 18-bit mode (!!), where the UNIBUS' two
parity lines were recycled into 2 extra data lines. Some DMA interfaces (e.g.
the RK11) could support this; in this particular case, it allowed the PDP-15
to use RK05 drives.

Noel


More than just that -

The DEC KS10 (PDP-10) used the UNIBUS and Massbus peripherals (RP06
disk, etc) in 18-bit mode. There was a special version of the RH11
(RH11C?) that had extra buffering and could be configured in "Fast
Transfer Mode" where it used a pair of 18-bit UNIBUS transfers to do
36-bit DMA.

I've never decided if this was really clever engineering, or just
'messed up' ... I guess it saved having 36-bit peripherals and
peripheral buses.

Rob.

Re: Ideas for a simple, but somewhat extendable computer bus

[Noel Chiappa via cctalk]

> From: Charles Anthony

> a hybrid PDP-11 (16 bits) / PDP-15 (18 bits) on a shared bus (UNIBUS?)

That's a UNICHANNEL-15: it allowed devices on the -11 to do DMA directly into
the PDP-15's memory through the MX15-B Memory Multiplexer.

Odd factoid: this UNIBUS could run in 18-bit mode (!!), where the UNIBUS' two
parity lines were recycled into 2 extra data lines. Some DMA interfaces (e.g.
the RK11) could support this; in this particular case, it allowed the PDP-15
to use RK05 drives.

Noel

Re: Ideas for a simple, but somewhat extendable computer bus

[Eric Smith via cctalk]

On Nov 20, 2017 7:41 AM, "Tapley, Mark via cctalk" 
wrote:

Catching up late, sorry if this is an old question, but what did
the Digital Group computers use? My recollection is that they offered cards
with 6800, 6502, 8080, and Z-80 CPUs on the same bus, and that part of the
system seemed to work reasonably well.


The Digital Group had two separate buses, a memory bys and an I/O bus, as
well as two other slot types incompatible with either bus, for a CPU card
and a TVC (video and cassette) card. They didn't support interrupts or DMA
on any bus. If you wanted to use an interrupt, you had to wire it over the
top. Doc Suding said that he didn't put interrupts on the bus because
(paraphrasing) they are complicated and you don't need them.

As you say, they did support various CPUs, but not more than one in a
system. I wouldn't recommend that anyone consider The Digital Group as an
example of good bus design.

Re: Ideas for a simple, but somewhat extendable computer bus

[Veit, Holger via cctalk]

Am 19.11.2017 um 16:08 schrieb emanuel stiebler via cctalk:

On 2017-11-18 23:48, Jim Brain wrote:

> Looking at the schematic for the ECB, I cannot find any description of
> the signals BAI, BAO, IEI, and IEO.  Can anyone shed some light on the
> function of these signals?

Here again:

https://en.wikipedia.org/wiki/Europe_Card_Bus

I have some ECB documentation "somewhere", but I'm moving so it is in 
one of the 100s boxes somewhere :(


But the guys on the retrobrewcomputers can help you for sure.

And yes, I like ECB, it was small & simple, you still can get boards 
for it, and the DIN conectors I still use ...


ECB is, like many similar approaches, basically Intel world, i.e. 8085, 
8088, Z80 (ok, that's Zilog). It is rather tricky
to adapt to the 6xxx (6502/68xx) world; and given the former Kontron et 
al socienty, it was basically used for a Z80 line

of CPU and peripheral boards, not much else.

To add another idea, why not run the IBM-XT bus on the DIN41612 
connector? This is to avoid the card edge connectors.
Use A+C with the classic 62 pins of the XT connector (2 are unused), and 
add the B pins in case to extend to the AT bus.
While the XT bus is also Intel world, it has been already successfully 
used for 68xx (6809) multiprocessing. Read
http://www.bradrodriguez.com/papers/ (section "Multiprocessing for the 
Impoverished...").


--
Holger

Re: Ideas for a simple, but somewhat extendable computer bus

[Charles Anthony via cctalk]

On Mon, Nov 20, 2017 at 5: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.
>
>
Dim memory of U. of. WA School of Dentistry running a hybrid PDP-11 (16
bits) / PDP-15 (18 bits) on a shared bus (UNIBUS?); the -11 did the I/O,
the -15 did the number crunching.

-- Charles

Re: Ideas for a simple, but somewhat extendable computer bus

[Chuck Guzis via cctalk]

On 11/20/2017 11:37 AM, allison via cctalk wrote:

> 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.

I did a similar thing, ca 1985-6 with a bunch of commodity PCSs in a
fault-tolerant setup and used a simple machine-to-machine full-duplex
serial connection, using shift registers and short twisted-pair
differential connections.  Uncomplicated protocol and simple to
implement.   I'd have to go back to my old documents and see what the
link speed was, but IIRC, it was pretty fast, in the megabit/second
range.  The limiting factor was the ISA bus it was hooked to.

--Chuck

Re: Ideas for a simple, but somewhat extendable computer bus

[Noel Chiappa via cctalk]

> From: Allison

>> I would seriously consider shared data/address lines, like on the QBUS.

> QBUS is wrapped around a subset of PDP11 and the unique processors made
> to fit it.

I did say "like ... the QBUS", not "the QBUS"! I was just trying to make the
point that the original sketch assumed separate address and data lines, and
that's an assumption worth looking at.

> The bottom line is for every bus you have to get on and off with
> devices to buffer ... The more you use the less card there is for other
> things

Yes, but that cuts both ways: multiplexed address and data also saves you a
lot of bus transceivers.

Noel

Re: Ideas for a simple, but somewhat extendable computer bus

[allison via cctalk]

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
>
>
>

Re: Ideas for a simple, but somewhat extendable computer bus

[Chuck Guzis via cctalk]

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.

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.

--Chuck

Re: Ideas for a simple, but somewhat extendable computer bus

[Tapley, Mark via cctalk]

On Nov 19, 2017, at 11:54 PM, Chuck Guzis via cctalk  
wrote:

> So we agree on parallel standard buses, that STD bus is a strong
> contender with varied processor base.

Catching up late, sorry if this is an old question, but what did the 
Digital Group computers use? My recollection is that they offered cards with 
6800, 6502, 8080, and Z-80 CPUs on the same bus, and that part of the system 
seemed to work reasonably well.  (At least, the Digital Group system complaints 
I read seem to center on the PhiDeck mass storage system not the 
CPU/memorylperihperal bus.)
There is a nice website at: http://www.bytecollector.com/dg_cards.htm 
which seems to show cards with not a whole lot of pins to connect to the bus - 
maybe 36 pins on the visible side, though the card is definitely 2-sided so 
probably 36 more on the back side?

Re: Ideas for a simple, but somewhat extendable computer bus

[allison via cctalk]

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

Re: Ideas for a simple, but somewhat extendable computer bus

[allison via cctalk]

On 11/19/2017 10:51 PM, Eric Smith wrote:
> On Nov 19, 2017 7:18 PM, "allison via cctalk"  > wrote:
>
> The rest is the specific implementation.  What happens if the CPU is
> 1802 or something else that does not match the 6500 or 8080z80 models.
>
>
> There is nothing that prevents either the serial or parallel
> arbitration schemes from working with other processors.
>
Understood but not always easily applied.

> In the case of the 1802, it would work easily for interrupts, but
> would need some additional circuitry for DMA, because the 1802 doesn't
> include any feature whereby another bus master can request that the
> 1802 surrender control of the bus. Instead, the 1802 has a built-in
> single-channel DMA controller.
>
Its why I picked that one.

> That 1802 bus master problem exists for interfacing _any_ sort of bus
> master to any 1802, and is totally independent of what kind of DMA
> arbitration is chosen.
>
True, but as a potential candidate on a generalized bus how do you
handle that, besides wait states
or processor clock stall? Of course being CMOS its easily done at a cost
of performance.

All of this is targeting a generalized bus to run a large selection of
cpus possibly mixed with radically different bus cycles.

Allison

Re: Ideas for a simple, but somewhat extendable computer bus

[alan--- via cctalk]

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.


STD bus is pretty antiquated.

-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

Re: Ideas for a simple, but somewhat extendable computer bus

[Chuck Guzis via cctalk]

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

Re: Ideas for a simple, but somewhat extendable computer bus

[Ken Seefried via cctalk]

I've always thought STD-Bus missed a real opportunity here.  Small
enough to be cost effective (relative to the size of, say, S-100
(bonus, no stupid power supply issues)), sane, flexible enough bus
structure that I believe there are at least CPU cards using:

- 4004/4040 (pre-standard?)
- 8080/8085/Z-80 and the myriad of variants
- 8088/8086/80188/10186 through at least 80486, including variants and
second sources
- 8048/8051 and the vast numbers of variants
- 8096/8097 and variants
- 6800 and variants
- 68HC11 and variants
- 6809/6309
- 6502 and variants
- 68xxx and variants up to at least the 68040 and 68332
- TMS9900/9995
- RCA 1802
- Signetics 2650
- Novix Forth

More importantly, the vast number of compatible I/O cards that were
produced.  Much alternative history to be pondered.

KJ

Re: Ideas for a simple, but somewhat extendable computer bus

[Eric Smith via cctalk]

On Nov 19, 2017 7:18 PM, "allison via cctalk"  wrote:

The rest is the specific implementation.  What happens if the CPU is
1802 or something else that does not match the 6500 or 8080z80 models.


There is nothing that prevents either the serial or parallel arbitration
schemes from working with other processors.

In the case of the 1802, it would work easily for interrupts, but would
need some additional circuitry for DMA, because the 1802 doesn't include
any feature whereby another bus master can request that the 1802 surrender
control of the bus. Instead, the 1802 has a built-in single-channel DMA
controller.

That 1802 bus master problem exists for interfacing _any_ sort of bus
master to any 1802, and is totally independent of what kind of DMA
arbitration is chosen.

Re: Ideas for a simple, but somewhat extendable computer bus

[allison via cctalk]

On 11/19/2017 08:54 AM, Noel Chiappa via cctalk wrote:
> > From: Allison
>
> > simple 16 data, 24 address likely 6 lines for basic control plus others
> > your up to 50+ lines
>
> I would seriously consider shared data/address lines, like on the QBUS. It
> doesn't add _that_ much complexity to share the lines (I did a slave device
> using only 74xxx parts, and it was dead simple - probably a goal of the
> designers), and it will really drop the pin count. The speed impact is not
> too bad - on reads, where the address and data naturally happen at different
> times, it can be none.
>
>   Noel
QBUS is wrapped around a subset of PDP11 and the unique processors made
to fit it.
The problem is carries is every card has to demux the bus that has
hardware cost on
every card. if the CPU doesn't initially multiplex the CPU card carries
the weight of
creating that muxed bus.    Dec had a full set of unique devices to do this.
I may add that things like PDP-11 with read before write adding its own
special set
of issues for peripherals.

The problem with multiplexed buses is speed cost.  You have to use fast
parts that are
compatible with the bus levels and the bus may have to be artfully
constructed to avoid
issues that occur when operating at high speed.   The other is how do
you multiplex
for example look and devices like 8085, 8088, z80 and 6502 the timing
overheard  is different
and the bus could even contradict something like the 8085/8088 which is
already multiplexed.

The bottom line is for every bus you have to get on and off with devices
to buffer and
possibly latch signals.  The more you  use the less card there is for
other things
and likely the mode complex the card and its related timings will be.

Its s solution when pins and their cost is more important that logic. 

The old saw Speed, quality, price pick any two applies.  Added complexity
will add cost or slow development and maybe even add bugs.


Allison

Re: Ideas for a simple, but somewhat extendable computer bus

[allison via cctalk]

On 11/19/2017 03:43 PM, Eric Smith via cctalk wrote:
> On Sat, Nov 18, 2017 at 10:48 PM, Jim Brain via cctalk <
> cctalk@classiccmp.org> wrote:
>
>> Looking at the schematic for the ECB, I cannot find any description of the
>> signals BAI, BAO, IEI, and IEO.  Can anyone shed some light on the function
>> of these signals?
>>
> Bus Acknowledge In and Out, Interrupt Enable In and Out, used for serial
> arbitration of the bus request and interrupt.  These signals are
> daisy-chained rather than bused.
>
> If a any card is requesting the bus by asserting the bus request, at some
> point the CPU will acknowledge that by asserting its bus acknowledge
> output, which is wired to the BAI signal of the first bus slot. The BAO of
> each slot is wired to the BAI of the next slot.  Since more than one card
> can request the bus, it is necessary for there to be some arbitration
> scheme to determine which card gets the bus grant. In the serial
> arbitration scheme, the highest priority goes to the card that is earliest
> in the daisy chain (closest to the CPU).  If a particular card is NOT
> requesting the bus, it passes the BAI signal on to BAO to make the
> acknowledge available to the next card. If it is requesting the bus, it
> does not pass BAI to BAO, but instead sets BAO inactive, so that no
> lower-priority card will see the bus acknowledge.
>
> Similarly for how the card deals with interrupts, but using the IEI and IEO
> as the daisy chain.
>
> This is a common technique since the 1960s, and for microcomputers was used
> by Intel Multibus in 1975, and by Zilog Z80 family peripherals in 1976.
>
> The drawback is that if there are a lot of cards, there can be a long
> propagation delay of the interrupt acknowledge from the CPU to the last
> card of the bus, particularly if routing the IEI/IEO chain through NMOS Z80
> peripherals. 
That asumes z80 and a default bus master...  What if the CPU  is 6502 or
still other.


> That can cause no device to respond to the interrupt
> acknowledge with a vector by the time the CPU needs it.  This can be solved
> by adding wait states to the interrupt vector read, or by using a parallel
> arbitration scheme instead of serial.
It also assumes and interrupt vector read.  Not al cpus do that or it
can be
very implementation dependent.

Its not a what bus us better its what bus suits the system and matching CPU.

> Parallel arbitration can be done with the same slot pin assignments, but
> instead of busing the request and daisy-chaining the acknowledge, the
> requests are each separately fed into a priority encoder.  The "any" output
> of the encoder goes to the request input of the CPU.  The acknowledge from
> the CPU goes into the enable of a decoder, and the select inputs of the
> decoder come from the priority encoder, so that each slot gets its own
> decoded acknowledge signal to its BAI input.  In this case the backplane
> doesn't connect the BAO output of a slot to anything.   This parallel
> arbitration scheme can be used for bus request and/or interrupt request.
The rest is the specific implementation.  What happens if the CPU is
1802 or something else that does not match the 6500 or 8080z80 models.

Buses and systems are not software abstractions they are hardware
implementation
and often driven by the host CPU as well as over all system needs.  If
this wasn't true
why do so many different buses exist?

Allison

> Eric

Re: Ideas for a simple, but somewhat extendable computer bus

[ben via cctalk]

On 11/18/2017 5:57 PM, Eric Christopherson via cctalk wrote:

On Fri, Nov 17, 2017, ben via cctalk wrote:

On 11/17/2017 6:59 PM, Chuck Guzis via cctalk wrote:

On 11/17/2017 05:34 PM, Jim Brain via cctalk wrote:


It does not have to be fast.  I rather thought, "what is the simplest
multi-cpu shared bus that could be easily understood by folks and allow
them to focus on multi-processing education, not bus understanding"


How about a serial bus?  Physically simple and not too awful logically
today.  Say, I2C or SPI...

--Chuck


Say USB-version 101101100 :)


Sorry to be dense, but are you referring to some actual USB version? Or
did you mean something like "one of the many USB versions, some not yet
released"? (101101100 is 364 in binary, but I don't see the significance
of that.)

As FOGHORN LEGHORN once said.
“That’s a joke, I say that’s a joke son”

Re: Ideas for a simple, but somewhat extendable computer bus

[Jim Brain via cctalk]

On 11/19/2017 2:43 PM, Eric Smith wrote:


Similarly for how the card deals with interrupts, but using the IEI 
and IEO as the daisy chain.
Thanks for the context.  I think the fact that !BUSAK is present on A31 
threw me


https://www.retrobrewcomputers.org/lib/exe/fetch.php?media=boards:ecb:backplane-3:backplane.pdf

and the fact that I don't see that the ECB routes BUSAK from the CPU 
card to BAI of the first slot




Parallel arbitration can be done with the same slot pin assignments, 
but instead of busing the request and daisy-chaining the acknowledge, 
the requests are each separately fed into a priority encoder.  The 
"any" output of the encoder goes to the request input of the CPU.  The 
acknowledge from the CPU goes into the enable of a decoder, and the 
select inputs of the decoder come from the priority encoder, so that 
each slot gets its own decoded acknowledge signal to its BAI input.  
In this case the backplane doesn't connect the BAO output of a slot to 
anything.   This parallel arbitration scheme can be used for bus 
request and/or interrupt request.
I like this idea better.  Is there any implementation docs you might 
suggest? (I have the Bus Handbook on order, but it has not arrived)


I also am unclear on how ECB handles dual CPUs, if it does at all.

Jim


Eric



--
Jim Brain
br...@jbrain.com
www.jbrain.com

Re: Ideas for a simple, but somewhat extendable computer bus

[Eric Smith via cctalk]

On Sat, Nov 18, 2017 at 10:48 PM, Jim Brain via cctalk <
cctalk@classiccmp.org> wrote:

> Looking at the schematic for the ECB, I cannot find any description of the
> signals BAI, BAO, IEI, and IEO.  Can anyone shed some light on the function
> of these signals?
>

Bus Acknowledge In and Out, Interrupt Enable In and Out, used for serial
arbitration of the bus request and interrupt.  These signals are
daisy-chained rather than bused.

If a any card is requesting the bus by asserting the bus request, at some
point the CPU will acknowledge that by asserting its bus acknowledge
output, which is wired to the BAI signal of the first bus slot. The BAO of
each slot is wired to the BAI of the next slot.  Since more than one card
can request the bus, it is necessary for there to be some arbitration
scheme to determine which card gets the bus grant. In the serial
arbitration scheme, the highest priority goes to the card that is earliest
in the daisy chain (closest to the CPU).  If a particular card is NOT
requesting the bus, it passes the BAI signal on to BAO to make the
acknowledge available to the next card. If it is requesting the bus, it
does not pass BAI to BAO, but instead sets BAO inactive, so that no
lower-priority card will see the bus acknowledge.

Similarly for how the card deals with interrupts, but using the IEI and IEO
as the daisy chain.

This is a common technique since the 1960s, and for microcomputers was used
by Intel Multibus in 1975, and by Zilog Z80 family peripherals in 1976.

The drawback is that if there are a lot of cards, there can be a long
propagation delay of the interrupt acknowledge from the CPU to the last
card of the bus, particularly if routing the IEI/IEO chain through NMOS Z80
peripherals.  That can cause no device to respond to the interrupt
acknowledge with a vector by the time the CPU needs it.  This can be solved
by adding wait states to the interrupt vector read, or by using a parallel
arbitration scheme instead of serial.

Parallel arbitration can be done with the same slot pin assignments, but
instead of busing the request and daisy-chaining the acknowledge, the
requests are each separately fed into a priority encoder.  The "any" output
of the encoder goes to the request input of the CPU.  The acknowledge from
the CPU goes into the enable of a decoder, and the select inputs of the
decoder come from the priority encoder, so that each slot gets its own
decoded acknowledge signal to its BAI input.  In this case the backplane
doesn't connect the BAO output of a slot to anything.   This parallel
arbitration scheme can be used for bus request and/or interrupt request.

Eric

Re: Ideas for a simple, but somewhat extendable computer bus

[Jim Brain via cctalk]

On 11/19/2017 9:08 AM, emanuel stiebler wrote:

On 2017-11-18 23:48, Jim Brain wrote:

> Looking at the schematic for the ECB, I cannot find any description of
> the signals BAI, BAO, IEI, and IEO.  Can anyone shed some light on the
> function of these signals?

Here again:

https://en.wikipedia.org/wiki/Europe_Card_Bus

I have some ECB documentation "somewhere", but I'm moving so it is in 
one of the 100s boxes somewhere :(


But the guys on the retrobrewcomputers can help you for sure.

And yes, I like ECB, it was small & simple, you still can get boards 
for it, and the DIN conectors I still use ...


I went there already, but the descriptions:


*BAI 1; BAO 1:* Bus Priority In; Bus Priority Out.

*IEI; IEO:* Interrupt Enable In; Interrupt Enable Out.


does not give much clue as to usage, especially as I see that the pins 
are unwired on the backplanes, and require ones to add jumpers to 
connect them.  I understand that they are used to "chain" boards 
toghether in some order, but how and why is left as an exercise for the 
reader.


I looked at each of the backplane schematics for guidance, as well as 
looking at various ECB cards (the interrupt card I thought would have 
more detail, but alas, not)


Jim


--
Jim Brain
br...@jbrain.com
www.jbrain.com

Re: Ideas for a simple, but somewhat extendable computer bus

[emanuel stiebler via cctalk]

On 2017-11-18 23:48, Jim Brain wrote:

> Looking at the schematic for the ECB, I cannot find any description of
> the signals BAI, BAO, IEI, and IEO.  Can anyone shed some light on the
> function of these signals?

Here again:

https://en.wikipedia.org/wiki/Europe_Card_Bus

I have some ECB documentation "somewhere", but I'm moving so it is in 
one of the 100s boxes somewhere :(


But the guys on the retrobrewcomputers can help you for sure.

And yes, I like ECB, it was small & simple, you still can get boards for 
it, and the DIN conectors I still use ...

Re: Ideas for a simple, but somewhat extendable computer bus

[Noel Chiappa via cctalk]

> From: Allison

> simple 16 data, 24 address likely 6 lines for basic control plus others
> your up to 50+ lines

I would seriously consider shared data/address lines, like on the QBUS. It
doesn't add _that_ much complexity to share the lines (I did a slave device
using only 74xxx parts, and it was dead simple - probably a goal of the
designers), and it will really drop the pin count. The speed impact is not
too bad - on reads, where the address and data naturally happen at different
times, it can be none.

Noel

Re: Ideas for a simple, but somewhat extendable computer bus

[Jim Brain via cctalk]

On 11/18/2017 1:46 AM, emanuel stiebler wrote:

On 2017-11-17 18:11, Jim Brain via cctalk wrote:
I'm currently working on a single board computer system, designing 
from scratch partially as an education experience, and also as 
something that might be of interest to others.


I've laid out the first version of the SBC, and I realize it would 
cost nothing to add an edge connector on the PCB, allowing expansion 
options.  As well, assuming the design has any merit, I can see 
creating one of these SBcs for each family (8080/Z80, 65XX, 68XX, and 
maybe even 16 bit options like TMS9900, 68K, etc.)


You know this projects?

https://en.wikipedia.org/wiki/N8VEM


Looking at the schematic for the ECB, I cannot find any description of 
the signals BAI, BAO, IEI, and IEO.  Can anyone shed some light on the 
function of these signals?



Jim

--
Jim Brain
br...@jbrain.com
www.jbrain.com

Re: Ideas for a simple, but somewhat extendable computer bus

[Eric Christopherson via cctalk]

On Fri, Nov 17, 2017, ben via cctalk wrote:
> On 11/17/2017 6:59 PM, Chuck Guzis via cctalk wrote:
> > On 11/17/2017 05:34 PM, Jim Brain via cctalk wrote:
> > 
> > > It does not have to be fast.  I rather thought, "what is the simplest
> > > multi-cpu shared bus that could be easily understood by folks and allow
> > > them to focus on multi-processing education, not bus understanding"
> > 
> > How about a serial bus?  Physically simple and not too awful logically
> > today.  Say, I2C or SPI...
> > 
> > --Chuck
> 
> Say USB-version 101101100 :)

Sorry to be dense, but are you referring to some actual USB version? Or
did you mean something like "one of the many USB versions, some not yet
released"? (101101100 is 364 in binary, but I don't see the significance
of that.)

> 
> I would say use a 68000 if your still can get them,
> but run with a 6800 style clock. The master CPU and
> shared memory on the high phase of the clock. The
> slave CPU's on the low clock PHASE (clocked by a inverted clock).
> This will give you multi-processing with a bit more than
> 64KB.
> Ben.

-- 
Eric Christopherson

Re: Ideas for a simple, but somewhat extendable computer bus

[Jim Brain via cctalk]

On 11/18/2017 1:46 AM, emanuel stiebler wrote:

On 2017-11-17 18:11, Jim Brain via cctalk wrote:
I'm currently working on a single board computer system, designing 
from scratch partially as an education experience, and also as 
something that might be of interest to others.


I've laid out the first version of the SBC, and I realize it would 
cost nothing to add an edge connector on the PCB, allowing expansion 
options.  As well, assuming the design has any merit, I can see 
creating one of these SBcs for each family (8080/Z80, 65XX, 68XX, and 
maybe even 16 bit options like TMS9900, 68K, etc.)


You know this projects?

https://en.wikipedia.org/wiki/N8VEM


I've followed the N8VEM project for many years, but I had forgotten 
about looking at their bus design.  Thanks.


--
Jim Brain
br...@jbrain.com
www.jbrain.com

Re: Ideas for a simple, but somewhat extendable computer bus

[Jules Richardson via cctalk]

On 11/17/2017 07:11 PM, Jim Brain via cctalk wrote:

I looked at home computer busses (Atari, Apple, Commodore, Tandy, TI) for a
bit of inspiration, but they all seem overly simplistic (not horrible, but
hate to just punt on the idea).


Is the multi-CPU stuff important initially? If not then maybe keep things 
simple, but reserve a chunk of pins for "future expansion" with that in 
mind (or take the approach of various manufacturers and run the 'extra' 
stuff through to the boards separately from the backplane as/when it became 
necessary)


Alternately, STE immediately sprang to mind (it's 8 bit, but plenty of 
boards using 16 bit CPUs existed so long as they could handle data 8 bits 
at a time). Hazy memory is telling me there's some issue with 6502 CPUs, 
but pretty much any other 8-bitter (as well as m68k, ns32k etc.) is fair 
game. You could homebrew your own boards then, but also make use of all the 
hundreds of different commercial ones which existed.


If I remember right STE was essentially a simplified version of VME though, 
so that's probably worth a look too (I think someone else already mentioned 
it) - presumably there's more complexity and cost involved.


cheers

Jules

RE: Ideas for a simple, but somewhat extendable computer bus

[Dave Wade via cctalk]

> -Original Message-
> From: cctalk [mailto:cctalk-boun...@classiccmp.org] On Behalf Of emanuel
> stiebler via cctalk
> Sent: 18 November 2017 07:47
> To: Jim Brain <br...@jbrain.com>; General Discussion: On-Topic and Off-
> Topic Posts <cctalk@classiccmp.org>
> Subject: Re: Ideas for a simple, but somewhat extendable computer bus
> 
> On 2017-11-17 18:11, Jim Brain via cctalk wrote:
> > I'm currently working on a single board computer system, designing
> > from scratch partially as an education experience, and also as
> > something that might be of interest to others.
> >
> > I've laid out the first version of the SBC, and I realize it would
> > cost nothing to add an edge connector on the PCB, allowing expansion
> > options.  As well, assuming the design has any merit, I can see
> > creating one of these SBcs for each family (8080/Z80, 65XX, 68XX, and
> > maybe even
> > 16 bit options like TMS9900, 68K, etc.)
> 
> You know this projects?
> 
> https://en.wikipedia.org/wiki/N8VEM

Now :-

https://www.retrobrewcomputers.org/doku.php


Dave

Re: Ideas for a simple, but somewhat extendable computer bus

[alan--- via cctalk]

If you need simple arbitration, there is always this:

https://www.retrotronics.org/arbiter/

-Alan

On 2017-11-17 20:11, Jim Brain via cctalk wrote:

I'm currently working on a single board computer system, designing
from scratch partially as an education experience, and also as
something that might be of interest to others.

I've laid out the first version of the SBC, and I realize it would
cost nothing to add an edge connector on the PCB, allowing expansion
options.  As well, assuming the design has any merit, I can see
creating one of these SBcs for each family (8080/Z80, 65XX, 68XX, and
maybe even 16 bit options like TMS9900, 68K, etc.)

However, as the design is not *for* any purpose, and I've never
designed a bus that could be shared among multiple CPUs, I am
wondering what bus layout would satisfy the following criteria:

 * At least enough to support a traditional 8 bit CPU (A0-15,D0-7,
   RESET, READ/WRITE,CLOCK,INTERRUPTS) with potentially a few more
   address bits (A16-23)
 * Minimal number of bus signals to support multi-processors and
   peripheral cards, but not so few that usefulness is severely 
crippled

 * Easy to implement (minimize need for logic that serves to solely
   handle the bus)
 * (If 16 bit data bus is part of the design): Easy for 8 and 16 bit
   CPUs and peripherals to share the bus (Maybe this means 16 bit units
   need to be constrained to 8 bit, not sure)
 * Works out to a size that I can buy edge connectors cheaply (62 pin
   .100" connectors are looking like my cheap option at present)

I looked at home computer busses (Atari, Apple, Commodore, Tandy, TI)
for a bit of inspiration, but they all seem overly simplistic (not
horrible, but hate to just punt on the idea).  I also looked at the
ISA bus and the S-100 bus, but they are a bit overwhelming to me (I
can grok all the signals, but ensuring they are all responsive seems
like it will drive more logic be on the PCB jsut to handle the bus,
and I am trying to keep costs very minimal).

Thus,

Is there a bus (or a fraction of a bus standard) that I should
consider to accommodate the above?  Anyone else interested in this
idea and in a collaborative mood?

Jim

Re: Ideas for a simple, but somewhat extendable computer bus

[emanuel stiebler via cctalk]

On 2017-11-17 18:11, Jim Brain via cctalk wrote:
I'm currently working on a single board computer system, designing from 
scratch partially as an education experience, and also as something that 
might be of interest to others.


I've laid out the first version of the SBC, and I realize it would cost 
nothing to add an edge connector on the PCB, allowing expansion 
options.  As well, assuming the design has any merit, I can see creating 
one of these SBcs for each family (8080/Z80, 65XX, 68XX, and maybe even 
16 bit options like TMS9900, 68K, etc.)


You know this projects?

https://en.wikipedia.org/wiki/N8VEM

Re: Ideas for a simple, but somewhat extendable computer bus

[Chuck Guzis via cctalk]

On 11/17/2017 06:33 PM, ben via cctalk wrote:

> Say USB-version 101101100 :)

No, I'm serious--lowers parts count tremendously.  I run SPI at 40 MHz.

But for something simpler in a parallel bus there's always STD bus, or
STD-32.

--Chuck

Re: Ideas for a simple, but somewhat extendable computer bus

[allison via cctalk]

On 11/17/2017 08:11 PM, Jim Brain via cctalk wrote:
> I'm currently working on a single board computer system, designing
> from scratch partially as an education experience, and also as
> something that might be of interest to others.
>
> I've laid out the first version of the SBC, and I realize it would
> cost nothing to add an edge connector on the PCB, allowing expansion
> options.  As well, assuming the design has any merit, I can see
> creating one of these SBcs for each family (8080/Z80, 65XX, 68XX, and
> maybe even 16 bit options like TMS9900, 68K, etc.)
>
 A bus that can accommodate 8/16 and also IO mapped plus memory mapped
peripherals forces a
lot of bus logic or interface logic.  The Current winner that has had
all of those is S100-IEEE-696
and its messy.

The more you try to cram into it the more complex it must be, or the
interface from each SBC is so
constrained they can easily share memory or IO in their natural form
(ex: 16bitter reading 8 bit ram will be slow).

At a minimum make 8 and 16it exclusive or your bus interfacs have high
overhead.   Also take into account that not
all cpus mix well or play well in a multicpu mix.

> However, as the design is not *for* any purpose, and I've never
> designed a bus that could be shared among multiple CPUs, I am
> wondering what bus layout would satisfy the following criteria:
>
>  * At least enough to support a traditional 8 bit CPU (A0-15,D0-7,
>    RESET, READ/WRITE,CLOCK,INTERRUPTS) with potentially a few more
>    address bits (A16-23)
>  * Minimal number of bus signals to support multi-processors and
>    peripheral cards, but not so few that usefulness is severely crippled
>  
Mread, Mwrite, IOread IOwrite, Eread (early),  Ewrite (Early write)

Then you need a set of bus-request, bus-available signals.

And signals to indicate an 8 or 16 bit read or write (Bhi, Blow) or
byte/word
for IO and memory...

Interrupts each differs and few overlap.

Bottom line if your teaching multi-cpus make the bus as simple as
possible as you then
are not locked to explaining how a 8bitter lives on a 16bit bus or the
other way around.

> * Easy to implement (minimize need for logic that serves to solely
>    handle the bus)
More un-alike stuff on the bus the harder it gets.

>  * (If 16 bit data bus is part of the design): Easy for 8 and 16 bit
>    CPUs and peripherals to share the bus (Maybe this means 16 bit units
>    need to be constrained to 8 bit, not sure)

>  * Works out to a size that I can buy edge connectors cheaply (62 pin
>    .100" connectors are looking like my cheap option at present)
>

simple 16 data, 24 address likely 6 lines for basic control plus others
your up to 50+ lines and
you may want interleaved grounds and also doubled DC pins for current
capability and more
for multiple voltages.  is 62 enough?   Look at ISA-8 for an answer.

> I looked at home computer busses (Atari, Apple, Commodore, Tandy, TI)
> for a bit of inspiration, but they all seem overly simplistic (not
> horrible, but hate to just punt on the idea).  I also looked at the
> ISA bus and the S-100 bus, but they are a bit overwhelming to me (I
> can grok all the signals, but ensuring they are all responsive seems
> like it will drive more logic be on the PCB jsut to handle the bus,
> and I am trying to keep costs very minimal).
>

Easy limit the possible mixed set of CPUs. 

   in the 8bit realm that mix well are 8085, Z80, Z180, 8088.   The
other set would be the 6502/6800/6809 group.
  Mixing 6502 and z80 is messy or 6502 with 8088 more of same.

 Adding in the 16bit takes the need for bus translation and timing
between 8bit or 16 bit peripherals.

 Mixing 6500 and z80 are annoying as z80(and 8080, 8085,8088) do IO in
separate space from
memory there 6500/6800/6809 peripheral IO is in memory space.  Sure you
can force the issue with logic
or make the z80 do io in memory space for simple convenience but for
those cpus that is atypical.

The single fastest way to limit cost is limit the possible cpu flavors. 
for example ts fairly trivial to make
8085, 8088 and z80 present similar signals to a common bus.

Most of the machine mentioned were at best single cpu (Atari, Apple,
Commodore, Tandy, TI) and many were
not well executed.  FYI TI 9900 is both 16bit and serial as the LRU
interface is bit addressed serial and
very unique perpierals.

> Thus,
>
> Is there a bus (or a fraction of a bus standard) that I should
> consider to accommodate the above?  Anyone else interested in this
> idea and in a collaborative mood?
>

All depends.  IF your trying share peripherals and memory you end up
with S100 or S100 like.  If you trying to
talk to each other than maybe something like GPIB or SCSI (or a flavor
of those) may suit the need.  Or simple
network bus serial or parallel.  The latter can be few in wires but
imposes a protocal to talk from A to B
and may make putting memory (not mass storage) in it awkward.

I did this years ago with 8085/z80/8088 and that ended up sorta like 

Re: Ideas for a simple, but somewhat extendable computer bus

[Charles Anthony via cctalk]

On Fri, Nov 17, 2017 at 5:11 PM, Jim Brain via cctalk  wrote:

> I'm currently working on a single board computer system, designing from
> scratch partially as an education experience, and also as something that
> might be of interest to others.
>
>
I don't know how complex the logic is, but VME bus springs to mind:
https://en.wikipedia.org/wiki/VMEbus

96 pins
32 bit data
32 bit address
Has bus arbitration for multiple CPUs
Existing hardware


>
>
>

Re: Ideas for a simple, but somewhat extendable computer bus

[Toby Thain via cctalk]

On 2017-11-17 8:55 PM, Jon Elson via cctalk wrote:
> On 11/17/2017 07:34 PM, Jim Brain via cctalk wrote:
>> On 11/17/2017 7:25 PM, Paul Koning wrote:
>>>
>>> One key question is whether it should be asynchronous, as the Unibus
>>> is, or synchronous.
>> I thought synchronous would make for a smaller/simpler design, but
>> could be wrong.
>>> A synchronous version of the Unibus would be quite easy; all the
>>> ...
>> It does not have to be fast.  I rather thought, "what is the simplest
>> multi-cpu shared bus that could be easily understood by folks and
>> allow them to focus on multi-processing education, not bus understanding"
>>
>> Jim
>>
>>
> You might also take a look at Multibus and VME, if you just want to see
> how others did it.

For a nice survey of buses, including those two: "Digital Bus Handbook",
Joseph di Giacomo.

https://dl.acm.org/citation.cfm?id=83494

> 
> Jon
> 

Re: Ideas for a simple, but somewhat extendable computer bus

[ben via cctalk]

On 11/17/2017 6:59 PM, Chuck Guzis via cctalk wrote:

On 11/17/2017 05:34 PM, Jim Brain via cctalk wrote:


It does not have to be fast.  I rather thought, "what is the simplest
multi-cpu shared bus that could be easily understood by folks and allow
them to focus on multi-processing education, not bus understanding"


How about a serial bus?  Physically simple and not too awful logically
today.  Say, I2C or SPI...

--Chuck


Say USB-version 101101100 :)

I would say use a 68000 if your still can get them,
but run with a 6800 style clock. The master CPU and
shared memory on the high phase of the clock. The
slave CPU's on the low clock PHASE (clocked by a inverted clock).
This will give you multi-processing with a bit more than
64KB.
Ben.

Re: Ideas for a simple, but somewhat extendable computer bus

[Chuck Guzis via cctalk]

On 11/17/2017 05:34 PM, Jim Brain via cctalk wrote:

> It does not have to be fast.  I rather thought, "what is the simplest
> multi-cpu shared bus that could be easily understood by folks and allow
> them to focus on multi-processing education, not bus understanding"

How about a serial bus?  Physically simple and not too awful logically
today.  Say, I2C or SPI...

--Chuck

Re: Ideas for a simple, but somewhat extendable computer bus

[Jon Elson via cctalk]

On 11/17/2017 07:34 PM, Jim Brain via cctalk wrote:

On 11/17/2017 7:25 PM, Paul Koning wrote:


One key question is whether it should be asynchronous, as 
the Unibus is, or synchronous.
I thought synchronous would make for a smaller/simpler 
design, but could be wrong.
A synchronous version of the Unibus would be quite easy; 
all the funny one-shot delays would disappear and actions 
would simply be taken on the clock edge (rising or 
falling, pick one).  Just make the clock period 
comfortably longer than the worst case propagation delay 
and you're in business.
Given the CPU landscape, I am thinking < 10MHz, which 
would seem to satisfy the criteria.


I'm assuming it doesn't need to be all that fast.  If you 
clock period > prop delay is an issue, things get vastly 
more complicated.  If so, you might want to stick with 
something that's already been sorted out, like PCIe.
It does not have to be fast.  I rather thought, "what is 
the simplest multi-cpu shared bus that could be easily 
understood by folks and allow them to focus on 
multi-processing education, not bus understanding"


Jim


You might also take a look at Multibus and VME, if you just 
want to see how others did it.


Jon

Re: Ideas for a simple, but somewhat extendable computer bus

[william degnan via cctalk]

On Nov 17, 2017 8:34 PM, "Jim Brain via cctalk" 
wrote:
>
> On 11/17/2017 7:25 PM, Paul Koning wrote:
>>
>>
>> One key question is whether it should be asynchronous, as the Unibus is,
or synchronous.
>
> I thought synchronous would make for a smaller/simpler design, but could
be wrong.
>
>> A synchronous version of the Unibus would be quite easy; all the funny
one-shot delays would disappear and actions would simply be taken on the
clock edge (rising or falling, pick one).  Just make the clock period
comfortably longer than the worst case propagation delay and you're in
business.
>
> Given the CPU landscape, I am thinking < 10MHz, which would seem to
satisfy the criteria.
>
>>
>> I'm assuming it doesn't need to be all that fast.  If you clock period >
prop delay is an issue, things get vastly more complicated.  If so, you
might want to stick with something that's already been sorted out, like
PCIe.
>
> It does not have to be fast.  I rather thought, "what is the simplest
multi-cpu shared bus that could be easily understood by folks and allow
them to focus on multi-processing education, not bus understanding"
>
> Jim
>

Not simpler but there were S100 systems with those cpus, except maybe the
TI 16.

Bill Degnan
twitter: billdeg
vintagecomputer.net

Re: Ideas for a simple, but somewhat extendable computer bus

[Jim Brain via cctalk]

On 11/17/2017 7:25 PM, Paul Koning wrote:


One key question is whether it should be asynchronous, as the Unibus is, or 
synchronous.
I thought synchronous would make for a smaller/simpler design, but could 
be wrong.

A synchronous version of the Unibus would be quite easy; all the funny one-shot 
delays would disappear and actions would simply be taken on the clock edge 
(rising or falling, pick one).  Just make the clock period comfortably longer 
than the worst case propagation delay and you're in business.
Given the CPU landscape, I am thinking < 10MHz, which would seem to 
satisfy the criteria.


I'm assuming it doesn't need to be all that fast.  If you clock period > prop 
delay is an issue, things get vastly more complicated.  If so, you might want to 
stick with something that's already been sorted out, like PCIe.
It does not have to be fast.  I rather thought, "what is the simplest 
multi-cpu shared bus that could be easily understood by folks and allow 
them to focus on multi-processing education, not bus understanding"


Jim

Re: Ideas for a simple, but somewhat extendable computer bus

[Paul Koning via cctalk]

> On Nov 17, 2017, at 8:11 PM, Jim Brain via cctalk  
> wrote:
> 
> I'm currently working on a single board computer system, designing from 
> scratch partially as an education experience, and also as something that 
> might be of interest to others.
> 
> I've laid out the first version of the SBC, and I realize it would cost 
> nothing to add an edge connector on the PCB, allowing expansion options.  As 
> well, assuming the design has any merit, I can see creating one of these SBcs 
> for each family (8080/Z80, 65XX, 68XX, and maybe even 16 bit options like 
> TMS9900, 68K, etc.)
> 
> However, as the design is not *for* any purpose, and I've never designed a 
> bus that could be shared among multiple CPUs, I am wondering what bus layout 
> would satisfy the following criteria: ...

You might start with the Unibus and make some small tweaks.  If you think of 
each of the several CPUs as a DMA device, which asks for the bus and gets the 
grant from a central arbiter, you've got your MP bus right there.  Strip out 
some unneeded stuff, like multiple interrupt levels (if you want).

One key question is whether it should be asynchronous, as the Unibus is, or 
synchronous.  If you put a central clock on the bus also (presumably from the 
arbiter since there's one of those) everything else gets a whole lot simpler.  
There are good reasons for the Unibus to be async, but if you can do sync 
that's a much better choice.

A synchronous version of the Unibus would be quite easy; all the funny one-shot 
delays would disappear and actions would simply be taken on the clock edge 
(rising or falling, pick one).  Just make the clock period comfortably longer 
than the worst case propagation delay and you're in business.

I'm assuming it doesn't need to be all that fast.  If you clock period > prop 
delay is an issue, things get vastly more complicated.  If so, you might want 
to stick with something that's already been sorted out, like PCIe.

paul

Ideas for a simple, but somewhat extendable computer bus

[Jim Brain via cctalk]

I'm currently working on a single board computer system, designing from 
scratch partially as an education experience, and also as something that 
might be of interest to others.


I've laid out the first version of the SBC, and I realize it would cost 
nothing to add an edge connector on the PCB, allowing expansion 
options.  As well, assuming the design has any merit, I can see creating 
one of these SBcs for each family (8080/Z80, 65XX, 68XX, and maybe even 
16 bit options like TMS9900, 68K, etc.)


However, as the design is not *for* any purpose, and I've never designed 
a bus that could be shared among multiple CPUs, I am wondering what bus 
layout would satisfy the following criteria:


 * At least enough to support a traditional 8 bit CPU (A0-15,D0-7,
   RESET, READ/WRITE,CLOCK,INTERRUPTS) with potentially a few more
   address bits (A16-23)
 * Minimal number of bus signals to support multi-processors and
   peripheral cards, but not so few that usefulness is severely crippled
 * Easy to implement (minimize need for logic that serves to solely
   handle the bus)
 * (If 16 bit data bus is part of the design): Easy for 8 and 16 bit
   CPUs and peripherals to share the bus (Maybe this means 16 bit units
   need to be constrained to 8 bit, not sure)
 * Works out to a size that I can buy edge connectors cheaply (62 pin
   .100" connectors are looking like my cheap option at present)

I looked at home computer busses (Atari, Apple, Commodore, Tandy, TI) 
for a bit of inspiration, but they all seem overly simplistic (not 
horrible, but hate to just punt on the idea).  I also looked at the ISA 
bus and the S-100 bus, but they are a bit overwhelming to me (I can grok 
all the signals, but ensuring they are all responsive seems like it will 
drive more logic be on the PCB jsut to handle the bus, and I am trying 
to keep costs very minimal).


Thus,

Is there a bus (or a fraction of a bus standard) that I should consider 
to accommodate the above?  Anyone else interested in this idea and in a 
collaborative mood?


Jim

--
Jim Brain
br...@jbrain.com
www.jbrain.com