17 Nov
2017
17 Nov
'17
5:11 p.m.
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
brain at jbrain.com
www.jbrain.com
17 Nov
17 Nov
5:25 p.m.
On Nov 17, 2017, at 8:11 PM, Jim Brain via cctalk
<cctalk at classiccmp.org> 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
5:34 p.m.
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
5:52 p.m.
On Nov 17, 2017 8:34 PM, "Jim Brain via cctalk" <cctalk at
classiccmp.org>
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
5:55 p.m.
On 11/17/2017 07:34 PM, Jim Brain via cctalk wrote:
On 11/17/2017 7:25 PM, Paul Koning wrote:
You might also take a look at Multibus and VME, if you just
want to see how others did it.
Jon
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
6:42 p.m.
On 2017-11-17 8:55 PM, Jon Elson via cctalk wrote:
On 11/17/2017 07:34 PM, Jim Brain via cctalk wrote:
For a nice survey of buses, including those two: "Digital Bus Handbook",
Joseph di Giacomo.
https://dl.acm.org/citation.cfm?id=83494
On 11/17/2017 7:25 PM, Paul Koning wrote:
You might also take a look at Multibus and VME, if you just want to see
how others did it.
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
Jon
5:59 p.m.
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
6:33 p.m.
On 11/17/2017 6:59 PM, Chuck Guzis via cctalk wrote:
On 11/17/2017 05:34 PM, Jim Brain via cctalk wrote:
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.
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 
18 Nov
18 Nov
4:57 p.m.
On Fri, Nov 17, 2017, ben via cctalk wrote:
On 11/17/2017 6:59 PM, Chuck Guzis via cctalk wrote:
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.)
On 11/17/2017 05:34 PM, Jim Brain via cctalk
wrote:
Say USB-version 101101100 :) 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
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
19 Nov
19 Nov
2:28 p.m.
On 11/18/2017 5:57 PM, Eric Christopherson via cctalk wrote:
On Fri, Nov 17, 2017, ben via cctalk wrote:
As FOGHORN LEGHORN once said.
?That?s a joke, I say that?s a joke son?
On 11/17/2017 6:59 PM, Chuck Guzis via cctalk
wrote:
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.) On 11/17/2017 05:34 PM, Jim Brain via cctalk
wrote:
Say USB-version 101101100 :) 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 
17 Nov
17 Nov
7:01 p.m.
On Fri, Nov 17, 2017 at 5:11 PM, Jim Brain via cctalk <cctalk at classiccmp.org
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
7:08 p.m.
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 a
simplified bus not unlike ISA-8 (PC xt)
with lines to signal bus master request and ack, plus a interrupt system
tht could be shared (daisy chain or not).
Later I added 8749 cpus as smart IO and found it worked if I created a
false address space for the limited 8749
(8049 can only address 4K rom space and 256bytes ram or IO space) but
the timing and other aspects worked ok.
Busses like PDP-11 (Unibus or Qbus) are DEC unique and have high logic
overhead to talk or even listen.
Also PDP11 had memory mapped IO in a reserved space (BBS7 or any address
with 15/14/13=1) it was also
unmapped space when using MMU.?? S100 was primitive and even 696 didn't
make it clean(crosstalk and
ringing issues) though it you used different connector and layout it can
be a model as it addresses
everything but at a price.? Multibus can be 8 or 16 bit but is skewed to
Intel or intel like (z80) cpus and
not unlike ISA-8/16 save for cleaner interrupt implementation (PCs broke
that).
I leave out system specific buses like Exorbus(6800 68000), STDbus(z80),
and a few others unique to a CPU.
Generally after ISA bus (PC XT and AT) PC buses are CPU specific and unique.
Bottom line if ISA-8 is to much then your conditions are contradictory
as anything more is going to
make that look simple.?
Allison
Jim
11:46 p.m.
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
18 Nov
18 Nov
12:59 a.m.
-----Original Message-----
From: cctalk [mailto:cctalk-bounces at classiccmp.org] On Behalf Of emanuel
stiebler via cctalk
Sent: 18 November 2017 07:47
To: Jim Brain <brain at jbrain.com>; General Discussion: On-Topic and Off-
Topic Posts <cctalk at classiccmp.org>
Subject: Re: Ideas for a simple, but somewhat extendable computer bus
On 2017-11-17 18:11, Jim Brain via cctalk wrote:
Now :-
https://www.retrobrewcomputers.org/doku.php
Dave
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
9:20 a.m.
On 11/18/2017 1:46 AM, emanuel stiebler wrote:
On 2017-11-17 18:11, Jim Brain via cctalk wrote:
I've followed the N8VEM project for many years, but I had forgotten
about looking at their bus design.? Thanks.
--
Jim Brain
brain at jbrain.com
www.jbrain.com
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
10:48 p.m.
On 11/18/2017 1:46 AM, emanuel stiebler wrote:
On 2017-11-17 18:11, Jim Brain via cctalk 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?
Jim
--
Jim Brain
brain at jbrain.com
www.jbrain.com
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
19 Nov
19 Nov
7:08 a.m.
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 ...
11:56 a.m.
On 11/19/2017 9:08 AM, emanuel stiebler wrote:
On 2017-11-18 23:48, Jim Brain wrote:
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
brain at jbrain.com
www.jbrain.com
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 ... 
20 Nov
20 Nov
3:20 a.m.
Am 19.11.2017 um 16:08 schrieb emanuel stiebler via cctalk:
On 2017-11-18 23:48, Jim Brain wrote:
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
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 ... 
19 Nov
19 Nov
12:43 p.m.
On Sat, Nov 18, 2017 at 10:48 PM, Jim Brain via cctalk <
cctalk at 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
1:16 p.m.
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:backp…
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
brain at jbrain.com
www.jbrain.com
7:19 p.m.
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 at classiccmp.org> wrote:
That asumes z80 and a default bus master...? What if the CPU? is 6502
or
still other.
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.
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
7:51 p.m.
On Nov 19, 2017 7:18 PM, "allison via cctalk" <cctalk at classiccmp.org>
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.
20 Nov
20 Nov
4:49 a.m.
On 11/19/2017 10:51 PM, Eric Smith wrote:
On Nov 19, 2017 7:18 PM, "allison via
cctalk" <cctalk at classiccmp.org
<mailto:cctalk at classiccmp.org>> 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
18 Nov
18 Nov
12:04 a.m.
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
6:54 a.m.
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
2371
days inactive
2373
days old
26 comments
16 participants
participants (16)
-
alan＠alanlee.org -
allisonportable＠gmail.com -
bfranchuk＠jetnet.ab.ca -
billdegnan＠gmail.com -
brain＠jbrain.com -
cclist＠sydex.com -
charles.unix.pro＠gmail.com -
dave.g4ugm＠gmail.com -
echristopherson＠gmail.com -
elson＠pico-systems.com -
emu＠e-bbes.com -
holger.veit＠iais.fraunhofer.de -
jules.richardson99＠gmail.com -
paulkoning＠comcast.net -
spacewar＠gmail.com -
toby＠telegraphics.com.au