Intro

TL;DR; Show me the code, I want to build one! - https://github.com/banksy-git/nbreak-econet

I made this project to scratch an old itch - to bring back Econet, the mysterious technology from our old school network of BBC Micro computers. We still fire up our old Beeb for the occasional round of retro gaming, and I always thought it was a shame that the Econet ports just sat there doing nothing. The protocol looked simple enough at first glance - just a clock line and a data line. What could possibly go wrong?

Once I got into it, I realised Econet isn’t just clock and data - it’s a precise, RS-422 differential protocol with tight timing and some very 1980s assumptions baked in. What started as a weekend tinker turned into an engineering exercise in signal integrity and microsecond-level timing inside a busy micro-controller.

This article walks you through some of the details, the design choices and the end result is an Econet-to-WiFi bridge that anyone can build using less than 20 euro of parts. Build guide included.

The first hardware test

To test the code, I needed hardware, and to test the hardware, I needed code. I decided to start with the hardware to see whether I could get any response from the BBC’s Econet electronics. The goal was simple: fail fast. The interface in my old Beeb had never been tested by me, and if it didn’t respond, there’d be no point writing any firmware.

Here’s the high-level schematic of my Econet interface used throughout this article - simple wiring, nothing exotic. (Full details and the parts list are at the end.)

After checking and adjusting the idle bias with a multimeter (my initial resistor values didn’t produce enough voltage difference), I wrote a short test routine to generate an Econet clock at 100 kHz and connected it to the Beeb.

Booting directly into the NFS (Econet’s ROM) by holding down N and tapping BREAK, the display confirmed that the NFS was active and that the clock was being detected. A promising start.

With an oscilloscope on the clock and data lines, I issued a couple of commands to generate network traffic:

*NET
*I AM A CLOCK

Instead of a data packet, I was greeted by a never-ending train of identical pulses. Decoding them by eye, they turned out to be Econet’s FLAG byte (0x7E), repeatedly transmitted back-to-back - a clear sign something was wrong. Suspecting a hardware fault, I dug through various online forums, and fortunately the full BBC Micro schematics are freely available.

Tracing the interrupt line, which is routed to the BBC’s NMI pin through gating logic, I confirmed that the ADLC - the chip handling Econet’s link layer - was generating IRQ signals, but they weren’t reaching the CPU. Following the circuit revealed the culprit:

The wire link S2 was still connected, effectively disabling the interrupt. No wonder nothing worked! After cutting the link, I powered on again and verified the CPU’s NMI pin was toggling. Hardware issue number one: fixed. But the network still didn’t work.

Staring at the board, I began wondering how the Beeb’s operating system (MOS) processed the NMI and how that interrupt ultimately reached the NFS ROM’s code. Then it hit me: I had a third-party “Smart SPI” ROM installed. If it was intercepting the NMI, that could explain the remaining behaviour. I removed it and powered on again.

This time, a stream of real packets appeared on the scope. Econet was alive, and the hardware was officially verified.

An Econet Primer

Econet is a shared, synchronously clocked bus that connects two or more nodes - called stations - together. Being a bus architecture, only one station can transmit at any given time, so the protocol is designed to make efficient use of the shared medium and minimise wasted bandwidth.

Frame data is delimited by FLAG characters (0x7E), which receiving stations use to identify valid packets within the continuous data stream. To prevent false frame markers inside packets, the protocol employs a bit-stuffing mechanism that ensures the FLAG bit pattern appears only at the start and end of each frame.

The outer-most frame structure is shown below:

Data integrity is verified with a 16-bit CRC appended to the end of the payload.

When one station wishes to contact another, it first transmits a short packet known as a scout, addressed to the destination station:

The receiving station, on seeing a scout addressed to it, replies with a short four-byte acknowledgement (ACK), addressed to the originating station:

The scout serves two purposes:

1. It alerts the receiving station to prepare for an incoming data transfer.

2. The corresponding ACK tells the sender that the remote station is alive and ready to receive data.

Once the originating station receives the ACK, it sends the data payload:

After successfully receiving the data, the destination station transmits one final ACK.

