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

[BeebMaster]

Not very I think. It's probably all right on the FileStore, which should support these what Acorn call "pseudo" directory symbols, &, % etc. It's an assembler option in the Level 3 file server code to turn them on, so you can't guarantee that any particular build of the Level 3 FS will support them.

A bit of a knotty problem I think, though I would say it's fairly unusual to have files relating to one particular use - ie. the game Elite in this instance - split across two different file server discs.

What we really need is RISC OS style aliases so we can use things like Obey$Dir etc. but we don't have that luxury on Beebs!

[MarkMoxon]

Not very I think.

So I just tried *DIR & on my Level 4-based network, and now I remember why I ditched it in favour of plain old *DIR.

*DIR & works correctly on my Master with ANFS 4.25 and takes me to my URD, but the same command just gives a "Not found" error on my Model B with NFS 3.60. This is all on the same network with the same server, so I'm guessing it's also related to the NFS version?

*DIR on its own works fine on both, but then I only have one server.

Mark

[BeebMaster]

Hmmm yes. I just tried on L3 server 1.33, which I built from source including the pseudo-directory symbols option, and *DIR & works in all cases.

However, on version 0.92 which I think is unlikely to support these symbols, BBC B with NFS 3.60 gives "Not found" but ANFS BBC B or Master works - and the file server monitor screen shows the command received from ANFS stations is just "DIR" whereas it's "DIR &" on the NFS station. So it seems like ANFS is trapping *DIR & and just sending *DIR to the file server.

Also Level 4 FS does the same as L3 0.92!! I suppose I shouldn't be surprised, my less than complimentary opinion of L4FS is fairly well known I think!

A way forward can be found, I'm sure, but we may need to devise a fairly convoluted loader which checks the (A)NFS version and also checks the file server version (ie. Acorn vs MDFS), so it knows which commands to issue. Maybe then it could overlay the correct set of * commands after the main code has been loaded, if we can make sure the start point of each * command is always in the same memory location?

[MarkMoxon]

A way forward can be found, I'm sure, but we may need to devise a fairly convoluted loader which checks the (A)NFS version and also checks the file server version (ie. Acorn vs MDFS), so it knows which commands to issue. Maybe then it could overlay the correct set of * commands after the main code has been loaded, if we can make sure the start point of each * command is always in the same memory location?

That would be possible - it depends on what the sequence of commands should be for the various servers.

I'm hoping that MDFS might already work with the current command set, and that the TNMOC issue was simply a missing directory. They may be able to test this tomorrow.

But *is* there a sequence of commands that would work on a FileStore, with multiple discs, on versions where *DIR & isn't supported? Seeing as *DIR doesn't appear to switch between discs on those systems either...

Mark

[markusher]

I did a little experiment with the Master ET and added an internal co-pro (there isn't a socket for an external one). The ELITESP version works fine and doesn't get logged off the server. Reverting back to the ELITEM it does. So the station corruption is only in the non-copro version.

[MarkMoxon]

I did a little experiment with the Master ET and added an internal co-pro (there isn't a socket for an external one). The ELITESP version works fine and doesn't get logged off the server. Reverting back to the ELITEM it does. So the station corruption is only in the non-copro version.

Interesting. So I'm guessing there is a memory location somewhere in the Master ET that is crucial to retaining the station number, and the Master version of Elite overwrites it, while the I/O Processor part of the 6502 Second Processor version doesn't. And that same location can presumably be overwritten in a standard Master without affecting the network.

I guess these are all useful clues, though how one would go about identifying said memory location is another matter, as there are loads of memory locations that the Master version writes to that the 6502SP code doesn’t touch…

Thank you for doing the test. It's an intriguing problem!

Mark

[arg]

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)

No, MDFS doesn't do that. On MDFS, each user has one URD and it's always in the same place. There's no concept of "the user's home directory on another disc".

I don't understand why this second-disc behaviour is significant here - as I understand it, Elite is wanting to keep its files in some location, and go to the user's home directory to save user-specific data. If the intention is that the Elite installation is a shared resource (everyone loads it from a common place, but saves to their home directory), then if the code is switching between those locations with *DIR it needs to use an absolute pathname for where the shared stuff is (or load it from the Library). If the shared code is "in the user's URD but on the other drive", surely that's specific to a single user and so there's no sharing going on and no point in keeping the savefiles elsewhere.

& as a pathname component was invented for MDFS, and later copied by Acorn in various products, including in ANFS on Master to give the & behaviour on fileservers that didn't support it directly. But & is not part of any solution here, as the whole issue is that you don't want to go to the user's URD, you've gone off to some other directory on some other drive. And in any case, *DIR & is redundant and will have the same effect as a plain *DIR with no parameter.

The easy way to kludge this is to use *DIR with an absolute pathname for the shared stuff and *DIR on its own to select the URD. But that means hard-coding the absolute pathname.

Another approach is to just set it up in a single subdirectory and access everything with ELITE.xxxx relative to the current directory (never *DIR at all) - that will work on anything with a copy of the binaries per-user, and it will work nicely on SJ servers with the binaries in the Library and the savefiles in the user's URD (so ELITE.save01 will go in the subdirectory ELITE within the home directory, but ELITE.ELITESP etc won't be found there and will search the library and be found in the ELITE subdirectory of the library).

