Question about RM$RUNP

Feel free to discuss any Organiser II related topic here
Cosi1125
Posts: 17
Joined: Wed Jul 28, 2021 6:36 pm

Question about RM$RUNP

Post by Cosi1125 »

Howdy.

I've stumbled across a weird problem related to the RM$RUNP system call. I'm trying to use it from within my machine code program (but written in the "homebrew" way, using OPL's `usr()`), and it successfully runs a procedure, but then the Psion displays some garbage and restarts.

In Jaap's syscall reference it is mentioned that "the run-time stack is cleared, and all files closed and the language is re-initialised before running. This service should therefore not be called from within a procedure." This seems to be in line with the observed behavior (OPL doesn't know where to return to), but – curiously – this caveat is missing from Bill Aitken's book, and I'm confused as to what is the correct way of executing this service (would it run from a machine-code routine compiled with the assembler?)

Alternatively, if "the run-time stack is cleared", would it be possible to dump the PC (or even the entire RT stack) on the general stack and recreate it upon leaving the child procedure?

Or maybe I'm overcomplicating things: is it possible to run an OPL procedure *by name* from another procedure (and then return to the parent procedure or not) using pure OPL (which, unfortunately, is lacking the `eval()` keyword)?

Thanks in advance!
MartinP
Posts: 26
Joined: Tue Oct 05, 2021 7:01 pm

Re: Question about RM$RUNP

Post by MartinP »

It would be great to have an "eval" type procedure for OPL, and it seems that you have the answer which is to save the RT stack and restore it afterwards. That's not something I've done before, but maybe someone else has?

You could probably avoid the problem by doing the procedure selection in machine code and starting the machine code from a bootable pack?

If I wanted to call a procedure in OPL based on a name held in a text variable I'd do it using multiple IF statements, but it would require one for each procedure to be called e.g.: IF name$="Proc1" : Proc1:()
Then you'd need a long list of IF and ELSE IF statements or some sort of look-up table. I don't know if that's practical for you, it depends on how many possibilities you want to deal with?
Martin P
Cosi1125
Posts: 17
Joined: Wed Jul 28, 2021 6:36 pm

Re: Question about RM$RUNP

Post by Cosi1125 »

Thanks for the response, Martin.

I guess I should explain my motivation :-)
Inspired by Martin Reid's "menu app", I though I'd write a slightly more elaborate version – instead of being hard-coded, program names would be read from a data/notepad file (during run time, making it possible to extend the menu without recompiling the procedure). Being a complete newbie to Psion programming, I'd made a "feasibility study", and it should be easily doable if I get past this syscall problem.

Hopefully that explains why I can't resort to "normal" ways of doing that in OPL (however I'm grateful for your advice!)

