Using Absolute files from within BASIC

If I have an existing Absolute file (eg compiled via ObjAsm), can I import/call that code from within BASIC?

A bit of context – I’m a seasoned developer (assembler on PICs etc) but am new to developing within RISC OS and the DDE. I’ve got some small assembler apps running and would like to look at BASIC next. It would be great to employ some of my existing assembler code within BASIC but couldn’t figure out how to do this other than pasting my original sources inline. So, is it a choice between BASIC with inline assembler vs C with Absolute files, or can I link into my Absolute files from BASIC?

If there are related docs anyone can recommend then all the better; the BASIC, DDE and Acorn Assembly manuals are great for their respective topics but I’m really looking for something “one step back” so I can understand if/how these tools best fit together. My objective will be app development in the first instance.

Many thanks
-JC

A typical way is to make it a raw binary file (not an absolute), and set the first few instructions to be branches to your routines, like:

   ENTRY
   B     one
   B     two
   B     three
   MOV   PC,R14 ; for expansion
   MOV   PC,R14 ; for expansion

one
   ; code here

two
   ; code here

three
   ; code here

   END

On the BASIC side of things, find out how big the file is, DIM memory for it, then *LOAD it in (or just open the file and byte read it into the allocated memory).

Assuming it is called code%, you can call the first routine with CALL code% and the second with CALL code%+4 and so on. Don’t forget you can use USR if you want a value returned.

I don’t recall how to get link to output a raw binary. As you are building your Absolute, you’ll be passing the command line option “-aif” to link to tell it to add in a standard application header.
On a command line, do link -h and it should list the available options. I’d tell you, but I’m using my phone, not a RISC OS device. ;-)

PS: go on, tell me it’s either -raw or -bin…

Aha *LOAD has filled in the missing link, and that branching pattern is a nice solution too thank you! I shall give all that a go.

Regarding Link yep I can see a -bin option for outputting a plain binary :)

Thanks for the quick reply

Not a BBC BASIC seasoned user, I think I stopped using it like 25 years ago in favour of C…

However, your question may have two part’s answer:

P1 – Dealing with binary code in BBC BASIC:

BBC BASIC (like other BASICSs too) should handle the binary code using allocated memory via DIM (similar to allocating an array basically).

So, for raw binaries, you could try to load your binary straight into that allocated memory as a file and make sure P% points at it, so something like:

DIM org 100
P% = org

And then you could try to run your binary using:

CALL org

For example, to save the opcodes you have stored in your org when you assembled using BBC BASIC ASM you can use something like:

A = OPENOUT "<Obey$Dir>.MyBinary"

FOR check=0 TO 100
    BPUT #A, org?check
NEXT check

CLOSE #A

You can even open that file into (for example) !DisAssem and it will disassemble it correctly ;)

Now to load it back on another BBC BASIC program:

DIM org 100
P% = org

A = OPENOUT "<Obey$Dir>.MyBinary"

FOR offset=0 TO 100
    org?offset = BGET #A
NEXT offset

CLOSE #A

CALL org

P2 – Dealing with AOF binaries

Now while the above is the answer to how to run binaries in BBC BASIC (that you do not assemble in the same code), the problem with AOF format is that it’s a chunk file format and not a raw binary as we have seen above.

That means that you need a more friendly format, one thing that may help here it’s the DDE Linker Link to which you could pass your AOF and make it produce a binary output.

If you decide to use the trick above then remember to UNCHECK the AIF from Link Window and then check Binary, this is the “magic” to use ObjASM to produce BBC BASIC compatible binaries.

Hope this helps!

@ Rick

PS: go on, tell me it’s either -raw or -bin…

Just -bin. And to avoid confusions: no -AIF or -AOF. If he uses -AIF or -AOF then “boom” lol

So something like:

Link -bin blah blah

Thanks Paolo that’s really helpful. I’d spotted the optional addition of -AIF so good to know that should be avoided. I’ll read up some more on the binary types and linking – it’s a little bit different to what I’m used to but is mostly making sense!

A typical way is to make it a raw binary file (not an absolute), and set the first few instructions to be branches to your routines, like:

Interesting starting point for a shared library for BASIC (or other language I suppose)?

@ Steve

Interesting starting point for a shared library for BASIC (or other language I suppose)?

Yeah every single old school binary “libraries” were designed this way, it makes it easy to handle that:

CALL org?offset_to_function_entry_point

So you can use it for whatever language even ASM to ASM, however in BBCBASIC you have the advantage that CALL consider org position in memory as the beginning, so makes things easier to handle jumps, while other languages may not and that means you need to be careful with the jump addresses.

On The Amiga, for example, Libraries jump addresses gets relocated at loading time using a simple trick, by obtaining a pointer to the library base address and then (after put it in the 68000 register A6) you could do a relative jump to the function entry point

On older 8 bit computers you could use the BANK number as base position and so use static addresses and change the BANK ID to use functions from different libraries.

So plenty of tricks added on top of the “functions entry point table”

Sorry just love to talk about these things… :D

Ok last bit lol sorry, just want to share this…

If for example you want to execute an AIF from BBC BASIC, you actually can… again simple memory offsetting tricks…

it’s just a little more tricky than using raw binaries, but can be done:

DIM org 160: REM The number here depends on the size of your AIF file
P% = org

PRINT "Loading an AIF..."

A = OPENIN "@.MyAIF"

FOR offset=0 TO 160
    org?offset = BGET #A
NEXT offset

CLOSE #A

PRINT "Done"

REM execution:

CALL org+128

Now if you’ve read my introduction to the AIF format (or any other introduction to it that mention how the AIF works internally), you’ll know that the AIF has an header of 128 words, so just skip it :)

The trick in this case is to use the linker Link with the options -AIF and -bin at the same time:

link -AIF -bin blah blah

The code will work, however it’s not as controllable as the examples I gave before to Jonathan.

Also it wont work with C Compiled code, only binaries generated from ASM and without complicated structures.