Pi Econet

Not sure whether this should be in Wish List, I’ve put it in here as it involves hardware.

Anyone reckon it would be possible to hook an Econet interface (the Master/Archimedes type) up to a Pi using GPIO, then have a patched Econet module loaded to talk to it?

I’m thinking using a Pi as a tiny Level 4 server for BBC Micros etc.

I also remember someone wrote an aund for *nix, so perhaps resurrect this to run on Raspbian? (I know that’s not RO, but it’ll talk to RO boxen over AUN.)

Just a wild suggestion. Have been feeling strangely nostalgic recently. I must be getting old.

Timing is tight because you’d have to bitbang the ADLC (which runs at 2MHz). However Ian Bradbury managed to convince a Master Econet module to work in a Risc PC using my suggested podule adaptor and some changes to the Econet module. So masochists could try it.

An alternative… the ADLC is fairly simple, and most Econets don’t actually run that fast (KHz). So why not bitbang the Econet wire? If it’s too much overhead for a Pi, an Arduino or similar dedicated to bitbanging might be able to keep up.

A few thoughts about this.

AUND only implements a subset of the Econet protocol, specifically that found on AUN Ethernet LANs used between Archimedes and Level4s. Much of the protocol required for a Beeb to be a client is missing, essentially there was no way for that to ever happen so the author didn’t feel any need to write it.

I have been vaguely contemplating how to attach an ADF10. I am inclined to pare it up with a decent AVR or PIC32 chip on a HAT, chances of me actually doing that are not so good.

There has been talk of a USB Econet interface. Without using a 68B54 the protocol on the wire is a bit hard to deal with. Last time I checked I didn’t think that I could bit bang it with an AVR at 20Mhz and an 250KHz Econet. What would make it a lot more practical would be a GAL/PAL device that could do the zero insertion/removal, flag detection and output the remaining data stream to SPI. An AVR or PIC32 could then turn that into USB or you could feed it into the PI SPI given the right voltages. Unfortunately my antique GAL programmer won’t do a device big enough for this job.

Then the other possibility is an Econet to Ethernet bridge. I should test this soon though as hardware goes these are quite rare.

Resurrecting a 7-year-old thread here, but some interesting developments in the retro scene which might be of interest (and hopefully of benefit). Someone has managed to create a cycle-exact emulation of the Commodore 1541 and 1581 floppy drives in a Raspberry Pi based emulator:

https://cbm-pi1541.firebaseapp.com/

Relevant here because these were contemporaries of the Beeb. The floppy drives for the Commodore 8-bit systems weren’t exactly trivial, they contained a 6502 and a pair of 6522s, with a few K of system memory, and linked up with an IEC-style protocol running over a proprietary Commodore serial bus. (Forerunner of USB perhaps?)

My instinct is that a cycle-exact emulation of a floppy drive is a lot harder than bit-banging the Econet bus. It may be possible to do what I suggested in the opening post just by hooking the GPIO pins to a couple of line driver chips?

Anyone have any thoughts on this, and whether it’s possible to build something similar for the Beeb for Econet using a Pi?

Sligthely off-topic, but if you need to interconnect modern RISC OS Pis with BBC Micros/Masters, have you tried the excellent Sprow Ethernet card for the Beeb?

I use that and have no regrets/nostalgia for Econet.

I did take a look at that, but I have a large number of Beebs (unsure of total but it’s definitely >10 Model Bs, a B+ and 2-3 Masters – although the B+ doesn’t have Econet fitted as yet) which I’d perhaps like to set up as a “retro computing” exhibit sometime. I could run Level4 on a RISC OS machine but these are in short supply (I have a pile of A310s with RISC OS 2, not sure if it’ll run on these or if it needs RO3+) but a Pi with Econet would be a dream come true.

It’s slightly outside my area of expertise, but what I’m imagining is something like this:

Raspberry Pi running PiCore (a build of TinyCore for the Pi) fitted with some form of Econet interface
RTC module for timestamps etc
Level 4-type server daemon for Linux (it’s been done, someone wrote aund a while back)
Access / ShareFS daemon for 32-bit clients on Ethernet (sources exist, unsure how trivial it would be to port to *nix)
Samba / CIFS to copy files on and off the system from modern systems