If it's possible to execute RM$RUNP from a machine-code routine without crashing something, I think an (ambitious) alternative solution would be to write this program entirely in assembly – similar to what you're suggesting, sans the "bootable pack" part. If not, I'll read more about the RT stack. Who knows, maybe I'll end up creating a completely new, interesting project (guess that's called "yak shaving")?
MartinP
Posts: 26
Joined: Tue Oct 05, 2021 7:01 pm

Re: Question about RM$RUNP

Post by MartinP »

Ok, sounds good. Let us know how you get on with it.
I suggested a bootable pack as I wasn't sure how to run machine code without calling it from OPL, but I guess there are a number of ways. A look through the technical manual reveals that you can add a machine code subroutine to the top level menu using TL$ADDI so that's one option.
I've not done much assembly language on the Psion, but I'm curious about it. Which assembler are you thinking of using? There are a couple of assemblers on Jaap's site which run in dosbox, I think, and Andrew wrote one which I've had a go with: https://github.com/blackjetrock/psion-org2-assembler
Are you a Windows, Linux or Mac user?
Martin P
Cosi1125
Posts: 17
Joined: Wed Jul 28, 2021 6:36 pm

Re: Question about RM$RUNP

Post by Cosi1125 »

There's a tool by Jaap that makes .OB3 files from Psion machine code files, but I believe the Organiser-native Assembler behaves the same way (maybe Jaap will chime in and correct me...)

And I think that answers your question as well. I have this assembler: https://www.jaapsch.net/psion/manassem.htm on a datapak, but of course there's no way I'll test my works on real hardware :D JAPE is very comfortable to use.
(Btw. it would be super cool if we had an integrated development enviroment akin to what other "retro platforms" have – I'm not even talking about a real IDE; having everything in one place and ready to run from a modern OS, and coupled with JAPE would be a great step forward.)

I'm a devoted Linux user, but I can run software on a Mac or use WINE.

Thanks,
Cosi
MartinP
Posts: 26
Joined: Tue Oct 05, 2021 7:01 pm

Re: Question about RM$RUNP

Post by MartinP »

That's dedication, doing it within an Organiser emulator! Impressive, but a bit more screen space would probably make things a bit easier. So I agree, some sort of IDE would be good, a platform independent one that would run on Windows or Linux. Perhaps someone will take up the challenge?
Martin P
Cosi1125
Posts: 17
Joined: Wed Jul 28, 2021 6:36 pm

Re: Question about RM$RUNP

Post by Cosi1125 »

Well, I think I can at least start... I won't do much, but I can try to compile a list of what we have already and propose some further steps. I believe we're already equipped with a nice range of tools which could be incorporated into an integrated environment (heck, even Emacs would do), but they're usually running on DOS and that might be a limiting factor (unless something can be done with DosEmu).

Anyway, stay tuned!
User avatar
MartinReid
Posts: 160
Joined: Wed Jan 27, 2021 3:44 pm

Apps programme

Post by MartinReid »

You chaps are getting me excited now... The thought of a TSR (terminate and stay resident) Apps programme is fantastic... Currently I use two using OPL - (Apps and Games)... You can't really burn them to a datapak as you may want to modify or add to them.... The idea that the 'menu items' could be in a Notepad or Database is ideal...

Watching with interest
Martin Reid
Cosi1125
Posts: 17
Joined: Wed Jul 28, 2021 6:36 pm

Re: Question about RM$RUNP

Post by Cosi1125 »

Keep your fingers crossed, Martin! This effort can not only result in a new tool, but also – hopefully – facilitate software development for the Psion :-)
User avatar
Lostgallifreyan
Posts: 68
Joined: Fri Jun 11, 2021 2:52 pm

Re: Question about RM$RUNP

Post by Lostgallifreyan »

RM$RUNP is definitely only to run top level OPL from machine code that was not called from OPL. No parameters, total initialising of OPL, etc, all clues as to intent.

The Workabout has ways to run stuff within OPL, but the Organiser doesn't, but one likely reason is the risk of recursion, it eats memory so fast that even if all else works, the OS will be hosed anyway. If recursion must happen, Psion probably decided to contain it in OPL calls where there was a chance of gracefully handling any excess.

The RAM space issue also shows that even if you plug in some name (and maybe some args) you have to represent them somewhere, so hardcoding them in the OPL code is as good a place as any. Taking user input would mean handling unknown string length and content, and that's HARD, a program could take a lot of space doing it, and the edit services solve that by deliberately constraining string length, but can't solve the need for relative jumps in code to remain fixed if the user is putting in stuff that would force change.

(It's like the dilemma about whether to use malloc in C or to set adequately sized but uninitialised variables when the program is started. 'Embedded' systems programmers advocate NO malloc for this reason, and an Organiser is a lot like an embedded system because of restraints on speed and space.)

Looking at the innards of an OB3 file, the translated OPL shows a byte value 0x84 following any procedure name. (I didn't look deeper to see how args are handled). This means that a procedure would have to know its own address in RAM, use that offset with something like my 'BYTES' proc to write arbitrary bytes to arbitrary locations, namely the one in the code that names the proc, then be VERY sure not to enter a name that is too long. Allocating all 8 chars might still cause unrest if the user-supplied proc name is too short! Trying to run an absent proc will halt OPL outright, so it must be there to work in any practical case.

The upshot of this is that a menu driven selection from existing procs, and passing expected args, is the only way to do it, which in turn explains why Psion never offered another service after RM$RUNP. To do that they needed to make a fundamentally different machine. Even on the series 3, the problem is so acute that they still did all the testing for valid paths and names during the translation of a procedure because at any other time the wait might be unbearable. :)
Post Reply