Running binaries on a Communicator

[RobC]

I've been doing some assembly language coding on the Communicator to try to recreate some of the Econet utilities but have hit an issue that has confused me.

If I assemble my code and then call it from BASIC, it works. However, when I *SAVE the code, any attempt to do *filename gives the error "File unsuitable for Communicator".

Does anyone know how you're supposed to run assembly routines on the Communicator without resorting to *LOAD & CALL?

Thanks,

Rob

[BigEd]

I wonder if there's some kind of header needed? Especially if Communicator binaries are somehow relocated at run time... is there any executable that can be *RUN - what does it look like in terms of execution address?

(Maybe Dominic's disassembly of the OS can help - that string should be searchable.)

[RobC]

Thanks Ed - I don't think *RUN is available (but *filename is) and wonder if everything has to be built into a module?

I guess what I'd really like to know is how the Econet library utilities worked on the Communicator. Did they have to be loaded from a module, CHAINed from BASIC or run some other way?

[BeebMaster]

Big Ed and I played about with a Communicator at the January 2020 ABug and we referred to a couple of manuals which I think were probably these:

viewtopic.php?p=396791#p396791

I was trying to do Econet things with it, implementing some file server call or other. Chapter 6.8 of the "Acorn Communicator Systems Manual" deals with Econet.

Intriguingly, the other document "Acorn Communicator Software Tools Manual" describes the Communicator OEM development package as consisting of BBC Master 128 with ARM Second Processor and the development tools on floppy disc - so presumably if we have these development tools, we can use Pi Tube Direct's ARM Second Processor to re-create this environment and all have a play?! I am not sure whether that means the development package is a 65C816 emulator running on an ARM parasite on a 6502 host!

[RobC]

Thanks BeebMaster - that may have been one of my Communicators!

I've been able to implement various simple utilities (e.g. *PROT, *UNPROT, *FLIP, *LEX etc.) and these work when CALLed from BASIC. I just can't figure out how to turn them into * commands.

[BeebMaster]

The OEM guide describes a sort of interface provided in the Communicator BASIC into the more normal BBC MOS interface, such as OSB% and OSW% being used instead of calling &FFF4 and &FFF1 for example (and also some weird thing where you open Econet: as a file handle to do network related things, which is reminiscent of the way you use the IEEE488 cheese wedge, but not necessarily directly relevant here) - so I wonder if because BASIC is running the assembled code, it works, but take BASIC away, and the Communicator doesn't then know how to handle the translation of the OS calls?

Can you do something really rudimentary like a simple counting loop in assembler and *SAVE that to see if it works as a * command, without using any kind of OS call in the code?

[dominicbeesley]

What filing system are you using Rob? I think only the card and econet filing systems have load/exec addresses from what I can see

Other than that I've not worked out how transient utilities are supposed to be run as *commands. Due to the way tasks are allocated I'm really not sure where such command should run to not clash with

I'll be interested to know how you get on

Beebmaster / Ed where is this OEM manual? Any documentation would be a great help with my disassembly efforts!

[BeebMaster]

Manual was in the post I linked to above. Also the Communicator FileStore Manager's Guide (at Chris's Acorns) is interesting, as it almost reads as if it is suggesting that the FileStore is part of the Communicator. Of course, it could be considered as a peripheral, because you can connect a FileStore to a Communicator directly using an Econet lead (which it does describe), just as you can connect a FileStore to a Beeb the same way.

Reading up a bit on the 65SC816, it seems it defaults to 6502 compatibility mode, so I am wondering if there really were a separate set of Communicator Econet library utilities? Maybe it just uses the standard "Library1" utilities but they have to be run from within the Communicator BASIC which does special things like facilitiating Communicator OS <> BBC OS call translation?

The Communicator FileStore Manager's Guide refers frequently to going into the BASIC task in order to network management related things. Either that was just a convenience, because you would have a prompt to type at, or maybe it was crucial for what BASIC was doing behind the scenes to make the normal 6502-based utility commands work?

Another clue is that at one point in the OEM guide it reads that BASIC executes the machine code. Well, no, that's either very uncharacteristically sloppy wording from Acorn, as it's the OS or CPU which is executing machine code, not the high level language - unless BASIC really is doing something special on the Communicator.

[RobC]

