Close

Why I Am and Am Not a Fan of STEbus.

A project log for Backbone Bus

Backbone is my proposal for an off-chip, Wishbone-inspired backplane interconnect that supports multiple bus masters.

samuel-a-falvo-iiSamuel A. Falvo II 11/05/2021 at 19:2212 Comments

First, the cons, which are deal-breakers for me.

1. 20 Address Bits.  This might seem like an awful lot of address space; I mean, you have 1MiB of memory space with STEbus.  However, with so few address bits, this means you cannot practically add any card that exposes a memory space about that size.  Consider, a video card with a 24-bit 800x600 resolution will require close to 2MB alone, forcing the processor to switch between memory banks when updating the frame buffer.  For good performance and minimizing visual tear, this just plain sucks!  Also, consider the case of a SCSI or ATA controller, wanting to DMA data from a harddrive into memory.  The processor will be able to address a lot more memory than the STEbus can, so what is the value of having a bus master on the STEbus if you can't address the processor's memory?  The only thing that makes sense is a separate CPU card.

2. 12 Address Bits.  When addressing I/O, you're limited to 4KiB of space for all 20 cards possible on the backplane.  For processors like the 8086 and its subsequent progeny, this is a serious limitation, as a number of peripherals first designed for the ISA bus readily use, or even hard-wire, 16-bit I/O addresses.

3. No plug-and-play capabilities what-so-ever.  You're obliged to select a board's I/O and memory base addresses via jumpers.  You're obliged to select interrupts and DMA requests via jumpers.  There are jumpers literally everywhere in this system.  Compared to the Apple IIe bus, the STEbus offers a sharp regression in user experience and functionality.

4. DIN 41612 connectors.  If all you care about is 10 insertions before they break,
then this connector is fine.  You can pick them up for relatively cheap on Digikey.
However, while building my own video/FPGA development card for the RC2014,
I must have removed and inserted cards well in excess of this figure.  So, if you want a DIN connector that can handle more than this number of insertions, you need to start shelling out upwards of $7 per connector.  That's $7 for each connector on your backplane, plus $7 for each mating connector on your expansion cards.  This quickly gets expensive.  My RC2014 has six cards in it.  If DIN connectors were used, that'd total $14*6=$84, just in connectors used.  That's almost 1/3rd the cost of the computer!  There are significantly cheaper options.

5. Only three bus masters throughout the whole system.  You get the "default" bus master, plus no more than two other bus masters across the whole backplane, even if your backplane has the full allotment of 20 slots!

To fix these deficiencies, I would do the following:

STEbus does have some pros which I really like, though:

1. Fully asynchronous.  The master drives ADRSTB#.  Then it drives DATSTB#.  Then it waits for the card to assert DATACK#.  Then, the master negates DATSTB#, which triggers the card to release DATACK#.  (Concurrently and unrelated, ADRSTB# may also be negated; or it may not, in the case of a read-modify-write cycle.)  Only then can the next cycle begin.  Using chips like the 74HCT688, xCT138, and xCT74 for a timing chain, you can readily generate the acknowledgement.  The circuit is literally no worse than DTACK# generation on a 68000.

The SYSCLK (16MHz) clock provided on the bus is intended only as a timing reference for those xCT74 DFFs, and even then, only if you choose to use it.  It otherwise has no other influence on the operation of the bus.

2. Surprisingly Fast.  If you look at the timing diagrams and parameters for STEbus, you'll see that this bus can achieve a theoretical maximum data rate of about 28MB/s.  That's insanely fast!  Unfortunately, that's also impossible in the real world; which is to say, anything outside of a NIST laboratory.  However, more practical designs will be able to achieve closer to 4MB/s to 6MB/s, which is still very impressive, considering that Zorro-II can push at most 3.5MB/s.

These are absolutely features to keep in any expansion bus technology chosen for the ForthBox, I think.

The only thing is, because of how asynchronous interfaces work, everything behind the interface must be considered "slow."  So, the ForthBox will probably end up having a "slow RAM" and "fast RAM" dichotomy, just as the Apple IIgs did, and the Commodore Amiga (vis-a-vis. "chip RAM" instead of "slow RAM").  Basically, fast RAM is local to its own CPU and inaccessible to other CPUs or I/O devices, almost like a cache memory, while slow RAM is global, seen by everything else in the system.

