Date   : Thu, 18 Aug 2005 11:35:34 +0100
From   : Richard Gellman <splodge@...>
Subject: Re: BeebEm bug?

>Tom, I've also noticed that Model B runs at 99% on my home PC (or 49% on my
>work PC which has hyperthreading on its single CPU), and I also wondered if
>this needed to be the case.  I wonder what BeebEm 2.2 is doing to be able
>to cut its CPU use down to 10%?  Is it possible to Sleep() the process for
>the few microseconds required, rather than stalling it with a delay loop?
>(I am not a Windows programmer so I have no idea if sleeping for such a
>small amount of time is possible...)
>
>Cheers,
>Rich
>  
>
BeebEm < 2.x was written in my less-informed years, and uses a rather 
nasty way of delaying itself to run at the right speed: if we all 
remember the BBC Micro trick of now=TIME:REPEATUNTILTIME>=now+100? Well 
BeebEm's consisted of now=GetTickCount();while 
(GetTickCount()<(now+1000) { } ....

Not elegant, and consumes the whole CPU while doing it.

The better option is to either:

a) usleep() the required period (like sleep(), but with finer time 
resolution)
or
b) instead of running the emulator in a continuous loop, have one 
"cycle" executed on the signalling of a Windows WaitableTimer. This 
would literally hold the (host) CPU in suspension until it is time for 
the next (emulated) CPU cycle.

Keep in mind, that a lot of BeebEm's operation has been ported from 
Unix/Linux, and lacks some of the more elegant programming practices 
common to windows (in terms of responsiveness, CPU usage, etc). Ideally, 
the following would need to occur:

i) Move the CPU loop into a separate thread, with proper thread syncing 
between the Windows message pump and the emualtion thread.
ii) Move from Windows Message-based I/O (mouse, kbd) to DirectInput. 
This operates through the COM/Notification system, and would be more 
efficient, and less CPU-intensive.
iii) Improve the DirectDraw (now part of DirectShow) interface to use a 
buffered/buffer-flip system. I was partway into getting this going, but 
suffered a time deficiency. This does typically only work in full-screen 
mode.
iv) Put the sound processor into a separate thread. Sound has always 
suffered from a cycle-to-time problem, that occasionally results in 
audio break-up. A separate thread (ideally running on notifies) would 
sort this out.
v) Do away with my utterly crap serial port code that breaks anything it 
touches.

Any takers?

-- Richard