The Sinclair QL Forum

polka wrote:Wouldn't this scheme only work if SuperBasic is the only job running ? Otherwise, I guess that other jobs may be stealing 1/50sec time slices ? same question for PAUSE 1 : normally it pauses the computer (actually the SuperBasic job) for at least one 1/50sec cycle, but actually may it not pause for longer ?

Would it be possible (to your opinion) to add a little counting code sequence linked directly into the Qdos scheduler, which for sure ticks every 1/50sec ? If so, I think it would be the best timer practical...

Paul

Yes of course if you are thinking in terms of accurate 1/50sec timings, then my routine isn't at all accurate in that respect, but does a reasonable job of incrementing counts for display purposes like mr navigator seemed to want (or what I thought he wanted).
George Gwilt's timing routines in the Quanta mag in June/July 2011 (page 27) showed how simply that could be done with a small piece of assembler code (just 10 lines) linked into the polled list, incrementing a counter held in a spare system variable long word at offset $DC. Most of that 10 lines of code is actually linking in the routine, the timer facility itself (called every 1/50 second) is just an instruction to increment the value and an RTS instruction.

Dilwyn

dilwyn wrote: Yes of course if you are thinking in terms of accurate 1/50sec timings, then my routine isn't at all accurate in that respect, but does a reasonable job of incrementing counts for display purposes like mr navigator seemed to want (or what I thought he wanted).
Dilwyn

From here http://www.theqlforum.com/viewtopic.php?f=3&t=1022

I adapted this slightly

10 PAPER 0
20 CLS
30 frames=PEEK_W(163886)+32768
40 AT 0,0:PRINT frames,INT(frames/50)
50 GO TO 30

to

10 WTV
30 frames=PEEK_W(163886)+32768
40 PRINT frames,INT(frames/50)
50 GO TO 30

This works well on QemuLator in all three modes although slightly longer in BBQL mode as the graphics scroll takes time to update (I believe) on the screen where as the original line 40 requires less time for screen updating. Gold Card Mode works perfectly as does Full speed with the JS ROM. and with all memory allocated up to 8 meg too. Minerva is exactly the same with all memory up to 16Meg and at all speeds as before. Loading SMSQ/e into QemuLator moves the address of the variables so the value PEEK_W is in the wrong location, I will now search for the way round this which I have read somewhere but it escapes me for thew moment.

I seem to remember that this system variable (sv_rand offset $2e or dec.46) was used on systems with microdrives to provide the random number used when formatting cartridges to give the "fingerprint" system used in Microdrive copy protection.

I tried the routine on QPC2 and as I expected it doesn't work. The value stored is different for every run of the program, but does not increment.

I referred originally to George Gwilt's timing routines in Quanta magazine back in 2011 - I hope George doesn't mind that I reproduce it here. This can just be assembled then LRESPRed and it increments a similar counter stored in the system variable at offset $DC decimal 220 (absolute address $280dc or decimal 164060). To check the value of the counter in frames (1/50th or 1/60th second depending on country), just PEEK_L that system variable after it has been LRESPRed, something like

sys_variables=163840
IF VER$='HBA' THEN sys_variables=VER$(-2)
start_time = PEEK_L(sys_variables+220)
.....
end_time=PEEK_L(sys_variables+220)
REMark time elapsed is difference between the two

This is George Gwilt's timing code.

Hi,
RANDOMISE DATE has a bug. Mark Knight wrote a function called True_Randomise in QL Today which is accurate. I do not have the issue on hand, so maybe someone knows which one it is in.
Steve.

Hi,
It's in Volume 01 Issue 6_en. RANDOMISE DATE is described as a "waste of time" This works on the most significant 16 bits - which doesn't vary often enough to be effective.
Michael