As I say, I’m just throwing this open in the hope that someone with the hardware expertise and a lot of spare time fancies having a go at it.

Have a look over at stardot for lots of retro-Econet goodness [Edit: actual hardware projects involving RPi, in case that wasn’t obvious]

but a Pi with Econet would be a dream come true.

It would be cute to have some form of Econet to revive my old FileStore just for the sake of doing so… but it’s more a wish list than a priority.
I would envisage hijacking GPIO to talk to the ADLC, not sure if that’s feasible. Can’t see why not, mind you. If a 1.2GHz Pi can’t keep up with a 2MHz Beeb there’s something wrong in the world. ;)

But, as I said, it’s mostly for the sake of nostalgia rather than any actual practical application.

Level 4-type server daemon for Linux

Why not just run awServer on the Pi?

I would envisage hijacking GPIO to talk to the ADLC, not sure if that’s feasible. Can’t see why not, mind you. If a 1.2GHz Pi can’t keep up with a 2MHz Beeb there’s something wrong in the world. ;)

Bit-banging the GPIO pins would probably work. A more elegant solution would be to come up with a hardware shim in some form of PIC chip which can effectively create a USB Econet interface. Then it’s just a case of shoehorning the driver into an appropriate OS.

Why not just run awServer on the Pi?

I’d considered that (or Level4 if it’s 32-bit compatible), however using piCore Linux for a server environment is more elegant.

If you’ve not looked at piCore then it’s worth checking out, it runs entirely from RAM disk so no more corrupted SD cards if the power gets pulled, and boots up in a few seconds. I use it on a couple of Pis to run piCorePlayer (a software implementation of the Squeezebox), one of which has the touch screen with JiveLite running, the other is a Pi Zero W installed into a stereo amplifier with integrated USB DAC. But that’s going way off topic… :-)

I just had a quick glance at the MC68B54 ADLC chip’s data sheet. The data transmission format has a lot in common with telco D channel transmission. Been there, done some of that. A project to replace that will occupy someone many hours of “fun”.

What clock speed was Econet? Was it 500 kHz? (I dunno, I never used Econet.)

I’ve done a shim for a much slower protocol using an NXP LPC1114. You can get development boards very cheaply from Olimex. Development software is free from IAR Systems; it runs natively under Windows, and I run it under Wine on Ubuntu.

I’m sure it’s possible to emulate an Econet interface with a shim. I just wonder why anyone would bother with Econet these days – but then my interest in this platform is in moving it forward, not clinging to the past.

What clock speed was Econet? Was it 500 kHz?

Possibly doable between RISC OS machines. With Beebs in the mix, more like 150-200kHz with a tailwind. Even slower if using a FileStore as it was not nippy.

The SJ MDFS (like the Rolls Royce of servers) could easily keep up with an Archimedes. The FileStore was basically a stripped down BBC Micro running a custom version of the Level 3 code and for some reason it was extraordinarily lethargic.

I wonder if this went anywhere?

https://github.com/google/myelin-acorn-electron-hardware/tree/main/econet_from_scratch

With Beebs in the mix, more like 150-200kHz with a tailwind

Do you really mean that different machines used different clock speeds?

The data rate is an entirely different question.

I quickly glanced at the Econet from scratch project. I don’t see anything about bit stuffing and destuffing. Note that it is only legal to send 6 consecutive 1’s in a flag. If you want to send 01111110 as data, it has to be sent as 011111010 – yes, it grows another bit. This is one reason why the data rate, regardless of other considerations, is data-dependent. Correspondingly, on receive, 011111010 is decoded as 01111110.

I had no end of fun implementing that in VHDL. I remember that I got it subtly wrong several times.

different machines used different clock speeds

Hell, no. One clock to rule them all. It helped if the Econet installers hadn’t left 50m loops of spare cable under the floor too.

bit stuffing and destuffing

