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


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.


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

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