The reliable way to fix this that works on any fileserver and doesn't involve hard-coding pathnames in the binary is to manipulate the directory handles - don't *DIR to get to the user's home directory to save the private files and *DIR ELITE to get back again, rather use the current directory (or even the Library) for the binaries and the URD for the savefiles, and switch between them by switching handles (which you can thus switch back afterwards, entirely local to the BBC and the fileserver not involved).

The client BBC maintains a set of three handles - CSD, URD and LIB - for the current user. Things like *DIR and *LIB change the values of these handles, but the idea here is not to change them, just use the appropriate one for whatever operation is currently in hand. OSWORD &13 takes a control block with 4 bytes: first byte is operation, 6 to read the handles, 7 to write them; remaining three bytes are the three handles, URD, CSD, LIB in that order.

So if we have decided that binaries are going to come from the CSD (some script has done a *DIR into wherever the administrator wants to keep them before things start), we just load the binaries as normal - LOAD xxxx. Then to load or save a savegame file which needs to be in the URD, we first call OSWORD &13,op=6 and save those three bytes somewhere, then we call OSWORD &13,op=7 replacing the CSD with the URD (so copying the handle from offset 1 to offset 2), then do the savegame operation (filenames will be resolved relative to the URD), then do OSWORD &13,op=7 again with the values we stashed earlier and we are back in the original place.

[MarkMoxon]

Just to clarify the needs for Elite, here's what should happen:

1. The user issues a *EliteSP or *EliteM command

2. This loads various game binaries, some of which load other binaries

3. The last game binary to load should change directory to the user's directory, so the game's load/save menu will save commander files into the user's directory (and, more specifically, into a folder called Elite within the user directory)

That's it. Once the game binaries are all loaded, then we don't need to access them again.

Currently it works like this, though this could change:

1. *EliteSP and *EliteM live in $.Library and $.Library1

2. *EliteSP and *EliteM are simple scripts that first do a *DIR $.Elite, which is where all the game binaries live, and then *RUN the relevant version's loader binary

3. The final binary in each version’s load chain does *DIR followed by *DIR Elite, a combination that should leave us in the Elite directory in the user's diectory

The issue seems to be that on some multi-disc configurations, the last step doesn't work.

I don't know a lot about how the different networks work, but figured it might be useful clarify the requirements. For example, we don't need to worry about changing directories again once the game is up and running correctly, so that’s one thing we don’t have to do. I think, anyway!

Mark

[MarkMoxon]

To put it another way - if I replace the *DIR / *DIR Elite command in the final step of loading with an OSWORD &13 to fetch the URD, followed by another OSWORD &13 to set the CSD to that folder, would that solve the whole problem in a way that works on all networks?

Mark

[MarkMoxon]

In anticipation of the TNMOC LAN Party (see here), I have put together a version of Elite that will load over Econet for the BBC Micro; all you need is 16K of sideways RAM.

I would love to know if it works! If you have a networked BBC Micro with SRAM and you have time to try it out, do let me know how it goes.

You can find the download and installation instructions in the usual place:

https://www.bbcelite.com/hacks/elite_ov ... loads.html

This means that Elite can now be loaded over Econet for the following machines:

• BBC Micro Model B with 16K Sideways RAM
• BBC Micro Model B+ 64K
• BBC Micro Model B+ 128K
• BBC Micro with 6502 Second Processor
• BBC Master 128
• BBC Master Turbo

