Not ROM but speed

[Mr_Navigator]

I'm sure this has been asked before but is there a way for S*BASIC to detect at what speed it is running or at least the difference between different setups without using the ROM ident?

I would like to detect

BBQL
BBQL Gold Card
BBQL Super Gold Card
Q-Emulator BBQL
Q-Emulator BBQL Gold Card
Q-Emulator FSA
SMSQmulator

QPC2 is probably similar to the last of above as it runs at the speed of the host machine therefore hopefully the same applies, I can use the ROM for this.

[RWAP]

There is no documented way as such (apart from using calls to look up the processor and/or expansion available), but then not all QLs will have access to this, and some QL expansion RAM is faster than others.

Your best bet is to add a bit of code at the start of your program which runs a specific loop a set number of times, and compares the time taken to run it - use the DIY toolkit timer routines, or ideally a quick machine code routine to do this.

Daniele developed a short timing routine for me to run some years ago to get the relative speeds of the QL, Super Gold Card and q-emulator....

[tofro]

Whatever "relative speed" would mean....
Just one example to make you think about it:

GoldCard + S*Basic on SMSQ/E is executing a BASIC program way faster than a SuperGoldCard + SuperBASIC on QDOS.

The Linux community has tried to build something like that with their famous "BogoMips" and has horribly failed. There is no such thing as a general "x Times faster than..." that can by easily measured by a simple piece of code.

If you want something that runs exactly at the same speed on all QDOS platforms, you need to use timers. Period.

Tobias

[Peter]

BogoMIPS was just intended to calibrate delay loops, not a scientific measurement.

BogoMips is also useful to verify whether the processor is working at the proper speed. This way I have alreday detected wrong PLL settings, wrong oscillator frequencies and cache problems.

[1024MAK]

As in many other areas, "speed" is not a closely defined term.
Maybe we should talk about cycle timings instead.
But even here, there are problems, as the 68K processors allow variable memory cycle times...

Mark

[Mr_Navigator]

Perhaps I should elaborate, I am writing a program that involves moving a cursor around the screen in character blocks, this size changes depending the CSIZE selected in program. Eventually when finished I will probably compile it using TURBO so that it can run on most systems and adequate speed on the original BB. I don't want it to move too quick on faster systems and hence become unusable. So I am looking for a way to detect the system it is running in so that some slow down routines can be invoked. Or should I be looking at some other way to achieve this?

[tofro]

Lee,

maybe you need to turn around your way of thinking - Don't concentrate on "speed", but rather on "elapsed time".
That is, define, for example, your cursor should move no faster than 5 steps per second. That is, one single cursor move should have an elapsed time of 0.2s (obviously, that elapsed time should be within the achievable range of the slowest platform, i.e. interpreted SuperBASIC). Then code along this line (you will definitely need some timer routines for this, as pointed out before).

Code: Select all

REPEAT outer 
   StartTimer (0.2)
   MoveCursor
   REPEAT inner
       IF timer expired : EXIT inner
   END REPEAT inner
END REPEAT outer

If your program can do something sensibly - like nice additional animation - on faster platforms within the "inner" loop, even better. Do that, instead of just wasting time.

"Modern" commercial machine code or C games on the PC do it very much like that (and machine code games on home computer platforms were defined around similar design patterns). They define a complete "frame rate" (That is, "I want the screen completely redisplayed every 0.xs") - But that is most probably impossible with interpreted S*BASIC

Regards,
Tobias

[stevepoole]

It is important in timing routines not to ignore the overhead of the timing routine itself.
QL Today printed a basic code timer and article of mine in 2007.
It should run on any QL system.
Steve.

[EmmBee]

Perhaps I should elaborate, I am writing a program that involves moving a cursor around the screen in character blocks, this size changes depending the CSIZE selected in program. Eventually when finished I will probably compile it using TURBO so that it can run on most systems and adequate speed on the original BB. I don't want it to move too quick on faster systems and hence become unusable. So I am looking for a way to detect the system it is running in so that some slow down routines can be invoked. Or should I be looking at some other way to achieve this?

In these types of situation, I use the INKEY$ function, usually with a delay parameter of -1, which would cause the QL to wait until a key is pressed before continuing. There are delays built into the Inkey$ function which allow for the light/heavy handedness of some uses, and also control the amount of time that elapses before another keypress is detected. From the users point of view, this is an ideal situation. Also, since these delays are governed by the rate of the electricity mains supply, the cursor should move across the screen at the same rate on any type of QL installation. Inkey$ simply has to be regarded as the ideal way of detecting key presses. The alternative of using KEYROW calls do not have these advantages. The code I write using Inkey$ would typically be along the following lines ...

Code: Select all

100 :
110 MANIFEST : left = 192 : right = 200 : up = 208 : down = 216 : Esc = 27
120 :
130 c = FOPEN("CON_448x180a32x16")
140 CSIZE #c,3,1
150 colmax = 448 DIV 16 -1
160 rowmax = 180 DIV 20 -1
170 col = colmax DIV 2
180 row = rowmax DIV 2 : REMark start in the centre
190 CLS #0 : CLS #c : CURSOR_ON #c
200 REPeat loop
210   AT #c,row,col : AT #0,0,0 : PRINT #0,"AT #c,"; row; ","; col; "  "
220   k = CODE(INKEY$(#c,-1))
230   SELect ON k
240   = left  : IF col > 0      : col = col-1
250   = right : IF col < colmax : col = col+1
260   = up    : IF row > 0      : row = row-1
270   = down  : IF row < rowmax : row = row+1
280   = Esc : EXIT loop
290   END SELect 
300 END REPeat loop
310 CURSOR_OFF #c : PRINT #c, "Q" : CLOSE #c
320 PRINT #0,"Done!"

I compile with Turbo and also use the Turbo Toolkit. Notice the use of the MANIFEST command, which is used to make certain that the initial constant values given to the variables on the same line will not change. Also, the use of the Cursor on/off commands allow the task to fully multi-task alongside other jobs that may be running on the QL.

We are living in a world where the modern PC runs at 1000 times the speed of the original QL. Today, emulators are all the rage. QPC2 is one of the fastest and best emulators there is - it is also free! Using QPC2 version 4.02, SBASIC runs under SMSQ/E 12.5 times faster than the old QDOS. Nowadays, there are many more colours available, much larger screens, the pointer environment, and Toolkits abound. Todays QL programmer has it all like never before. We live in a multi-tasking environment, where there may be several tasks running concurrently. However, only one of these tasks can have control of the keyboard at any one time. Control and C is used to switch tasks, and when this happens, the cursor of the new task begins to flash. The cursor has to be regarded as the most singly significant icon on the QL and so INKEY$ is the function to use.

Michael

[stevepoole]

Yes, INKEY$(#1,1) is the one to go for. You could use PAUSE 1 for the same effect, but PAUSE won't accept a channel number, and so you need to compile with #0.

Much simpler is to compile with no windows on the menu screen, but have OPEN#1, con_128 in your code. Then you can have INKEY$ from channel one, and a much smaller task code in your job.
Cursor too, only works well in channel one anyway.

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.