Private/Shared memory

Currently RO remaps the application space from 8000 upwards when task switching, could this be extended to allow additional private memory regions that are specific to that application/module. A means to allow these regions to be shared among applications/modules would also be required.

This might resolve the issue of having to restrict application space across all apps to 32mb when running legacy software under ADFFS and possibly Aemulor, the memory regions they require can be created as private, so wouldn’t be mapped in for other applications. It would also allow each legacy app to have it’s own isolated environment if required.

DA’s might be a simple means of doing this, provided they were extended to contain a list of applications that have access to privately created DA’s.

For modules support, add an SWI to map private DA’s in/out.

There isn’t really a concept of privacy, if you play with Zap you’ll see it’s a doodle to read modules, module workspace, and application workspace.
For what you want, a DA will probably do it¹, though note that the privacy aspect is purely down to it being highly bad form for software to go messing with memory it doesn’t own…

¹ Though I’m not sure about executing code in a DA.

If you want additional memory regions that are specific to an application, a DA is the standard way. The regions are private in that they belong to the app the requested them. There’s no such thing in RISC OS as a memory area that is private in the sense that it cannot be read by another app.

If you want to share a DA between cooperating applications, send WIMP messages between the apps. The message content can be what you want. You can send the DA’s base address and use that in a simple shared memory model.

Unfortunately you can’t map a DA to 1F88000 when application space is over 31mb, you could if it was private to the application creating it and only mapped in when the application is mapped into application space.

I’d like to find a solution to resolve the application limit when emulating a RO3.1-RO4.x environment under RO5.

I think where you may be coming unstuck is with all this talk of mapping stuff. As I understand it, DAs are not mapped, they just are. Think of them as a replacement to claiming loads of tiny bits of the RMA (and the associated fragmentation problems).

It seems to me that Aemulor is trying to do the best of a difficult job. I wouldn’t be surprised if the idea of running the code in DAs hasn’t already been discussed, and sure, it sucks to have the limitations affect the rest of the system, however looking at it the other way around – how much speed are you willing to sacrifice? If I had more time and intelligence, I could probably make you a completely sandboxed emulation. The flip side? You’ll get that good old 8MHz ARM2 feeling. ;-)

What you’re really talking about is the concept of a sparse application area.

RO4 supports sparse DAs and since the Application Space has a DA number of -1 from 4.2 one might imagine one could achieve exactly that with OS_DynamicArea 10.

But you can’t – because the application space is a curious hack performed by the Wimp so even if the OS implemented it, the Wimp would get confused.

So you’ll have to do it the hard way – get your pages either by reserving specific pages in your application slot or by creating a DA of the appropriate size, and then on Service Calls &CC and &CD remap the pages with SetMemMapEntries to appear where you want them (and back again).

You could do the remap after (and possibly before) Wimp_Poll, but doing it at the Wimp’s task switching level would most probably be better.

Actually I just tried it in RO4 and no switching back and forth is necessary if it’s application space pages you move — the Wimp maintains the mapping. Isn’t that nice?!

So just be careful about remapping pages when you change the slot size and Bob’s your uncle.

So to clarify, use ReadMemMapInfo to find the size of a page, FindMemMapEntries to find the area of your slot (in terms of pages) that you want to move, and SetMemMapEntries to move it.

Just checked in RO5 too. Works.

I can code private and shared memory myself, that’s not a problem. The reason I raised it here, is that I feel it would be useful to extend the task switcher to map more than just application memory and introduce the concept of protected/shared memory.

For my particular project, I require as an example, 480KB mapped twice from 1F88000 up and shared between the ADFFS module and the game that’s running.