Econet LAN party – TNMoC 20th and 21st May 2023

[BeebMaster]

Although I have 17 machines on my Econet currently, as I showed on my eve-of-show screenshot, they weren't all on during the weekend.

Pi Bridge 77.254 was on Saturday & Sunday
A3010 L4 server 77.31 was on Saturday & Sunday
Also on Saturday I had a selection of other machines on all at the same time:
A5000 Station 50
Master 128 Station 1
Master 512 (though with co-pro off) Station 201
Domesday II (Master "AIV") Station 87

Definitely getting the machine peek call used by !Machines, *STATIONS, and my own "Machines!", to work across Pi Bridges would make for a more accurate count next time. I hope there is a next time!

[arg]

Talking of which, I'm sure there used to be a utility to display the bridge topology (by querying the various bridges), but I couldn't remember what it was called (which made it rather hard to check if I had a copy on hand!).

Anyone remember?

Not sure if Chris implements the relevant packets in the Pi bridge at present (though probably does).

[Lum]

For me, agree with the comment of I'm not 100% sure exactly what we did to help the museum, but it was a ton of fun, and I'm glad I went. Really appreciated the warehouse tour afterwards too!

I especially enjoyed pottering around ArenaII, moreso than Cave, it was like a little time capsule of late 80s grammar school drama. Like the Domesday machine in the other room has plenty of articles about kid's lives in the 80s, all sanitised and curated and very important, but ArenaII was closer to how I actually remember this time period, except my school never had a network so none of it got documented in a silly MUD where the school librarian is a dragon

I guess one thing that might be nice next time is figuring out more things to do on the Econet, and making times to do them together to see how they scale. Maybe also for those of us who are willing to let the general public touch our machines (and I realise not everyone is), make it into an event where paying people can come in and do these things? IDK.

[danielj]

To echo other comments - a great event (big thanks Tom & all at the Museum), and lovely to meet so many people and put faces to names.

Having done a couple of fix-a-thons and also this event at the museum, I think (hope!) the museum is getting a community engaged who are just very happy to help, enthuse, tell stories, impart knowledge, fix things, pour vinegar on stuff, share artefacts, and encourage other people to visit. And buy a few bits in the shop

I learnt a heap over the weekend including the practicalities of these old networks, why t-pieces are utter bobbins, how many batteries a communicator has in it, and how awful its MODE7 display update is.

Bravo!

d.

[BeebMaster]

Oh yes, I can vouch for how useless T-pieces are. I had my whole Econet held together by T-pieces for years after I decided to rip out all the socket box wiring one Easter and never put it back together again and it was so unreliable. Gladly it's all held together solidly with Ken's socket hubs now, plus two SJ socket boxes.

[Issue7]

I’m so glad everyone enjoyed it. The event did everything I expected of it. As the title suggests, it was primarily arranged as a social event. This gives lots of benefits to the museum, raising our profile and growing our contact list. And yes, we were hoping to kindle interest and get everyone to come back and help us with other things too!

This is the third large group event we have organised in the current era. This one was targeted specifically at the Acorn community, whist others have been more general. Previous events have been about repairing things. When planning these weekends, we do not know what skills people are bringing, so we have to be prepared with a range of tasks. That said, now I’m getting to know some of you we can be more targeted!

Our first two events focused on battery damage, and recapping BBCs and Cub monitors, both activities done with the power off and requiring no high voltage fault finding. I think these get the most out of the Fixathon format. Other repair activities can be more disjointed, often having to stop for a week while parts are obtained. If we do too many of these part-repairs at a Fixathon we can be left with several piles of bits, which are bad for restoration as they may stall and the machine ends up being in a worse condition than when we started.

So what’s next in the museum’s Acorn plans?
• Our next priority: Monitor repair sessions for people with experience working on live monitors.

• Improve weekend display – we can do better than a room full of basic prompts. We are currently running on a floppy only Filestore. If we can get more server space then each machine can run something interesting. We now have a program that reads the machine number and uses a CSV file to put a different program on each machine. So we just need to set up the SCSI to SD adapter – and this will be the third attempt! PS. Our MDFS is now working too. After the memory fault was fixed I then found the ROM was corrupt.

• Fixathons with a snip’n’vinegar theme. Go through our collection, stop the battery rot, image the disc, store nicely and update the museum records etc.

• Repair ‘clinics’ for set machines.

• And yes, another LAN party!

