Not ROM but speed
- Mr_Navigator
- QL Fanatic
- Posts: 782
- Joined: Mon Dec 13, 2010 11:17 pm
- Location: UK, Essex
- Contact:
Not ROM but speed
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.
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.
-----------------------------------------------------------------------------------
QLick here for the Back 2 the QL Blog http://backtotheql.blogspot.co.uk/
QLick here for the Back 2 the QL Blog http://backtotheql.blogspot.co.uk/
-
- RWAP Master
- Posts: 2848
- Joined: Sun Nov 28, 2010 4:51 pm
- Location: Stone, United Kingdom
- Contact:
Re: Not ROM but speed
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....
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....
Rich Mellor
RWAP Software
RWAP Adventures
SellMyRetro
Retro-Printer Module - add a USB printer to your QL
Also Involved in:
Icephorm
RWAP Software
RWAP Adventures
SellMyRetro
Retro-Printer Module - add a USB printer to your QL
Also Involved in:
Icephorm
Re: Not ROM but speed
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
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
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
Re: Not ROM but speed
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.
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
- Super Gold Card
- Posts: 592
- Joined: Sun Dec 11, 2011 1:16 am
- Location: Looking forward to summer in Somerset, UK...
Re: Not ROM but speed
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
Maybe we should talk about cycle timings instead.
But even here, there are problems, as the 68K processors allow variable memory cycle times...
Mark
Standby alert
“There are four lights!”
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb
Looking forward to summer in Somerset later in the year
QL, Falcon, Atari 520STFM, Atari 1040STE, more PC's than I care to count and an assortment of 8 bit micros (Sinclair and Acorn)(nearly forgot the Psion's)
“There are four lights!”
Step up to red alert. Sir, are you absolutely sure? It does mean changing the bulb
Looking forward to summer in Somerset later in the year
QL, Falcon, Atari 520STFM, Atari 1040STE, more PC's than I care to count and an assortment of 8 bit micros (Sinclair and Acorn)(nearly forgot the Psion's)
- Mr_Navigator
- QL Fanatic
- Posts: 782
- Joined: Mon Dec 13, 2010 11:17 pm
- Location: UK, Essex
- Contact:
Re: Not ROM but speed
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?
-----------------------------------------------------------------------------------
QLick here for the Back 2 the QL Blog http://backtotheql.blogspot.co.uk/
QLick here for the Back 2 the QL Blog http://backtotheql.blogspot.co.uk/
Re: Not ROM but speed
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).
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
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
"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
ʎɐqǝ ɯoɹɟ ǝq oʇ ƃuᴉoƃ ʇou sᴉ pɹɐoqʎǝʞ ʇxǝu ʎɯ 'ɹɐǝp ɥO
-
- Super Gold Card
- Posts: 725
- Joined: Mon Nov 24, 2014 2:03 pm
Re: Not ROM but speed
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.
QL Today printed a basic code timer and article of mine in 2007.
It should run on any QL system.
Steve.
Re: Not ROM but speed
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 ...Mr_Navigator wrote: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?
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!"
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
-
- Super Gold Card
- Posts: 725
- Joined: Mon Nov 24, 2014 2:03 pm
Re: Not ROM but speed
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.
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.