The Sinclair QL Forum

SET_PRIORITY or SPJOB and the like won't change much (or anything at all) in the behaviour of a system that runs only one job. Whether you set the priority to 1 or 127, doesn't really matter, that one job will still receive all of the CPU. You won't see an effect.

Priority of a job is only relevant with regards to a job's runtime when there is more than one active job competing for CPU time because it is only used by the OS to determine the amount of CPU to distribute to jobs relative to each other. So, all in all, setting the priority of a job is not really usable to adjust the responsitivity of a game.

Sending a job to sleep with SUSJB can actually change responsitivity. The problem is that the original QL gets pretty busy with the overhead of re-scheduling (even if there is only a limited number of jobs running) jobs on a SUSJB, so the granularity available for adjustment is pretty coarse. In my experience, the difference between suspending a job for zero frames (SUSJB -1, 0) (which only does a re-scheduling) and suspending a job for one frame (SUSJB -1,1) is absolutely neglectable, the difference between not suspending at all and SUSJB -1,0 is huge. (That is, re-scheduling after a SUSJB by the system takes much longer than any of the small wait times you might possibly want to wait for) Alltogether, SUSJB is also not a very usable method to time a game.

I think:
For a beginner like you, Tiny, the only timing aid that really makes sense (and will make you see results quickly) is delay loops (but please make them adjustable). Once more advanced, you might be wanting to look into PAUSE with a timeout, then into Dilwyn's timer extension. Note all timing on the QL is still pretty coarse-grained due to the limited QL hardware - The smallest delay you can build is 20ms (I think you've asked for that in an earlier question), because that is the most fine-grained timing source the QL has (Note that is, in comparison, not particularily bad - The IBM PC's smalled timing granularity used to be 18.2ms for a very long time)

Tinyfpga wrote:I have three SMSQE setups:- QPC2, SMSQmuator and Q68.
I have two SMS2 setups:- On PC via Steem and on MIST.

On a Q68, you have the Hardware Timer. Which counts in 25nS steps. Of course this will only work in the Q68

PEEK_L ($1C060)

The counter rolls around about every 107.3 seconds

IO_PRIORITY is not the same as setting a job's relative priority (viz
SPJOB). It is a system wide setting that is supposed to change how
SMSQ balances I/O retries against crude performance. TBH, Im not able
to detect a great difference whatever the setting. I theorised that
that might partly be due to background updating introduced in post-
Tebby versions of SMSQ/E, and that it therefore could still have some
beneficial effect on the SMS2 situation described by Tinyfpga.

My suggestion re loading SUSJB was also wrt SMS2. It is included in
SMSQ/E V3.35 and later.

I dont know about your system, tofro, but on mine the following loop takes exactly 20s, as expected. This will pretty much be the same
across all systems. The same if you replace SUSJB -1, 1 with
k$ = INKEY$(1): exactly 20s.

If you set the timeout to 0, however, loop times vary widely, from ~0
(emulator) to 6-8s (QL). This cannot be due to the loop overhead
processing time, otherwise the the timeout = 1 loop times would
vary similarly. I surmise that the only explanation must be that the
system is rescheduling.

Hence my suggestion that waiting loops should, if possible, include a
scheduler-invoking instruction so as to release the system to do other
stuff while waiting. Clearly, the delay counter must be calibrated
according to the system its running on, but something like
might prevent some otherwise nice or useful program from degrading
overall system performance..

Regarding delays in programs. When I wrote Langton's Ant, in Assembly, back in the eMagazine Issue 5, https://github.com/NormanDunbar/QLAssem ... ag/Issue_5, I originally built in a delay by suspending the task for 1 delay period using MT_SUSJB. It made performance abysmal on a system (QPC) with nothing running except the assembler (which was idle pretty much, waiting for input), QED (also idle as no editing was taking place) and SuperBASIC -- again, idle.

In the end, I built in a delay loop within a loop, with a period of 3 * 65536 * (2 * NOP) + overhead, whatever that works out as! Performance was better, but it kills my laptop as QPC is then hogging all of one core (and I only have 2) reducing Linux to a bit of a crawl.

Sometimes, suspending a job isn't necessarily the best option.

Just a thought.


Cheers,
Norm.

NormanDunbar wrote:<>
Sometimes, suspending a job isn't necessarily the best option. <>

Clearly you didnt see my last post

You are correct, I didn't, but then again, when I started typing, it wasn't there! I went off and made coffee and fed the dog before I finished.

Cheers,
Norm.

Blimey, So much to think about. So much, in fact, that I am going to have to collate all the posts and print them out.
What, and/or where,and what is the purpose of the Q68 hardware timer. Could someone write some demo code to include the use of PEEK_L($1C060) as a method of controlling program flow? Don't PCs have hardware timers?

The purpose of this timer is to provide much higher granularity than 50 Hz. It is mainly intended for hardware drivers. A famous example is Martyn's QL network driver. Since it runs at CPU clock speed, also handy to measure execution timings. Of course you can also use it for precise time measurements in user programs.

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.

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?

Once I learn how to use the instruction in Qlib I will try to lower the priority of the job for a period of time. This might solve the problem mentioned in my earlier posts. As Tofro mentioned the effect I mention is only experienced when there is more than one job executing, and I have always more than 7 jobs running on my setup)

As there does not seem to be access to a timer on a PC or Raspberry Pi this would only work on a Q68.

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.

Replace it with PEEK_L(114784) That's $1C020 converted to decimal.

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

Use something like
a=PEEK_L(114784)
a=a + (a delay in 25ns units)
REPeat loop
IF PEEK_L(114784) > a THEN EXIT loop
END REPeat loop

This is not perfect. If the hardware timer rolls over (resets) during the loop. It will not end.

Don't try to POKE the hardware timer (I don't know if it's possible), As the Hardware timer may be in use by another program.

It should be easy enough to write a machine code SuperBASIC extension to do this delay using the Hardware timer. Some thing like Q68WAIT (a delay in 25ns units)