Tom

[arg]

• Improve weekend display – we can do better than a room full of basic prompts. We are currently running on a floppy only Filestore. If we can get more server space then each machine can run something interesting. We now have a program that reads the machine number and uses a CSV file to put a different program on each machine. So we just need to set up the SCSI to SD adapter – and this will be the third attempt! PS. Our MDFS is now working too. After the memory fault was fixed I then found the ROM was corrupt.

With the extra MDFSs you just acquired, and the drives belonging to them that I will return shortly when I have imaged and sanitised them, you should have enough for an MDFS+drive as your fileserver and a 'hot spare' pair on hand. While the MDFS could probably also operate from a SCSI/SD, I'm not actually sure that it's worth it just to preserve the hard drives - they are as likely to die from old age in storage as they are from regular use.

A teletext server also seems like it should be feasible as a permanent exhibit (obviously there's no more live teletext broadcasts, but there are Pi-based simulators that could drive a real BBC-micro teletext server, or modern kit could emulate the teletext server while keeping the authentic client on the BBCs).

[danielj]

• Improve weekend display – we can do better than a room full of basic prompts. We are currently running on a floppy only Filestore. If we can get more server space then each machine can run something interesting. We now have a program that reads the machine number and uses a CSV file to put a different program on each machine. So we just need to set up the SCSI to SD adapter – and this will be the third attempt! PS. Our MDFS is now working too. After the memory fault was fixed I then found the ROM was corrupt.

My MDFS is running fine with a SCSI-SD, but I seem to remember the one that you've got seemed to not behave quite canonically! - I'm pretty sure BlueSCSI2 should work okay with the MDFS - I'm intending to get one soonish and will report back. It has the added bonus of being rather cheaper than the scsi2sds...

The bit I find useful over hard drives is it takes seconds to restore from an image if I decide I want to take it back to a certain point in time or vanilla configuration - just restore the sd card from a previously hoovered image on a PC and you're away.

d.

[arg]

My MDFS is running fine with a SCSI-SD, but I seem to remember the one that you've got seemed to not behave quite canonically! - I'm pretty sure BlueSCSI2 should work okay with the MDFS - I'm intending to get one soonish and will report back. It has the added bonus of being rather cheaper than the scsi2sds...

Note that there are various modification levels of MDFS around with two modifications reflecting conformance to later revisions of SCSI spec. One was timing related, the other generated parity on outbound SCSI data (originally optional in the spec, drives started insisting on it).

The parity mod is tiresome in needing a PAL sitting on top of one of the MDFS chips, so probably best avoided by hacking the emulator to ignore parity (if indeed they check it in the first place), but the other mod is probably worth doing on any MDFS discovered without it.

The bit I find useful over hard drives is it takes seconds to restore from an image if I decide I want to take it back to a certain point in time or vanilla configuration - just restore the sd card from a previously hoovered image on a PC and you're away.

You can do a certain amount with copying partitions on an MDFS with a large hard drive, but have to admit you have a point there!

[danielj]

Note that there are various modification levels of MDFS around with two modifications reflecting conformance to later revisions of SCSI spec. One was timing related, the other generated parity on outbound SCSI data (originally optional in the spec, drives started insisting on it).

The parity mod is tiresome in needing a PAL sitting on top of one of the MDFS chips, so probably best avoided by hacking the emulator to ignore parity (if indeed they check it in the first place), but the other mod is probably worth doing on any MDFS discovered without it.

I did SCSI-2 on mine, but not the parity mod, so I'm fairly sure the emulators aren't too fussed about parity. It's the museum's SCSI2SD that didn't seem to be quite canonical in its behavior though - I'll have to ask @flibble what he remembers from when we were poking at it. The original intention was to get it to work with the filestore, but my recollection was that we couldn't get it to load the right version of the firmware. The filestore was very fussy about the drive identifiers it'd work with and needed a particular version of the sd2scsi firmware to let you change this! Fortunately the MDFS is rather less worried about things like that

[arg]

Fortunately the MDFS is rather less worried about things like that

For hard drives, yes. If you ever fancy emulating the 3M tape drive, you need to change the characters "3M" to "4M" in the manufacturer string in the appropriate SCSI page to circumvent the hack that prohibited third-party supply of the tape drives.

[Winston]

For a network project that can get the public engaged, music is always quite a good bet I think.

Over in the Spectrum world, we did this a few years ago (the Spectranet is my project, Matt Westcott ("Gasman") is part of the Spectrum demoscene and suggested we do this, and wrote the software to do it) - we got together for a museum event with a dozen machines to take on a challenge that Steve Vickers unwittingly set in the computer's manual back in the day. And it actually drew a bit of a crowd!

And there's no reason you can't do something like this with an econet network of course.

The Mahler Project: https://www.youtube.com/watch?v=LxPXLIALJJI

[BeebMaster]

There are lots of multi-user things we could do with Econet, and I am sure with a bit of thought we can do a lot better than Cave etc.

For timing reasons, I think it would be difficult to get multi-user shoot-em-up type games working reliably. Beyond me, but I'm sure someone could have a decent go at it.

I suppose in a sense from the user input point of view, all the game is doing is listening for keypresses on the actual machine, then reacting, updating the screen etc. For an Econet game, an extra step would be required to listen for keypresses on the remote station, then react to that by updating the status of the second player. Probably some sort of periodic sync would be sensible to make sure the two, or more, machines don't get too far out of step.

Plenty of card games or board games could be adapted to be Econet multi-user. With these the timing is less critical, the computer has to wait until the remote user has made his move then update accordingly, and I am sure that's a lot easier than trying to do real-time updates of an arcade kind of game.

Chess might be a good place to start, if any of the existing chess games have the source code available. Just replace the computer move with listening for a remote move on another station. Though I'm sure it isn't a simple as I am suggesting!

Music as well, of course, with multiple different channels being played on different machines in sync, or there's that scrolling screen message system across multiple stations which I really must try here soon.

[aerobaticant]

Hi all,

I'd like to add my appreciation to Tom, Lee, Jacquie, et. al. for arranging this weekend. Well done and thank you!

I thoroughly enjoyed myself with a group of like-minded people. It was great to put faces to names/stardot handles. As I probably said a few times, name badges with *I AM <name> <handle> might have been a useful addition.

My Atom did feel a little lonely. Maybe that was a factor in it throwing a tantrum (when playing Chuckie Egg) and taking down the network!
Anyone know why *CAT from the MDFS doesn't list any files on the Atom? The PiEconetBridge fileserver works well.

Here's looking forward to the next one.

Ant.

[arg]

Anyone know why *CAT from the MDFS doesn't list any files on the Atom? The PiEconetBridge fileserver works well.

Because Atoms had faded from the education/econet scene very early on and (to my regret) MDFS didn't bother implementing the protocol extensions that Atoms need. BBCs decode *LOAD, *SAVE, *CAT locally and go directly to the specific protocol for those operations. The Atom always sends the whole command line to the fileserver (as BBCs do for unrecognized commands), and the fileserver then sends back to the Atom "That was a *CAT you know!", the Atom then goes "So it was!" and then issues the next step using the exact same protocol as the BBC.

So there's just that small step missing. As and when I get back into a position to re-compile the MDFS from source, I will add the feature back - there seems to be more demand for it in 2023 than there was in 1983!

[BeebMaster]

As and when I get back into a position to re-compile the MDFS from source, I will add the feature back - there seems to be more demand for it in 2023 than there was in 1983!

Ooo am I able to send in my wishlist of new features please please?

[Ragster]

For timing reasons, I think it would be difficult to get multi-user shoot-em-up type games working reliably. Beyond me, but I'm sure someone could have a decent go at it.

I've been thinking about it... and reading the advanced Econet manual ... the network protocols really are very primitive. But I'm wondering how much of a connection layer can be put on top of what's there without imposing too much of a burden on the (let's face it, by modern standards) limited processing capability.