The end result of such a design would more closely resemble NuBus-on-a-Budget, versus STEbus's VME-on-a-Budget design approach.

ForthBox?

Oh, what is a ForthBox?  I guess you'll need to wait and see.

And, will I use such a bus for the ForthBox?  Not entirely sure, to be honest; but, it is on my short-list of considerations.

Discussions

Keith wrote 12/31/2022 at 02:43 point

@Samuel A. Falvo II No, I feel that STEbus was designed for modest industrial control systems using the affordable technology of 1982. It is a good fit for hobbyists wanting to make their own Z80/6809/6502 system today. It doesn't exclude plug-and-play, but you'd have to specify the scheme. 
It certainly isn't up to supporting high-bandwidth high-resolution workstation graphics, or a fast FPGA-to-FPGA bus, I agree. I wondered how to get round that and thought the solution would be to use the bus to pass messages to an intelligent graphics board. The SGT1 and SG84 boards do that, with a 6803 and 68000 processor respectively. The designers of the Raspberry Pi processor realised the bus bottleneck and put everything on a single chip. I do find graphics interesting but realised (with some dismay) that modern PCs have vast libraries of graphics code. There are hundreds of person-years of coding just in the R-Pi chip alone.
So I now think about making my projects produce graphics in the form of html or SVG. That way I can have a gadget doing a job and then squirting html or SVG over ethernet to the internet. Seems easier than designing hardware and software to drive VGA (obsolete) or HDMI (GHz speed).
Regarding connectors, RC2014 systems use so many because they often put the ROM and RAM on seperate cards and the cards are not very big. With a Eurocard, you can get a decent system on far fewer cards. So less expense.
With just a few cards, one doesn't need backplanes at all. The PC104 bus just had cards stacking over each other. The PC104 style connector pins are the same thickness as RC2014 connector pins, and should be strong enough for you. The 2x32-pin connector is commonly available, and not too expensive. A pair of those would give you the number of pins you want, perhaps.
Do keep up your Hackaday pages, they are interesting.

  Are you sure? yes | no

Samuel A. Falvo II wrote 01/18/2024 at 21:37 point

OK! OK!  You've convinced me.  :-)  I'll use the STEbus as the I/O channel for an up-coming project I'm working on.  BUT!!  I'm going to be using DIL connectors, and not the DIN connectors, mainly because of cost.  But all the signals will be there, and making an adapter should just be a matter of routing signals in a DIL-to-DIN adapter.

  Are you sure? yes | no

Keith wrote 01/18/2024 at 22:20 point

As technology advanced, people needed fewer boards in practice so the PC104 standard reduced the signal fanout requirement (and maximum number of boards). If you reduce the number of boards then the bus length is shortened and the impedance is less critical and you may be able to get away with a stacking system. The 64-way PC104 connectors (e.g. Harwin part M20-6103245) have exactly the number of pins required, and will very conveniently fit in the signal breakout holes of certain Eurocard prototyping boards. I'd recommend the Roth Electronic RE201-LFDS board.
Using this board means you won't have to make a DIL-to-DIN adapter. Just fit the DIN connector if you need to plug into a backplane.

NB the pins should stick upwards as is the convention for pin headers. Your bus master could then have header-pins only on the 'topside', and a bus terminator have female-only connector on the 'underside'. With very short bus lengths, you could build a terminator into the bus master if you allow it to be disabled when fitting into a backplane that has built-in terminators.

  Are you sure? yes | no

Ralphw wrote 03/18/2022 at 15:33 point

Perhaps a "dual-connector" approach would work, 2x50 headers for the "low-cost" version of the connector.
Use DIN41612 for STE32-A and specify the pins on row 2 as needed

Use 100 "header pins" for the other option,  2x50 pins.

If someone wants to support both connectors (either/or), they can design the PCB layout that way.

  Are you sure? yes | no

Ralphw wrote 03/11/2022 at 14:51 point

I found out about the STEbus standard when I was researching the N8VEM system, which use the ECB bus format (same connector, different signals)

I'm interested in enhancing STE bus, and the "B row" of pins might be usable for additional signals.
That would make it impossible to use the P2 connector in a full-blown 6U VMEbus system,  but I'm not sure that's a huge consideration.

I want to give my 1802, Z80, 6809, and 65c02 processors a home, but not forclose the possibility of putting something faster in there to run a proper Unix system with demand paging, etc.  I'd be looking to the bus to share peripheral cards, like VGA, sound, networking and other cards I hope to only have to build one or two of.

