Aemulor just got broken.

I’m now going to start writing a specification for multi-core operation, preemptive multitasking and overlapped I/O, to see whether – upon posting that – you again say “I’ve just about finished that…” ;)

The more help the better! Often getting the specification right is half the battle.

OS_DynamicArea 26

A little bit of good news to confirm the efficacy of this call.

On a Mac RPCEmu 0.9.1 running RISC OS 5.27 (27 Sep 2019) Aemulor 2.52 fails to start with the “Overlapping areas” error. The better news is that Aemulor 2.52 does start up on a home built rom that contains the new Kernel OS_DynamicArea 26 call.

map a second image of the OS ROM at &03800000 upwards because some old software (!DeskEdit, and quite probably others) assumes its address

I can’t speak for apps, but there’s plenty of games that assume the OS address, for protection purposes. TOPOLOGIKA’s Adventures Classic Collection for example uses the value at 3800000 during one of it’s many decrypt phases.

I’m wondering if I can also make use of OS_DynamicArea 26 to improve Wimp support in ADFFS. To date, I’ve preferred to pause the 26bit environment when the Wimp task switches – the problem with that method is the OS doesn’t preserve L2PT access bits on Appspace pages between task switches, which breaks self-modifying code. The Wimp also appears to task switch at certain points without notifying the Filters, which is a different matter entirely.

Using OS_DynamicArea 26 won’t fix the self-modifying code issue, but it would prevent a lock when the Wimp switches without calling the Filters.

Does OS_DynamicArea 26 perform any checks on existing processes, to see if they have more than the requested Appspace allocated?

Does OS_DynamicArea 26 perform any checks on existing processes, to see if they have more than the requested Appspace allocated?

Yes – it’ll refuse to change the limit if the new value intersects an existing DA/wimpslot

Nota for Adrian: it would be really great to be able to disable/enable Aemulor (and the little/big wimpslots) with an adjust click on the icon. Then, it could be loaded on start (disabled) without consequences. Perhaps it could be even possible to enable/disable it with a CLI command (used in the !Run file of 26bit software).

@David: Suggestion noted, but I don’t really see how it can be made to work. It would require that all execution of 26-bit code be stopped whilst disabled, which means unhooking/somehow deactivating every running application, module, service call handler, IRQ handler etc etc. With RISC OS this just isn’t really possible.

The alternative of killing all that code when asked to disable Aemulor is really no different from just quitting Aemulor.

Sometimes I idly toy with the idea of making things application-local such that the 26-bit application sees its own set of dynamic areas and 26-bit support modules, and then it would not be necessary to restrict the application slot size for 32-bit code, but the ramifications aren’t really clear; anything using service calls in particular would not be notified at the appropriate time of information that it needed. It would in effect become detached from the 32-bit world and the goal of Aemulor was always transparency and integration rather than a sandbox/virtual machine approach.

It seems a lot of work only to discover that it’s an essentially unusable feature, working only for 26-bit BASIC and/or assembler applications with no supporting modules.

The alternative of killing all that code when asked to disable Aemulor is really no different from just quitting Aemulor.

I agree. My idea is just to say, autoactivation (eventually with a predefined app list), autoquit (when no 26bit app is loaded) and stay on iconbar (active: colourful icon / inactive: b&w icon). Today, there is autodetection of 26bit code, but the module is active even if there is no need for it.

Of course, you’ll need to throw a message if Aemulor can’t be activated (existing wimpslots way too large).
For example: “Error while launching Impression. Please quit NetSurf and try again”.
The opposite could be true too: “Error while launching OBrowser. Please quit Impression and try again”.

IMHO, that would be more transparent. In fact that could be so transparent that no icon will be needed any more, but just a pref applet to manage the 26bit application list and perhaps a tool to see what’s loaded in 26bit mode.

Anyway thanks for your attention.
And please, a DVD player for my Doctor Who collection :)

What might work (maybe?) is a small helper module that can be loaded at boot. If it notices an attempt to run a 26 bit C application or module (it’s a distinctive enough error message), it could tap that and offer to start up Aemulor? Perhaps that might work?

Note that you’re on your own when it comes to 26 bit assembler (or BASIC/assembler) programs, as the “no can’t” error for apps is actually generated by CLib when it uses the old method of linking into the library. There is, as far as I know, no mechanism for detecting 26 bit apps otherwise, although to be honest RISC OS is a bit remiss in not rejecting programs that begin with a BLX instruction as those crash before making it as for as CLib. BLX was once upon a time BLNV which was the old fashioned NOP and does turn up in old 26 bit programs.

Perhaps that might work?

That’s what Aemulor already does (+ a list of 26bit apps).

What I suggest is not loading the Aemulor module until an attempt to run 26bit code is detected. And unloading it as soon as there is no 26bit code running.

+ Messages for apps with large wimpslots (trying to launch Aemulor while running = apps should be stopped – attempt to run apps while Aemulor is running = Aemulor should be stopped).

What I suggest is not loading the Aemulor module until an attempt to run 26bit code is detected

Yeah… You might want to go back and read my message again…

You might want to go back and read my message again

Yes I should :)