The Sinclair QL Forum

XorA wrote:Ah that timer is nicely in the IO space, so would not be hard to emulate that on sQLux using clock_gettime with the MONOTONIC source!

And it is implemented in sQLux as it was so easy, tested with martin's extension!

Martin_Head wrote:Here's a quick and dirty Q68WAIT SuperBASIC extension for the Q68.<>

Very nice, Martin. What bothers me a little is: Do we now have to code around JVA_WAIT, QPC_WAIT, Q68_WAIT, SUX_WAIT,.. commands? Why not just use a single, sensible, set of keywords for all those functions that do more or less the same thing?

SMSQmulator (and QPC2?) have timers too. Would it be possible to allow all the relevant keyword(s) to be compatible (even though they may not yet have any keyword commands) and wont all support the same facilities (eg through the use of parameters)?

I havent thought deeply about this - I'll leave that to the implementers - but something like TMR_10HZ, TMR_25HZ, or whatever, to be part of the name: Availability function: TMR_25HZ_AVAIL; timer start proc: TMR_10HZ_START 40000.. or whatever..

It bears thinking about for the sake of compatibility, so that programs written for one system can be run on as many systems as possible with a minimum of change or workarounds. The pool is small enough as it is; no point in unnecessarily making it smaller.
£0.01

pjw wrote:Theres no such function in SMSQ/E for Q68, unless its in an as yet unreleased version.
I think it was meant more hypothetically, as in:

I believe Marcel was hinting that someone (me!) could probably knock up a PEEK_UL function, as opposed to there already being one.

Cheers,
Norm.

I'm with Pjw on the matter of a hardware WAIT for SMSQE. Meanwhile I would like thank Martin_head for his Q68Wait instruction. Does the instruction actually halt the program or does it run a program loop reading the real-time clock?

Tinyfpga wrote:I'm with Pjw on the matter of a hardware WAIT for SMSQE. Meanwhile I would like thank Martin_head for his Q68Wait instruction. Does the instruction actually halt the program or does it run a program loop reading the real-time clock?

It reads the Q68 hardware timer address. Then adds the required wait time as a target.

It then effectively enters a REPeat loop reading the hardware timer, waiting for the hardware timer to reach the target time.

I thought afterwards, That a possible improvement might be to reduce the current jobs priority when entering the loop. Then restoring it after leaving the loop.

This could reduce the system load during a paused program.

Martin head posted:- This could reduce the system load during a paused program.

Seems like a good idea. Does reducing a job's priority actually do this?
I assume that hardware is required to actually STOP and CONTINUE a program, but doesn't this kind of hardware exist on all computing systems? How could one write an OS without such control?

Tinyfpga wrote:

Martin head posted:- This could reduce the system load during a paused program.

Seems like a good idea. Does reducing a job's priority actually do this?
I assume that hardware is required to actually STOP and CONTINUE a program, but doesn't kind this hardware exist on all computing systems? How could write an OS and its drivers without such control?

Nope, there's no such thing as hardware that stops and continues multitasking programs. The computer is simply interrupted every 20ms to check whether another job needs to run. If yes, the scheduler "simply" exchanges the CPU context of the currently running job with that of the new one.

Hi Folks,

I just wrote a wait routine that automatically adjusts itself for any system, from 128ko upwards. (Tested on SGC, with QDOS or SMSQ/e and QPC2).

It will allow divisions of up to 1/1000 second, which should be ok for most games... ( or far better on faster systems if needed).

The demo routine beeps at intervals depending on the 'wait' DiVider unit chosen. You may adapt the routines as you wish.

It is first calibrated to the date timer of each system, (and then continues to call the DATE parameter redundantly in the wait loop for loop compatibility).

Of couse, it does waste processing time, but overcomes the weakness of PAUSE and INKEY$, by allowing waiting if any keys are pressed etc.

Hope Tiny and others will find it useful... Regards, Steve.

Hmm. Thinking about it, it is probably possible to build a finer resolution timer purely in SBASIC (if you don't need to use sound in your program) by using BEEP and then wait for NOT BEEPING. This might give you a time granularity of a number of milliseconds. (Parameter 1 of BEEP is the duration of a tone in 72µs increments) You might, however, have to endure quite a bit of horrible noise.

Hi Tofro,

The problem with trying to use beeps as a timer, is that they involve slow communication between the two QL coprocessors.

So you need to use a delay loop before NOT BEEPING to get the right answer... Believe me, I used to use that for music, and it was the only recourse !

But the idea might be worth some experimenting again...

Regards, Steve.
_________________________