Thanks all - I'm using Econet (which is why I'm keen to have the utilities available).

I get the same "File not suitable for Communicator" message when I try to call the existing Beeb or Master utilities in Library/Library1. This led me to work on 65816 versions.

Pretty sure that any simple code will give the same result when called as a star command - I cut *FLIP right down with the same result (before realising there's a version in the Communicator's Net module!).

I'll have a look at that Filestore manual as I'd not found it before and it might give me some clues.

[RobC]

Looking at that Communicator Filestore Manual, it seems that the NetMgr task is loaded when you log on as SYST.

I'm wondering if this is a module that's loaded via a !BOOT file and provides the *commands rather than them being held in a Library directory?

[jgharston]

Also: where are you trying to load them to? What are their load/exec addresses. CALLing stuff in BASIC's memory from BASIC is all operating within BASIC. Stuff run via a *command has to follow the MOS's rules, not BASIC's rules.

Looking at the code around the 'Not suitable for Communcator' error, it appears to be checking the file information block.
It appears to be doing:
If filetype<>&FF -> error
If length>=16M -> error
If load=&FFFFFFFF, exec=&xxxxxxFF -> does something
else -> does something else

So, to start with the filetype needs to be set to &FF=run-only. This depends on if this is supported by the file server. If supported, doing *ACCESS file e/e would make the file run-only.

[BeebMaster]

I cut *FLIP right down with the same result (before realising there's a version in the Communicator's Net module!).

Yes, actually, if the Communicator has an ANFS of sorts, it should have PROT, UNPROT, FLIP and LEX already!

[james]

On p2.61 of the Software Tools manual, it says “When creating an assembler program to run on Communicator, it has lo be made to conform to the module format expected by the Communicator MOS.”

Here’s my guess: the Communicator MOS is geared to running comms and the user-facing ‘Blue Screen’ applications, rather than being a general purpose home computer. To do this, it carefully manages memory allocation for all processes (so your BASIC assembler is using a bit of BASIC’s allocated memory - and, if not, something else could trample over it). Likewise, executable code needs to be a module, so the MOS can understand if it’s running in 16/24 bit and its memory needs - and restore the system afterwards.

I reserve the right to be wholeheartedly wrong, though

[dominicbeesley]

Ah so the "OEM" manuals are just the System and Software tools manuals. I was hoping there was something else had been unearthed.

I can confirm that the OS supports two APIs that overlap in many places: A COP based system call (analogous to ARM SWI) which is a COP instruction followed by a call number. there are calls to do many things like OSBYTE, OSWORD etc. Then there are some jump vector locations at the top of bank 0. These are like the BBC/Electron MOS entry points but are to be called with a long jsr and are not in the same locations as the older MOS.

