Timing of emulator base on win32

skyler · Post by **skyler** » Fri Sep 19, 2003 5:07 pm

Scott,

Inface,If I can't finish 1ms task,the next ONTIME message will be miss.because Timer priority is lower than other message.It would not queue in windows message.

Skyler.

+++++++++++++++++++++++++++++++++++++++++++++++

kc5tja,

Sorry,I do not know how to post code in this forum before.I'll be notic later.
Thank you.

Skyler.

schidester · Post by **schidester** » Fri Sep 19, 2003 8:54 pm

Skyler,

Well, then did your code snippet work? It looks like it would. If it doesn't, I'd try a mutithreaded approach (although I think 95/98 don't support it as much as NT/2000). Anyone else with some Win32 experience want to chime in?

Scott

kc5tja · Post by **kc5tja** » Sat Sep 20, 2003 3:43 am

schidester wrote:

Skyler,

Well, then did your code snippet work? It looks like it would. If it doesn't, I'd try a mutithreaded approach (although I think 95/98 don't support it as much as NT/2000). Anyone else with some Win32 experience want to chime in?

Scott

Windows 95/98 support threads about as much as Windows NT/2000/XP does. The critical difference is that 9x doesn't support the Unicode APIs and the security APIs. Otherwise, threading between the two of them are identical.

Also, 95/98 lacks the "real time" priority, IIRC, but that's OK. Any task running at "real time" priority will, due to WIndow's wholesale inadequate synchronization APIs, effectively lock the system up, since it'll hog the entire CPU. Real-time priorities are useful on SMP systems, though.

schidester · Post by **schidester** » Sat Sep 20, 2003 2:25 pm

kc5tja,

There are some things missing from 95/98 that NT/2000 provides. I know (from limited experience) that NT/2000 provides CreateWaitableTimer and associated functions. That's what I was thinking would be good for skyler's project, but 95/98 doesn't support them. I suppose the MMTimer stuff he's using is equivalent. And yes, 95/98 does at least provide semaphores, threads, mutexes, etc., so sure, it supports multithreading.

What I'm looking for from either 95/98 or NT/2000 is a wait until an absolute time, not a relative time. For example (in pseudo code):

Code: Select all

EXPIRE TIME = CURRENT TIME
LOOP
	CASE TIME EXPIRE MESSAGE:
		RUN SIMULATION ( 4000 cycles )
		EXPIRE TIME += 1ms
END LOOP

This will always run the simulation on 1ms intervals, unless the PC is too slow. Even then, if the PC got hung up on some printing process or something else, at least the current time marches on and the simulation will eventually catch up. I suppose there are caveats, such as Windows dropping a timer message because it's low priority, but with workarounds such as skyler's, it can be done.

Another approach is to not wait until an absolute expire time, but to "wait until 1ms from now, minus any time already taken." That's a relative-time approach and isn't guaranteed to work because the process can be preempted between calculating the relative time and actually waiting on it.

Skyler's approach using a periodic timer and checking the current time for an "are we already past the 1ms mark?" condition resembles the absolute time method, so it should work.

Scott

kc5tja · Post by **kc5tja** » Sat Sep 20, 2003 3:21 pm

schidester wrote:

Skyler's approach using a periodic timer and checking the current time for an "are we already past the 1ms mark?" condition resembles the absolute time method, so it should work.

Scott

It'll definitely work. I've written several multitasking kernels in the past (which are no longer publically available, but I might develop another one for the fun of it; it's an enjoyable hobby for me), and the last two had timer support which, off of one PIT timer, supported all the running tasks with microsecond (or as close to it as I could get with the PIT chip) resolution, precisely by using the technique you describe above.

It saddens me to see that Windows and Linux making using the timing facilities of the computer so doggone hard/borderline impossible. It's retarded. AmigaOS made the timer facilities so patently obvious to the programmer that for the longest time, AmigaOS applications rarely were multithreaded -- they just didn't need it.