Not ROM but speed

[stevepoole]

If you time your programs with INKEY$(#1,1), you are not measuring the speed of your code, but moreover the overhead of time used up by INKEY$.
Avoid this as follows :
100 delay=1 : REMark 1/50th second
110 Wait$ = INKEY$(#1,delay)
This way you can set delay=0 so their is no delay and therefore time only the effective code, not the pausing.
Steve.

[dilwyn]

I'm not saying this would solve the requirement for this particular case, but another way of working around the need for a timing routine is to put in a user-selectable slow down, by using a command like SUSPEND_TASK with a user defined delay. Has the advantage that key presses don't shorten the delay.

At the start of the program, something like

INPUT "Speed 0-50 (0=fastest) ";delay%

then in the main program loop something like

SUSPEND_TASK delay%

Or even when you read the keyboard, arrange for the speed to be changed in real time, e.g. using the "+" and "-" keys:

LET k$ = INKEY$
IF k$ = '-' THEN LET delay% = delay% - (delay%>0)
IF k$ = "+" THEN LET delay% = delay% + (delay%<50)
IF delay% > 0 THEN SUSPEND_TASK delay%

SUSPEND_TASK is a Turbo Toolkit command which when used with a single parameter (delay% in the example) slows down the job issuing the command by delay%/50 'th second.

If you don't want to rely on users having Turbo Toolkit there is a stand-alone SUSPEND extension on my website at http://www.dilwyn.me.uk/tk/suspend.zip

[Mr_Navigator]

Many thanks guys

[Mr_Navigator]

As for timing, the DATE function is based on units of 1/50th second, so this is why it is good for use on timing code on any machine.
100 D=DATE: if D<>DATE: d=DATE: else GOTO 100
110 REMark sets the clock ticking.
115 REM inner_program
120 PRINT DATE-D!'seconds'
As the returned value is only accurate to one second, loop your inner code 50 times for better accuracy.
Regards,
Steve.

Steve.

Im not sure if I get this right, how can I print to the screen some of these 50ths of a second,

Print Date in a loop doesnt do it.

The following works for me using DATE$, but the shortest delay is a second, I would like to get a shorter timed delay, any ideas people?


5000 FOR f=1 TO 78:PRINT "*";:DelayForAwhile 1:END FOR f
5010 :
5030 DEFine PROCedure DelayForAwhile (amount%)
5040 a$=DATE$
5050 a%=a$(19 TO)+amount%
5060 REPeat TimeLoop
5070 b$=DATE$
5075 b%=b$(19 TO)
5090 IF b%>a% THEN EXIT TimeLoop
5100 END REPeat
5110 END DEFine

[dilwyn]

Try the Simon Goodwin DIY Toolkit volume H (Heaps and Horology). This includes BASIC keyword extensions code (lust LRESPR that -and assembler source for 50 Hz timers. It provides up to five stopwatch timers - with keywords like T_START timer_number, LET value=T_COUNT(timer_number) and so on.

Although you have to download the entire DIY toolkit, you can just use the TIMING_CODE file by itself. They can be linked to compiled programs, but as Simon puts the extensions table at the end of the code, it can be hard to figure out the directive needed without reassembling with the table in the more conventional place.

Get the DIY Toolkit from my website at http://www.dilwyn.me.uk/tk/index.html

[dilwyn]

Correction - provides four timers, not five.

[dilwyn]

I've added a small package to the Toolkits page on my website which shows how to implement the 1/50th second timers using a slightly modified versions of the timing_code file by Simon Goodwin from DIY Toolkit volume H. The only change is relocating the extensions table within the code to make it easier to add to compiled BASIC programs. The modified version has been reassembled as timing_cde (note slight change of spelling), and I've added a little demo BASIC program called timers_bas which compiled with both Turbo and QLiberator and included the compiled versions just to show it works!

You'll need to read the Quill _doc files and the README_txt file

To run the BASIC program timers_bas, install the timing_cde with an LRESPR command:

LRESPR win1_timing_cde
LRUN win1_timers_bas

or just EXEC either of the compiled versions - these don't need the timing_cde LRESPRed.

Hopefully, studying timers_bas will show you how to implement these timers quite easily. If it's not clear enough, I can add REM statements throughout to clarify the code, but Iwanted to keep it as short as possible.

Download the package from http://www.dilwyn.me.uk/tk/index.html (scroll down to the Timers package).

Hope this proves useful to you.

[EmmBee]

I've added a small package to the Toolkits page on my website which shows how to implement the 1/50th second timers using a slightly modified versions of the timing_code file by Simon Goodwin from DIY Toolkit volume H. The only change is relocating the extensions table within the code to make it easier to add to compiled BASIC programs. The modified version has been reassembled as timing_cde (note slight change of spelling), and I've added a little demo BASIC program called timers_bas which compiled with both Turbo and QLiberator and included the compiled versions just to show it works!

You'll need to read the Quill _doc files and the README_txt file

To run the BASIC program timers_bas, install the timing_cde with an LRESPR command:

LRESPR win1_timing_cde
LRUN win1_timers_bas

or just EXEC either of the compiled versions - these don't need the timing_cde LRESPRed.

Hopefully, studying timers_bas will show you how to implement these timers quite easily. If it's not clear enough, I can add REM statements throughout to clarify the code, but Iwanted to keep it as short as possible.

Download the package from http://www.dilwyn.me.uk/tk/index.html (scroll down to the Timers package).

Hope this proves useful to you.

Hi Dilwyn,
I've had some problems with your new timing_cde, in that after finishing a task that uses this, and after execing another job, the QL crashes. This has happened with both Turbo tasks and QLiberator jobs. Fortunately, LRESPR ing in the BOOT file still works, though. I haven't learnt any QL machine code yet, so haven't been able to work out what you have done.
Michael

[dilwyn]

To the best of my knowledge, all I did was move the keyword definitions to the start of the code to make it easier to locate the block and work out the directive needed.

The problem may be that in reassembling the assembler may have made some assumptions such as word length and long word length operands may have been incorrectly defaulted. I don't know what assembler Simon used for the original, I used Computer One Assembler.

Given the amount of time I spend caring for my wife at the moment while she is gravely ill and (hopefully temporarily while the NHS try to get a grip on which of her many medications is causing all this) unable to look after herself, and hence the amount of QL work building up let alone anything else, I fear it will be a long time before I can do anything about things like this.

The assembler source is in the Timers package at http://www.dilwyn.me.uk/tk/timing.zip if anyone else would be willing to take a look to help Michael with this. It's hopefully as simple as going through the timing.asm listing, finding places where Simon has not specified move.w/move.l etc and making all these explicit depending on what's needed in the code.

A simpler way perhaps would be for someone to look at Simon's original DIY TK listing and working out the assembler directive needed for the original version, where the keywords definition block is located not far from the end of the code and use that unmodified version.

[EmmBee]

As for timing, the DATE function is based on units of 1/50th second, so this is why it is good for use on timing code on any machine.
100 D=DATE: if D<>DATE: d=DATE: else GOTO 100
110 REMark sets the clock ticking.
115 REM inner_program
120 PRINT DATE-D!'seconds'
As the returned value is only accurate to one second, loop your inner code 50 times for better accuracy.
Regards,
Steve.

Steve.

Im not sure if I get this right, how can I print to the screen some of these 50ths of a second,

Print Date in a loop doesnt do it.

The following works for me using DATE$, but the shortest delay is a second, I would like to get a shorter timed delay, any ideas people?


5000 FOR f=1 TO 78:PRINT "*";:DelayForAwhile 1:END FOR f
5010 :
5030 DEFine PROCedure DelayForAwhile (amount%)
5040 a$=DATE$
5050 a%=a$(19 TO)+amount%
5060 REPeat TimeLoop
5070 b$=DATE$
5075 b%=b$(19 TO)
5090 IF b%>a% THEN EXIT TimeLoop
5100 END REPeat
5110 END DEFine

Hi Lee,

That's a very interesting bug you have in your seconds counting program. Both a% and b% get to be a number of seconds. At the end of the FOR loop, a% will be increased by 78, and so even if a% starts off at zero, it will get a minimum value of at least 78. On the other hand, in the TimeLoop, b% will count up to a maximum of only 59 and can never go higher. We reach a stage where b% can never be higher than a%, and as a result, the TimeLoop is never EXITed. The asterisks will stop being printed out, and nothing can be done about it.

When I first noticed this, my instinctive reaction was to jump to the conclusion that this was somehow down to QPC2. I believe having read somewhere that QPC2 only updates the DATE clock once ever minute - that's what I thought. This is not the case, however; the bug is caused by a logic error in your code. I will leave you with the arduous task of fathoming out what has to be done.

Michael