it is not well defined when one should use one or the other but there are hints in the System manual (I can't find where) that the jump table is preferred - probably on efficiency grounds.

I can also confirm that the CPU stays in native mode the entire time from early in the boot sequence.

I suspect, but haven't confirmed on my disassembly adventures, that what James says is correct and the communicator wants everything to be a module. I also suspect that any transient commands will need to be written in "relocatable" 65816 code. This is not difficult but is fairly ugly as there are no branch relative instructions you have to do

Code: Select all

	PER @ret
	BRL routineToCall
@ret ...
[code]

for a pseudo BSR instruction or

[code]
	PHK
	PER @ret
	JML __MM ; an operating system routine
@ret

to call an OS routine. Similarly accessing local data often involves using PER to get the address of local data then popping the address from the stack or other jiggery pokery! The Keyboard module that I've been looking at recently is mainly relocatable. Though for some reason it also has a smattering of absolute code in there as if they got sick of all the relocatable stuff. Maybe at one point it was soft loaded but then they went absolute when they put it in ROM?

If you start a couple of instances of BASIC they will have quite different values of PAGE/HIMEM so I can't see how assembling to fixed location could really work. I've not yet worked out on the Communicator menu to tell BASIC how much memory you want it to claim. The BASIC is capable of addressing large amounts of program space but I've not spotted a way to tell it how much - it's probably something blindingly obvious but not having a real machine to test against is making it quite difficult! [I only have Mame to test with an it doesn't correctly emulate the pre-empt key so starting a new task is not straight-forward]

D

[RobC]

Thanks again all - that's really helpful.

Yes, actually, if the Communicator has an ANFS of sorts, it should have PROT, UNPROT, FLIP and LEX already!

Unfortunately, it doesn't. *FLIP is there but the others aren't. However, they are all pretty trivial to implement with with a few *commands or lines of BASIC.

I suspect, but haven't confirmed on my disassembly adventures, that what James says is correct and the communicator wants everything to be a module. I also suspect that any transient commands will need to be written in "relocatable" 65816 code.

I'm inclined to agree - the fact that NetMgr is loaded as a task on logon and this provides the extra Econet commands backs this up.

I've been borrowing heavily from the examples in the Communicator Systems Manual so was vaguely aware of how to make the code relocatable. I'm mostly using COP calls with the PER thing or OPBHA to access data.

[BigEd]

> I've not yet worked out on the Communicator menu to tell BASIC how much memory you want it to claim

I feel I have run Basic at different sizes, and if I did, it would have been while I had RobC's Communicator... but anyway I don't see any record of my experiments. I don't suppose
*BASIC NNNN
would do the trick?

[BigEd]

Looks like you can specify memory in a main menu entry using a number: a task of "BASIC,32" would allocate 32k. Maybe!

[dominicbeesley]

Thanks Ed,

That makes perfect sense - I'll go back to my BASIC disassembly and see if I can figure out the other parameters - where did you find that info?

Interestingly the "File unsuitable..." message is in the Net module and not the main MOS where I would have thought it should be. I did promise somebody on the ABUG call to try and make a start on the Net and Econet modules sooner rather than later so I'll try and do those this evening or tomorrow.

D

[BeebMaster]

On p2.61 of the Software Tools manual, it says “When creating an assembler program to run on Communicator, it has lo be made to conform to the module format expected by the Communicator MOS.”

When I read that I couldn't quite decide whether whether it applied generally to any and all assembler, or whether it was describing how to write an app/task in assembler. It seems like a bit of a faff to have to do that just for a * command.

But then again it also seems like a bit of a faff if there had to be a separate set of Communicator Econet library utilities. Already by this point there was Library and Library1 for BBC and Master, and ArthurLib was coming for Arthur & RISC OS machines. It does seem to be stretching credulity a bit that a fourth distinct library would be needed just in case anyone added a Communicator to an Econet.

That's Acorn for you though, they might well have done just this!

The slightly perturbing thing is that I may have had the answer to all this 20 years ago, as my FileStore E20 is the Communicator version! It can be seen in this picture underneath my E01, with Communicator coloured paint and AFH product code:



As far as I recall, I bought it in 2002 or 2003 from 8bs and it wasn't working as an Econet file server hard disc and I had to format it to use it with the FileStore E01.

[BigEd]

Thanks Ed,
...where did you find that info?

I think it was in the User Guide page 32 of the PDF.

[james]

On p2.61 of the Software Tools manual, it says “When creating an assembler program to run on Communicator, it has lo be made to conform to the module format expected by the Communicator MOS.”

When I read that I couldn't quite decide whether whether it applied generally to any and all assembler, or whether it was describing how to write an app/task in assembler. It seems like a bit of a faff to have to do that just for a * command.

Aye, indeed.

The Systems Manual p4.1 says "The operating system manages the altocation of memory in the machine. Requests may be made by programs for small (less than &10000 or 65536) or large (more than &10000) areas of memory". Given that the OS (COS?) has such a tight reign over memory usage, just *RUNing some code could trample over who knows what? Hence, I suppose, the need for everything to be a module.

Which makes you wonder what happens when a Communicator logs on to a user directory with *opt 4,2 set on Econet.
And how do you load and initialise a module?

Incidentally, the Software Tools Manual mentions an "External ROM Expansion Card" as part of the OEM development kit, which includes a ROM with some debugging commands (CBFREE, HANDLES, MAP, MODULES & IRQLIST). Do these exist anywhere?

[jgharston]

Which makes you wonder what happens when a Communicator logs on to a user directory with *opt 4,2 set on Econet.

https://beebwiki.mdfs.net/FSCV#Boot_options

[james]

Which makes you wonder what happens when a Communicator logs on to a user directory with *opt 4,2 set on Econet.

https://beebwiki.mdfs.net/FSCV#Boot_options

Your MDFS site is an absolute goldmine, thank you!

But does !CBOOT need to be a module? Or can it be any old executable code (potentially) trampling over another processes’s memory?

[RobC]

Which makes you wonder what happens when a Communicator logs on to a user directory with *opt 4,2 set on Econet.

I'll give this a go after work.

And how do you load and initialise a module?

At a guess, and at a high level, you get a memory pool, load the module into the pool and then do OPAM to add the module. The practicalities of doing all this without the ability to easily execute code still baffles me though! (I do wonder what the tantalisingly named OPATR - allocate transient is for...)

Incidentally, the Software Tools Manual mentions an "External ROM Expansion Card" as part of the OEM development kit, which includes a ROM with some debugging commands (CBFREE, HANDLES, MAP, MODULES & IRQLIST). Do these exist anywhere?

Don't think so - unless they're in the Briefcase Communicator ROMs?

[dominicbeesley]

OPATR given a memory pool handle in Y places a jump/return block at DP,X and the DEAD marker afterward

OPFTR checks that the DEAD marker is still there.

https://raw.githack.com/dominicbeesley/ ... LLK-COP_3F

This may well be part of a sequence when a module is loaded then executed somehow. It looks kind of analogous to OPRFR

I'm still a bit baffled by all these jump blocks that the Communicator creates for calling stuff. It seems a bit of an unnecessary palaver but I'm probably missing something!

[arg]

I've just found a slightly interesting document in my old floppies (credit to John Newcombe for imaging them).

This is a set of initial proposals for what work needed to be done to bring the Econet stuff into the framework of the new Communicator OS.

The background here is that someone had done an initial very crude port of BBC OS onto the Communicator hardware - running in Native Mode on the CPU, but not really exploiting most of the features of the machine (and in many aspects not working very well). I believe that had been done in late 1985/early 1986 in order for the prototypes to be hawked around potential customers. By August 1986, there were some sales and a small team had been assembled under Paul Bond to do the OS properly. This was mostly contractors or new-hires to Acorn - all the core Acorn R&D people were too busy on the ARM project to get involved. There was limited time and limited budget, which explains why the shipping OS still had duplicate ways of doing many things (the original BBC OS interfaces that hadn't been entirely removed, and the 'new way').

Page 6 of the document talks about transient utilities and so is relevant to this thread - though I can't promise that what I proposed was ever actually implemented!

communicator.pdf

(24.37 KiB) Downloaded 23 times

Note: the original document was three plain text files with formatting control codes from the Acorn E80 editor (including the ones to chain the three files together into a single document for printing). I had a program which processed those control codes to drive my ML84 matrix printer; SJ Research later extended this command set for use with Apple Laserwriter, and I've used that utility to generate Postscript, which I then passed through PS2PDF to generate the PDF I have attached here.

[dominicbeesley]

Thanks for posting this it is very interesting. I just had a quick skip through and will try and see if I can match that up with what goes on in the econet disassemblies.

If you find any more communicator os documents please do pass them on as I've been very much working blind. Any hints at the thinking behind the internals would be a big help

D

[arg]

That's probably all I've got apart from a fan-fold listing of the Econet source - I did all my work on Communicator on-site at Acorn and didn't bring away any files.

That printout is probably the state of the code before I had done much work on it. (though having looked at it, maybe later than I thought)

Looking at the printout, it follows the file layout of the DNFS source with the first section (primitives) little changed, but then the NFS part has a comment "NB. Derived from BBC anfs V 4.0752". There's a comment against a change "Simon 9/12/85" which confirms my recollection about the original port having been done in late 1985. Was "Simon" maybe Simon Rayne?

Tracing through the listing to follow star commands/*RUN:

• There's an entry point commented "Enter here from DVUNK module call, ie. unknown *COMMANDs"
• Escape is enabled
• The command is passed to the fileserver. If the fileserver says it's *INFO (which covers a multitude of sins), *I AM, *SDISC, *DIR, or *LIB, appropriate action is taken; if the fileserver says the command has been handled, processing stops.
• For all unrecognized commands, it does a fileserver ReadObjectInfo(5) call to get the load/exec addresses, first looking in the current directory and then explicitly checking the library (ie. repeating the ROI with the handles swapped). If not found in either place, exits "Bad command".
• If the high three bytes of the exec address aren't FFFFFF then it exits with error "File unsuitable for Communicator"
• If the exec address is FFFFFFFF, it does the equivalent of *EXEC using what the comments describe as "the magic handle". It opens the file, then the comment says "We do *EXEC !CBOOT and the OPEN code ignores the !CBOOT and supplies the magic handle! (what a fudge!!)" (sic)
• If the exec address is FFFFFFFE it's assumed to be a transient program.
• Other values of the low byte are reserved for future use but in this version also give "File unsuitable for Communicator"
• The load address is then checked. FFFFFFFF means position-independent code, load anywhere. FFFFxxxx means bank-independent (6502-like), load at the given address in any bank. Other values mean "attempt to load at that precise address".
• The file size is checked for being < 64K
• For absolute code, it does the COP OPMM with X=MMAX ("allocate explicit area") Y=HDMMT (allocate from task memory). For bank independent it does the same, looping through all the banks in task memory (the range of which is found from COP OPMM X=MMBAS/MMTOP Y=HDMMT). For position-independent, it calls COP OPMM with HA=size X=MMASA ("allocate small ascending area") Y=HDMMT.
• If the memory allocation was succesful, it calls the fileserver 'load as command' to load the file into the space allocated. (looks like there's a security hole here if the file size changed meantime!)
• Failure to allocate the memory gives the arguably incorrect "File unsuitable for Communicator" error.
• Some direct page is allocated via COP OPADP. This is &100 bytes for the transient program to use, plus a few 'secret' bytes for housekeeping, hidden by setting the transient's DP just after the secret bytes.
• On entry to the transient code, the first three bytes of direct page will point to the tail of the command line (equivalent of argv[1] in modern parlance)
• A coroutine instance is created for the transient, with (I think) &200 bytes of stack. This appears to be a call entry point at &00FF90 with X=COCRE rather than a COP.
• The transient coroutine is entered by calling CCO (00FF94) with Y= coroutine handle. Comments say that BHA and X are nominally passed to the transient on entry but 'ignored' - looks like they don't in fact have anything useful in them. The transient can return with X=RCER to return an error (pointer to the error in BHA), or RCKEY ('preempt key' in which case control is passed to the menu coroutine but it is expected to come back and the transient will be re-entered), or any other exit assumed to be normal success exit. For RCOK (and in fact all other values), the memory, handles etc are deallocated and cleaned up.
• That isn't quite the interface to the transient code itself. The coroutine created for it has some veneer code which creates a break handler; it's the break handler that returns RCER to return the error message that was created BBC-style with a BRK. The actual loaded transient code is entered with a simple JSL, and returns carry clear (for OK exit) or carry set and BHA pointing to an error string (as an alternative to invoking BRK). The RCKEY seems to come from the coroutine system itself, presumably when the transient calls OSRDCH or similar? (I can't remember exactly how the coroutine scheme works).

I think that (transient command loading) is the one big new chunk in this code; all the rest is ANFS-derived, but with lots of tweaks here and there. I see a string constant "LibraryC." which is presumably a communicator-specific library searched for at login, but I haven't found the code for that yet.

[Pernod]

I've just found a slightly interesting document in my old floppies (credit to John Newcombe for imaging them).

Don't want to derail this topic too much, but do you have any idea what the PCF0335 device does in the Communicator? We haven't been able to find a datasheet for this part, so could be a custom thing. I think it's a I2C device and likely modem related, maybe dialler and baud rate generator for the ACIA 6850. Any clues would be really useful.

[hoglet]

Don't want to derail this topic too much, but do you have any idea what the PCF0335 device does in the Communicator?

This part number is (I think) a Philips/Mullard CMOS gate array (a bit like the various ULAs in the Beeb).

The "33" bit of the part number refers to a gate density of 330 2-input gates (in an 11x15 matrix)

I couldn't find a datasheet for the specific PCF0335 part, but here's a generic datasheet for the family:
https://datasheetspdf.com/pdf-file/6272 ... /PCF0330/1

The bottom line is this is a semi-custom chip, so could be doing pretty much anything! But given it's location between the modem and the uart, I'd say it's likely to be communications related.

Dave