Elite over Econet (BBC Master, 6502SP, BBC Micro)

[MarkMoxon]

The catalogue works fine now on the SP version.
When you put them side by side there are a few differences. Title, colour and interestingly the Front Shield/Aft Shield and Shield 1,2,3,4 in the console are filled in the SP version.

The SP version shows the competition number when saving, the M128 doesn't. The SP version doesn't have the menu option 5 - Default Jameson that the M128 has.

Yes, the 6502SP and Master versions differ quite a lot - the differences in text colour are particularly noticeable, and there wasn't a competition for the launch of the Master version, so there's no code.

That "DRIVE A" bit in the title is wrong though, so I'll switch it to "CATALOGUE", like the Master version. Thanks!

Thankfully the saves seem compatible between the two versions.

Excellent. Interestingly, you can switch commander files between all the different Acornsoft versions - you can even load your Electron files into Master Elite if you want to. And each file makes a note of the different versions that its been loaded into, even differentiating the two different disc versions. I think it's competition-related.

Setting the Master ET as station 129 solves the issue and it is possible to load/save/catalogue. The CMOS isn't corrupted so it will be the station byte in the workspace as you say. Strange that the Master 128 is ok (v3.20) - I haven't tested 3.50 yet. When pressing Break on the Master ET I get the message "Bad NET checksum" indicating that the station has been corrupted.

Just to be sure, I changed my Master's station number from 129 to 64, and it all works on both MOS 3.20 and 3.50. So this does appear to be ET-specific (with the Compact untested for now).

I'll look through the code again for anything suspicious, but this is a tricky one. Thanks for all the testing, it’s really useful.

Mark

[MarkMoxon]

That "DRIVE A" bit in the title is wrong though, so I'll switch it to "CATALOGUE", like the Master version. Thanks!

This is now done, updated version at https://www.bbcelite.com/versions/elite ... econet.ssd

This is starting to look like a releasable version - thanks for all the feedback, and if anyone has any suggestions for the ET issue, I'm very happy to try things out.

Mark

[Rich Talbot-Watkins]

Ha, for a moment I thought you'd implemented this for reals!

[MarkMoxon]

Ha, for a moment I thought you'd implemented this for reals!

Ha! Not seen that before, nice one.

Though this part's a bit rough, even for the 1980s:

"Players may choose between piloting trading ships, police ships or Thargoid craft, while some of our lady readers may like to try their hand at being space-stations."

Um... OK.

Mark

[gavinlew]

There are some Econet Master Compacts about, JGH and Ian J have one, probably others. Including me, but it's not here, nor my ET. I'd really like to know how come the ET gives this Who are you?/Station number corruption error when the M128 doesn't.

In 2024 I am planning an enhanced BeebRoom with a greater variety of machines on my Econet, including Electron, ET, Compact, FileStore and MDFS, all of which are currently absent.

I have an Econet enabled master compact if can help in anyway

[MarkMoxon]

I have an Econet enabled master compact if can help in anyway

Well, I'd really like to know if Elite works on a Compact whose station number isn't set to 129, just in case the ET issue we're seeing is also present on the Compact. Instructions for downloading and deploying Elite over Econet are in the first post.

Any feedback on how this works on a Compact would be really valuable, really! Thank you.

Mark

[markusher]

I tried using the debugger in BeebEm with the Master ET OS etc. to see if the STN is changed. The debugger keeps crashing BeebEm but it seems that &0B01 is not affected after selecting option 3. Catalogue - so the station number may be corrupted elsewhere on the real hardware but not in the emulator.

[MarkMoxon]

If anyone knows much about MDFS, I have a question.

