RISC OS Open
Safeguarding the past, present and future of RISC OS for everyone
ROOL
Home | News | Downloads | Bugs | Bounties | Forum | Documents | Photos | Contact us
Account
Forums → Community Support →

Aemulor just got broken.

Subscribe to Aemulor just got broken. 36 posts, 9 voices

Posts per page:

Pages: 1 2

 
Sep 26, 2019 10:10am
Avatar Jeffrey Lee (213) 6017 posts

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.

 
Sep 28, 2019 11:40am
Avatar David Pitt (3386) 1248 posts

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.

 
Sep 29, 2019 9:16am
Avatar Jon Abbott (1421) 2356 posts

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?

 
Sep 29, 2019 10:45am
Avatar Jeffrey Lee (213) 6017 posts

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

 
Oct 4, 2019 7:27am
Avatar David Feugey (2125) 2626 posts

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).

 
Oct 4, 2019 10:13am
Avatar Adrian Lees (1349) 122 posts

@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.

 
Oct 4, 2019 11:58am
Avatar David Feugey (2125) 2626 posts

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 :)

 
Oct 4, 2019 6:24pm
Avatar Rick Murray (539) 12213 posts

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.

 
Oct 4, 2019 6:39pm
Avatar David Feugey (2125) 2626 posts

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).

 
Oct 4, 2019 7:28pm
Avatar Rick Murray (539) 12213 posts

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…

 
Oct 4, 2019 8:54pm
Avatar David Feugey (2125) 2626 posts

You might want to go back and read my message again

Yes I should :)

Pages: 1 2

Reply

To post replies, please first log in.

Forums → Community Support →

Search forums

Social

Follow us on and

ROOL Store

Buy RISC OS Open merchandise here, including SD cards for Raspberry Pi and more.

Donate! Why?

Help ROOL make things happen – please consider donating!

RISC OS IPR

RISC OS is an Open Source operating system owned by RISC OS Developments Ltd and licensed primarily under the Apache 2.0 license.

Description

Community-provided support for all users of RISC OS.

Voices

  • Jeffrey Lee (213)
  • David Pitt (3386)
  • Jon Abbott (1421)
  • David Feugey (2125)
  • Adrian Lees (1349)
  • Rick Murray (539)

Options

  • Forums
  • Login
Site design © RISC OS Open Limited 2018 except where indicated
The RISC OS Open Beast theme is based on Beast's default layout

Valid XHTML 1.0  |  Valid CSS

Powered by Beast © 2006 Josh Goebel and Rick Olson
This site runs on Rails

Hosted by Arachsys