The BBC Micro version is based on the sideways RAM variant from Ian Bell's site, which was expertly coded by Stuart McConnachie - see this thread for lots of interesting details about this variant. This reduces the amount of network access that's required, so you should only see slow-downs for loading when you launch and dock; hyperspacing between systems is instant.

You can tell when the network is being accessed as the top of the dashboard flickers slightly.

Hopefully this will enable lots more Elite fans to load over Econet. Bring on the LAN party!

Mark

[KenLowe]

Thank you for making this!

I've installed this on my PiFS, but I'm having problems getting the EliteB version to run. This is what I've done:

• I've created a directory on my PiFS called $.Games.Elite and I've copied all the files from floppy over to this directory (apart from MAX).
• I've created a subdirectory called Elite, and copied the MAX file into there.
• I've created a user called Elite, and set the User Home Directory to $.Games.Elite, so when you *I AM ELITE, it takes you directly to $.Games.Elite
• I've patched the EliteB (and the EliteSP) files so the DIR is $.Games.Elite<0D>
• I've removed all other ROMs, so PAGE is sitting at &1200.

When I try to run the game from *EliteB the game loads to the point where you need to press space or fire to continue. When I press fire, I get a bad command error. The *EliteSP version works fine.

Have I done something wrong here?

[MarkMoxon]

How odd. By the time the spinning space ship has appeared, all the star-commands should have been run and we're into the core Elite code, so it's not obvious what's going on here.

Just checking, when you did this bit:

• I've created a subdirectory called Elite, and copied the MAX file into there.

I assume you created that subfolder in the user's main directory, so it's at $.Games.Elite.Elite? I guess so as otherwise 6502SP Elite wouldn't work, but I thought I'd check what the structure is, so I can set it up this way myself for testing.

Also, when *EliteB runs, what happens if you choose Y from the main screen, before getting to the "press Space' screen? Can you catalogue the network drive, for example?

And finally, when you press fire, is this on a joystick, or are you tapping Space?

I'm not sure what's going on - your setup sounds correct, so it must be something in my code. Could you maybe post your amended EliteB binary, so I can set things up this way on my system and see if I can replicate the issue?

Hopefully it's an easy fix! And thank you for giving it a test - it's much apprciated.

Mark

[KenLowe]

I assume you created that subfolder in the user's main directory, so it's at $.Games.Elite.Elite?

Correct

Also, when *EliteB runs, what happens if you choose Y from the main screen, before getting to the "press Space' screen? Can you catalogue the network drive, for example?

Yes, Catalogue works fine.

And finally, when you press fire, is this on a joystick, or are you tapping Space?

I'm running it on BeebEm. I've selected the standard Model B with 4 banks on SWR enabled, and removed all ROMs, other than DNFS and Basic. I've also selected the 1770 Disc controller, so the DFS part of DNFS doesn't grab any memory.
So, I just press space, and F10 to launch. It's when I press F10 to launch that I get the Bad Command.

Could you maybe post your amended EliteB binary, so I can set things up this way on my system and see if I can replicate the issue?

Attached.

Hopefully it's an easy fix! And thank you for giving it a test - it's much appreciated.

No problem. And thank you for all the hard work you put into this!

As an aside, I see slightly different issues if I try to run it with the IntegraB enabled, but let's see if we can get to the bottom of the standard model B issue first.

Directory Listing

Catalogue

Bad Command when pressing F10

EliteB.zip

Patched EliteB

(394 Bytes) Downloaded 2 times

[MarkMoxon]

So, I just press space, and F10 to launch. It's when I press F10 to launch that I get the Bad Command.

Aha, it's the F10 that's causing the error? Good, that makes a lot more sense than Space causing the issue. F10 loads the flight code, so that's where it's going wrong.

Did you copy EliteB into your library? The command needs to be runnable from anywhere for disc Elite, as it uses the commands

Code: Select all

*EliteB T

and

Code: Select all

*EliteB D

to load the docked and flight binaries. If it isn't in your library, then when the game tries to run either of those commands, it will give a Bad Command error. Might this be the cause?

This doesn't happen with the Master or 6502SP versions, as they don't need to load new binaries once they're loaded.

Mark

[KenLowe]

Did you copy EliteB into your library? The command needs to be runnable from anywhere for disc Elite, as it uses the commands

