Running a file server on RISC OS

I’ve recently got a Pi400 to run RISC OS having not touched RISC OS in ~25 years. Many programs I wrote back in the 90s are network based, so I’m keen to get networking setup, including running AUN on multiple networked Pis.

Back in the day, Level 4 file server was what I was used to. I’m curious what the options are today and if there are any articles on running a file server on RISC OS, specifically on RISC OS 5 running on Pis.

A quick Google / forum search hasn’t thrown up anything obvious.

Thanks in advance.

So Googling here, I find that AUN (in the RISC OS world) is ShareFS running over TCPIP, which allows it to be routed. ShareFS runs on a LAN only. This version seems to be part of the RISC OS 4 fork called Select (and later Adjust). Development in that fork seems to have stopped.

If you are running on rPi, then you’re almost certainly running RO5, which is the other branch of the fork. So if what I’ve read is correct, it doesn’t support AUN. However if all you want is to share across a LAN, then the standard sharing (ShareFS) is built in.

The other possibility is that you want non-RISC OS clients. In that case you have a choice of two servers, as far as I know. One is Moonfish, which is an NFS server. I haven’t used it. The other is SMBserver, which as it says serves SMB, allowing Windows to access it natively. My experience of it is that it is rather unstable and keeps crashing.

MOre googling. Level 4 file server seems to refer to Econet, which is an old version of the wiring. Current machines use Ethernet, and ShareFS runs happily over that with no additional software needed.

Yep I am running RO5.

I’m going to do some experimentation. I downloaded from the Store !MyShares and shared a folder with that; this then shows up (on the same Pi right now) under the “Discs” application (this is new to me).

To some extent actually sharing files is secondary .. in the sense that I’m keen on trying out some of the programs I originally wrote back in the day that somehow talked to the old server protocols.

Right now I see a “Net” app in the icon bar, and hitting this comes up with something that seems familiar — eg presenting “File server 0.254” and then asking for a username + password … so I’m wondering how I can run something that this can talk to.

I think I possibly need to dive deeper into that rabbit hole. I will report back after more experimentation.

Update: ShareFS does indeed work (between two Pis). Nice.

Still investigating the older legacy network features.

The complexity is in the fact everything has multiple names!

ShareFS/Discs/Access: this allows you to share entire discs or directories between RISC OS machines across Ethernet.

Net/AUN: this is typically where you connect to a ‘Level 4 file server’ and share files. The protocol was extended to work across Ethernet and TCP/IP, but has its roots in Econet (on the earlier Archimedes or BBC machines).

Your technology choice will depend on what you want to achieve.

ShareFS is probably the simplest option.

Another one is to use an ‘industry standard’ network share (a NAS with an NFS or Samba protocol on an Ethernet port). Then you can use OmniClient to connect to it.

Don’t suppose you know if there are any working Net/AUN options?

I found a copy of level4 but it doesn’t start; complains about a missing module. Will dig a bit deeper tomorrow.

I have two observations on using a Level 4 fileserver.

Ethernet is not a problem. Decades ago, I had a Level 4 system running on a collection of RiscPCs, A400s and an A4 all connected with Ethernet. It all worked perfectly.

However, Level 4 will not work on a 32bit Raspberry Pi. It needs old 26 bit hardware. (RiscPC, etc).

awServer?
http://heyrick.eu/econet/

Decades ago, I had a Level 4 system …

Me too! With BBC Bs on Econet and A3000s on Ethernet.

I still have copies of my Level4 and its support apps, but I would be pushed to know how to use them now.

[Level4] complains about a missing module.

Would that be WimpMan? I have dozens of old modules from that era and the WimpMan is v1.92 (13 Jun 1991).

awServer?

Ah! Fond memories. I took inspiration from that – not copying – and wrote my own server. It was surprisingly simple. I had it running in parallel to the L4 for a while, but it was never available to the pupils.

I had a FileStore E01S with 40MB (woo!) harddisc, and an MDFS with 200MB harddisc. Sadly something went badly wrong with the PSU of the MDFS and it fried the board, several Econet ports in other machines, and blew every single fuse back to and including the master fuse at the mains inlet. Mom was….not pleased.

Thankfully the line drivers all died valiantly, so no machines were lost.

The E40S eventually died, and finding some sort of replacement was practically impossible due to the weird way the FileStore bakes an identification into the drive in a write-once service page. I did find the same sort of Rodime drive, but no dice. And formatting… Pretty much impossible without the right hardware (IIRC a Master with a copro?).

I did briefly use Level4, but frankly the MDFS was better than anything Econet Acorn ever made, like, ever.

wrote my own server.

Me too. I called it LevelFive. Ho ho. But lack of interest and other things to do (I was getting into the BBS scene at the time) and it never got finished. Don’t know if I even have the code any more.

awServer looks perfect! And I love http://heyrick.eu/econet/

My current networking state is:

1. I have two Pis with static IPs on my local network (192.168.0.5 and 192.168.0.6); shareFS is working fine
2. My programs run fine; eg the Econet SWIs are available and callable; they even return sane network and station numbers (128.5 and 128.6)
3. Each machine can only see itself; this is using the Machines! program from Rick’s website, and also matches my own various random network software from the 90s — eg none of that can actually communicate with the other machine either

