-
Side quest
06/08/2026 at 13:36 • 0 commentsFinally getting back to the project. I decided I want to play around with different circuits for the bus master, etc. but didn't especially want to use breadboards or spin a new board every couple of days. I figured I'd start working it out on an FPGA. That gave me an idea for a separate but related project. A compact and modern system for retro style computers that still captures the essentials.
---------- more ----------The idea is to have some generic FPGA boards that plug into a backplane using cheap, standard connectors but still using the STEbus layout so it's relatively easy to build an adapter or re-implement on a real STEbus. There will be one (initially) or more FPGA boards with external connectors or a proto area (space permitting) with access to some of the FPGA outputs. Most of the GPIOs would function as STEbus lines. A couple of obvious choices for physical connectors would be SODIMM or M.2. I opted for M.2 because of the size.
I did a quick mapping of the various bus lines to an M.2 key M. I tried to set some of the power pins such that accidental insertion into a real M.2 socket wouldn't blow things up then mapped the remaining lines, grouping them by similar function.
I decided to play around with some GenAI to do an initial signal integrity check so I fed the pinout to GPT 5.4. It seemed to do a decent job, making a couple of suggested changes which at first glance seemed reasonable. Given STEbus uses a relatively low clock rate I probably won't run any openEMS simulations and just spin the boards.
Conversation Title: Evaluate M.2 Pinout for Signal Integrity and Current
Agent: ONEchat
[06/05/2026 20:24:39 +00:00] Trevor Clarke:
Evaluate the following pinout for possible signal integrity issues. Estimate the maximum current for each of the power lines. The physical connection is an M keyed M.2 socket. This is a custom, non-standard use of the M.2 connector. SYSCLK is a fixed 16MHz clock. All other lines are typically much lower than this and will never exceed it.Socket 3 Key M
74 TRST TMS 75
72 TCK GND 73
70 TDI TDO 71
68 3V3 GND 69
SYSRST 67
58 3v3 GND 57
56 3v3 GND 55
54 SYSCLK GND 53
52 A19 GND 51
50 A17 A18 49
48 A15 A16 47
46 A13 A14 45
44 A11 A12 43
42 GND A10 41
40 A9 A8 39
38 A7 A6 37
36 A5 A4 35
34 A3 GND 33
32 A1 A2 31
30 ADRSTB A0 29
28 DATCK GND 27
26 DATSTB D7 25
24 D6 D5 23
22 D4 D3 21
20 D2 D1 19
18 D0 GND 17
16 ATNRQ6 ATNRQ7 15
14 ATNRQ4 ATNRQ5 13
12 ATNRQ2 ATNRQ3 11
10 ATNRQ0 ATNRQ1 9
8 BUSAK0 BUSAK1 7
6 BUSRQ0 BUSRQ1 5
4 CM2 TRFERR 3
2 CM0 CM1 1Response:
## Plan1. Assess the pinout for signal-integrity risks based on adjacency, return paths, and the 16 MHz max clock.
2. Estimate current capability of the 3.3 V pins from typical M.2 connector/contact ratings rather than SSD-system power budgets.
3. Summarize practical layout/routing recommendations and the likely safe current envelope.
## PlanI’ll assess three things: the connector’s likely bandwidth margin, the pin-field layout for return-path/crosstalk risk, and the current limit of the 3.3 V pins.[doc1][doc2]
## Assumptions
I am assuming your stated operating condition is a direct M-keyed M.2 card/socket interconnect, with SYSCLK fixed at 16 MHz and all other signals at or below that rate. I am also assuming these are single-ended logic signals rather than controlled-impedance differential pairs.
## Bottom line
This pinout is likely workable at 16 MHz, because M-key M.2 connectors are commonly sold for PCIe Gen4/Gen5 service and use a 67-contact, 0.5 mm-pitch interface, so the connector itself has far more bandwidth than your stated clock rate.[doc1][doc2] The main signal-integrity risks are therefore not “M.2 is too fast/too small,” but rather single-ended bus crosstalk, shared return paths, simultaneous-switching noise, and any very fast logic edge rates you may have on the address/data/control lines.[doc1][doc2]
## Signal-integrity review
### What looks good
Your two obvious clocks, SYSCLK and DATCK, each have an adjacent ground in the pin map you posted, which is exactly what you want for a clean local return path and reduced crosstalk. This is a strong feature of the assignment.
The supply pins are also distributed rather than concentrated at only one end, which helps reduce shared impedance in the power feed.
Because the connector family is designed for much higher-speed protocols than 16 MHz, the contact geometry itself is unlikely to be the limiting factor here.[doc1][doc2]
### Main concerns
The address and data buses are mostly arranged as signal-next-to-signal rather than signal-next-to-ground. That means the dominant risk is capacitive/inductive coupling between adjacent lines, especially where multiple address or data bits switch at the same time.
The ground pins are present, but they are not densely interleaved through the entire wide bus. That can force return currents to spread through the connector and nearby planes instead of staying tightly local to each signal, which increases crosstalk and ground bounce.
If your drivers have fast edges, the electrical behavior will be set more by rise/fall time than by the 16 MHz repetition rate. In practice, that means a “slow” 16 MHz clock can still ring or overshoot if the launch edge is sharp and the trace plus connector path is electrically long enough.
JTAG is probably fine, since it is usually low activity, and TCK has a nearby ground in your map. Still, TMS/TDI/TDO are not fully shielded, so I would not route them with unnecessarily aggressive edge rates.
### Highest-risk signal groups
1. **Address bus A0-A19**
Large single-ended bus, many adjacent signal neighbors, not much ground interleaving.2. **Data bus D0-D7 plus DATSTB/DATCK**
DATCK placement is good, but the surrounding data lines can still inject crosstalk into one another if the source edges are fast.3. **Handshake/request groups**
ATNRQx, BUSRQx, BUSAKx, CMx, and TRFERR are probably low rate, but simultaneous edges in clusters can still create local ground movement.## Practical SI recommendations
Keep all connector-associated routing over a continuous solid reference plane on both boards. A split plane under this connector will hurt you more than the connector choice itself.
Add source termination on the fastest and most timing-sensitive outputs first, especially SYSCLK, DATCK, and possibly TCK. In practice, that usually means a small series resistor near the driver, tuned empirically.
If possible, use the weakest output drive strength and slowest acceptable slew rate in the transmitter devices. That usually gives a bigger benefit than rearranging a few low-speed pins.
If you revise the pinout later, the biggest improvement would be to interleave more grounds inside the wide address/data fields, not because 16 MHz demands transmission-line-style shielding everywhere, but because it reduces crosstalk and simultaneous-switching noise margin loss.
Place local decoupling near the connector on both sides of the interconnect, especially because your 3.3 V rail is shared across multiple logic groups.
## Power-pin current estimate
### What the connector data says
I found two relevant M-key M.2 connector data points from the same general connector family: one lists **0.5 A per pin** current rating,[doc1] while a newer Gen5 variant lists **1 A on power pins**.[doc2] That means the exact allowable current depends on the specific receptacle part number you are actually using, and you should not assume all M-key sockets have the same power rating.[doc1][doc2]
### Conservative estimate
If you do **not** have the exact socket datasheet, I would use **0.5 A maximum per 3.3 V contact** as the safe estimate, because that is explicitly stated for one M-key M.2 connector datasheet.[doc1]
You appear to have three 3.3 V pins in the posted map, so the conservative connector-limited total is:
$$I_{\text{total, conservative}} = 3 \times 0.5\text{ A} = 1.5\text{ A}$$
### Less conservative upper bound
If your exact connector is a variant that specifically rates **power pins at 1 A**, then the upper bound becomes:
$$I_{\text{total, upper}} = 3 \times 1.0\text{ A} = 3.0\text{ A}$$
### Per-line estimate table
| 3.3 V line | Conservative max | Upper bound if exact socket is 1 A/power-pin type |
|---|---:|---:|
| Pin 68 | 0.5 A[doc1] | 1.0 A[doc2] |
| Pin 58 | 0.5 A[doc1] | 1.0 A[doc2] |
| Pin 56 | 0.5 A[doc1] | 1.0 A[doc2] |
| **Total 3.3 V rail** | **1.5 A**[doc1] | **3.0 A**[doc2] |## Contact drop and heating estimate
One cited M-key connector spec gives **55 mΩ contact resistance**.[doc1] Using that value, one power contact at 0.5 A drops about:
$$V = I R = 0.5 \times 0.055 = 0.0275\text{ V}$$
So the drop is about **27.5 mV per contact** at 0.5 A.[doc1]
The power dissipated in one contact at 0.5 A is:
$$P = I^2R = 0.5^2 \times 0.055 = 0.01375\text{ W}$$
So that is about **13.8 mW per contact** at 0.5 A.[doc1]
At 1 A on a power-rated contact, the drop is about **55 mV** and the dissipation is about **55 mW per contact**.[doc1][doc2]
Those numbers are not alarming by themselves, but real current sharing across three pins is rarely perfect, so I would still derate unless you validate temperature rise on the actual hardware.
## Final assessment
For your stated 16 MHz maximum signaling, this custom use of an M-key M.2 socket is **probably electrically reasonable**.[doc1][doc2] The connector family has ample intrinsic speed margin for that rate,[doc1][doc2] and your two clock-like lines are placed sensibly with adjacent grounds. The main risks are bus crosstalk and return-path sharing across the large single-ended address/data fields, not the connector technology itself.
For current, I would treat **0.5 A per 3.3 V pin, 1.5 A total** as the default design limit unless you can confirm a socket datasheet that explicitly allows **1 A on power pins**, in which case **3.0 A total** is a reasonable connector-only upper bound.[doc1][doc2]
If you want, I can next turn this into a **pin-by-pin SI risk table** and suggest a **revised pin assignment with better ground interleaving**.
[06/05/2026 20:34:09 +00:00] Trevor Clarke:
create a pin-by-pin SI risk table and suggest a revised pin assignment.Response:
I created a markdown artifact with a pin-by-pin SI risk table for the current pinout and a revised assignment that improves return-path placement for the most sensitive control nets.
# Custom M.2 Socket 3 Key M Pinout SI Review
## Scope
This review assumes:
- M-keyed M.2 card/socket interconnect with no cable in between
- Single-ended digital signals
- Maximum signal frequency of **16 MHz**
- The real SI limiter is **edge rate**, not the 16 MHz repetition rate
- Both PCBs can provide a continuous reference plane under the connector breakout## Risk legend
- **Low**: Good local return path and/or low switching activity; unlikely to be the first SI problem
- **Medium**: Acceptable at 16 MHz, but worth routing carefully and possibly damping with small series resistors
- **High**: Most likely place to see crosstalk, ringing, or ground-bounce sensitivity if edge rates are fast## Overall observations on the current pinout
1. **SYSCLK (54)** is well placed with **GND (53)** adjacent.
2. **DATCK (28)** is also well placed with **GND (27)** adjacent.
3. The largest SI concern is the **wide single-ended address/data field** with limited ground interleaving.
4. The **address reset/strobe area** is less optimal than the main clocks.
5. The lower control cluster is not high speed, so its SI risk is driven more by **asynchronous behavior and shared return current** than by raw bandwidth.## Pin-by-pin SI risk table for the current assignment
| Pin | Signal | Group | Risk | Why | Suggested handling |
|---:|---|---|---|---|---|
| 75 | TMS | JTAG | Medium | Adjacent to TRST, no immediate ground on the same row | Keep slew rate low; route with TCK separated where possible |
| 74 | TRST | JTAG | Low | Low activity; little timing sensitivity | No special action beyond normal routing |
| 73 | GND | Return | Low | Good return for TCK and nearby signals | Tie solidly into the reference plane |
| 72 | TCK | JTAG | Low | Immediate adjacent ground on pin 73 | Good as assigned; series damping optional |
| 71 | TDO | JTAG | Medium | Adjacent to TDI; no same-row ground | Keep JTAG edge rates modest |
| 70 | TDI | JTAG | Medium | Adjacent to TDO; no same-row ground | Keep routing short and away from clocks |
| 69 | GND | Return | Low | Local return for upper power area | Stitch well to plane near connector |
| 68 | 3V3 | Power | Low | Adjacent ground helps local return | Decouple near connector entry |
| 67 | SYSRST | Control | Medium | Isolated control net with no immediate same-row return | Filter or debounce if needed; avoid fast edges |
| 58 | 3V3 | Power | Low | Part of distributed 3.3 V feed | Decouple close to the connector |
| 57 | GND | Return | Low | Return for nearby power | Stitch to plane with multiple vias |
| 56 | 3V3 | Power | Low | Good power distribution point | Decouple and share current evenly |
| 55 | GND | Return | Low | Return next to SYSCLK region | Excellent place for stitching |
| 54 | SYSCLK | Clock | Low | Immediate adjacent ground on 53; short return path | Keep as assigned; add source series resistor if edges are sharp |
| 53 | GND | Return | Low | Return for SYSCLK and upper address area | Keep solidly referenced |
| 52 | A19 | Address | Low | High-order address bit; adjacent ground on 51 helps | Good candidate for a sensitive control net if reassigned |
| 51 | GND | Return | Low | Return boundary for top of address field | Very useful anchor point |
| 50 | A17 | Address | Medium | Adjacent to A18; limited local shielding | Fine at 16 MHz but route over solid plane |
| 49 | A18 | Address | Medium | Adjacent to A17 | Same as above |
| 48 | A15 | Address | Medium | In a signal-dense part of the address bus | Keep trace lengths consistent |
| 47 | A16 | Address | Medium | Adjacent to A15 | Same as above |
| 46 | A13 | Address | Medium | Surrounded by address activity, no immediate ground | Moderate crosstalk risk if edges are fast |
| 45 | A14 | Address | Medium | Surrounded by address activity | Same as above |
| 44 | A11 | Address | Medium | Mid-bus location, no same-row ground | Moderate simultaneous-switching sensitivity |
| 43 | A12 | Address | Medium | Mid-bus location, adjacent active address line | Same as above |
| 42 | GND | Return | Low | Important return point inside address field | Keep well stitched to plane |
| 41 | A10 | Address | Low | Adjacent ground on 42 reduces coupling | Good location for a timing-sensitive address-side control if needed |
| 40 | A9 | Address | Medium | Neighbors are active address lines | Acceptable with good plane reference |
| 39 | A8 | Address | Medium | Same as A9 | Same as above |
| 38 | A7 | Address | Medium | Same bus-density issue | Same as above |
| 37 | A6 | Address | Medium | Same bus-density issue | Same as above |
| 36 | A5 | Address | Medium | Same bus-density issue | Same as above |
| 35 | A4 | Address | Medium | Same bus-density issue | Same as above |
| 34 | A3 | Address | Low | Close to ground boundary at 33 | Good location for a lower-order address bit |
| 33 | GND | Return | Low | Useful return boundary between address and lower field | Stitch aggressively |
| 32 | A1 | Address | Medium | Next to address activity, no same-row ground | Fine at 16 MHz with solid plane |
| 31 | A2 | Address | Medium | Same as A1 | Same as above |
| 30 | ADRSTB | Address control | High | Timing-sensitive control with no immediate same-row ground | Best candidate to move to a ground-adjacent pin |
| 29 | A0 | Address | Medium | Lower-order bit may toggle often; no same-row ground | Keep short and matched with nearby address lines |
| 28 | DATCK | Data clock | Low | Immediate adjacent ground on 27 | Good as assigned; series damping optional |
| 27 | GND | Return | Low | Return for DATCK and lower data group | Keep solid to plane |
| 26 | DATSTB | Data strobe | Medium | Near DATCK and data cluster, but still coupled to adjacent signal | Acceptable as-is; keep route matched to data |
| 25 | D7 | Data | Medium | Adjacent to DATSTB and D6 | Moderate coupling risk |
| 24 | D6 | Data | Medium | In a dense data cluster | Match routing and keep over a solid plane |
| 23 | D5 | Data | Medium | In a dense data cluster | Same as above |
| 22 | D4 | Data | Medium | Center of data field; no same-row ground | Moderate simultaneous-switching risk |
| 21 | D3 | Data | Medium | Center of data field | Same as above |
| 20 | D2 | Data | Medium | Dense switching neighborhood | Same as above |
| 19 | D1 | Data | Medium | Dense switching neighborhood | Same as above |
| 18 | D0 | Data | Low | Close to ground boundary at 17 | Good location for a frequently used data bit |
| 17 | GND | Return | Low | Return boundary for data/control transition | Stitch to plane close to breakout |
| 16 | ATNRQ6 | Control | Medium | Control cluster with no interleaved grounds | Fine if edge rates are slow |
| 15 | ATNRQ7 | Control | Medium | Same as above | Same as above |
| 14 | ATNRQ4 | Control | Medium | Same as above | Same as above |
| 13 | ATNRQ5 | Control | Medium | Same as above | Same as above |
| 12 | ATNRQ2 | Control | Medium | Same as above | Same as above |
| 11 | ATNRQ3 | Control | Medium | Same as above | Same as above |
| 10 | ATNRQ0 | Control | Medium | Same as above | Same as above |
| 9 | ATNRQ1 | Control | Medium | Same as above | Same as above |
| 8 | BUSAK0 | Control | Medium | Low-rate control but no local return segregation | Keep routing short |
| 7 | BUSAK1 | Control | Medium | Same as above | Same as above |
| 6 | BUSRQ0 | Control | Medium | Same control-cluster issue | Same as above |
| 5 | BUSRQ1 | Control | Medium | Same as above | Same as above |
| 4 | CM2 | Control | Medium | Low-speed but in a dense low-end cluster | No special action if timing is relaxed |
| 3 | TRFERR | Control | Medium | Asynchronous/error line in dense control cluster | Consider filtering at receiver if needed |
| 2 | CM0 | Control | Medium | Low-speed clustered control line | Fine at 16 MHz context |
| 1 | CM1 | Control | Medium | Low-speed clustered control line | Fine at 16 MHz context |## Recommended revised assignment
### Design goals for the revision
The revision below tries to improve SI without adding pins or changing connector type:
1. Keep **SYSCLK** and **DATCK** on their current ground-adjacent pins.
2. Move the **address-side timing/control net** onto a ground-adjacent location.
3. Put the **highest-order, lowest-toggle address bit** onto the isolated pin.
4. Keep the **data bus compact** so board-level length matching remains straightforward.
5. Avoid large functional reshuffles in the low-speed control cluster.### Recommended revised pin map
```text
Socket 3 Key M
74 TRST TMS 75
72 TCK GND 73
70 TDI TDO 71
68 3V3 GND 69
A19 6758 3V3 GND 57
56 3V3 GND 55
54 SYSCLK GND 53
52 SYSRST GND 51
50 A18 A17 49
48 A16 A15 47
46 A14 A13 45
44 A12 A11 43
42 GND ADRSTB 41
40 A10 A9 39
38 A8 A7 37
36 A6 A5 35
34 A4 GND 33
32 A3 A2 31
30 A1 A0 29
28 DATCK GND 27
26 DATSTB D7 25
24 D6 D5 23
22 D4 D3 21
20 D2 D1 19
18 D0 GND 17
16 ATNRQ6 ATNRQ7 15
14 ATNRQ4 ATNRQ5 13
12 ATNRQ2 ATNRQ3 11
10 ATNRQ0 ATNRQ1 9
8 BUSAK0 BUSAK1 7
6 BUSRQ0 BUSRQ1 5
4 CM2 TRFERR 3
2 CM0 CM1 1
```## What changed and why
| Change | Reason | Expected effect |
|---|---|---|
| **A19 moved from pin 52 to pin 67** | A19 is the lowest-toggle address bit and tolerates the isolated position best | Reduces pressure on the better SI locations inside the address field |
| **SYSRST moved from pin 67 to pin 52** | Reset is important but low toggle; pin 52 has adjacent ground on 51 and nearby ground on 53 | Cleaner reset reference and less sensitivity to noise pickup |
| **ADRSTB moved from pin 30 to pin 41** | Pin 41 sits next to **GND 42**, making it a much better location for a timing-sensitive address-side control | Lower crosstalk and better return path for the address-side strobe/reset |
| **Address lines re-packed so A0-A18 occupy the main address field cleanly** | Keeps the bus visually and electrically grouped while reserving a better SI location for ADRSTB | Easier PCB routing and more consistent address-bus timing |## Why I did not move DATSTB
Although **DATSTB** is a timing-sensitive net, it is already relatively well placed because:
- it remains inside the **data cluster**
- it is close to **DATCK**
- it is near the **GND boundary at pin 27**Moving it farther up the connector would improve local shielding only slightly, but would usually make **board-level matching to D[7:0] harder**.
## Practical routing guidance for either pinout
1. Route all connector breakouts over a **continuous reference plane**.
2. Add **source series resistors** first on:
- SYSCLK
- DATCK
- ADRSTB
- DATSTB
- TCK
3. Use the **lowest practical drive strength / slowest acceptable slew rate**.
4. Keep the **data group and its strobe/clock tightly length-controlled** on the PCB, even though the connector itself is short.
5. Put **several stitching vias** near the connector ground pins, especially at 17, 27, 33, 42, 51, 53, 55, 57, 69, and 73.
6. Place **local decoupling** near the connector entry for the 3.3 V pins.## Priority list if you only make two changes
1. **Move ADRSTB to pin 41 and use GND 42 as its local return reference.**
2. **Move A19 to pin 67 and free pin 52 for SYSRST.**That gives the biggest SI improvement with the least disruption to the rest of the bus grouping.
-
5 Slot STEbus Backplane rev 1
05/01/2023 at 03:01 • 4 commentsNOTE: This post contains sponsored content.
I finished rev 1 of a 5 slot backplane and sent it to PCBWay who were kind enough to send me some free boards to try out in exchange for a review of the service. Check out the end of this post for info on how they turned out.
---------- more ----------This is a simple 5 slot backplane with active termination. Follow along with the schematic while I describe the design.
I decided to use an ATX-24 connector to support an ATX power supply since these are very common and fairly inexpensive for multiple power rails. The 3.3v isn't used but the +12v, -12v, and +5v rails provide power for the STEbus rails. The caveat is that the ATX standard defines a looser standard for voltage stability on the +/-12V rails than the requirements for STEBus so the rails may not be compliant. STEBus requires +/-5% and 50mV pk-pk ripple on all rails and -2.5% on the +5V rail. ATX only requires +/-10% on the -12V rail and 120mV pk-pk ripple on the +/-12V rails. In reality, these are the worst case specifications and most ATX supplies will be more stable and have less ripple. Also, a lot of STEBus cards should also work fine with the looser specifications with the possible exception of DAC/ADC cards and the like. The ripple can be further mitigated with more filtering and bigger caps on the backplane or boards. This should also help with voltage drop on the -12V rail. In short, there should be no problem getting a mostly digital hobbyist system running with an ATX power supply.
ATX power supplies use hard and soft switches for power. The backplane includes a header (J104) to accommodate a soft switch but this can be bridge with a jumper or solder bridge to force the soft switch closed. In addition, an ATX supply has a +5VSB rail which is a 5V rail with lower current capability and looser stability requirements. It's meant to supply power to circuits used for the soft power capability and some other standby capabilities like status LEDs. We can tie it to VSTBY on the STEBus and treat it like a battery. This allows us to simulate a power fail by turning off the supply with a soft switch. The full system can be turned off with the hard switch on the power supply. There's a jumper pad (JP102) to tie VSTBY to either +5V or +5VSB.
The other jumper (JP101) ties the PWR_OK line on the ATX supply to ATNRQ0. It is pulled low after power is turned on to give it time to stabilize. It can be used to trigger a power failure interrupt on the line suggested by the STEBus spec. After looking at the schematic of rev 1 I believe there's an error. There's an inverter connected to the line to switch to inverted logic but re-reading the ATX spec I think this is already inverted logic so if you use this revision you might not need to populate Q101, R103, and R104 and jumper JP101 pin 2 directly to Q101 pin 3. If this is the case I'll put out rev 2. Another change that might be worthwhile for rev 2 is the ability to jumper PWR_OK directly to the System Controller board so it can be used to manage SYSRST on startup. Stay tuned for updates.
Bus termination is based on the IEEE-1000 §7.7 Termination Networks. The circuit is verbatim from Figure B.1 Bus Terminology Arrangement with component types chosen from jelly bean parts. A 1N4148 silicon diode and some SD103C Schottky diodes. You should be able to substitute any of these with just about any diodes you have on-hand provided they can handle the current. The 2.8V needed for termination is created with an RT9080 LDO regulator. I happen to have some around from another project and they are more than capable of providing a stable 2.8V. Similar devices should work ok if you have something around but YMMV.
The boards arrived from PCBWay in a timely manner and they were very well packaged.
![]()
The layout is fairly simple, rev 1 gerbers are available in the github repo. Once I've tested everything, I'll release them here as well. The cost was a bit more than I'd pay at some other PCB proto services but the number of options available for impedance controlled boards and other advanced options is quite a bit larger than those other services and the quality seems to be at least as good as, or better than the others I've used. I'm pretty happy with the boards and I'll definitely use PCBWay again, at least for my HAM radio projects that require impedance control. I'll be ordering the rest of the boards for this project as well.
![]()
![]()
-
Finalized on Bus
04/26/2023 at 16:23 • 0 commentsI began laying out my modified RC2014 bus and I realized it has more problems than just missing signals. There's not termination, layout is not friendly to cross coupling concerns, etc. It's a great breakout for a z80 but it's a badly designed bus for a backplane based system so I'm entirely dropping it. However, I have a better solution.
---------- more ----------While researching some of these issues I ran across STEbus. I'm somewhat surprised I haven't run into it earlier. It's got a lot going for it:
- It's a proper standard. IEEE1000 to be specific. (latest rev seems to be 1988)
- It's designed to be processor agnostic so it's not just a breakout for a specific processor's pins.
- It was quite successful in its day and there are many industrial automation modules available
- The physical layout is based on eurocard (STEbus means STandard Eurocard bus). It supports 3U and 6U 160mm cards and uses the standardized DIN 41612 plug and socket. This means subracks and cases are plentiful and easy to find.
It's essentially an 8-bit version of the VME bus designed to reduce costs when 8-bits are enough. (often the case in industrial automation settings) It never really caught on in the homebrew computer world because it came a bit late when ISA was already dominating with the IBM PC and clones. It's a shame because it's really a great bus for the purpose. There are some homebrew computers using the bus and a lot of the industrial systems are useful too including a variety of CPU boards (z80, 6809, 68000, etc.), serial boards, etc.
One of the design goals of the bus is to make it very easy and inexpensive to create peripheral cards for STEbus. It puts most of the tricky arbitration logic on the System Controller card (often a CPU card) so peripherals typically just need some basic logic, buffers, and address decoding.
I'm attaching the relevant standards documents to the project but I'll summarize the important parts in this post.
The physical layout uses 100mm (3U) x 160mm eurocards. 6U cards are allowed but not suggested. This small size decreases cost and encourages separation of functions onto different cards. There are a few classes of cards to will different roles.
- System Controller - This is a required and there should be only one. It generates the system clock, system reset, and transfer error signals. This can be a separate card or it can be combined with another card. Often this is part of a CPU card.
- Arbiter - This handles allocation grants for masters. The STEbus allows multiple master cards (usually CPUs but can also include DMA sources) and the arbiter decides which gets to control the bus. Like the System Controller, this can be on a CPU card.
- Master - This is a card that can control the transfer of data on the bus. This is usually a CPU board or a DMA controller. There can be a special Master call the Default Master which automatically gets control of the bus until it releases control. A Master can be Release-On-Request (the Default master is always RoR) or Release-When-Done. A Default Master does not need to be present and if one isn't, the Arbiter will choose a current master.
- Slave - This includes all boards that can only receive and respond to bus transfers. Most peripherals will be Slave cards. A card can act as both a Master and a Slave.
The STEbus is asynchronous and uses various synchronization and attention lines to sequence data transfers.
A CPU card can use off-card memory but is limited to 1 MiB due to the 20-bit address space of the bus. A paging system can be implemented to address more memory or a CPU card and contain more memory which isn't accessible over the STEbus. In addition to memory, the bus allows for 4 KiB of I/O addresses for CPUs which have I/O ports (like the Z80).
The bus does not differentiate between DMA requests, interrupts, and similar functions but instead provides 8 attention request lines. These can be used for DMA, interrupts, and similar functions such as notifying of an imminent power failure.
Electrically, there are 2 power buses available. A +5V bus with a maximum available 4A per card. This is intended to be the primary power for all cards. In addition, +12V and -12V buses are provided at a maximum of 1A per card. These have looser noise requirements and are intended for RS-232 signaling, bipolar OPAMP rails, etc. Finally, an optional +5V battery bus is available at a maximum of 1A per card. This connects to a battery backup or UPS and is intended for critical components to function in the event of a power failure. It may be tied to the main +5V bus if a UPS is not available.
There are a few STEbus projects on hackaday including this one which contains links to a lot of STEbus cards and some great information on the bus itself.
-
RC2014+VW Bus
04/17/2023 at 17:14 • 0 commentsThe bus I'm using is based on the RC2014 bus. It's primarily a break out for the Z80 pins with a few notable changes.
The biggest change is the use of a JAE TX-24/25 connector instead of 2.54mm headers. The RC2014 boards suggest not using pins 40 and 80 as the resulting board would need to be longer than 100mm (the magic width for using the free version of some PCB design tools and the limit for super cheap proto boards from many manufacturers). These were used because they are very easy to hand solder, most hobbyists have a bunch of them in junk boxes, and they are very inexpensive. I've decided to move to the TX-24 connector a it is 1.27mm pitch so 80 pins fit very easily on a 100mm board with plenty of room to expand with another connector if needed. They are keyed, shrouded, and click together leading to a fairly robust connection and can be plugged and unplugged a number of times. They are also fairly inexpensive at just over $2 per connector in lots of 10.
The RC2014 extended bus does not connect pins 41-56 and uses them as a way to key the 2.54mm header connectors. My bus connects these to GND since they are already present, this should help with impedance and noise issues that can arise with longer runs of the RC2014 bus while remaining compatible with the pinout.
There are a number of user pins reserved in the RC2014 bus. My bus uses 5 of the 8 to add some important strobes from the S-100 including pSTVAL, pSYNC, ERROR, POC, and INTA. These are defined as in the S-100 specification. Certain RC2014 boards use these for other signals causing incompatibilities but this is a problem with user defined signals regardless of their use. Care should be paid when adding other boards.
I'm ignoring DMA and temporary master capabilities of the S-100 as well as 16-bit data transfers. If I decided to add this later, I'll likely utilize pins 41-57 or add a second connector to the bus.
I haven't added additional power rails as the occasional +/-10v (for RS-232), etc. can be easily generated on-board with modern DC-DC converter chips. The RC2014 does not state, but assumes a regulated 5v rail which is reasonable for a small system. 5V LDO regulators (for example, the 1117) are cheap and easy to use to increasing the rail voltage and regulating on each board is not a bad idea. For now, I plan to add a footprint for a regulator but not populate it. If necessary, I can add the regulators and increase the rail voltage to 12v or so.
-
Introduction
04/17/2023 at 16:28 • 0 commentsThis is a homebrew Z80 based retroish computer that I'm designing and building. This post provides some background on why I'm working on this project, how I got to the design, and what my end goals are.
---------- more ----------Why am I building another Z80 based retro computer? This one is easy. I'm old enough that I cut my teeth on early home computers in the 1980s. I started with an Apple //e and moved on to an XT clone but I never had one of the classic S-100 based systems. There are many options today for one of these including purchasing an original Altair or IMSEI, building a clone, or using a modern work-alike system like the RC2014. I wanted to learn all I can about the details and design considerations so I opted to create my own system from scratch. I'd like it to work with classic or modern modules in case I decide to pop in an old 8" floppy, etc.
One of the design requirements is to stick with the general feel and soul of a classic S-100 system but not limit myself to original components which can be tough to find and sometimes expensive. I'm using modern CMOS components, denser memories, etc. while still keeping the overall design features of the classic hardware. I went with a CMOS Z80 since you can buy them new but the architecture is essentially the same as it was in the '70s. The CMOS is more tolerant to noise on the bus and has higher fanout than the NMOS devices. The modern Z80s can also run at higher clock speeds.
Next I had to decide on a bus. Since I've building most of this myself, it doesn't matter as much as if I'd planned to use existing modules from the start. Originally I was going to stick with S-100 but there is a lot of glue logic needed to put a Z80 on an S-100 bus, mostly because the bus originally coincided with the pinout on the 8080. There are also a lot of pins used to allow for temporary bus masters and DMA, functions I'm not interested in implementing this time around. The next obvious choice is the RC2014, a bus designed to get a Z80 system running with minimal effort. It is a breakout of the Z80 pins with power. However, it has a number of problems, it's not well designed from a robustness standpoint. It's not designed for latching of address and data values, it has only one (or two in the extended version) ground pin, it only has 5V lines, lacks multi-level interrupts, and isn't laid out with signal integrity in mind.
After spending too much time thinking about and designing for S-100 I wanted to get something done so I switch to RC2014 with a few changes I'll detail in another post.
In addition to a CPU board with a ROM chip, I'm creating a RAM board, a dual serial board with a PC16552 compatible UART, a front panel/debug board, and some sort of TBD storage (likely an SD card simulating a floppy). User I/O will be through a VT420 terminal.
Trevor R.H. Clarke

