Re: [Ql-Users] TURBO and testing it exists

[Wolf via Ql-Users]

Hi,

If I understand the circumstances correctly, I would handle the chicken 
and egg problem differently.


The circumstances are that you're trying to develop a BOOT program, 
which loads a certain set of extensions. You want to avoid loading the 
extensions again if the BOOT program is run again in the same session. I 
stress that this is a BOOT program, i.e. at some time it is really the 
first program to be started.


I would then definitely use a small toolkit (several have been proposed 
here) which checks for the presence of specific keywords.


To get around the chicken and egg problem of finding out whether this 
toolkit is loaded, I'd do the following:


Check what version of machine/OS you're using, this enables you to get 
at the system variables, the address of which you put into a variable 
called sysvar_address. Then use this function:


def proc load_checking_toolkit (sysvars_address)
local a,is_loaded
  is_loaded=peek_l (sysvars_address + 372)
  if not is_loaded
 a=respr(xxx)
 lbytes ,a
 call a
 poke_l sysvars_address + 372,1
  endif
end def load_checking_toolkit


If you run this when the machine is just started up, the address at 
sysvars + 372 will be 0. This is true for SMSQE, QDOS ans Minerva.


Under SMSQE, this one of the rare unused addresses in the system 
variables, so if you poke 1 into there you know that your boot program 
has already run once.


Under QDOS/Minerva, this may eventually be filled up as and when 
channels are opened - but then you also know that you already ran the 
BOOt program.


HTH

Wolfgang
___
QL-Users Mailing List

Re: [Ql-Users] TURBO and testing it exists

[Dilwyn Jones via Ql-Users]

I agree, Derek, leaving TK_VER$ unaltered would be a better idea. Thus, 
there is less chance of any change upsetting existing programs, while new 
programs can use the new keyword.


Dilwyn

-Original Message- 
From: Derek via Ql-Users

Sent: Saturday, August 19, 2017 5:23 PM
To: ql-us...@q-v-d.com
Cc: Derek
Subject: Re: [Ql-Users] TURBO and testing it exists

Hi George,
I proposed in th QL Forum adding a S or Q in the TK_VER$.
But your proposed new Function sounds a good idea.
RegardsDerek
 Original message From: gdgqler--- via Ql-Users 
<ql-users@lists.q-v-d.com> Date: 19/08/2017  13:12  (GMT+00:00) To: 
ql-us...@q-v-d.com Cc: gdgq...@gmail.com Subject: Re: [Ql-Users] TURBO and 
testing it exists


On 19 Aug 2017, at 09:21, gdgqler--- via Ql-Users 
<ql-users@lists.q-v-d.com> wrote:


I would think it possible to have TK_VER$ print “TK”, “SMS” or “REM” after 
the version number. Is this what people would like?


It might be better to have a new keyword, TK_TYPE$, which would return “TK”, 
“SMS” or “REM”. This would leave TK_VER$ unaltered.


George
___
QL-Users Mailing List
___
QL-Users Mailing List

---
This email has been checked for viruses by AVG.
http://www.avg.com 


___
QL-Users Mailing List

Re: [Ql-Users] TURBO and testing it exists

[Derek via Ql-Users]

Hi George,
I proposed in th QL Forum adding a S or Q in the TK_VER$.
But your proposed new Function sounds a good idea.
RegardsDerek
 Original message From: gdgqler--- via Ql-Users 
<ql-users@lists.q-v-d.com> Date: 19/08/2017  13:12  (GMT+00:00) To: 
ql-us...@q-v-d.com Cc: gdgq...@gmail.com Subject: Re: [Ql-Users] TURBO and 
testing it exists 

> On 19 Aug 2017, at 09:21, gdgqler--- via Ql-Users <ql-users@lists.q-v-d.com> 
> wrote:
> 
> I would think it possible to have TK_VER$ print “TK”, “SMS” or “REM” after 
> the version number. Is this what people would like?

It might be better to have a new keyword, TK_TYPE$, which would return “TK”, 
“SMS” or “REM”. This would leave TK_VER$ unaltered.

George
___
QL-Users Mailing List
___
QL-Users Mailing List

Re: [Ql-Users] TURBO and testing it exists

[Derek via Ql-Users]

Hi,
The link works for me, even on an android tablet...


Regards,
Derek

 Original message 
From: Per Witte via Ql-Users <ql-users@lists.q-v-d.com> 
Date: 19/08/2017  13:13  (GMT+00:00) 
To: ql-us...@q-v-d.com 
Cc: Per Witte <pjwi...@online.no> 
Subject: Re: [Ql-Users] TURBO and testing it exists 

Hi Michael, I dont know why it doesnt work for you. I just clicked on the
link now and it works for me. Try copying the link and pasting it in your
browser. The article is about searching for specific keywords in
SuperBASIC, SBASIC and compiled BASIC without the use of an external
toolkit.
Per

PS Apologies if Im top-posting or bottom-posting or whatever one objects
to. Im not at home, with my normal email client, and am at the mercy of
whatever my browser-based email client thinks appropriate. (HELL is stupid
programs that THINK they are clever (or rather those who made them))

On 19 August 2017 at 12:17, Michael Bulford via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> On Thu, 17 Aug 2017 21:08:31, Per Witte <pjwi...@online.no> wrote:
>
> > Thats a nice solution. Not sufficient for all manner of keywords,
> though. A
> > more general solution for checking for relevant toolkits in boot
> programs,
> > without having to load a toolkit to do so can be found in this
> article:
> > http://www.hunggartorino.it/ql/findkey/ (also available in Italian!)
>
> Hi Per, I cannot get the above link to work.  It says not found.
>
>
>
> On Thu, 17 Aug 2017, 16:54:32, Duncan  <matras...@aol.com> wrote:
>
> Hi Lee, If booting from a Win drive  on the first instance of needing
> to load the Turbo toolkit check for the existence of a file on the boot
> device called "TTKLoaded", or similar. If the file does not exist create it
> and load TurboTK. If the file is found to exist do not load the
> toolkit. At the end of the session tidy up the boot device by deleting
> this file. Not elegant but practical.
>
>
> Hi Duncan,
>
> But what if during the session the QL crashes?  The TTKLoaded file will
> remain on the Win drive, and the next time the QL session is started, it
> won't work properly.  A nice idea though.  Another way of doing this is to
> use environment variables, which I use myself.  The details are here:
> http://www.dilwyn.me.uk/tk/env.zip
>
>
> Michael
> ___
> QL-Users Mailing List
>
>
>
___
QL-Users Mailing List
___
QL-Users Mailing List

Re: [Ql-Users] TURBO and testing it exists

[Per Witte via Ql-Users]

Hi Michael, I dont know why it doesnt work for you. I just clicked on the
link now and it works for me. Try copying the link and pasting it in your
browser. The article is about searching for specific keywords in
SuperBASIC, SBASIC and compiled BASIC without the use of an external
toolkit.
Per

PS Apologies if Im top-posting or bottom-posting or whatever one objects
to. Im not at home, with my normal email client, and am at the mercy of
whatever my browser-based email client thinks appropriate. (HELL is stupid
programs that THINK they are clever (or rather those who made them))

On 19 August 2017 at 12:17, Michael Bulford via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> On Thu, 17 Aug 2017 21:08:31, Per Witte  wrote:
>
> > Thats a nice solution. Not sufficient for all manner of keywords,
> though. A
> > more general solution for checking for relevant toolkits in boot
> programs,
> > without having to load a toolkit to do so can be found in this
> article:
> > http://www.hunggartorino.it/ql/findkey/ (also available in Italian!)
>
> Hi Per, I cannot get the above link to work.  It says not found.
>
>
>
> On Thu, 17 Aug 2017, 16:54:32, Duncan   wrote:
>
> Hi Lee, If booting from a Win drive  on the first instance of needing
> to load the Turbo toolkit check for the existence of a file on the boot
> device called "TTKLoaded", or similar. If the file does not exist create it
> and load TurboTK. If the file is found to exist do not load the
> toolkit. At the end of the session tidy up the boot device by deleting
> this file. Not elegant but practical.
>
>
> Hi Duncan,
>
> But what if during the session the QL crashes?  The TTKLoaded file will
> remain on the Win drive, and the next time the QL session is started, it
> won't work properly.  A nice idea though.  Another way of doing this is to
> use environment variables, which I use myself.  The details are here:
> http://www.dilwyn.me.uk/tk/env.zip
>
>
> Michael
> ___
> QL-Users Mailing List
>
>
>
___
QL-Users Mailing List

