19 Nov
2017
19 Nov
'17
8:11 p.m.
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
19 Nov
19 Nov
9:54 p.m.
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
10:52 p.m.
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 
20 Nov
20 Nov
5:40 a.m.
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
10:18 a.m.
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
11:37 a.m.
On 11/20/2017 01:18 PM, Chuck Guzis via cctalk wrote:
On 11/20/2017 05:40 AM, allison via cctalk wrote:
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.
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.
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
12:20 p.m.
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
1:36 p.m.
On Mon, Nov 20, 2017 at 5:40 AM, allison via cctalk <cctalk at classiccmp.org>
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
7:41 a.m.
On Nov 19, 2017, at 11:54 PM, Chuck Guzis via cctalk <cctalk at classiccmp.org>
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?
22 Nov
22 Nov
1:11 p.m.
On 11/20/2017 8:41 AM, Tapley, Mark via cctalk wrote:
On Nov 19, 2017, at 11:54 PM, Chuck Guzis via cctalk
<cctalk at classiccmp.org> wrote:
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. :)
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?
2362
days inactive
2364
days old
9 comments
7 participants
participants (7)
-
alan＠alanlee.org -
allisonportable＠gmail.com -
bfranchuk＠jetnet.ab.ca -
cclist＠sydex.com -
charles.unix.pro＠gmail.com -
mtapley＠swri.edu -
seefriek＠gmail.com