I'm - slowly - looking at why Eagle Empire doesn't work in BeebEm. As part of that I'm going back to square one and working out how it works from the ground up (as a learning experience, and getting back into the swing of Acorn things!)

A lot of the below is incidential to the question - just putting it all here in case anyone asks - what's that missing bit do?

So, to begin - part of the loading process loads & runs EAG#1:

EAG#1 0700 070A 00A0

Execution starts at 070A

The first thing we do is preserve the existing OSWRCH vectors, and then we set up our own OSWRCH routine, at &0785:
We load EAG#2 ... (not relevant to this discussion)
We then restore the original OSWRCH vector, so our routine only during the OSFILE operation.The next chunk is decoding the loaded file (not relevant here.)
... and then we jump to the decoded game ...After the JMP is our new OSWRCH routine
So - if I read that OSWRCH routine correctly - if the character requested for write is &3f (?) then convert to &20 (space). But WHY would you do that?

I wondered if it was loading from a tape and you got question marks in the status messages, they'd be blanked out ... but again ... why?

Or have I misread what is going on - it's been a long time!

(As I type this - I wonder - maybe the original game had some sort of copy protection that has been removed and now this code makes no sense? Have I answered my own question?)

The main code file is actually called "EAG#2"+CHR$(195), i.e. it contains a non-standard character at the end of the name, which the OS displays as a question mark when loading.

My guess is that the OSWRCH code is to turn the question mark into a space, so it looks like the file is simply called "EAG#2" as it loads. Quite what the point in any of this is, I have no idea, as the file can be trivially loaded from tape just using *LOAD without a filename.

Seems like a rather pointless attempt at obfuscation to me.

Edit: to say, I just tried it now, and actually the file won't *LOAD without a filename (it aborts with the rather curious error "Bad address"). So that's entirely the point: just a bit of basic protection to stop the code from being trivially *LOADed.

Just to add, I noticed that in the hex dump you posted above, EAG#1 starts like this:

whilst in the tape image on the STH site, it looks like this:

In your version, the file has been renamed to remove the CHR$(195), i.e. the C3 byte in the filename, as it's not valid on disc. This doesn't seem to have anything to do with the crashing though, as it still happens on the tape image from STH.

Ahhhh, I missed that completely - that makes a lot of sense ... I guess the version I dumped (the disc version from STH ... I think, I did try a few!) had the "illegal" character removed (either in a disc version as sold, or someone moved it to disc and removed that part.)

I know it is not related to the crashing later on - but it's just been BUGGING me as to what the goal might have been.

But what you said makes a lot of sense - someone will try to *LOAD EAG#2 ... and it will get told there's no such file. You'd have to write a special loader to load the file (as they did) - but no need to do that if the special character has been knocked out - which more than likely explains why the file name has two terminating &0Ds - one the original, and one to knock out the &C3.

Thank you!