Re: [Ql-Users] TURBO and testing it exists

[gdgqler--- via Ql-Users]

> On 19 Aug 2017, at 09:21, gdgqler--- via Ql-Users  
> wrote:
> 
> I would think it possible to have TK_VER$ print “TK”, “SMS” or “REM” after 
> the version number. Is this what people would like?

It might be better to have a new keyword, TK_TYPE$, which would return “TK”, 
“SMS” or “REM”. This would leave TK_VER$ unaltered.

George
___
QL-Users Mailing List

Re: [Ql-Users] TURBO and testing it exists

[Per Witte via Ql-Users]

Your approach is commendable as an option for those who dont load a Turbo
toolkit by default, but for the rest of us it doesnt do much good.
Presumably, the REM version is based on the generic version which is
somewhat less optimal under SMSQ/E? And Turbo-compiled tasks will use the
incorporated keywords rather than those loaded into the machine at boot?
Thus the high-end user will end up with 7k of belt-and-braces bloat running
at less than optimal speed. I guess in the scheme of things its not going
to make much real difference, but I thought it was worth pointing out that
my comment was not just a thoughtless blurt.
Per

On 19 August 2017 at 09:13, George Gwilt via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

>
> > On 18 Aug 2017, at 17:38, Per Witte via Ql-Users <
> ql-users@lists.q-v-d.com> wrote:
> >
> > George, the question is relevant if you write programs intended for other
> > people: You cant be sure THEY will load Turbo. However, IMHO, any serious
> > Tinkerer should load Turbo as a matter of course.
>
> I would usually expect to compile any programs before releasing them to
> the general public. In that case TURBO_TK_REM would have been added.
>
> George
> ___
> QL-Users Mailing List
>
>
>
___
QL-Users Mailing List

Re: [Ql-Users] TURBO and testing it exists

[Michael Bulford via Ql-Users]

On Thu, 17 Aug 2017 21:08:31, Per Witte  wrote:

> Thats a nice solution. Not sufficient for all manner of keywords, though. 
A
> more general solution for checking for relevant toolkits in boot programs,
> without having to load a toolkit to do so can be found in this article:
> http://www.hunggartorino.it/ql/findkey/ (also available in Italian!)

Hi Per, I cannot get the above link to work.  It says not found.



On Thu, 17 Aug 2017, 16:54:32, Duncan   wrote:

Hi Lee, If booting from a Win drive  on the first instance of needing to 
load the Turbo toolkit check for the existence of a file on the boot device 
called "TTKLoaded", or similar. If the file does not exist create it and 
load TurboTK. If the file is found to exist do not load the toolkit. At the end 
of the session tidy up the boot device by deleting this file. Not elegant 
but practical.


Hi Duncan,

But what if during the session the QL crashes?  The TTKLoaded file will remain 
on the Win drive, and the next time the QL session is started, it won't work 
properly.  A nice idea though.  Another way of doing this is to use environment 
variables, which I use myself.  The details are here: 
http://www.dilwyn.me.uk/tk/env.zip


Michael
___
QL-Users Mailing List

Re: [Ql-Users] TURBO and testing it exists

[Dilwyn Jones via Ql-Users]

It makes sense to be able to identify which version of Turbo Toolkit is 
present. There would be two ways, one is to replace the period with a letter 
to identify which toolkit version, this maintains the length of the version 
string. However, some programs make explicit tests on the version string as 
though it was a number, so adding the version letter as a 5th digit is 
probably better.


Dilwyn

-Original Message- 
From: gdgqler--- via Ql-Users

Sent: Saturday, August 19, 2017 9:21 AM
To: ql-us...@q-v-d.com
Cc: gdgq...@gmail.com
Subject: Re: [Ql-Users] TURBO and testing it exists


On 17 Aug 2017, at 10:25, Tobias Fröschle via Ql-Users 
<ql-users@lists.q-v-d.com> wrote:


There is a keyword: TK_VER$, but only returns the version of Turbo 
Toolkit,

which is the same for the SMS and QDOS versions.


I would think it possible to have TK_VER$ print “TK”, “SMS” or “REM” after 
the version number. Is this what people would like?


George


___
QL-Users Mailing List

---
This email has been checked for viruses by AVG.
http://www.avg.com 


___
QL-Users Mailing List

Re: [Ql-Users] TURBO and testing it exists

[gdgqler--- via Ql-Users]

> On 17 Aug 2017, at 10:25, Tobias Fröschle via Ql-Users 
>  wrote:
> 
>> There is a keyword: TK_VER$, but only returns the version of Turbo Toolkit,
>> which is the same for the SMS and QDOS versions.

I would think it possible to have TK_VER$ print “TK”, “SMS” or “REM” after the 
version number. Is this what people would like?

George


___
QL-Users Mailing List

Re: [Ql-Users] TURBO and testing it exists

[George Gwilt via Ql-Users]

> On 18 Aug 2017, at 17:38, Per Witte via Ql-Users  
> wrote:
> 
> George, the question is relevant if you write programs intended for other
> people: You cant be sure THEY will load Turbo. However, IMHO, any serious
> Tinkerer should load Turbo as a matter of course.

I would usually expect to compile any programs before releasing them to the 
general public. In that case TURBO_TK_REM would have been added.

George
___
QL-Users Mailing List

Re: [Ql-Users] TURBO and testing it exists

[Ralf Reköndt via Ql-Users]

Simply load one of the thousand "is there that toolkit name" extensions 
like "ISIT" (Disassembler from DP) or similar and you are happy. Even 
Dilwyn has one on his site.


There is also a very old little toolkit from Steve Jones (Sidewinder), 
which can put every resident Procedure into an "F_xxx" Function 
extension to check, if it is available. I have to look.



Per Witte via Ql-Users:

George, the question is relevant if you write programs intended for other
people: You cant be sure THEY will load Turbo. However, IMHO, any serious
Tinkerer should load Turbo as a matter of course.

Per

On 18 August 2017 at 16:54, gdgqler--- via Ql-Users <
ql-users@lists.q-v-d.com> wrote:


On 17 Aug 2017, at 13:54, Lee Privett via Ql-Users <

ql-users@lists.q-v-d.com> wr


I feel there must be a way to test for TURBO toolkit, any ideas?

In my BOOT I load the TURBO toolkit. So why should I test for it?
If I don’t load it in my BOOT it just is not loaded.

George


___
QL-Users Mailing List

Re: [Ql-Users] TURBO and testing it exists

[Per Witte via Ql-Users]

George, the question is relevant if you write programs intended for other
people: You cant be sure THEY will load Turbo. However, IMHO, any serious
Tinkerer should load Turbo as a matter of course.

Per

On 18 August 2017 at 16:54, gdgqler--- via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

>
> > On 17 Aug 2017, at 13:54, Lee Privett via Ql-Users <
> ql-users@lists.q-v-d.com> wr
>
> > I feel there must be a way to test for TURBO toolkit, any ideas?
>
> In my BOOT I load the TURBO toolkit. So why should I test for it?
> If I don’t load it in my BOOT it just is not loaded.
>
> George
> ___
> QL-Users Mailing List
___
QL-Users Mailing List

Re: [Ql-Users] TURBO and testing it exists

[Ralf Reköndt via Ql-Users]

Ah, very clever ;-)))


gdgqler--- via Ql-Users:

On 17 Aug 2017, at 13:54, Lee Privett via Ql-Users  wr
I feel there must be a way to test for TURBO toolkit, any ideas?

In my BOOT I load the TURBO toolkit. So why should I test for it?
If I don’t load it in my BOOT it just is not loaded.

George

___
QL-Users Mailing List

Re: [Ql-Users] TURBO and testing it exists

[gdgqler--- via Ql-Users]

> On 17 Aug 2017, at 13:54, Lee Privett via Ql-Users  
> wr

> I feel there must be a way to test for TURBO toolkit, any ideas?

In my BOOT I load the TURBO toolkit. So why should I test for it?
If I don’t load it in my BOOT it just is not loaded.

George
___
QL-Users Mailing List

Re: [Ql-Users] TURBO and testing it exists

[matrassyl--- via Ql-Users]

Hi Lee, If booting from a Win drive  on the first instance of needing to load 
the Turbo toolkit check for the existence of a file on the boot device called 
"TTKLoaded", or similar. If the file does not exist create it and load TurboTK. 
If the file is found to exist do not load the toolkit. At the end of the 
session tidy up the boot device by deleting this file. Not elegant but 
practical.

