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:
- Use at least 24 to 32 address lines on the connector.
- Unify the I/O and memory address spaces.
- Use geographical addressing. Drive REGSEL# for a particular slot when addressing that slot's register space.
- Make register space at least 64KB in size per slot.
- Get rid of ATNRQ# lines for interrupts, and replace them with IRQ#, IRQ_IN#, and IRQ_OUT#, the latter two providing a priority chain of arbitrary length.
- Get rid of ATNRQ# lines for DMA, and just replace them with a generic bus mastering protocol, DMA_REQ#, DMA_ACK_IN#, DMA_ACK_OUT# analogous to IRQs.
- Swap in sets of 40-pin SIP connectors in place of DIN connectors. A pair gives you 80 usable pins which are far cheaper, more reliable, mechanically stable, and far easier to solder and maintain.
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.