The optimum model I've envisaged for actual arcade type game is a server-based one, with a dedicated machine handling the state of the game world, and sending out broadcast updates with state changes regularly. Clients send their intended move information, then redraw the world (from their perspective) based on the broadcast updates received.
That way the server doesn't have to worry about about any screen rendering - probably best to use a co-pro machine so the IO processor can worry about servicing the network, and the 2nd processor can handle the game world and rules, and generating the messages to be sent. Clients would only have to worry about screen rendering, user input and sending updates and listening for broadcasts. The occasional dropped packet would be more annoying than a disaster.
Not sure what sort of throughput could be managed.

I'm imagining something like a Cholo type thing, but multi-player - a free for all tank battle maybe.
The graphics may be beyond me - I'm a back-end sort of guy, and it's been a long time since I did anything in 6502 assembly.
If I can get the 6502 C compiler working for me, I might give it a go, time permitting. That way, it should be potentially possible to compile for RiscOs too (although I only have Beebs to play with.)

But for September might be a big ask...

[arg]

. the network protocols really are very primitive.

Note that there were higher layer protocols defined at the time (such as that used in *FAST), so if you want a TCP-like protocol you don't need to re-invent the wheel. OTOH, the basic Tx is reliable (so is more than what UDP gives you). But they do have their unique properties, and importing expectations from a TCP/IP world view can lead to poor results.