Duncan

 

 

 

-Original Message-
From: Lee Privett via Ql-Users <ql-users@lists.q-v-d.com>
To: ql-users <ql-us...@q-v-d.com>
CC: Lee Privett <lee.priv...@gmail.com>
Sent: Thu, 17 Aug 2017 18:14
Subject: Re: [Ql-Users] TURBO and testing it exists

Perhaps I should clarify this a little further.Using Q-emuLator, my boot first 
loads SMSQ_QEM and restarts with the sameboot, I will always do this or use 
QPC2, I am not really looking for a BBQLsolution as it is development for other 
things.Where this[code]IF VER$<>"HBA" THEN   LRESPR "WIN8_SMSQ_QEM"END 
IF[/code]loads SMSQ and fails the second time around (as designed, so all good) 
asthe same boot loads again, I then load (still in the same boot) 
theTURBO_SMS_CODE appropriate for SMSQ based system.This is all fine, however, 
I am developing the boot for different setupsand change them a lot depending on 
what project I decide to work on.This means re-running the boot several times 
in the one session to testwhat I am trying to do and I don't want to keep using 
up space re-LRESPRthe TURBO toolkit.Using another toolkit to test for the 
existence of a keyword in the TURBOtoolkit would then mean using another method 
to test for that additionalToolkit, a catch 22.So I may try the WHEN_ERR method 
as soon as I find the documentation on it.LeeLeeOn Thu, Aug 17, 2017 at 10:49 
AM, Derek Stewart via Ql-Users <ql-users@lists.q-v-d.com> wrote:> Hi Tobias,>> 
The WHEN solution is great, but on some version of QODS, the WHEN ERRor> did 
not work.>> There are some people still using AH,JM, roms which may have 
problems with> WHEN ERRor>> --> Regards,>> Derek>>> On 17/08/17 10:39, Tobias 
Fröschle via Ql-Users wrote:>>> After I sent this, I realised a bit of 
explanation might be in order, as>> WHEN ERRor is not so well-known:>>>> When 
the interpreter passes a WHEN ERRor/END WHEN pair during normal>> program 
execution, it doesn't do anything with the commands inside the>> clause but 
remembering "I should do this in case an error occurs". So, line>> 1020 is not 
executed if no error occurs in line 1050. But in case there is>> an error (the 
interpreter choking on the MANIFEST statement it doesn't know>> when TT is not 
loaded), line 1020 is executed, telling us TT is not loaded.>>>> After 1020 was 
executed, the program is continued at the point /after/>> the error 
occurred.>>>> The empty WHEN ERRor clause (1060-1070) simply de-activates 
error>> processing back to "normal".>>>> Line 1080 will thus have the variable 
TurboTkLoaded to 1, if 1050 was>> executed without a problem, and set to 0 in 
case there was an error.>> Because we have made sure line 1050 is the only line 
that can be executed>> while error processing is active, we clearly know the 
only problem in 1050>> can only be "bad name". So it is important to pick a 
"test command" from>> the toolkit you are testing for that cannot choke on a 
different error than>> "bad name". MANIFEST is pretty ideal for this.>>>> 
Tobias>>>> Am 17.08.2017 um 11:25 schrieb Tobias Fröschle via Ql-Users <>>> 
ql-users@lists.q-v-d.com>:>>>>>> Lee,>>>>>> there are a number of toolkits that 
allow you to check for specific>>> other toolkit commands loaded or not - But 
this is a bit useless as it>>> leaves you with a chicken-and-egg problem: How 
to check whether the>>> checking toolkit is loaded?>>>>>> Your best bet on 
SMSQ/E would be a WHEN ERRor clause you place just in>>> front of a Toolkit 
command you are about to execute:>>>>>> 1000 TurboTkLoaded = 1>>> 1010 WHEN 
ERRor>>> 1020TurboTkLoaded = 0>>> 1030 END WHEN>>> 1040 REMark Execute a 
Toolkit command>>> 1050 MANIFEST : x = 100>>> 1055 REMark de-activate error 
checker>>> 1060 WHEN ERRor>>> 1070 END WHEN>>> 1080 PRINT "Turbo Toolkit 
loaded:"!TurboTkLoaded>>>>>> On a QL with non-working WHEN ERRor commands 
(pre-MG) you are a bit>>> doomed, the only thing I could probably come up with 
is writing a BASIC>>> program that PEEKs the name list, which is not quite so 
simple.>>>>>> Tob

Re: [Ql-Users] TURBO and testing it exists

[Per Witte via Ql-Users]

Thats a nice solution. Not sufficient for all manner of keywords, though. A
more general solution for checking for relevant toolkits in boot programs,
without having to load a toolkit to do so can be found in this article:
http://www.hunggartorino.it/ql/findkey/ (also available in Italian!)

Per

On 17 August 2017 at 13:54, Lee Privett via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> I have also been able to get this method to work with TURBO ptr extensions
> as well by using the following
>
> 220 IF ACR<>0 THEN
> 230  PRINT "Done":STOP
> 240 ELSE
> 250  LRESPR win2_tptr_ext
> 260 END IF
>
>
> Lee
>
> Lee
>
>
>
>
> On Thu, Aug 17, 2017 at 12:22 PM, Lee Privett 
> wrote:
>
> > Thanks for all the suggestions guys,
> >
> > 220 IF TK_VER$<>"" THEN
> > 230  PRINT "Done":STOP
> > 240 ELSE
> > 250  LRESPR win8_turbo_sms_code
> > 260 END IF
> >
> > this works exactly how I wanted it to, so  to Tobias.
> >
> > Many thanks to you all
> >
> > Lee
> >
> >
> >
> >
> >
> >
> >
> >
> > Lee
> >
> >
> >
> >
> > On Thu, Aug 17, 2017 at 11:47 AM, Tobias Fröschle via Ql-Users <
> > ql-users@lists.q-v-d.com> wrote:
> >
> >> Lee,
> >>
> >> in case your question is really only Turbo Toolkit specific, you can
> very
> >> well do away with a much simpler solution than WHEN ERRor clauses:
> >>
> >> 1000 IF TK_VER$ <> ""
> >> 1010   REM do whatever you want to do when Turbo Toolkit is loaded
> >> 1020 ELSE
> >> 1030  REM Do whatever you want to do if it is not loaded
> >> 1030 END IF
> >>
> >> This relies on the fact that the interpreter will interpret TK_VER$ as a
> >> FUNCTION returning a string in case the toolkit is loaded, and an unset
> >> string variable in case it is not. And unset string variables are by
> >> convention "empty".
> >>
> >> Tobias
> >>
> >>
> >> > Am 17.08.2017 um 12:37 schrieb Lee Privett via Ql-Users <
> >> ql-users@lists.q-v-d.com>:
> >> >
> >> > Perhaps I should clarify this a little further.
> >> >
> >> > Using Q-emuLator, my boot first loads SMSQ_QEM and restarts with the
> >> same
> >> > boot, I will always do this or use QPC2, I am not really looking for a
> >> BBQL
> >> > solution as it is development for other things.
> >> >
> >> > Where this
> >> >
> >> > [code]IF VER$<>"HBA" THEN
> >> >   LRESPR "WIN8_SMSQ_QEM"
> >> > END IF[/code]
> >> >
> >> > loads SMSQ and fails the second time around (as designed, so all good)
> >> as
> >> > the same boot loads again, I then load (still in the same boot) the
> >> > TURBO_SMS_CODE appropriate for SMSQ based system.
> >> >
> >> > This is all fine, however, I am developing the boot for different
> setups
> >> > and change them a lot depending on what project I decide to work on.
> >> >
> >> > This means re-running the boot several times in the one session to
> test
> >> > what I am trying to do and I don't want to keep using up space
> re-LRESPR
> >> > the TURBO toolkit.
> >> > Using another toolkit to test for the existence of a keyword in the
> >> TURBO
> >> > toolkit would then mean using another method to test for that
> additional
> >> > Toolkit, a catch 22.
> >> >
> >> > So I may try the WHEN_ERR method as soon as I find the documentation
> on
> >> it.
> >> >
> >> > Lee
> >> >
> >> >
> >> >
> >> >
> >> > Lee
> >> >
> >> >
> >> >
> >> >
> >> > On Thu, Aug 17, 2017 at 10:49 AM, Derek Stewart via Ql-Users <
> >> > ql-users@lists.q-v-d.com> wrote:
> >> >
> >> >> Hi Tobias,
> >> >>
> >> >> The WHEN solution is great, but on some version of QODS, the WHEN
> ERRor
> >> >> did not work.
> >> >>
> >> >> There are some people still using AH,JM, roms which may have problems
> >> with
> >> >> WHEN ERRor
> >> >>
> >> >> --
> >> >> Regards,
> >> >>
> >> >> Derek
> >> >>
> >> >>
> >> >> On 17/08/17 10:39, Tobias Fröschle via Ql-Users wrote:
> >> >>
> >> >>> After I sent this, I realised a bit of explanation might be in
> order,
> >> as
> >> >>> WHEN ERRor is not so well-known:
> >> >>>
> >> >>> When the interpreter passes a WHEN ERRor/END WHEN pair during normal
> >> >>> program execution, it doesn't do anything with the commands inside
> the
> >> >>> clause but remembering "I should do this in case an error occurs".
> >> So, line
> >> >>> 1020 is not executed if no error occurs in line 1050. But in case
> >> there is
> >> >>> an error (the interpreter choking on the MANIFEST statement it
> >> doesn't know
> >> >>> when TT is not loaded), line 1020 is executed, telling us TT is not
> >> loaded.
> >> >>>
> >> >>> After 1020 was executed, the program is continued at the point
> /after/
> >> >>> the error occurred.
> >> >>>
> >> >>> The empty WHEN ERRor clause (1060-1070) simply de-activates error
> >> >>> processing back to "normal".
> >> >>>
> >> >>> Line 1080 will thus have the variable TurboTkLoaded to 1, if 1050
> was
> >> >>> executed without a problem, and set to 0 in case there was an error.
> >> >>> Because we have made sure line 1050 is the only line that can be
> >> executed
> >> >>> while error processing is active, we clearly know the 