Code: Select all

*EliteB T

and

Code: Select all

*EliteB D

to load the docked and flight binaries. If it isn't in your library, then when the game tries to run either of those commands, it will give a Bad Command error. Might this be the cause?

This doesn't happen with the Master or 6502SP versions, as they don't need to load new binaries once they're loaded.

No, I didn't have a copy in the Library. I thought you only did that if you wanted to enable all users to play Elite. As I was restricting it to user Elite, I thought it just needed to go into the user home directory.

Anyway, I've copied it into the library, but the issue I saw with the BeebEm Integrab has appeared on the plain BeebEm model B as well now. I'm not entirely sure this is linked to me copying EliteB to the library. I may have also seen this issue on the plain model B yesterday. It crashes out whilst loading.

Edit: I've just tried this on a real beeb too, and it also crashes in the same way, with or without the EliteB file in the Library directory.

Crash during loading

[MarkMoxon]

No, I didn't have a copy in the Library. I thought you only did that if you wanted to enable all users to play Elite. As I was restricting it to user Elite, I thought it just needed to go into the user home directory.

Hmm, good point, the instructions do say that, but I've got that wrong. I'm going to have to ponder how to solve this for restricted use, as it won't work as-is. Sorry about that!

The error you are getting now is an issue with the EliteB loader crashing. I did have problems with this at one point, but I thought I'd solved it by moving the code to pages B and C, which (I believe) aren't used for Econet on the BBC B. But if something is writing to this part of memory, that would break the loader. I wonder what's going on here.

I'm going to need to poke into it a bit more...

Mark

[KenLowe]

The error you are getting now is an issue with the EliteB loader crashing. I did have problems with this at one point, but I thought I'd solved it by moving the code to pages B and C, which (I believe) aren't used for Econet on the BBC B. But if something is writing to this part of memory, that would break the loader. I wonder what's going on here.

It does seem to be a bit intermittent. I was able to get beyond that earlier today (when I grabbed the previous screen shots), so I'm not sure why it's behaving differently now. The only thing I've done is copy the EliteB file to the Library directory. I've removed again as a quick check, but it hasn't made any difference .

Are zero page addresses &90..&9F being used by elite?

viewtopic.php?t=28692

[MarkMoxon]

You could also try copying EliteB into the $.Games.Elite.Elite folder as well. The game switches directory between $.Games.Elite.Elite (for saving commander files) and $.Games.Elite (for loading the docked and flight binaries), so if you don't want to have EliteB in the Library, then having it in both these folders should still ensure that the *EliteB command always works. In theory! Might be a bit hackish, but worth a shot.

If something else is using pages B and C, then things would only go wrong when there's a clash, which might explain why this is intermittent. As you are running this in BeebEm, I wonder if it's possible to work out what else is writing to that part of memory, if anything?

I might just move it to somewhere I know is safer, if I can work out where that is!

Mark

[MarkMoxon]

Are zero page addresses &90..&9F being used by elite?

viewtopic.php?t=28692

Not in the Econet version, no. Avoiding use of all Econet workspace is one of the key differences in this version of Elite.

Mark

[KenLowe]

I haven't gone into it in a lot of detail yet, but it seems to be linked to the SWR detection code.

If there's more than one bank available, it crashes. If it only has a single bank, but that bank already has the loader installed, it crashes.

If there's only a single bank available, and that bank is empty, then it loads fine.

[MarkMoxon]

I haven't gone into it in a lot of detail yet, but it seems to be linked to the SWR detection code.

If there's more than one bank available, it crashes. If it only has a single bank, but that bank already has the loader installed, it crashes.

If there's only a single bank available, and that bank is empty, then it loads fine.

Now that is a really great clue. Thank you!

I've fixed a definite bug in my code that would crash the loader if the Elite ROM is already loaded, and I just tested it with multiple RAM banks in b2 and it seems OK with that configuration too. Attached is an SSD containing a new version of EliteB, which I've pre-updated to point to $.Games.Elite. Does this make any difference?

Either copy into your library, or into both $.Games.Elite and $.Games.Elite.Elite (I'll try to tidy up the latter requirement once it's loading OK).

Mark

[KenLowe]

Will test the new build in a few minutes, but now I know how to get past the loader crash, I can confirm that F10 works fine if I place a copy of the EliteB file in the Library.

