Geminus and AemulorPro (Can't restart?)" /

For support of the Geminus screen acceleration feature
Post Reply
tonystill
Posts: 20
Joined: Sun Feb 23, 2003 6:41 pm

Geminus and AemulorPro (Can't restart?)" /

Post by tonystill » Fri Apr 21, 2006 10:15 pm

I have just bought Geminus and have an interaction problem with AemulorPro on RO 5.11 (Iyonix).

If I run AemulorPro (2.32) followed by Geminus(1.31 with just the JPEG acceleration) I then have problems quitting Aemulor, even if no 26-bit applications have been run. I have run Aemulor from the Filer and the icon is on the Icon Bar. I choose Quit (emulator too) and the icon disappears from the Icon Bar. If I then try to run a 26-bit application, there is no emulation (as expected). However, trying to rerun Aemulor (by double-click) gives the error message:

Aemulor can't be killed at the moment (Another program is using the SWI vector)

I presume that Aemulor has not exited cleanly but the effect is only apparent when Geminus has also been run. I have never seen this error before using Geminus and I do usually quit Aemulor whenever I'm not using it.

admin
Site Admin
Posts: 381
Joined: Wed Oct 23, 2002 11:25 pm
Location: Cambridge, England
Contact:

Post by admin » Sat Apr 22, 2006 12:39 pm

You need to load Geminus first, then Aemulor if you're going to be starting and stopping Aemulor. This is because the RISC OS API 'OS_ClaimProcessorVector' only allows claimants to unload in the opposite order to which they were loaded. ('First In Last Out')

If the modules are being loaded in your boot sequence, eg. in PreDesk as recommended, then you can change the loading order by adding/removing '!' characters at the start of the module filename(s). Modules are loaded in alphabetical order.

I have some prototype code intended to resolve this API weakness because it occurs with other modules too such as SpecialFX, DeskDebug and DDT.

tonystill
Posts: 20
Joined: Sun Feb 23, 2003 6:41 pm

Post by tonystill » Sat Apr 22, 2006 6:43 pm

Thanks Adrian.

However, it would be neater if Aemulor could simply refuse to quit rather than getting itself into this rather ambiguous state.

I have ignored the recommendation to load at Boot time so that my machine is, by default, as standard as possible - this for testing purposes, not just perversity.

admin
Site Admin
Posts: 381
Joined: Wed Oct 23, 2002 11:25 pm
Location: Cambridge, England
Contact:

Post by admin » Sat Apr 22, 2006 10:13 pm

However, it would be neater if Aemulor could simply refuse to quit rather than getting itself into this rather ambiguous state.
Indeed. The problem is that Aemulor can't really know whether it will succeed in shutting down other than by trying it, and releasing the processor vectors has to be pretty much the final stage of shutdown (after killing all the 26-bit apps and modules).

So I did the next best thing, which was to make sure that the 'zombie' state is safe and doesn't crash the machine, and you get a sensible error message when trying to start a new copy.

I'd rather work on the more generic solution of an API extension so that this problem is resolved for other modules too.

Post Reply