The Sinclair QL Forum

Thought I'd have another bash at SuperBASIC programming after a bit of time off (well, since the end of last year anyway). And, as I'm sure you're all aware for those of you who remember me and what I did a few years ago, I am a Spectrumaholic.

So this might be another case of "you're thinking too much like a Spectrum programmer", but bear with me.

All I want to do is measure the time that a procedure takes to run. It's easy enough on the Spectrum: POKE all three bytes of FRAMES to 0 (high to low), run the procedure, PEEK all three bytes (low to high), display the result. Probably only two bytes are needed, really, because it takes nearly 22 minutes to rack up 65,536 frames.

I am having real trouble finding the equivalent on the QL. I don't see any system variables listed on the documentation hosted here, none of the machine code manuals I have told me what I needed to know, and as much as I've found is the Technical Manual, which does have a list of system variables, but implies that machine code is needed to handle them ("find the position of the system variables in memory by calling the MT.INF trap") - and at that point I'm stumped. I can't even find anything in the list of SV_ or BV_ variables that looks like it could be a frame counter.

Before anyone mentions the real-time clock, measuring in whole seconds isn't going to cut the mustard here. 50ths of a second is ideal - it doesn't need to be as tiny an amount of time as a t-state.

I suspect that this is the kind of thing that was worked out very early in the QL's life, but you'd have to know where to look to find out.

Anyone know what I want to know?

Hi TMD!

Not an unreasonable ask and one that has appeared here before, under various guises...

Put simply, QDOS does not itself maintain any kind of frame-counter like our humble Speccy does, though it does count frame-interrupts when deciding when to service any waiting IO and uses a slightly more clever system for deciding when a given Job needs to be re-scheduled - also based on how many frame-interrupts have passed.

None of which leaves behind a continuously readable tick-counter like those 3-bytes at FRAMES on the Speccy...

So, Mr Goodwin wrote the 'Timer' extension as part of his DIY Toolkit series for QL World - and something I use myself quite a lot. You can download the entire DIYTK series of articles and ready-assembled code from Dilwyn's 'QL Homepage' repository - see the link in the QL Forum banner above. The download itself is here: https://dilwyn.theqlforum.com/tk/diytk2.zip

There is another article about timing by the late George Gwilt, though this one needs some knowledge of assembler

https://dilwyn.theqlforum.com/docs/articles/timer.pdf

There's another article about using them here: https://dilwyn.theqlforum.com/tk/timing.zip (note the warning about using them in compiled programs, though)

The Simon Goodwin files Martyn mentioned are at https://dilwyn.theqlforum.com/tk/diytk2.zip - within that package you'll need to look in Volume H (Heap & Horology).

dilwyn wrote: Wed Jun 18, 2025 9:31 am There is another article about timing by the late George Gwilt, though this one needs some knowledge of assembler

https://dilwyn.theqlforum.com/docs/articles/timer.pdf

There's another article about using them here: https://dilwyn.theqlforum.com/tk/timing.zip (note the warning about using them in compiled programs, though)

The Simon Goodwin files Martyn mentioned are at https://dilwyn.theqlforum.com/tk/diytk2.zip - within that package you'll need to look in Volume H (Heap & Horology).

The fact that the READMEs on DIY TK don't mention the same caveats for compiled programs as Dilwyn's timer code doesn't mean they don't suffer from the same problem in compiled programs: They indeed do. There's a proposal for a fix from Marcel Kilgus somewhere here that fixes the problems with an undocumented feature in QDOSMSQ.

viewtopic.php?p=39138#p39138

I think this is what tofro was referring to.

dilwyn wrote: Wed Jun 18, 2025 11:05 am viewtopic.php?p=39138#p39138

I think this is what tofro was referring to.

Yep, that's it. Thanks Dilwyn for remedying my laziness...

Cheers for all that. Simon Goodwin certainly gets around on all the Sinclair machines - the QL, the SAM Coupé, and a fair bit of how the Next has developed has got to be down to him. I've got to read his "Next Tech" book at some stage, though I might have to leave it until the dark nights close in.

Now let's see if I can get it to work! No worries about compiling the program, I'll not be resorting to that. What I'm going to need to test is some screen-drawing routines to see how fast I can get it done on a regular QL - no Gold Card, definitely no SMSQ/E - and if even the fastest one I can find is still too slow, I'll revert to writing to the screen with machine code (which should just be a ton of MOVE.Ws and a lot of loops).

Hi TMD

Good luck!

TMD2003 wrote: Wed Jun 18, 2025 8:45 pm Cheers for all that. Simon Goodwin certainly gets around on all the Sinclair machines

Doesn't he just!

TMD2003 wrote: Wed Jun 18, 2025 8:45 pm (which should just be a ton of MOVE.Ws and a lot of loops).

If it comes to that (and on a vanilla QL, it's not uncommon...), you might want to rationalise those MOVE loops with a hefty MOVEM (and fewer loops) instead...

Given the relatively sluggish bus-speed of the QL, you'll want to avoid instruction fetches and DBRA iterations as far as poss...

TMD2003 wrote: Wed Jun 18, 2025 8:45 pm Cheers for all that. Simon Goodwin certainly gets around on all the Sinclair machines - the QL, the SAM Coupé, and a fair bit of how the Next has developed has got to be down to him. I've got to read his "Next Tech" book at some stage, though I might have to leave it until the dark nights close in.

Now let's see if I can get it to work! No worries about compiling the program, I'll not be resorting to that. What I'm going to need to test is some screen-drawing routines to see how fast I can get it done on a regular QL - no Gold Card, definitely no SMSQ/E - and if even the fastest one I can find is still too slow, I'll revert to writing to the screen with machine code (which should just be a ton of MOVE.Ws and a lot of loops).

Our resident demo writer @spkr released his optimised screen drawing routines I think. Hopefully he notices this post as I cant remember his github!