Compile the subroutine as you would any other BASIC program, and then rename the RUN module to SBX. You may want to relocate it to the [p,0] or BAS: account if you want to be able to access it from other [p,pn]’s.

You may want to create your own DO file, e.g. comsbx.do, which compiles your SBX modules and renames the resulting .RUN file to .SBX.

You may also want to always compile with the /X:2 switch (for A-Shell extensions to A-BASIC.) This is mandatory if you use the XGETARG or XPUTARG statements, but even if you don’t, it clearly marks the resulting module as not being compatible with AMOS, eliminating any possibility of confusion by accidentally executing it under AMOS.

It is also recommended that you use the /M switch (to enforce mapping of all variables.) This is good programming practice in general, but is particularly useful in subroutine programming where it will quickly point out two of the most common subroutine programming errors, forgetting to ++INCLUDE ASHINC:XCALL.BSI, and misspelling one of the constants such as XCBGET, XCBPUT, MX_XCBDATAX, and MX_EXIT.

As an alternative to manually renaming the .RUN to .SBX, you can specify the following pragma:

++PRAGMA SBX

Or, you can compile with the /X:3 switch, which is like /X:2 but automatically invokes the ++PRAGMA SBX feature. In either case, the output of the compilation will be an SBX rather than an SBR.

Compiling a new SBX doesn’t necessarily replace one that is loaded into user memory! Always do a DEL * to force a fresh copy to be loaded from disk.