[Rpcemu] An idle loop?

Theo Markettos rpcemu at markettos.org.uk
Sun Jan 31 09:18:01 PST 2010

On Sun, Jan 31, 2010 at 05:35:57AM +0000, Johann Myrkraverk Oskarsson wrote:
> On Sat, Jan 30, 2010 at 11:40 PM, Theo Markettos
> <rpcemu at markettos.org.uk> wrote:
> Thank you.  It seems to work fine here.  I have not noticed any disturbance yet.
> Perhaps better granularity can be achieved by calling nanosleep where available?

I'm not sure that's the problem... the problem is something to do with
mouse/button presses getting lost while the emulator is sleeping.  RISC OS
only has a centisecond timer, so it shouldn't be affected by
microsecond-scale sleeps.  It stalls for IO, so they should be expected
anyway.  I think it's a problem with the emulator missing things rather than
the OS.

> > RISC OS also calls the SWI Portable_Idle when it is idle, so that's a
> > potential mechanism to release some of the CPU. I can't remember if RPCEmu
> > makes use of that.
> If you point me in the right direction I *may* look into it, depeding
> on time and other constraints.  If you do, keep in mind I have zero
> exp. points (rpg talk) in risc os programming.

OK, here goes.  The RISC OS 3 Programmer's Reference Manual is here:

(There isn't really a RO4/5/6 PRM, only supplementary volumes for new

Google reminds me that I got my facts slightly wrong, and it's
Portable_Speed that may be of use.  Have a read of this thread:

A bit of background... the A4 laptop had a 24MHz CPU clock which could be
reduced to 6MHz when the CPU was idle.  Portable_Speed is the call used to
do that, which is why it's such a blunt interface.  It appears it's still
called from modern OS code, unless RISC OS Ltd have tidied it away in their

The Portable module is documented on page 4-205, in other words page 205 of

The simplest way might be to receive the calls to Portable_Speed in the
emulator and convert them to cause more or fewer sleep calls.  The emulator
already traps some SWIs for its own purpose, so in the emulator core you can
see where it calls some routine rather than the emulated ARM SWI handler.  See
line 2744 and following of arm.c:

The JIT version of that code is in opSWI() in ArmDynarec.c

That would be a less clumsy way of doing things than the Sleep program,
though it needs to not miss UI input.  Possibly running variable amounts of
system load might be one way to simulate this problem.

[Note to mailing list folks: I'm a bit out of date, so feel free to point
out where I've gone horribly wrong]


More information about the Rpcemu mailing list