So.. something isn’t quite right with my AUN setup. I had some sneaky suspicion it might be that there’s a hardcoded expectation that the IP actually matches the network number. The AUNMap description always has this matching; perhaps that just complete luck.

So.. something isn’t quite right with my AUN setup. I had some sneaky suspicion it might be that there’s a hardcoded expectation that the IP actually matches the network number. The AUNMap description always has this matching; perhaps that just complete luck.So I need to try to figure out what I’ve got misconfigured since the machines can talk to each other; just not via AUN as far as I can tell.

I also tried running Level4; I just got rid of the RMEnsure that was trying to load WimpManager 1.00.

It tries to start, when using Aemulor, but then crashes because it says “No Econet Hardware”. So I guess that’s that.

Amusingly searching the net for AUN problems throw up an old thread from 2013 (which included Rick again! thank you!)

https://www.riscosopen.org/forum/forums/11/topics/1703

Ooh – AUN.

Didn’t that historically used to use a real world (IANA) address?
Changed a year or so back to a private address (might be in the Rick thread)
Or am I confusing something else?

I think you might be right, Steve.

Back in the old thread Rick said to use 1.0.129.2; the AUN map now says (in the inline help) to use 10.0.128.0 for example. I was sort of assuming this was just an example, but I’m now thinking it’s probably meant to be taken literally. I will figure out how to reconfigure my network to match and report back.

I think you might be right, Steve.

Back in the old thread Rick said to use 1.0.129.2; the AUN map now says (in the inline help) to use 10.0.128.0 for example. I was sort of assuming this was just an example, but I’m now thinking it’s probably meant to be taken literally. I will figure out how to reconfigure my network to match and report back.

Right, that discussion.

It was yours truly that pointed out that Acorn should never have used that IP range and encouraged the use of another from one of the private blocks.
10.0.0.0/8, 172.16.0.0/12 or 192.168.0.0/16.

Offhand I can’t recall whether the original 1.0.0.0 block use (and the change to 10.0.0.0) was baked in. Should be a config file.

I think it was always configurable. It was just unfortunate that the defaults were 1.0.0.0 rather than 10.0.0.0.

In my experience it wasn’t a massive problem. Don’t attempt to route a classroom of Archies directly to the Internet – use a proxy server. Job done.

Don’t attempt to route a classroom of Archies directly to the Internet

Until the internet became a thing and people were wanting to use it on their own machines, and then it was a big problem.

I wonder how much fiddling would be required to make it work with 192.168.1.x addresses? Then it can coexist with the rest of the world.

Proxy server? Invalid response from host! Better to fix the broken don’t you think?

I wonder how much fiddling would be required to make it work with 192.168.1.x addresses? Then it can coexist with the rest of the world.

I am currently using 10.0.128.x with a netmask of 255.255.0.0 and it coexists nicely with the rest of the world.

Offhand I can’t recall whether the original 1.0.0.0 block use (and the change to 10.0.0.0) was baked in. Should be a config file.

The earliest IP address I saw was 1.0.128.x (RISC OS 2) and it was in a config file (i.e. not baked in)

incidently 1.0.128.x (subnet 255.255.255.0) still works on my LAN but hides acceess to 256 real world internet adresses. One company in Thailand, I believe, so probably no great loss.

It was yours truly that pointed out that Acorn should never have used that IP range and encouraged the use of another from one of the private blocks.

The AUN Managers Guide has a 1992 copyright date. This is 2 years before RFC1597, never mind RFC1918 – at the time 1.0.0.0/8 was a popular choice for an unofficial private network, so Acorn certainly weren’t going out on a limb by choosing it.

For the record, RFC1597 came in for a fair amount of criticism when it was proposed in 1994 (see RFC1627) and it wasn’t until the release of RFC1918 in 1996 that the rest of the world learned that the IETF were going ahead with the idea after all.

Perhaps Acorn should have done something when RFC1918 was issued, but as far as I can see that would have been 4 years after AUN first appeared.

Trivia: On first reading RFC1627 I penned an open letter to the authors. The only place it ever appeared was alt.destroy.the.internet, so it is unlikely that any of the authors actually saw it at the time.

at the time 1.0.0.0/8 was a popular choice for an unofficial private network, so Acorn certainly weren’t going out on a limb by choosing it.

Cisco documentation still suggests 1.1.1.1 and a typical Cisco wireless controller will be using it.

I wonder how much fiddling would be required to make it work with 192.168.1.x addresses? Then it can coexist with the rest of the world.

Already can. You have to NAT all of the privates.
Intended use:
192.168.0.0/16 (set of 256 contiguous (class C) /24 blocks)
172.16.0.0/12 (set of 16 contiguous (class B) /16 blocks)
10.0.0.0/8 (one /8 (class A) block)

Of course with CIDR (that / stuff) the class A, B, C is ancient history

Interestingly here it suggests explicitly that you should be able to map from 192.168.0.x addresses.

http://www.riscos.com/support/developers/riscos6/networking/aunintro.html

To me this suggests that I’m not correctly configuring the AUN Map file. I’ll try that this morning and report back.