I would like to see ideas implemented for expanding the STEbus to be 32-bit address capable, if possible.

Going from 20-32 bits would use 12 pins on the "b" row, and upping data path width from 8 to 16 would take 8 more, leaving 12 for additional purposes.

I hope other use cases will be considered.

Preserving the ability for legacy STE cards to continue to work might be important, and being able to build a more capable music synth on an full-sized Eurocard would be nice.

- Ralphw

  Are you sure? yes | no

Samuel A. Falvo II wrote 03/13/2022 at 16:48 point

I'm in a similar situation.  My current desires are to support the W65C816 processor, which  uses an 8-bit data bus and a 24-bit address bus, and a home-made RISC-V core that I made, which has a 64-bit data and address bus.  I know I won't be able to fit the full 64-bit data path on a single connector (even with multiplexing), so a reasonable compromise is required.

I really like the idea behind STE bus.  I think it is a great foundation to expand from.  But, between the expense of the DIN connectors and its limited address space, I can't justify using it as-is.  It seriously needs a cost-reduced version.

  Are you sure? yes | no

Keith wrote 12/31/2022 at 01:19 point

65816 on a 10x16 cm Eurocard, done in 1986:
https://hackaday.io/project/168391-vmebus-68008-or-65816-cpu

  Are you sure? yes | no

Samuel A. Falvo II wrote 06/30/2022 at 15:24 point

The easiest way to update STEbus to 32-bit would be to have a separate 1MB and 4GB address space.  If a CPU attempts to work with resources in the 1MB address space, it will use the existing set of ADRSTB/DATSTB handshakes.  If accessing data in the 4GB address space, a separate set of ADRSTB32/DATSTB32 handshakes would be used.  That way, legacy cards that don't know how to speak the 32-bit protocol would never react to what is happening on the bus, and vice versa.

  Are you sure? yes | no

Keith wrote 12/31/2022 at 01:24 point

A 32-bit version of STEbus is VMEbus.

  Are you sure? yes | no

Samuel A. Falvo II wrote 12/31/2022 at 01:35 point

@Keith Don't worry.  I no longer have any plans to use STE, VME, or any other kind of parallel bus going forward except for RC2014, and even then, only for those precise applications that require it.

  Are you sure? yes | no

Keith wrote 12/31/2022 at 01:13 point

@Ralphw Do not 'enhance' STEbus by modifying it. The whole point of a nailing down a standard is to stop people making incompatible boards.
If you want or need a bus that supports 16 or 32-bit data and many megabytes of memory space, use the VME bus.
The VME bus existed before STE bus. But people did not buy VME for many industrial control systems because it was just too damn expensive. Most control systems didn't need any more power than a simple 8-bit micro like the Z80, 6809, or 6502. Most I/O peripherals had an 8-bit bus like parallel or serial I/O or SCSI chips.
There is an STEbus VGA board, but a Z80, 6809 or 6502 is going to struggle to do bit-mapped graphics fast enough, the bottleneck won't be the bus width.
I've got an STEbus 80486 board, and the PC chipset has a VGA controller. It uses the on-board bus (>8 bits!) and so graphics run 7 times faster than the separate VGA controller board.

  Are you sure? yes | no

Samuel A. Falvo II wrote 12/31/2022 at 01:41 point

I'm not sure if you've been keeping score, but the whole point of my speculating about taking and adopting STEbus to my own needs is precisely motivated because STEbus *itself* is too expensive for me.  The DIN connectors are hard to come by, and when you find good quality connectors, they're often in the $7+ range.  That's just too much for a connector.  Compared to RC2014's 40-pin SIL or 80-pin DIL strips, which are just as reliable, they're about $6 too expensive for the job.

Unfortunately, it seems like I've been fighting an uphill battle the whole time I've tried to explore this topic.  You have been steadfast and adament that STE would fit my requirements precisely as-is, when I've repeatedly documented otherwise.  Your replies have been curt, with zero attempt at making sure you understand my particular issues first.

As a result of this treatment, I'll be closing all of my projects here and my account as a whole some time in 2023, once I get my own hosting arrangements made.  There'll be no further discussion from about polluting STEbus purity for a purely personal project going forward.  I promise.

  Are you sure? yes | no