Im not sure that that kind of timer makes much sense for delaying loops. Yould still need a resource-demanding loop to monitor it. Yes, you can get more accurately timed delays, but unlike PAUSE, SUSJB etc such a timer doesnt let the system get on with other tasks while it waits (apart from normal job scheduling, of course).Tinyfpga wrote:I tried using PEEK_L($1C060) on a Q68 and in SMSQE's command line. It works as Peter describes, but I have two problems.
The first is that Qliberator will not accept $1C060. I have read through the Qlib manual but can't find a reference to this problem.{/quote]
Qlib V3.45+ accepts literal hex floats. Use that!
The second is that I cannot think of a way to halt a program for a certain amount of time using this instruction.
It would be nice to be able to do something like
n=(a delay in 25ns units)
a= PEEK_L($1C060)
STOP_UNTIL (PEEK_L($1C060))-a = n
I suppose this require something running in the background to monitor the time difference. How does the PAUSE instruction work for example?
On a different track, it might be useful to standardise some kind of timer(s) across platforms. Since the Q68's is already there, and cast in hardware, it would make sense to emulate its capabilities as a minimum. Step 2 would be to add suitable commands to use it into SMSQ/E.
Then, perhaps it wouldnt be too hard for anyone adding an RTC, or any other simple (or complex) piece of hardware to the QL itself to add a Q68-compatible timer too..? Then we could - at last - solve to problem of accurate, asynchronous, timing across the board for anyone who wants it.
Not being a hardware guy, I may be talking through my hat here, but wouldnt it be possible for such a timer (with extra circuitry, perhaps) to generate a hardware interrupt too, at user-specified, case-per-case, intervals? Then more precise wait loops could be implemented without unnecessary time-wasting. Ie, the system would be allowed to get on with other things, and the waiting job be suspended until the timer's release signal arrived..
<>