Re: [Ql-Users] TURBO and testing it exists

[François Van Emelen via Ql-Users]

Op 17/08/2017 om 12:40 schreef Dilwyn Jones via Ql-Users:
In that sense, the easiest way is to load the smallest keyword 
checking extension and just accept the chicken and egg scenario and 
that there is a risk that you may multiply-load that one small extension.


One such extension is Phil Borman's EXISTS (on Toolkits page on my 
site). Be aware that if it is to be used on more than your own system 
on pre-JS ROMs you can't use the extension in the same BASIC boot 
program that loads it, so you'd have to use the first BOOT program to 
install the EXISTS extension, then LRUN a second boot program to 
actually use it on version AH or JM ROMs.


Another way of doing this which may be good enough for most purposes 
is to assume that all your systems contain Toolkit 2 or a subset of, 
which contains the EXTRAS keyword (most will apart from 128k MDV-only 
systems). This method was suggested to me a long time ago by John 
Gilpin - send a list of EXTRAS to a file somewhere and read that file 
back to check for a keyword. A bit fiddly and prone to go wrong when 
you have toolkits with duplicate keyword names I suppose. Then you 
could write a little function like this (not tested, just quickly 
wrote it as I type):


DEF FN CHECK_FOR(keyword$)
 LOCAL found%,t$
 found% = 0 : REM assume not found
 OPEN_NEW #3,ram1_test : REM choose your own filename
 EXTRAS #3 : CLOSE #3
 OPEN_IN #3,ram1_test
 REPeat read_back
   IF EOF(#3) : EXIT read_back
   INPUT #3,t$
   IF t$ == keyword$ THEN
 found% = 1 EXIT read_back : REM keyword name matched
   END IF
 END REPeat read_back
 CLOSE #3 : DELETE ram1_test : REM remove the evidence
 RETurn found%
END DEF CHECK_FOR

Then if this function is appended to your boot program, use a line 
like IF CHECK_FOR("TK_VER$") = 1 THEN PRINT"Turbo Toolkit loaded" (or 
a known keyword from another toolkit of course)


Not the full answer you were hoping for but one which can cope with 
most situations apart from unexpanded BBQL.


Dilwyn

-Original Message- From: Tobias Fröschlevia Ql-Users
Sent: Thursday, August 17, 2017 10:25 AM
To: ql-us...@q-v-d.com
Cc: Tobias Fröschle
Subject: Re: [Ql-Users] TURBO and testing it exists

Lee,

there are a number of toolkits that allow you to check for specific 
other toolkit commands loaded or not - But this is a bit useless as it 
leaves you with a chicken-and-egg problem: How to check whether the 
checking toolkit is loaded?


Your best bet on SMSQ/E would be a WHEN ERRor clause you place just in 
front of a Toolkit command you are about to execute:


1000 TurboTkLoaded = 1
1010 WHEN ERRor
1020    TurboTkLoaded = 0
1030 END WHEN
1040 REMark Execute a Toolkit command
1050 MANIFEST : x = 100
1055 REMark de-activate error checker
1060 WHEN ERRor
1070 END WHEN
1080 PRINT "Turbo Toolkit loaded:"!TurboTkLoaded

On a QL with non-working WHEN ERRor commands (pre-MG) you are a bit 
doomed, the only thing I could probably come up with is writing a 
BASIC program that PEEKs the name list, which is not quite so simple.


Tobias


Am 17.08.2017 um 10:49 schrieb Lee Privett via Ql-Users 
<ql-users@lists.q-v-d.com>:


I originally posted this on the forum:

Hi community, I have searched for this on the forum but cannot find an
entry but I am sure this has been asked before.

I currently test for the presence of the HBA ROM in a boot program using
VER$ and would like to test for other toolkits, specifically the TURBO
toolkit. Is there a way to do this automatically in a boot so that when
subsequent runs of the boot it is not loaded again in one session?

e.g. for the HBA version I use:

Code: Select all <http://qlforum.co.uk/viewtopic.php?f=3=2063#>
IF VER$<>"HBA" THEN
  LRESPR "WIN8_SMSQ_QEM"
END IF


I feel there must be a way to test for TURBO toolkit, any ideas?

A reply from Derek suggested  the following:

There is a keyword: TK_VER$, but only returns the version of Turbo 
Toolkit,

which is the same for the SMS and QDOS versions.

A simple way would be to add "SMS" in the version number. Which would 
mean

a new version of Turbo Toolkit.

The SMS version calls the SMSQ/E extended traps, where the QDOS does 
not,

so maybe a test for SMSQ/E extended traps is the way, but I would favour
the about alteration to TK_VER$.

George Gwilt used to maintain Turbo and maybe the Toolkit. I think this
message needs to be posted in the QL-USERS mailing list, George Gwilt 
reads

that list.

Any views at all?

Regards Lee Privett
___
QL-Users Mailing List


___
QL-Users Mailing List

---
This email has been checked for viruses by AVG.
http://www.avg.com
___
QL-Users Mailing List


Dilwyn's CHECK_FOR(keyword$) is of course only reliable as interpreted 
AND in job 0.


François Van Emelen


___
QL-Users Mailing List

Re: [Ql-Users] TURBO and testing it exists

[Lee Privett via Ql-Users]

Thanks for all the suggestions guys,

220 IF TK_VER$<>"" THEN
230  PRINT "Done":STOP
240 ELSE
250  LRESPR win8_turbo_sms_code
260 END IF

this works exactly how I wanted it to, so  to Tobias.

Many thanks to you all

Lee








Lee




On Thu, Aug 17, 2017 at 11:47 AM, Tobias Fröschle via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Lee,
>
> in case your question is really only Turbo Toolkit specific, you can very
> well do away with a much simpler solution than WHEN ERRor clauses:
>
> 1000 IF TK_VER$ <> ""
> 1010   REM do whatever you want to do when Turbo Toolkit is loaded
> 1020 ELSE
> 1030  REM Do whatever you want to do if it is not loaded
> 1030 END IF
>
> This relies on the fact that the interpreter will interpret TK_VER$ as a
> FUNCTION returning a string in case the toolkit is loaded, and an unset
> string variable in case it is not. And unset string variables are by
> convention "empty".
>
> Tobias
>
>
> > Am 17.08.2017 um 12:37 schrieb Lee Privett via Ql-Users <
> ql-users@lists.q-v-d.com>:
> >
> > Perhaps I should clarify this a little further.
> >
> > Using Q-emuLator, my boot first loads SMSQ_QEM and restarts with the same
> > boot, I will always do this or use QPC2, I am not really looking for a
> BBQL
> > solution as it is development for other things.
> >
> > Where this
> >
> > [code]IF VER$<>"HBA" THEN
> >   LRESPR "WIN8_SMSQ_QEM"
> > END IF[/code]
> >
> > loads SMSQ and fails the second time around (as designed, so all good) as
> > the same boot loads again, I then load (still in the same boot) the
> > TURBO_SMS_CODE appropriate for SMSQ based system.
> >
> > This is all fine, however, I am developing the boot for different setups
> > and change them a lot depending on what project I decide to work on.
> >
> > This means re-running the boot several times in the one session to test
> > what I am trying to do and I don't want to keep using up space re-LRESPR
> > the TURBO toolkit.
> > Using another toolkit to test for the existence of a keyword in the TURBO
> > toolkit would then mean using another method to test for that additional
> > Toolkit, a catch 22.
> >
> > So I may try the WHEN_ERR method as soon as I find the documentation on
> it.
> >
> > Lee
> >
> >
> >
> >
> > Lee
> >
> >
> >
> >
> > On Thu, Aug 17, 2017 at 10:49 AM, Derek Stewart via Ql-Users <
> > ql-users@lists.q-v-d.com> wrote:
> >
> >> Hi Tobias,
> >>
> >> The WHEN solution is great, but on some version of QODS, the WHEN ERRor
> >> did not work.
> >>
> >> There are some people still using AH,JM, roms which may have problems
> with
> >> WHEN ERRor
> >>
> >> --
> >> Regards,
> >>
> >> Derek
> >>
> >>
> >> On 17/08/17 10:39, Tobias Fröschle via Ql-Users wrote:
> >>
> >>> After I sent this, I realised a bit of explanation might be in order,
> as
> >>> WHEN ERRor is not so well-known:
> >>>
> >>> When the interpreter passes a WHEN ERRor/END WHEN pair during normal
> >>> program execution, it doesn't do anything with the commands inside the
> >>> clause but remembering "I should do this in case an error occurs". So,
> line
> >>> 1020 is not executed if no error occurs in line 1050. But in case
> there is
> >>> an error (the interpreter choking on the MANIFEST statement it doesn't
> know
> >>> when TT is not loaded), line 1020 is executed, telling us TT is not
> loaded.
> >>>
> >>> After 1020 was executed, the program is continued at the point /after/
> >>> the error occurred.
> >>>
> >>> The empty WHEN ERRor clause (1060-1070) simply de-activates error
> >>> processing back to "normal".
> >>>
> >>> Line 1080 will thus have the variable TurboTkLoaded to 1, if 1050 was
> >>> executed without a problem, and set to 0 in case there was an error.
> >>> Because we have made sure line 1050 is the only line that can be
> executed
> >>> while error processing is active, we clearly know the only problem in
> 1050
> >>> can only be "bad name". So it is important to pick a "test command"
> from
> >>> the toolkit you are testing for that cannot choke on a different error
> than
> >>> "bad name". MANIFEST is pretty ideal for this.
> >>>
> >>> Tobias
> >>>
> >>> Am 17.08.2017 um 11:25 schrieb Tobias Fröschle via Ql-Users <
>  ql-users@lists.q-v-d.com>:
> 
>  Lee,
> 
>  there are a number of toolkits that allow you to check for specific
>  other toolkit commands loaded or not - But this is a bit useless as it
>  leaves you with a chicken-and-egg problem: How to check whether the
>  checking toolkit is loaded?
> 
>  Your best bet on SMSQ/E would be a WHEN ERRor clause you place just in
>  front of a Toolkit command you are about to execute:
> 
>  1000 TurboTkLoaded = 1
>  1010 WHEN ERRor
>  1020TurboTkLoaded = 0
>  1030 END WHEN
>  1040 REMark Execute a Toolkit command
>  1050 MANIFEST : x = 100
>  1055 REMark de-activate error checker
>  1060 WHEN ERRor
>  1070 END WHEN
>  1080 PRINT "Turbo Toolkit loaded:"!TurboTkLoaded
> 
>  On a QL with 

Re: [Ql-Users] TURBO and testing it exists

[Tobias Fröschle via Ql-Users]

Lee,

in case your question is really only Turbo Toolkit specific, you can very well 
do away with a much simpler solution than WHEN ERRor clauses:

1000 IF TK_VER$ <> "" 
1010   REM do whatever you want to do when Turbo Toolkit is loaded
1020 ELSE
1030  REM Do whatever you want to do if it is not loaded
1030 END IF

This relies on the fact that the interpreter will interpret TK_VER$ as a 
FUNCTION returning a string in case the toolkit is loaded, and an unset string 
variable in case it is not. And unset string variables are by convention 
"empty".

Tobias


> Am 17.08.2017 um 12:37 schrieb Lee Privett via Ql-Users 
> :
> 
> Perhaps I should clarify this a little further.
> 
> Using Q-emuLator, my boot first loads SMSQ_QEM and restarts with the same
> boot, I will always do this or use QPC2, I am not really looking for a BBQL
> solution as it is development for other things.
> 
> Where this
> 
> [code]IF VER$<>"HBA" THEN
>   LRESPR "WIN8_SMSQ_QEM"
> END IF[/code]
> 
> loads SMSQ and fails the second time around (as designed, so all good) as
> the same boot loads again, I then load (still in the same boot) the
> TURBO_SMS_CODE appropriate for SMSQ based system.
> 
> This is all fine, however, I am developing the boot for different setups
> and change them a lot depending on what project I decide to work on.
> 
> This means re-running the boot several times in the one session to test
> what I am trying to do and I don't want to keep using up space re-LRESPR
> the TURBO toolkit.
> Using another toolkit to test for the existence of a keyword in the TURBO
> toolkit would then mean using another method to test for that additional
> Toolkit, a catch 22.
> 
> So I may try the WHEN_ERR method as soon as I find the documentation on it.
> 
> Lee
> 
> 
> 
> 
> Lee
> 
> 
> 
> 
> On Thu, Aug 17, 2017 at 10:49 AM, Derek Stewart via Ql-Users <
> ql-users@lists.q-v-d.com> wrote:
> 
>> Hi Tobias,
>> 
>> The WHEN solution is great, but on some version of QODS, the WHEN ERRor
>> did not work.
>> 
>> There are some people still using AH,JM, roms which may have problems with
>> WHEN ERRor
>> 
>> --
>> Regards,
>> 
>> Derek
>> 
>> 
>> On 17/08/17 10:39, Tobias Fröschle via Ql-Users wrote:
>> 
>>> After I sent this, I realised a bit of explanation might be in order, as
>>> WHEN ERRor is not so well-known:
>>> 
>>> When the interpreter passes a WHEN ERRor/END WHEN pair during normal
>>> program execution, it doesn't do anything with the commands inside the
>>> clause but remembering "I should do this in case an error occurs". So, line
>>> 1020 is not executed if no error occurs in line 1050. But in case there is
>>> an error (the interpreter choking on the MANIFEST statement it doesn't know
>>> when TT is not loaded), line 1020 is executed, telling us TT is not loaded.
>>> 
>>> After 1020 was executed, the program is continued at the point /after/
>>> the error occurred.
>>> 
>>> The empty WHEN ERRor clause (1060-1070) simply de-activates error
>>> processing back to "normal".
>>> 
>>> Line 1080 will thus have the variable TurboTkLoaded to 1, if 1050 was
>>> executed without a problem, and set to 0 in case there was an error.
>>> Because we have made sure line 1050 is the only line that can be executed
>>> while error processing is active, we clearly know the only problem in 1050
>>> can only be "bad name". So it is important to pick a "test command" from
>>> the toolkit you are testing for that cannot choke on a different error than
>>> "bad name". MANIFEST is pretty ideal for this.
>>> 
>>> Tobias
>>> 
>>> Am 17.08.2017 um 11:25 schrieb Tobias Fröschle via Ql-Users <
 ql-users@lists.q-v-d.com>:
 
 Lee,
 
 there are a number of toolkits that allow you to check for specific
 other toolkit commands loaded or not - But this is a bit useless as it
 leaves you with a chicken-and-egg problem: How to check whether the
 checking toolkit is loaded?
 
 Your best bet on SMSQ/E would be a WHEN ERRor clause you place just in
 front of a Toolkit command you are about to execute:
 
 1000 TurboTkLoaded = 1
 1010 WHEN ERRor
 1020TurboTkLoaded = 0
 1030 END WHEN
 1040 REMark Execute a Toolkit command
 1050 MANIFEST : x = 100
 1055 REMark de-activate error checker
 1060 WHEN ERRor
 1070 END WHEN
 1080 PRINT "Turbo Toolkit loaded:"!TurboTkLoaded
 
 On a QL with non-working WHEN ERRor commands (pre-MG) you are a bit
 doomed, the only thing I could probably come up with is writing a BASIC
 program that PEEKs the name list, which is not quite so simple.
 
 Tobias
 
 
 Am 17.08.2017 um 10:49 schrieb Lee Privett via Ql-Users <
> ql-users@lists.q-v-d.com>:
> 
> I originally posted this on the forum:
> 
> Hi community, I have searched for this on the forum but cannot find an
> entry but I am sure this has been asked before.
> 
> I currently test for the presence of the 

Re: [Ql-Users] TURBO and testing it exists

[Dilwyn Jones via Ql-Users]

In that sense, the easiest way is to load the smallest keyword checking 
extension and just accept the chicken and egg scenario and that there is a 
risk that you may multiply-load that one small extension.


One such extension is Phil Borman's EXISTS (on Toolkits page on my site). Be 
aware that if it is to be used on more than your own system on pre-JS ROMs 
you can't use the extension in the same BASIC boot program that loads it, so 
you'd have to use the first BOOT program to install the EXISTS extension, 
then LRUN a second boot program to actually use it on version AH or JM ROMs.


Another way of doing this which may be good enough for most purposes is to 
assume that all your systems contain Toolkit 2 or a subset of, which 
contains the EXTRAS keyword (most will apart from 128k MDV-only systems). 
This method was suggested to me a long time ago by John Gilpin - send a list 
of EXTRAS to a file somewhere and read that file back to check for a 
keyword. A bit fiddly and prone to go wrong when you have toolkits with 
duplicate keyword names I suppose. Then you could write a little function 
like this (not tested, just quickly wrote it as I type):


DEF FN CHECK_FOR(keyword$)
 LOCAL found%,t$
 found% = 0 : REM assume not found
 OPEN_NEW #3,ram1_test : REM choose your own filename
 EXTRAS #3 : CLOSE #3
 OPEN_IN #3,ram1_test
 REPeat read_back
   IF EOF(#3) : EXIT read_back
   INPUT #3,t$
   IF t$ == keyword$ THEN
 found% = 1 EXIT read_back : REM keyword name matched
   END IF
 END REPeat read_back
 CLOSE #3 : DELETE ram1_test : REM remove the evidence
 RETurn found%
END DEF CHECK_FOR

Then if this function is appended to your boot program, use a line like IF 
CHECK_FOR("TK_VER$") = 1 THEN PRINT"Turbo Toolkit loaded" (or a known 
keyword from another toolkit of course)


Not the full answer you were hoping for but one which can cope with most 
situations apart from unexpanded BBQL.


Dilwyn

-Original Message- 
From: Tobias Fröschlevia Ql-Users

Sent: Thursday, August 17, 2017 10:25 AM
To: ql-us...@q-v-d.com
Cc: Tobias Fröschle
Subject: Re: [Ql-Users] TURBO and testing it exists

Lee,

there are a number of toolkits that allow you to check for specific other 
toolkit commands loaded or not - But this is a bit useless as it leaves you 
with a chicken-and-egg problem: How to check whether the checking toolkit is 
loaded?


Your best bet on SMSQ/E would be a WHEN ERRor clause you place just in front 
of a Toolkit command you are about to execute:


1000 TurboTkLoaded = 1
1010 WHEN ERRor
1020TurboTkLoaded = 0
1030 END WHEN
1040 REMark Execute a Toolkit command
1050 MANIFEST : x = 100
1055 REMark de-activate error checker
1060 WHEN ERRor
1070 END WHEN
1080 PRINT "Turbo Toolkit loaded:"!TurboTkLoaded

On a QL with non-working WHEN ERRor commands (pre-MG) you are a bit doomed, 
the only thing I could probably come up with is writing a BASIC program that 
PEEKs the name list, which is not quite so simple.


Tobias


Am 17.08.2017 um 10:49 schrieb Lee Privett via Ql-Users 
<ql-users@lists.q-v-d.com>:


I originally posted this on the forum:

Hi community, I have searched for this on the forum but cannot find an
entry but I am sure this has been asked before.

I currently test for the presence of the HBA ROM in a boot program using
VER$ and would like to test for other toolkits, specifically the TURBO
toolkit. Is there a way to do this automatically in a boot so that when
subsequent runs of the boot it is not loaded again in one session?

e.g. for the HBA version I use:

Code: Select all <http://qlforum.co.uk/viewtopic.php?f=3=2063#>
IF VER$<>"HBA" THEN
  LRESPR "WIN8_SMSQ_QEM"
END IF


I feel there must be a way to test for TURBO toolkit, any ideas?

A reply from Derek suggested  the following:

There is a keyword: TK_VER$, but only returns the version of Turbo 
Toolkit,

which is the same for the SMS and QDOS versions.

A simple way would be to add "SMS" in the version number. Which would mean
a new version of Turbo Toolkit.

The SMS version calls the SMSQ/E extended traps, where the QDOS does not,
so maybe a test for SMSQ/E extended traps is the way, but I would favour
the about alteration to TK_VER$.

George Gwilt used to maintain Turbo and maybe the Toolkit. I think this
message needs to be posted in the QL-USERS mailing list, George Gwilt 
reads

that list.

Any views at all?

Regards Lee Privett
___
QL-Users Mailing List


___
QL-Users Mailing List

---
This email has been checked for viruses by AVG.
http://www.avg.com 


___
QL-Users Mailing List

Re: [Ql-Users] TURBO and testing it exists

[Lee Privett via Ql-Users]

Perhaps I should clarify this a little further.

Using Q-emuLator, my boot first loads SMSQ_QEM and restarts with the same
boot, I will always do this or use QPC2, I am not really looking for a BBQL
solution as it is development for other things.

Where this

[code]IF VER$<>"HBA" THEN
   LRESPR "WIN8_SMSQ_QEM"
END IF[/code]

loads SMSQ and fails the second time around (as designed, so all good) as
the same boot loads again, I then load (still in the same boot) the
TURBO_SMS_CODE appropriate for SMSQ based system.

This is all fine, however, I am developing the boot for different setups
and change them a lot depending on what project I decide to work on.

This means re-running the boot several times in the one session to test
what I am trying to do and I don't want to keep using up space re-LRESPR
the TURBO toolkit.
Using another toolkit to test for the existence of a keyword in the TURBO
toolkit would then mean using another method to test for that additional
Toolkit, a catch 22.

So I may try the WHEN_ERR method as soon as I find the documentation on it.

Lee




Lee




On Thu, Aug 17, 2017 at 10:49 AM, Derek Stewart via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Hi Tobias,
>
> The WHEN solution is great, but on some version of QODS, the WHEN ERRor
> did not work.
>
> There are some people still using AH,JM, roms which may have problems with
> WHEN ERRor
>
> --
> Regards,
>
> Derek
>
>
> On 17/08/17 10:39, Tobias Fröschle via Ql-Users wrote:
>
>> After I sent this, I realised a bit of explanation might be in order, as
>> WHEN ERRor is not so well-known:
>>
>> When the interpreter passes a WHEN ERRor/END WHEN pair during normal
>> program execution, it doesn't do anything with the commands inside the
>> clause but remembering "I should do this in case an error occurs". So, line
>> 1020 is not executed if no error occurs in line 1050. But in case there is
>> an error (the interpreter choking on the MANIFEST statement it doesn't know
>> when TT is not loaded), line 1020 is executed, telling us TT is not loaded.
>>
>> After 1020 was executed, the program is continued at the point /after/
>> the error occurred.
>>
>> The empty WHEN ERRor clause (1060-1070) simply de-activates error
>> processing back to "normal".
>>
>> Line 1080 will thus have the variable TurboTkLoaded to 1, if 1050 was
>> executed without a problem, and set to 0 in case there was an error.
>> Because we have made sure line 1050 is the only line that can be executed
>> while error processing is active, we clearly know the only problem in 1050
>> can only be "bad name". So it is important to pick a "test command" from
>> the toolkit you are testing for that cannot choke on a different error than
>> "bad name". MANIFEST is pretty ideal for this.
>>
>> Tobias
>>
>> Am 17.08.2017 um 11:25 schrieb Tobias Fröschle via Ql-Users <
>>> ql-users@lists.q-v-d.com>:
>>>
>>> Lee,
>>>
>>> there are a number of toolkits that allow you to check for specific
>>> other toolkit commands loaded or not - But this is a bit useless as it
>>> leaves you with a chicken-and-egg problem: How to check whether the
>>> checking toolkit is loaded?
>>>
>>> Your best bet on SMSQ/E would be a WHEN ERRor clause you place just in
>>> front of a Toolkit command you are about to execute:
>>>
>>> 1000 TurboTkLoaded = 1
>>> 1010 WHEN ERRor
>>> 1020TurboTkLoaded = 0
>>> 1030 END WHEN
>>> 1040 REMark Execute a Toolkit command
>>> 1050 MANIFEST : x = 100
>>> 1055 REMark de-activate error checker
>>> 1060 WHEN ERRor
>>> 1070 END WHEN
>>> 1080 PRINT "Turbo Toolkit loaded:"!TurboTkLoaded
>>>
>>> On a QL with non-working WHEN ERRor commands (pre-MG) you are a bit
>>> doomed, the only thing I could probably come up with is writing a BASIC
>>> program that PEEKs the name list, which is not quite so simple.
>>>
>>> Tobias
>>>
>>>
>>> Am 17.08.2017 um 10:49 schrieb Lee Privett via Ql-Users <
 ql-users@lists.q-v-d.com>:

 I originally posted this on the forum:

 Hi community, I have searched for this on the forum but cannot find an
 entry but I am sure this has been asked before.

 I currently test for the presence of the HBA ROM in a boot program using
 VER$ and would like to test for other toolkits, specifically the TURBO
 toolkit. Is there a way to do this automatically in a boot so that when
 subsequent runs of the boot it is not loaded again in one session?

 e.g. for the HBA version I use:

 Code: Select all 
 IF VER$<>"HBA" THEN
   LRESPR "WIN8_SMSQ_QEM"
 END IF


 I feel there must be a way to test for TURBO toolkit, any ideas?

 A reply from Derek suggested  the following:

 There is a keyword: TK_VER$, but only returns the version of Turbo
 Toolkit,
 which is the same for the SMS and QDOS versions.

 A simple way would be to add "SMS" in the version number. Which would
 mean
 a new version of Turbo Toolkit.

Re: [Ql-Users] TURBO and testing it exists

[Derek Stewart via Ql-Users]

Hi Tobias,

The WHEN solution is great, but on some version of QODS, the WHEN ERRor 
did not work.


There are some people still using AH,JM, roms which may have problems 
with WHEN ERRor


--
Regards,

Derek

On 17/08/17 10:39, Tobias Fröschle via Ql-Users wrote:

After I sent this, I realised a bit of explanation might be in order, as WHEN 
ERRor is not so well-known:

When the interpreter passes a WHEN ERRor/END WHEN pair during normal program execution, 
it doesn't do anything with the commands inside the clause but remembering "I should 
do this in case an error occurs". So, line 1020 is not executed if no error occurs 
in line 1050. But in case there is an error (the interpreter choking on the MANIFEST 
statement it doesn't know when TT is not loaded), line 1020 is executed, telling us TT is 
not loaded.

After 1020 was executed, the program is continued at the point /after/ the 
error occurred.

The empty WHEN ERRor clause (1060-1070) simply de-activates error processing back to 
"normal".

Line 1080 will thus have the variable TurboTkLoaded to 1, if 1050 was executed without a problem, and set to 
0 in case there was an error. Because we have made sure line 1050 is the only line that can be executed while 
error processing is active, we clearly know the only problem in 1050 can only be "bad name". So it 
is important to pick a "test command" from the toolkit you are testing for that cannot choke on a 
different error than "bad name". MANIFEST is pretty ideal for this.

Tobias


Am 17.08.2017 um 11:25 schrieb Tobias Fröschle via Ql-Users 
:

Lee,

there are a number of toolkits that allow you to check for specific other 
toolkit commands loaded or not - But this is a bit useless as it leaves you 
with a chicken-and-egg problem: How to check whether the checking toolkit is 
loaded?

Your best bet on SMSQ/E would be a WHEN ERRor clause you place just in front of 
a Toolkit command you are about to execute:

1000 TurboTkLoaded = 1
1010 WHEN ERRor
1020TurboTkLoaded = 0
1030 END WHEN
1040 REMark Execute a Toolkit command
1050 MANIFEST : x = 100
1055 REMark de-activate error checker
1060 WHEN ERRor
1070 END WHEN
1080 PRINT "Turbo Toolkit loaded:"!TurboTkLoaded

On a QL with non-working WHEN ERRor commands (pre-MG) you are a bit doomed, the 
only thing I could probably come up with is writing a BASIC program that PEEKs 
the name list, which is not quite so simple.

Tobias



Am 17.08.2017 um 10:49 schrieb Lee Privett via Ql-Users 
:

I originally posted this on the forum:

Hi community, I have searched for this on the forum but cannot find an
entry but I am sure this has been asked before.

I currently test for the presence of the HBA ROM in a boot program using
VER$ and would like to test for other toolkits, specifically the TURBO
toolkit. Is there a way to do this automatically in a boot so that when
subsequent runs of the boot it is not loaded again in one session?

e.g. for the HBA version I use:

Code: Select all 
IF VER$<>"HBA" THEN
  LRESPR "WIN8_SMSQ_QEM"
END IF


I feel there must be a way to test for TURBO toolkit, any ideas?

A reply from Derek suggested  the following:

There is a keyword: TK_VER$, but only returns the version of Turbo Toolkit,
which is the same for the SMS and QDOS versions.

A simple way would be to add "SMS" in the version number. Which would mean
a new version of Turbo Toolkit.

The SMS version calls the SMSQ/E extended traps, where the QDOS does not,
so maybe a test for SMSQ/E extended traps is the way, but I would favour
the about alteration to TK_VER$.

George Gwilt used to maintain Turbo and maybe the Toolkit. I think this
message needs to be posted in the QL-USERS mailing list, George Gwilt reads
that list.

Any views at all?

Regards Lee Privett
___
QL-Users Mailing List


___
QL-Users Mailing List


___
QL-Users Mailing List


___
QL-Users Mailing List

Re: [Ql-Users] TURBO and testing it exists

[Derek Stewart via Ql-Users]

Hi,

Would it be possible to add in a code letter in TK_VER$ for each version 
of Turbo Toolkit, i.e.


TK_VER$ for SMS, 3.40s

--
Regards,

Derek

On 17/08/17 10:25, Tobias Fröschle via Ql-Users wrote:

Lee,

there are a number of toolkits that allow you to check for specific other 
toolkit commands loaded or not - But this is a bit useless as it leaves you 
with a chicken-and-egg problem: How to check whether the checking toolkit is 
loaded?

Your best bet on SMSQ/E would be a WHEN ERRor clause you place just in front of 
a Toolkit command you are about to execute:

1000 TurboTkLoaded = 1
1010 WHEN ERRor
1020TurboTkLoaded = 0
1030 END WHEN
1040 REMark Execute a Toolkit command
1050 MANIFEST : x = 100
1055 REMark de-activate error checker
1060 WHEN ERRor
1070 END WHEN
1080 PRINT "Turbo Toolkit loaded:"!TurboTkLoaded

On a QL with non-working WHEN ERRor commands (pre-MG) you are a bit doomed, the 
only thing I could probably come up with is writing a BASIC program that PEEKs 
the name list, which is not quite so simple.

Tobias



Am 17.08.2017 um 10:49 schrieb Lee Privett via Ql-Users 
:

I originally posted this on the forum:

Hi community, I have searched for this on the forum but cannot find an
entry but I am sure this has been asked before.

I currently test for the presence of the HBA ROM in a boot program using
VER$ and would like to test for other toolkits, specifically the TURBO
toolkit. Is there a way to do this automatically in a boot so that when
subsequent runs of the boot it is not loaded again in one session?

e.g. for the HBA version I use:

Code: Select all 
IF VER$<>"HBA" THEN
   LRESPR "WIN8_SMSQ_QEM"
END IF


I feel there must be a way to test for TURBO toolkit, any ideas?

A reply from Derek suggested  the following:

There is a keyword: TK_VER$, but only returns the version of Turbo Toolkit,
which is the same for the SMS and QDOS versions.

A simple way would be to add "SMS" in the version number. Which would mean
a new version of Turbo Toolkit.

The SMS version calls the SMSQ/E extended traps, where the QDOS does not,
so maybe a test for SMSQ/E extended traps is the way, but I would favour
the about alteration to TK_VER$.

George Gwilt used to maintain Turbo and maybe the Toolkit. I think this
message needs to be posted in the QL-USERS mailing list, George Gwilt reads
that list.

Any views at all?

Regards Lee Privett
___
QL-Users Mailing List


___
QL-Users Mailing List


___
QL-Users Mailing List

Re: [Ql-Users] TURBO and testing it exists

[Tobias Fröschle via Ql-Users]

After I sent this, I realised a bit of explanation might be in order, as WHEN 
ERRor is not so well-known:

When the interpreter passes a WHEN ERRor/END WHEN pair during normal program 
execution, it doesn't do anything with the commands inside the clause but 
remembering "I should do this in case an error occurs". So, line 1020 is not 
executed if no error occurs in line 1050. But in case there is an error (the 
interpreter choking on the MANIFEST statement it doesn't know when TT is not 
loaded), line 1020 is executed, telling us TT is not loaded.

After 1020 was executed, the program is continued at the point /after/ the 
error occurred.

The empty WHEN ERRor clause (1060-1070) simply de-activates error processing 
back to "normal".

Line 1080 will thus have the variable TurboTkLoaded to 1, if 1050 was executed 
without a problem, and set to 0 in case there was an error. Because we have 
made sure line 1050 is the only line that can be executed while error 
processing is active, we clearly know the only problem in 1050 can only be "bad 
name". So it is important to pick a "test command" from the toolkit you are 
testing for that cannot choke on a different error than "bad name". MANIFEST is 
pretty ideal for this.

Tobias

> Am 17.08.2017 um 11:25 schrieb Tobias Fröschle via Ql-Users 
> :
> 
> Lee,
> 
> there are a number of toolkits that allow you to check for specific other 
> toolkit commands loaded or not - But this is a bit useless as it leaves you 
> with a chicken-and-egg problem: How to check whether the checking toolkit is 
> loaded?
> 
> Your best bet on SMSQ/E would be a WHEN ERRor clause you place just in front 
> of a Toolkit command you are about to execute:
> 
> 1000 TurboTkLoaded = 1
> 1010 WHEN ERRor
> 1020TurboTkLoaded = 0
> 1030 END WHEN
> 1040 REMark Execute a Toolkit command
> 1050 MANIFEST : x = 100
> 1055 REMark de-activate error checker
> 1060 WHEN ERRor
> 1070 END WHEN
> 1080 PRINT "Turbo Toolkit loaded:"!TurboTkLoaded
> 
> On a QL with non-working WHEN ERRor commands (pre-MG) you are a bit doomed, 
> the only thing I could probably come up with is writing a BASIC program that 
> PEEKs the name list, which is not quite so simple.
> 
> Tobias
> 
> 
>> Am 17.08.2017 um 10:49 schrieb Lee Privett via Ql-Users 
>> :
>> 
>> I originally posted this on the forum:
>> 
>> Hi community, I have searched for this on the forum but cannot find an
>> entry but I am sure this has been asked before.
>> 
>> I currently test for the presence of the HBA ROM in a boot program using
>> VER$ and would like to test for other toolkits, specifically the TURBO
>> toolkit. Is there a way to do this automatically in a boot so that when
>> subsequent runs of the boot it is not loaded again in one session?
>> 
>> e.g. for the HBA version I use:
>> 
>> Code: Select all 
>> IF VER$<>"HBA" THEN
>>  LRESPR "WIN8_SMSQ_QEM"
>> END IF
>> 
>> 
>> I feel there must be a way to test for TURBO toolkit, any ideas?
>> 
>> A reply from Derek suggested  the following:
>> 
>> There is a keyword: TK_VER$, but only returns the version of Turbo Toolkit,
>> which is the same for the SMS and QDOS versions.
>> 
>> A simple way would be to add "SMS" in the version number. Which would mean
>> a new version of Turbo Toolkit.
>> 
>> The SMS version calls the SMSQ/E extended traps, where the QDOS does not,
>> so maybe a test for SMSQ/E extended traps is the way, but I would favour
>> the about alteration to TK_VER$.
>> 
>> George Gwilt used to maintain Turbo and maybe the Toolkit. I think this
>> message needs to be posted in the QL-USERS mailing list, George Gwilt reads
>> that list.
>> 
>> Any views at all?
>> 
>> Regards Lee Privett
>> ___
>> QL-Users Mailing List
> 
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] TURBO and testing it exists

[Tobias Fröschle via Ql-Users]

Lee,

there are a number of toolkits that allow you to check for specific other 
toolkit commands loaded or not - But this is a bit useless as it leaves you 
with a chicken-and-egg problem: How to check whether the checking toolkit is 
loaded?

Your best bet on SMSQ/E would be a WHEN ERRor clause you place just in front of 
a Toolkit command you are about to execute:

1000 TurboTkLoaded = 1
1010 WHEN ERRor
1020TurboTkLoaded = 0
1030 END WHEN
1040 REMark Execute a Toolkit command
1050 MANIFEST : x = 100
1055 REMark de-activate error checker
1060 WHEN ERRor
1070 END WHEN
1080 PRINT "Turbo Toolkit loaded:"!TurboTkLoaded

On a QL with non-working WHEN ERRor commands (pre-MG) you are a bit doomed, the 
only thing I could probably come up with is writing a BASIC program that PEEKs 
the name list, which is not quite so simple.

Tobias


> Am 17.08.2017 um 10:49 schrieb Lee Privett via Ql-Users 
> :
> 
> I originally posted this on the forum:
> 
> Hi community, I have searched for this on the forum but cannot find an
> entry but I am sure this has been asked before.
> 
> I currently test for the presence of the HBA ROM in a boot program using
> VER$ and would like to test for other toolkits, specifically the TURBO
> toolkit. Is there a way to do this automatically in a boot so that when
> subsequent runs of the boot it is not loaded again in one session?
> 
> e.g. for the HBA version I use:
> 
> Code: Select all 
> IF VER$<>"HBA" THEN
>   LRESPR "WIN8_SMSQ_QEM"
> END IF
> 
> 
> I feel there must be a way to test for TURBO toolkit, any ideas?
> 
> A reply from Derek suggested  the following:
> 
> There is a keyword: TK_VER$, but only returns the version of Turbo Toolkit,
> which is the same for the SMS and QDOS versions.
> 
> A simple way would be to add "SMS" in the version number. Which would mean
> a new version of Turbo Toolkit.
> 
> The SMS version calls the SMSQ/E extended traps, where the QDOS does not,
> so maybe a test for SMSQ/E extended traps is the way, but I would favour
> the about alteration to TK_VER$.
> 
> George Gwilt used to maintain Turbo and maybe the Toolkit. I think this
> message needs to be posted in the QL-USERS mailing list, George Gwilt reads
> that list.
> 
> Any views at all?
> 
> Regards Lee Privett
> ___
> QL-Users Mailing List

___
QL-Users Mailing List

[Ql-Users] TURBO and testing it exists

[Lee Privett via Ql-Users]

I originally posted this on the forum:

Hi community, I have searched for this on the forum but cannot find an
entry but I am sure this has been asked before.

I currently test for the presence of the HBA ROM in a boot program using
VER$ and would like to test for other toolkits, specifically the TURBO
toolkit. Is there a way to do this automatically in a boot so that when
subsequent runs of the boot it is not loaded again in one session?

e.g. for the HBA version I use:

Code: Select all 
IF VER$<>"HBA" THEN
   LRESPR "WIN8_SMSQ_QEM"
END IF


I feel there must be a way to test for TURBO toolkit, any ideas?

A reply from Derek suggested  the following:

There is a keyword: TK_VER$, but only returns the version of Turbo Toolkit,
which is the same for the SMS and QDOS versions.

A simple way would be to add "SMS" in the version number. Which would mean
a new version of Turbo Toolkit.

The SMS version calls the SMSQ/E extended traps, where the QDOS does not,
so maybe a test for SMSQ/E extended traps is the way, but I would favour
the about alteration to TK_VER$.

George Gwilt used to maintain Turbo and maybe the Toolkit. I think this
message needs to be posted in the QL-USERS mailing list, George Gwilt reads
that list.

Any views at all?

Regards Lee Privett
___
QL-Users Mailing List