A reasonably simple frame counter...?

[TMD2003]

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?

[martyn_hill]

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

[dilwyn]

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).

[tofro]

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.

[dilwyn]

viewtopic.php?p=39138#p39138

I think this is what tofro was referring to.