And I think you might be right about multiple banks not being an issue. I've just tried with IntegraB and 4 banks of SWR, and it also works fine as long as there isn't already a copy in the SWR bank (but only in OSMODE 0 for some odd reason).

[KenLowe]

There's still something not quite right with the SWR detection. It no longer crashes the loader. However, if the ROM already exists, then F10 fails with a 'Not Found' error. It works fine if the ROM doesn't exist when starting the game.

Not Found, but only if SWROM was already loaded

[MarkMoxon]

There's still something not quite right with the SWR detection. It no longer crashes the loader. However, if the ROM already exists, then F10 fails with a 'Not Found' error. It works fine if the ROM doesn't exist when starting the game.

Thanks Ken, this is really useful. I think I have pinpointed the cause, and again I attach an updated EliteB that's been updated for your $.Games.Elite folder. I'm really hoping this one is going to be more stable, as I'd completely messed up the ROM-loading code... and now, I hope I haven't!

Fingers crossed...

Mark

[KenLowe]

Ok. That's definitely working better now . Tested on both BeebEm, and on a real beeb, and it's now loading fine. It's actually failing to load on one of my beebs (it crashes at the loader as we saw earlier), but I suspect that beeb has got some memory issues, so Iet's not worry about that for now.

The only outstanding issue I have now is that the game hangs of F10 / f0 when I try to load with my IntegraB board set to the default OSMODE4. This happens on both BeebEm and on real hardware:

OSMODE 4 Hang on F10 / f0

It's not a major issue, I just need to switch the board to IntegraB OSMODE0, and it works. However, I've just checked the original disc based SWRAM version of Elite, and it loads fine in OSMODE4, so wonder if it's something that would be fixable?

For reference, the different OSMODEs attempt to emulate different machines as follows:

0 Standard BBC Model B
1 BBC Model B with Shadow RAM
2 BBC Model B+ 128 emulation
3 BBC Master 128 emulation
4 BBC Model B+ emulation
5 BBC Master Compact emulation

[MarkMoxon]

I have also (I hope) fixed the issue with BBC Micro players who want to install the game just for them (rather than in the library). There is a new version in the usual place:

https://www.bbcelite.com/hacks/elite_ov ... loads.html

You will notice that the installation instructions are now slightly different if you want to install the game for specific users only. Now you should copy the EliteB, EliteM and EliteSP files into the user's Elite directory (e.g. $.Mark.Elite). This should ensure that the game loads properly if you don't install anything in the library.

In short:

* To allow all users to play, Elite* goes in $.Library etc.
* To allow individual users to play, Elite* goes into $.<user>.Elite

Hopefully this addresses all the Model B issues. Hope so!

Mark

[MarkMoxon]

The only outstanding issue I have now is that the game hangs of F10 / f0 when I try to load with my IntegraB board set to the default OSMODE4.

Ooh, not entirely sure how to replicate that issue with my setup. I've not got any emulators set up with Econet, and don't have a B+ or Integra board.

What difference does the OSMODE actually make? If it's explainable in simple terms!

Mark

[KenLowe]

What difference does the OSMODE actually make? If it's explainable in simple terms!

The main difference is probably that in any OSMODE, other than 0, Shadow RAM is available. But it does other things like WXYZ mapping for SWRAM banks to provide better compatibility with later acorn machines (like the B+, Master etc). If you change OSMODE, *FX0 will also report a different machine, depending on the OSMODE selected:

OSMODE / FX0

[MarkMoxon]

What difference does the OSMODE actually make? If it's explainable in simple terms!

The main difference is probably that in any OSMODE, other than 0, Shadow RAM is available.

There is some shadow code in the original SRAM version's loader that I didn't port into the *EliteB loader, so perhaps that's it? I'll see if I can work out what it does and knock out another version for you to try...

Mark

[MarkMoxon]

What difference does the OSMODE actually make? If it's explainable in simple terms!

The main difference is probably that in any OSMODE, other than 0, Shadow RAM is available.

There is some shadow code in the original SRAM version's loader that I didn't port into the *EliteB loader, so perhaps that's it? I'll see if I can work out what it does and knock out another version for you to try...

Here's a version of EliteB set to your folder structure and with the shadow-RAM-related code ported from the original SRAM loader. I have no idea if this will make any difference, but it's worth a go! Let me know what happens...

Mark