Re: 1.0.0 RC 1 is now available for download

On 4/5/07, toby <toby_at_email.domain.hidden> wrote:
>
>
>
>
> You could instead test how long a frame update takes.

That's actually a good idea.

You've sort of inspired a thought: Looking at wxMilliSleep's source it seems to call nanosleep which can be interrupted. So one thing to measure is the clock around the sleep statement and adjust accordingly. It is possible for an even to interrupt the sleep.

The reason I suspect this is that I'm fairly sure that the logic behind the timing mechanism is correct. The math for the MHz display seems to me to be right. But none the less, the actual Lisa clock which should increment every 1/10th of a second goes fast after a while and runs 2x-3x. So that means that the value I'm telling the code to sleep for isn't right, even though I pass the right value to it - therefore, it must be getting interrupted.

You can actually confirm this by running LisaWrite and watching the text insertion bar cursor - it flashes much faster than on a real Lisa, even when the 68K CPU speed is roughly 5Mhz...

So this opens up another idea. Perhaps I shouldn't tie the 1/10th second clock to the CPU clock, but rather, base it on the host's timing. That way, no matter how fast you set the throttle, the Lisa's clock will work. I'm not sure that it's worth the hassle because of the year 1995 issue, but perhaps it'll be useful in some way.

Another thing I need to be sure of is what nanosleep really does. If it's something truly dumb such as a tight cpu burning loop that just counts cycles, that would hurt performance rather than help.

Why not refresh say once per second anyway? That cannot be much of a
> cost.

If we get too far away from a 60Hz refresh rate, the mouse movement gets choppy, so there's some narrow range of parameters that provides the right number of refreshes where it doesn't eat up too much CPU and doesn't introduce a high latency. Finding that is tricky as it's different for every class of machine.

There is another thought which is rather than update and blit, I can update the screen directly - this would be just for OS X, but I need to write some logic around it to prevent a full Blit afterwards. I'd still have to Blit the lisa's display changes to a wxBitmap internally incase the window needs a full redraw. So it would be something like update the bitmap, and write the changes to the display, but suppress the full Blit for just that cycle.

I'll give these ideas a spin and see if they work.

On a G4 500Mhz tower with only 512M, I get an average of about 2.3Mhz when there's display activity, but it occasionally spikes as high as 20MHz with RC2, 18 with B2 at those times when the display isn't being refreshed and is idle. Now the CPU emulation is at times expensive, espeically in tight loops such as during the Power On Self Test memory and MMU tests - which is why there's a cheat for it.

--~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "LisaList" group. To post to this group, send email to lisalist_at_email.domain.hidden To unsubscribe from this group, send email to lisalist-unsubscribe_at_email.domain.hidden For more options, visit this group at http://groups.google.com/group/lisalist?hl=en -~----------~----~----~----~------~----~------~--~---