Tinyfpga wrote:<>
On the matter of my questions 3 and 4, I have tried pjw's suggestion of using a timeout of 0. On my laptop this creates a delay of approximately 50 micro seconds. Looped 5 times this creates a delay of 0.25 msecs. It is the smallest delay that ameliorates the performance problems mentioned in my post.
I like the sound of pjw's SUSJB but it also creates a minimum delay of 20msecs whereas for animation I need a lot less than this. Can SUSJB be altered to have a resolution of 1/1000th of a second?
Has no one else experienced the effects I mention when executing animation programs in the foreground?
Im never quite sure of when you refer to your Q68 and SMSQ/E or your SMS2 system, and since I have no experience with SMS2, I cant tell which facilities are available..
Does your SMS2 system have the command IO_PRIORITY? If you do, have you played with it? The syntax is IO_PRIORITY <level>, with levels running from 1 (QDOS levels of response, higher crude performance) to ca 1000 (Maximum response, the performance depends on the number of jobs waiting for input.) Perhaps fiddling with that may prevent the foreground task hogging the system?
Delay loops: I think its probably better to involve the scheduler in some form rather than just creating friction by loops and calculation. This allows more opportunity for the system to get on with other things meanwhile. Please someone correct me if Im wrong, but any traps that would normally invoke the scheduler, even with a timeout of 0, allows jobs to be rescheduled, no? Thus SUSJB -1, 0 would be useful in any delay loops where SUSJB -1, 1 is too slow. A simple AT#ch; 0,0 or similar, where appropriate, might also do.