This sequence is known as the Econet four-way handshake. Other frame types and handshake variations exist for control and management purposes, but this covers the basic data-transfer exchange.

Timing is everything

I coded up a frame decoder with bit un-stuffing and CRC validation, attaching it to one of the ESP32’s GPIO interrupts. It worked; packets were being decoded successfully.

It was about 95% reliable; the interrupt clearly wasn’t keeping up perfectly, but it was good enough for this early stage.

Next, I built a frame encoder with CRC generation and bit stuffing, and used it to send an ACK back to the Beeb.

But the log showed the Beeb responded only with a single flag - no additional data or much else.

After double-checking the hardware (it’s always hardware, right?), I did some more digging and discovered that timing in the four-way handshake is absolutely critical. Each station only has about 14 bit periods to respond, and my firmware was taking its sweet time.

I quickly lashed together a proof-of-concept using precomputed bitstream responses to keep the interrupt service routine lean and mean. This time, the Beeb responded with a full command packet containing exactly what I’d typed at the prompt.

That proved the end-to-end path was working, but it also made something very clear: bit-banging with interrupts wasn’t going to cut it. To meet Econet’s tight timing, I was going to need a completely new approach.

A journey through the ESP32 peripherals.

To reduce reliance on interrupts, which would be unworkable anyway once Wi-Fi was enabled, I explored a few possible approaches using the ESP32’s DMA-backed peripherals:

1. SPI in slave mode; it’s just clock and data, right?
2. I²S in slave mode; also just clock and data!
3. PARIO - and this is the one I finally picked.

I listed them in this order mainly by how commonly available they are across the ESP32 family.

I tried SPI first but got no data at all. It turns out that in slave mode, the chip-select (CS) pin must toggle for the peripheral to return data. It could have been made to work with an external counter flipping CS every 8 bits, but I wanted to keep the hardware simple so anyone could build this with off-the-shelf parts; no extra logic required.

Next up was I²S, which looked very promising. It gave 100% reliable transmit and receive, but I couldn’t get the latency down far enough, and controlling the driver output-enable precisely was tricky relying again on interrupts and their variable latency. The line driver has to be active only during the packet’s data bits; not a mircosecond more!

Both SPI and I²S could probably be made to work with deeper register-level control and some serious digging into the hardware, but for my sanity, I moved on.

The PARIO peripheral turned out to be almost ideal. It accepts an external clock, provides independent transmit and receive blocks, and gives fine-grained control over both timing and the output-enable signal. In short, it’s exactly what Econet needed.

Breakthrough!

I hooked up the encoder and decoder logic to the PARIO peripheral. By choosing a bit width of 2 on the receive side, I could trigger an interrupt every 4 bits. Combined with DMA backing, this meant interrupt jitter would no longer cause missed clock pulses and data corruption; a big improvement over the earlier bit-banging ISR approach.

The transmit side was trickier. I was getting spurious glitches on the output until I realised it was necessary to align the stream to 8-bits with respect to the output, not just the input buffer.

After a few more optimisations, such as pipelining the receive CRC (computing it while receiving bits instead of after), I was finally greeted with a successful response:

*NET
*I AM SPARTACUS

Incorrect password
>

And with that, Econet over Wi-Fi was alive.

Wrapping up

That little “Incorrect password” prompt felt like victory. It meant the handshake, timing, encoding - the entire stack - was working end to end. The Beeb was finally talking to a Wi-Fi-connected file server through an ESP32.

The best part is how little hardware it needs: just an ESP32-C6, a couple of RS-485/RS-422 transceivers, three resistors, and some wire. No custom PCBs, no vintage ADLC chips, no black magic.

I’ve open-sourced the firmware and shared the wiring details on GitHub, so anyone with a soldering iron and a fondness for the Beeb can bring Econet back to life.

Of course, this isn’t the first Econet revival; there are some fantastic projects out there that have kept the protocol alive, from Pi-based bridges to dedicated microcontroller interfaces and even FPGAs. This one just happens to use the hardware most of us already have in a drawer.

It’s been a fun mix of nostalgia and modern embedded engineering; a reminder that even forty-year-old networks can still teach you something new about timing, hardware, and patience.

Resources

• Source code for the ESP32 firmware