broadcast updates with state changes regularly.

Note that broadcasts are small and unreliable. So they are great for transmitting a synchronisation 'heartbeat' or some minimal update info that can get replayed later, but any significant volume of data needs to be in ordinary packets.

[Ragster]

. the network protocols really are very primitive.

Note that there were higher layer protocols defined at the time (such as that used in *FAST), so if you want a TCP-like protocol you don't need to re-invent the wheel. OTOH, the basic Tx is reliable (so is more than what UDP gives you). But they do have their unique properties, and importing expectations from a TCP/IP world view can lead to poor results.

Interesting - I've not seen references to those in the literature I've found so far. Will have a further hunt.

broadcast updates with state changes regularly.

Note that broadcasts are small and unreliable. So they are great for transmitting a synchronisation 'heartbeat' or some minimal update info that can get replayed later, but any significant volume of data needs to be in ordinary packets.

Small, I had noticed, and was wondering how to work around that - 8 bytes isn't a lot to work with. Streaming a set of broadcasts might be feasible, if the data is very tight - but if they're unreliable, that might not work.
I wondered if using the broadcast to send an 'update available' message, followed by each client that chooses to then requests a PEEK for a pre-determined block which contains the world data (agreed in the setup handshake.)
That would involve separate read requests for each client though, which would fairly quickly cap the number of clients that could be serviced. Might be ok - would need to test, if I had the available machines.

Obviously, no security or safety involved anywhere, of course.

[aerobaticant]

Anyone know why *CAT from the MDFS doesn't list any files on the Atom? The PiEconetBridge fileserver works well.

Because Atoms had faded from the education/econet scene very early on and (to my regret) MDFS didn't bother implementing the protocol extensions that Atoms need.

That would do it.

[Winston]

I'm imagining something like a Cholo type thing, but multi-player - a free for all tank battle maybe.