When interfacing to a radar subsystem twenty-some years ago over SDLC, it reminded me of that feature of Econet!

But why reinvent the wheel, there are working implementations over on stardot.

I use that and have no regrets/nostalgia for Econet.

Nor me! I had to fix the mess left by the installers at Acornsoft. Every permutation possible of wiring, including leaving some out.

For them wot do, may I refer to the answer given above.

But why reinvent the wheel, there are working implementations over on stardot.

https://stardot.org.uk/forums/viewtopic.php?p=359632#p359632

Interesting, but it’s a Linux driver… anybody hacked RISC OS to be able to use one of these?

it reminded me of that feature of Econet!

Yup. I was wondering a long time ago about bit banging the protocol, but the ADLC actually automates a number of annoyances.

Every permutation possible of wiring, including leaving some out.

Yeah, the problem with Econet is that it was so damned resilient, up to a point. So faulty/missing terminators? Yup, it’ll work. One data wire broken? Yup, it’ll work. Two clocks? ¹ Amazingly it’ll work.
Until an extra station is added and then it’ll all collapse into a sulking heap. Unplug the station, all will work again. Swap it for another, it’ll still work. Put that other working station back on, failure. Hook it in anywhere, failure. Unplug a completely different random station, back to life.
You could tear your hair out over stuff like this.

¹ Classroom used an SJ clock which is much more configurable in mark and space sizes. Certain combinations would not be “seen” by the FileStore which would then start putting out it’s own clock signal. Really, it was best to remove all the links in the FileStore to completely disable the internal clock.

https://stardot.org.uk/forums/viewtopic.php?p=359632#p359632
Interesting, but it’s a Linux driver… anybody hacked RISC OS to be able to use one of these?

This actually looks ideal from the point of view of what I’m trying to achieve, at least on the hardware side. Having it running on Linux is ideal for a server / infrastructure project.

So if someone can get a Level4 daemon running on that hardware under Linux (I’d suggest a port to piCore for resilience) then we’re sorted. Use the Pi as a Level 4 server for both Econet and AUN/Ethernet. I’ll keep an eye on that project and perhaps when the Pi is no longer unobtanium I may get hold of a Pi 4 and experiment a little.

Next project – a ShareFS server for piCore Linux anyone?

You could tear your hair out over stuff like this.

And often did.

Really, it was best to remove all the links in the FileStore to completely disable the internal clock.

Really, it was best to remove the entire FileStore and bin it.

> Why not just run awServer on the Pi?

This is what I intend to do first and given I have packet exchange working between basic on my pi and a BBC its pretty close.
A full drop in replacement for the RISC OS Econet module is some way off though.

There is work being done over in stardot around the 6854 emulation but I am exposing the existing Pico Econet api to RISC OS on the pi via gpio in a way somewhat like scsi.

This picture
https://app.fieldinsight.com/scheduler/settings/documents/template/21287/
Shows my board in the foreground, the Ken Low linux stack mentioned earlier to the left, A filestore with a PICO board plugged in to its 2MHzE bus (waiting on a port of BEEB SCSI), and Ecolink at the bottom of the PC case.
I have two other versions of my Pi HAT one for Pi0 and one just USB, but they have no code yet. The latter is theoretically PinebookPro Econet.

I nice PCBA RP2040 Econet hat compatible with both Linux and RISC OS would be a super outcome but it may or may not happen.

https://app.fieldinsight.com/scheduler/settings/documents/template/21287/

Login page…

Ah sorry Rick.
https://app.fieldinsight.com/generic/files/download/00429965-7cd6-4f76-b8d2-3f0f51b89d88/

I think you’re missing a cable in there…

keep in mind that the Pi 4 offers improved performance and features compared to its predecessors. Since your preference is to run it on Linux, you might explore different distributions available for the Raspberry Pi, including piCore as you mentioned.

For your Level 4 daemon project, you’ll likely need to consider software development aspects, ensuring compatibility, and possibly making any necessary adaptations for the hardware and operating system environment. It’s a good idea to keep an eye on relevant projects and communities, as they can provide valuable insights, updates, and support for your endeavors.