I'm getting reports that Econet Elite doesn't load across MDFS networks (it's fine on FileStore servers on the same network). It hangs somewhere during the loading process (it shows the Saturn, but freezes at that point).

I have no idea what the differences might be between MDFS and FileStore servers as far as the client is concerned - anyone any thoughts? This is happening on a Master with ANFS 4.25. *ELITEM works fine from a FileStore floppy, but hangs when loading the same binaries from an MDFS fileserver.

Are there any differences between things like star-commands or library settings on MDFS? The game does use shortcut star-commands, so if they behave differently, it could be that?

Really not my area of expertise this, so any suggestions gladly received!

Mark

[MarkMoxon]

I’ve had a look at the code, and Econet Elite uses *DIR with no arguments to go to the user’s main directory. Does anyone know if this command is supported on MDFS? The other commands in Econet Elite look pretty standard, but this one’s worth checking.

Edit: Have downloaded the manual and *DIR with no argument should work. Hmm.

Mark

[arg]

One difference is that ordinary LOAD (or OPEN) will look up files in the library (same as *RUN does), so if you are expecting to get "file not found", under some circumstances it will find something from the library.

Abbreviated star commands could be an issue as it supports more commands - depends which ones you are talking about.

Do you have any other machines on your network on which you can run netmon? (I can assist with decoding netmon traces if reqd).

[MarkMoxon]

One difference is that ordinary LOAD (or OPEN) will look up files in the library (same as *RUN does), so if you are expecting to get "file not found", under some circumstances it will find something from the library.

Interesting, though I don't think that will break loading, as all the files should be there.

Abbreviated star commands could be an issue as it supports more commands - depends which ones you are talking about.

The star commands run after the Saturn is drawn are:

Code: Select all

*L.ELTBD FFFF1300
*L.ELTBC FFFF1300
*DIR
*DIR ELITE

The two ELT files should be present in the current directory. This loads the two parts of the game (relocating the first one before loading the second), and then switches to the ELITE folder in the user's home directory.

Does *L. do a *LOAD on MDFS? I guess it could do something like *LIB instead. It's easy enough to expand these to their full commands and see if that helps - I might give that a whirl, if only to rule out the OSCLI part.

Do you have any other machines on your network on which you can run netmon? (I can assist with decoding netmon traces if reqd).

This is the TNMOC network, so I only have access myself every now and then, or when the network admins are on-site.

If anyone has their own MDFS server setup and is able to try this and poke around in the logs, that would be handy. Or this might be a fun job for TNMOC's next Econet LAN party!

Mark

[arg]

*L. should be OK as that's a MOS-implemented command: the abbreviation will be resolved locally and the fileserver never gets to see it.

*DIR will take you to the user's home directory (URD); the one other thing that's different is that the URD could be anywhere (any directory, any drive), rather than being more regimented as $.<username> which does sometimes give trouble if programs "think they know" where the URD is. But it sounds like you are doing the opposite to that.

Access permissions are another area, though MDFS should be less troublesome than other fileservers in that respect: on MDFS, access permissions to a given file/directory are always the same (based on the identity of the user), independent of the pathname you use to get there. So on an Acorn FS, accessing "fred" (assuming your current directory is the user's URD) will give you owner access rights, while accessing the same file as
$.<username>.fred will only give you public access rights. MDFS knows whether or not you own the file, and will give you the appropriate rights whichever pathname you use. Conversely, on MDFS you can't assume that you own all (or any!) files in your URD - normally you will, but the administrator can set things up differently if they so wish. This is particularly applicable to games, where it used to be common practice to set up a 'games' user which had read-only access to the games files but no access to write to anything.

However, nothing in that lot suggests any reason for trouble in your particular case.

[MarkMoxon]

However, nothing in that lot suggests any reason for trouble in your particular case.

Thanks for the help so far - it’s good to know it’s nothing obvious.

I might have to try fixing this in situ, maybe at the next LAN party. Though if anyone has an MDFS server and fancies having a play, it would be useful to know if this is a problem with all MDFS servers, or something specific to the TNMOC setup. All clues are potentially useful…

Mark

[BeebMaster]

Has Econet Elite been tested with MDFS using BBC B?

One difference between Acorn and SJ servers is that the MDFS generally doesn't use "FIndLib" for Master stations as all the library utilities are in $.Library and there isn't a separate Library1 usually on MDFS. As Library files tend to load around &E00, it means it's essential for Master stations to use the SPACE configuration setting to push PAGE up to &1000 to stop Econet library commands corrupting user RAM.

So something along those lines could be happening with Econet Elite on MDFS with a Master station.

However, that would also signify something else going wrong, which isn't going wrong on an Acorn file server. It might mean when run from MDFS, a Library utility is being loaded by the Master somehow, which it shouldn't be.

[Issue7]

Here's a thought:
Does it make a difference that Elite is on a different drive to the library and URD? On TNMoCs Filestore and MDFS, we log in as TNMOC, which lives on Disc1. Elite is on Disc2 on both servers. Does the *DIR command issued by Elite have an effect on this if it’s on the wrong drive for the Elite files?

The file structure is as follows for both servers:

Code: Select all

Disc1
>Library
>>EliteM
>>EliteSP
>TNMOC

Disc2
>Elite
>>Elite files etc

We don’t yet have a library1 on the Filestore (or the MDFS).

To use the file on the MDFS, we tried the following:

Code: Select all

*I AM 6.253 TNMOC
*DIR $Disc2
*EliteM

This stops with an unaninated image of Saturn.

Because the Filestore doesn’t like *DIR $etc, I used this:

Code: Select all

*I AM TNMOC
*SDISC Disc2
*EliteM

This worked. Unfortunately I did not try *SDISC on the MDFS

In case it was a bridging issue, I tried unplugging the bridge and talking direct to the MDFS. This actually made it worse, and the Master crashed before getting to any Elite graphics. Note sure why this happened, either network corruption or Elite got to an error message a little quicker?

Otherwise both servers are working fine, able to load and save files without problem.

Oh and the MDFS has been on continuously for about 3 months too!
Tom

[MarkMoxon]

Has Econet Elite been tested with MDFS using BBC B?

I'm hoping to get some results on that this week, which should tell us whether this is a Master-specific issue. I'd be surprised if Master Elite was loading any &0E00 library programs during its load process, but if it did, that would almost certainly break things.

Here's a thought:
Does it make a difference that Elite is on a different drive to the library and URD? On TNMoCs Filestore and MDFS, we log in as TNMOC, which lives on Disc1. Elite is on Disc2 on both servers. Does the *DIR command issued by Elite have an effect on this if it’s on the wrong drive for the Elite files?

I don't know what effect that might have on Elite, but there's an easy way to find out! We could try entering the exact same commands that Elite runs during its loading process, and see if any of them give errors or do the wrong thing on MDFS.

So here's the full set of *-commands when loading Econet Elite. If any of these fail, then that would break things. Perhaps we could try entering these commands on the TNMOC network to see if any fail, replacing the *RUNs with *LOAD to stop things actually running.

The *EliteM command simply does the following commands:

Code: Select all

*DIR $.Elite
*RUN ELTMC

ELTMC then draws the Saturn and issues the following commands:

Code: Select all

*L.ELTBD FFFF1300
*L.ELTBC FFFF1300
*DIR
*DIR ELITE

So if you log onto the MDFS system using the normal login commands that you would enter before *EliteM, and then instead of runing *EliteM, try the following, and see if anything fails?

Code: Select all

*DIR $.Elite
*LOAD ELTMC
*L.ELTBD FFFF1300
*L.ELTBC FFFF1300
*DIR
*DIR ELITE

If these all work and you end up in the Elite directory in your user directory, then this probably isn't a star-command issue. But if you get any errors, then it's a clue!

Mark

[markusher]

Does EliteSp have the same commands and sequence?

[MarkMoxon]

Does EliteSp have the same commands and sequence?

It’s similar, but the names are different and it’s split between the Parasite and I/O Processor. The code runs in the I/O Processor and does the following when *EliteSP is run from the library.

Run the following in the I/O Processor:

Code: Select all

*DIR $.Elite
*RUN ELTSP
*R.ELTIE
*R.ELTIC -> runs in I/O Processor and terminates
*R.ELTPC -> runs in Parasite 

And then these get run in the Parasite before jumping into the game:

Code: Select all

*DIR
*DIR ELITE

Note that one file is intentionally called ELTIE, just to throw you.

Mark

[BeebMaster]

I think changing discs is a likely cause of the problem, as the behaviour is different between MDFS and Acorn file servers.

*SDISC on an Acorn file server will "permanently" select that disc, so any subsequent navigation commands (omitting a disc spec) will operate on that disc.

On MDFS, *SDISC will select the disc, but *DIR alone will return you to the disc on which the user root directory is stored.

(See MDFS manual chapter 3, c. page 109).

So I think when the Elite code is doing *DIR it will be changing discs back to the original disc, which doesn't have the Elite files in the correct place.

I think the way round this is to do *DIR :Disc2 after logging on (which I think should "permanently" change the selected disc on MDFS in the way that SDISC does on an Acorn file server, but the MDFS manual doesn't give an example for this use of *DIR) and then to run Elite, use the full pathname so that it finds it on the other disc (e.g. *RUN :DISC1.$.EliteM).

(I don't think *DIR $Disc2 does anything by the way, unless it truncates the command line after the $, and therefore selects the original disc root, which again may be a cause of what's going wrong).

[MarkMoxon]

So I think when the Elite code is doing *DIR it will be changing discs back to the original disc, which doesn't have the Elite files in the correct place.

At this stage all the game binaries are loaded into memory, so the only network access that's required from that point is when loading and saving commander files, and that only happens if you explicitly use the load/save menu. So if the *DIR command on MDFS is working, that shouldn't cause things to crash, and it should presumably select the correct directory (the user folder) so the *DIR ELITE will also work?

I think.

Mark

[BeebMaster]

Somebody with a working MDFS will have to test, but I think what may be happening is still related to the way changing disc is different on the MDFS. I think *DIR still puts you in the URD of the original disc in which case this will be the sequence:

User Logs on, URD is on Disc1.
User changes to Disc2 (but the library on Disc1 is still selected)
User does *ELITEM, this is searched in the current library, which is on Disc1, so works.
Elite does *DIR. User is put back in URD on Disc1
Elite does *DIR ELITE - falls over because there is no Elite directory on Disc1, it's on Disc2.

(And to correct myself earlier, MDFS manual p3.3 confirms that *DIR $<disc> is a valid alternative to *DIR :<disc>)!

[MarkMoxon]

Elite does *DIR ELITE - falls over because there is no Elite directory on Disc1, it's on Disc2.

That ELITE directory is inside the user’s main directory - it’s where the commander files are saved and is on Disc1. If it doesn’t exist then the game will hang with an error, but then it wouldn’t work on FileStore either. It is distinct from the $.Elite folder on the file server that contains the game binaries, which is on Disc2.

If permissions on <URD>.ELITE were problematic then that might cause a hang, but we’re logged in as us and we’re in our own main directory, so that would be odd!

Mark

[BeebMaster]

Are you sure, the disc structure posted earlier only has one Elite directory, on Disc2 (unless there's an Elite sub-directory within TNMOC which wasn't shown):

Here's a thought:
Does it make a difference that Elite is on a different drive to the library and URD? On TNMoCs Filestore and MDFS, we log in as TNMOC, which lives on Disc1. Elite is on Disc2 on both servers. Does the *DIR command issued by Elite have an effect on this if it’s on the wrong drive for the Elite files?

The file structure is as follows for both servers:

Code: Select all

Disc1
>Library
>>EliteM
>>EliteSP
>TNMOC

Disc2
>Elite
>>Elite files etc

[MarkMoxon]

Are you sure, the disc structure posted earlier only has one Elite directory, on Disc2 (unless there's an Elite sub-directory within TNMOC which wasn't shown):

Here's a thought:
Does it make a difference that Elite is on a different drive to the library and URD? On TNMoCs Filestore and MDFS, we log in as TNMOC, which lives on Disc1. Elite is on Disc2 on both servers. Does the *DIR command issued by Elite have an effect on this if it’s on the wrong drive for the Elite files?

The file structure is as follows for both servers:

Code: Select all

Disc1
>Library
>>EliteM
>>EliteSP
>TNMOC

Disc2
>Elite
>>Elite files etc

Good point! I don't know the answer, that's a question for Issue7. Though if there wasn't an ELITE folder within TNMOC, wouldn't it also fail to run from a FileStore? Unless the FileStore is the one ending up in the wrong place on MDFS, and there happens to be a folder called ELITE in wherever it ends up!

Interesting stuff...

Mark

[BeebMaster]

If I'm right about the difference in changing discs between FileStore and MDFS, then it would work on the FileStore, because *DIR will put you in a $.<username> on the current disc (ie. Disc2 in this case), if it exists, or just $ if it doesn't, in which case *DIR ELITE would then work as there appears to be $.Elite on Disc2.

But on the MDFS, *DIR changes you to :<original disc>.$.<username>, so we are then in :Disc1.$.TNMOC, then *DIR ELITE doesn't work as there is no :Disc1.$.TNMOC.Elite.

[MarkMoxon]

If I'm right about the difference in changing discs between FileStore and MDFS, then it would work on the FileStore, because *DIR will put you in a $.<username> on the current disc (ie. Disc2 in this case), if it exists, or just $ if it doesn't, in which case *DIR ELITE would then work as there appears to be $.Elite on Disc2.

But on the MDFS, *DIR changes you to :<original disc>.$.<username>, so we are then in :Disc1.$.TNMOC, then *DIR ELITE doesn't work as there is no :Disc1.$.TNMOC.Elite.

This sounds very promising! I will try to find out. If this is the cause, that’s a great bit of detective work!

Mark

[BeebMaster]

I have !SoftMDFS on my RISC PC, so as long as it's authentic MDFS behaviour, I can test.

I exported my usual RISC PC Level 4 export as "Disc1" and the RPC RAM Disc as "Disc2" and made a directory $.Elite on Disc2.

If I log on as IAN, I am in :Disc1.$.IAN, then if I SDISC to Disc2, *DIR keeps me on Disc2 so *DIR Elite works (so this is FileStore behaviour, but *SDISC wasn't tried at TNMOC, and this isn't the SDISC-followed-by-DIR behaviour the MDFS manual specifies (but could be incorrect implementation in !SoftMDFS):

*DIR $Disc2 doesn't change discs at all, but puts in me in the root of Disc1 instead of my URD (it's actually just doing *DIR $ as anything after $ is ignored, e.g. *DIR $RUBBISHHERE also puts me in $) (but again this could be incorrect implementation in !SoftMDFS), but then *DIR followed by *DIR Elite do not work as we're not where we thought we would be after changing disc, because !SoftMDFS didn't actually change disc):

*DIR :Disc2 works to change to Disc2, but then *DIR puts us back on Disc1 in my $.IAN URD and so again *DIR ELITE fails:

There's nothing on Disc2 apart from the directory Elite, so we can also see that the Library directory isn't being changed by any disc change command, as it stays as Library1, which means the originally selected library at log-on will still be searched for "EliteM" even after changing discs.

[MarkMoxon]

So if I’m following, it looks like the main issue is that *DIR on its own does not always take you to your user directory on multi-disc setups, and this is where things go wrong with Elite (and this issue can happen on both FileStore and MDFS, assuming your first test is true for real MDFS servers). Is this right?

If so, then I guess the next question is whether there is another way of reliably going to the URD from an arbitrary current directory. For example, can a the full path of the URD be found somehow, and injected into a *DIR command that way?

I may have the wrong end of the stick here, though - apologies if I’m being thick.

Mark

[james]

Does "&" work? ie

Code: Select all

*DIR &.ELITE

FWIW, the MDFS manual http://8bs.com/othrdnld/manuals/sjresearch.shtml

There are other special symbols that can be used in pathnames: & stands for the pathname of your User Root Directory
[...]
Using *DIR without a pathname will return you to your User Root Directory

The Econet documents I have don't appear to mention & at all, but this comment in the Master Reference Manual Part 1 under ADFS implies it exists:

& is equivalent to $ (ie the root directory) and is included for compatibility with the Advanced Network Filing System (ANFS).

[MarkMoxon]

Does "&" work? ie

Code: Select all

*DIR &.ELITE

FWIW, the MDFS manual http://8bs.com/othrdnld/manuals/sjresearch.shtml

There are other special symbols that can be used in pathnames: & stands for the pathname of your User Root Directory
[...]
Using *DIR without a pathname will return you to your User Root Directory

The Econet documents I have don't appear to mention & at all, but this comment in the Master Reference Manual Part 1 under ADFS implies it exists:

& is equivalent to $ (ie the root directory) and is included for compatibility with the Advanced Network Filing System (ANFS).

Interesting. I started out by using &, but as you say, none of the official Econet manuals seem to mention it, though they do mention *DIR on its own, so I assumed that the latter would be the more compatible option. But if "*DIR &" works correctly on more systems, then that might make things a bit more reliable.

Does anyone know how well supported "*DIR &" is with the various servers (or versions of NFS if it's an NFS thing)?

Mark