This is what we did on the Sinclair Spectrum with the Spectranet, a game called Spectank. Client/server based. The server kept game state ("authoratative game server" - the clients sent move requests and the server figured out if they were valid), and also served up the map (this bit is more demanding of the network - I could do that with the Spectranet as it can max out the memory bandwidth of the Spectrum - the network really isn't the bottleneck here). You could take this demand off of the network by having the map done (and collision detection with the map) done entirely client side.

Here's a video of a Spectank tournament we did in Spain for the machine's 30th anniversary at RetroEuskal: https://www.youtube.com/watch?v=6fEvuENABZY

The game is basically a 2vs2 capture the flag. The match making was done in a separate program, that then loaded the main game so match making didn't have to live in memory while the game was running. I also did a spectator client for the RPi so we could put a map on a projector so that spectators could see the whole game (we used this at a subsequent RetroMañía in Zaragoza)

[Ragster]

I'm imagining something like a Cholo type thing, but multi-player - a free for all tank battle maybe.

This is what we did on the Sinclair Spectrum with the Spectranet, a game called Spectank. Client/server based. The server kept game state ("authoratative game server" - the clients sent move requests and the server figured out if they were valid), and also served up the map (this bit is more demanding of the network - I could do that with the Spectranet as it can max out the memory bandwidth of the Spectrum - the network really isn't the bottleneck here). You could take this demand off of the network by having the map done (and collision detection with the map) done entirely client side.

Here's a video of a Spectank tournament we did in Spain for the machine's 30th anniversary at RetroEuskal: https://www.youtube.com/watch?v=6fEvuENABZY

The game is basically a 2vs2 capture the flag. The match making was done in a separate program, that then loaded the main game so match making didn't have to live in memory while the game was running. I also did a spectator client for the RPi so we could put a map on a projector so that spectators could see the whole game (we used this at a subsequent RetroMañía in Zaragoza)

Sounds like you should do it!

[flibble]

A quick note to say thanks for all at TNMOC for organising this, I had a great time.

Attached a few pics I took over the weekend.

[paulb]

A quick note to say thanks for all at TNMOC for organising this, I had a great time.

A Spectar II or Briefcase Communicator, too! Did that go on the network as well?

[Vee]

the network reliability was pretty lively, certainly on network 4 where I was recording this!

Hey, I was trying my best, but those T pieces were not helping!

Still, I think an excellent time was had by all (apart from my own Beeb which never got onto the Econet).
And big thank you to you all for coming, especially to everyone who travelled long distances to get to Bletchley.

September then

All the best,
Lee

PS. And yes, definitely "*I AM <name> <handle>" badges for next time.

[8271]

I unfortunately missed this event - hope to join the next one and can bring a haul of 18 econet & AUN machines if they can fit in the van.

In terms of a demo, what about trying to reinact the famous 1980's TV programme - Strike it Lucky! - From memory that was 32 econet bbc micros or A3000s

https://www.youtube.com/watch?v=bCNBKzE50P4

[WrightStuff]

Small, I had noticed, and was wondering how to work around that - 8 bytes isn't a lot to work with. Streaming a set of broadcasts might be feasible, if the data is very tight - but if they're unreliable, that might not work.
I wondered if using the broadcast to send an 'update available' message, followed by each client that chooses to then requests a PEEK for a pre-determined block which contains the world data (agreed in the setup handshake.)
That would involve separate read requests for each client though, which would fairly quickly cap the number of clients that could be serviced. Might be ok - would need to test, if I had the available machines.

Obviously, no security or safety involved anywhere, of course.

What happens to broadcast packets when they hit a bridge ? Are they re-broadcast on the other side ?
Is this the same for legacy bridge v PiEconetBridge ?

Also after a bit of head scratching recently I noticed the Econet Advanced User Guide seems to wrongly specifiy the control block for broadcast.
This is wrong :

Code: Select all

cblock?0=<ctrl byte>
cblock?1=<port>
cblock?2=&FF
cblock?4=&FF
cblock!8=<8 byte buffer>

This is correct (Econet System User Guide) :

Code: Select all

cblock?0=<ctrl byte>
cblock?1=<port>
cblock?2=&FF
cblock?3=&FF
cblock!4=<8 byte buffer>

[BigEd]

In terms of a demo, what about trying to reinact the famous 1980's TV programme - Strike it Lucky! - From memory that was 32 econet bbc micros or A3000s
Strike it Lucky (1993) with Michael Barrymore!

Interesting! I found this from BBC Acorn User May 1990, which reckons initially 8 Masters were slaved to a ninth. I'm supposing then that only 8 distinct digital images are needed on the 32 monitors.

[IanS]

In terms of a demo, what about trying to reinact the famous 1980's TV programme - Strike it Lucky! - From memory that was 32 econet bbc micros or A3000s

I'm sure I've read somewhere that it was only 8/10 machines with a big video switch, but I' can't find the details now. So it wasn't actually possible to go across the "board" in one go, as there wern't enough unique video outputs for each screen.

[arg]

What happens to broadcast packets when they hit a bridge ? Are they re-broadcast on the other side ?

They are. However, the reliability reduces. Reliability on a single network is reasonable (provided the sending station has collision detect hardware) - if successfully sent they are highly likely to be received by all listening stations, and if not sent you get to know about it and retry.
However, if they successfully transit the local network and reach a bridge, but then hit a collision on the other side they are lost and you don't get to know.

I don't want to overstate the reliability issue - they've been widely used across heavily bridged networks with success, but in styles of use where dropping the occasional packet doesn't matter (either because they get retried - like the find-printer usage - or because the content is ephemeral and superceded by the next one).

Is this the same for legacy bridge v PiEconetBridge ?

Above is for legacy bridges; it wouldn't be surprising if there were some corner cases in the many configurations supported by the Pi bridge, but they will probably get fixed if you find them.

Also after a bit of head scratching recently I noticed the Econet Advanced User Guide seems to wrongly specifiy the control block for broadcast.
This is wrong :

While it's good to have a selection of different sources to refer to, I would recommend the SJ Fileserver Manual (chapter 10) as the most complete/accurate reference for the various layers of Econet protocols. It's not perfect, but a lot of effort was made to collate the different sources of info, clarify which things were SJ-specific, Acorn-specific or universal etc.