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

[Ql-Users] Turbo Parser

[Michael Bulford via Ql-Users]

I’ve been working on a new proposed update to the Turbo parser. Here is what it 
can do: Warn of duplicated parameters/locals, locals overwriting parameters, 
names used again in nested FOR/REPeat loops; locals not used - or used but not 
assigned. If MANIFEST or IMPLICIT statements are made too late, then Turbo will 
now be able to give the line number where they need to be placed. Any missing 
REFERENCE statements are now warned of with a by-ref/by-value conflict check. 
REMarks can now be attached to the top of IF/SELect/FOR/REPeat structures.
  
Besides the above additions, some existing parts of the code have been improved 
upon. Warnings of "LOCALs must follow DEFinitions." and "Meaningless command 
ignored." have not been working. This is now fixed. Some bugs are extremely 
minor - On Turbo's front panel, it is possible to overflow the report file 
window. This is now fixed.
  
May I ask everyone please, if you are aware of any problems in using Turbo, can 
you please inform me. I’m quite familiar with Turbo's code, having studied this 
for some while, so should be able to investigate.

The parser will increase in size by 11k to 91k. I presume this will be 
acceptable. I need to check my code first, before submitting this to George.

Michael
___
QL-Users Mailing List

Re: [Ql-Users] Turbo switch-bouton history

[Alain HAOUI]

Yes, the switch position should be selected before powering on.
The so called "Turbo-switch" has 3 wires and 2 static positions (1-2/2-3).
For the original ROM Selector on Q40, we need only the (2-3) position, the
other position should be open. So, the wire 1 should not be connected.
Thanks Dave, Derek.

-Message d'origine-
De : Ql-Users [mailto:ql-users-boun...@lists.q-v-d.com] De la part de Peter
Graf
Envoyé : vendredi 5 mai 2017 21:45
À : ql-us...@q-v-d.com
Objet : Re: [Ql-Users] Turbo switch-bouton history

No. Alain wants to use the turbo switch, not the reset button.

Am 05.05.2017 um 19:37 schrieb Dave Park:
> As the reset button is momentary, it will also take a bistable 
> flipflop like a 7474...
> 
> When I get back, I'll do you a little circuit. :)
> 
> Dave
> 
> On Fri, May 5, 2017 at 7:58 AM, <pg...@q40.de> wrote:
> 
>> On 5 May 2017 at 14:47, Alain HAOUI wrote:
>>
>>>> You'd have to bend one pin of each EPROM, so they don't connect to 
>>>> the
>>> socket. Then connect both bent pins by wire with turbo switch and a
>> pullup.
>>> (The onboard ROM selector jumpered to "Normal Operation".)
>>>
>>> This sounds promising. Not afraid. Pins number please. Thanks
>>
>> Depends on size. Why not look into EPROM datasheet yourself? Simply 
>> the highest addressline you've got.
>>
>> Peter
>>
>> ___
>> QL-Users Mailing List
___
QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] Turbo switch-bouton history

[Dave Park]

My apologies. I misunderstood.

Dave

On Fri, May 5, 2017 at 2:45 PM, Peter Graf  wrote:

> No. Alain wants to use the turbo switch, not the reset button.
>
> Am 05.05.2017 um 19:37 schrieb Dave Park:
> > As the reset button is momentary, it will also take a bistable flipflop
> > like a 7474...
> >
> > When I get back, I'll do you a little circuit. :)
> >
> > Dave
> >
> > On Fri, May 5, 2017 at 7:58 AM,  wrote:
> >
> >> On 5 May 2017 at 14:47, Alain HAOUI wrote:
> >>
>  You'd have to bend one pin of each EPROM, so they don't connect to the
> >>> socket. Then connect both bent pins by wire with turbo switch and a
> >> pullup.
> >>> (The onboard ROM selector jumpered to "Normal Operation".)
> >>>
> >>> This sounds promising. Not afraid. Pins number please. Thanks
> >>
> >> Depends on size. Why not look into EPROM datasheet yourself? Simply
> >> the highest addressline you've got.
> >>
> >> Peter
> >>
> >> ___
> >> QL-Users Mailing List
> ___
> QL-Users Mailing List
>



-- 
Dave Park
Sandy Labs
d...@sinclairql.com
___
QL-Users Mailing List

Re: [Ql-Users] Turbo switch-bouton history

[Peter Graf]

No. Alain wants to use the turbo switch, not the reset button.

Am 05.05.2017 um 19:37 schrieb Dave Park:
> As the reset button is momentary, it will also take a bistable flipflop
> like a 7474...
> 
> When I get back, I'll do you a little circuit. :)
> 
> Dave
> 
> On Fri, May 5, 2017 at 7:58 AM,  wrote:
> 
>> On 5 May 2017 at 14:47, Alain HAOUI wrote:
>>
 You'd have to bend one pin of each EPROM, so they don't connect to the
>>> socket. Then connect both bent pins by wire with turbo switch and a
>> pullup.
>>> (The onboard ROM selector jumpered to "Normal Operation".)
>>>
>>> This sounds promising. Not afraid. Pins number please. Thanks
>>
>> Depends on size. Why not look into EPROM datasheet yourself? Simply
>> the highest addressline you've got.
>>
>> Peter
>>
>> ___
>> QL-Users Mailing List
___
QL-Users Mailing List

Re: [Ql-Users] Turbo switch-bouton history

[Dave Park]

As the reset button is momentary, it will also take a bistable flipflop
like a 7474...

When I get back, I'll do you a little circuit. :)

Dave

On Fri, May 5, 2017 at 7:58 AM,  wrote:

> On 5 May 2017 at 14:47, Alain HAOUI wrote:
>
> > > You'd have to bend one pin of each EPROM, so they don't connect to the
> > socket. Then connect both bent pins by wire with turbo switch and a
> pullup.
> > (The onboard ROM selector jumpered to "Normal Operation".)
> >
> > This sounds promising. Not afraid. Pins number please. Thanks
>
> Depends on size. Why not look into EPROM datasheet yourself? Simply
> the highest addressline you've got.
>
> Peter
>
> ___
> QL-Users Mailing List
>



-- 
Dave Park
Sandy Labs
d...@sinclairql.com
___
QL-Users Mailing List

Re: [Ql-Users] Turbo switch-bouton history

[pgraf]

On 5 May 2017 at 14:47, Alain HAOUI wrote:

> > You'd have to bend one pin of each EPROM, so they don't connect to the
> socket. Then connect both bent pins by wire with turbo switch and a pullup.
> (The onboard ROM selector jumpered to "Normal Operation".)
> 
> This sounds promising. Not afraid. Pins number please. Thanks

Depends on size. Why not look into EPROM datasheet yourself? Simply 
the highest addressline you've got.

Peter

___
QL-Users Mailing List

Re: [Ql-Users] Turbo switch-bouton history

[Alain HAOUI]

Thanks Peter for your comments.

> Could it be your QubATA code? I remember that Qubide was always a bit
critical on powerup.

This happens without QubATA or any extra code or configured items.
Qubide was always a bit critical on powerup, QubATA is not ;-)

> How about the monitor? Or did you find one of the rare Flatscreens that
can display 1024x512 well?

I still have a CRT multisync monitor (probably the last one working) but I
used also a video upscaler VGA to HDMI on faltscreens.

Anyway, I don't really use the high resolution (1024x512) which is not
enough compliant with my eyes quality requirement.
However the 16 bits colours mode is excellent.

> You'd have to bend one pin of each EPROM, so they don't connect to the
socket. Then connect both bent pins by wire with turbo switch and a pullup.
(The onboard ROM selector jumpered to "Normal Operation".)

This sounds promising. Not afraid. Pins number please. Thanks

PS : Bouton = Button = Taste = Botòn = some kind of electrical equipment
when pushed or turned, switches from a stable state (Computer OFF) to an
unstable state (Computer ON) - :-)

Regards,
Alain

___
QL-Users Mailing List

___
QL-Users Mailing List

Re: [Ql-Users] Turbo switch-bouton history

[pgraf]

On 5 May 2017 at 9:41, Alain HAOUI wrote:

> I have managed to burn the latest SMSQ/E version 3.31 on a big ROM with some
> extra modules. This also worked as expected; A new "Quantum Leap".

Congratulations, you are ahead of the Q40 designer ;) I have not yet 
tried the latest SMSQ/E version from ROM.

> Then I was discussing for a while with Peter and Derek to learn how to
> split/combine all parts and construct the big ROM image with 2 OSes. Very
> interesting but we discovered later that ROM selector doesn't permit more
> than 128KBytes as continuous space addressing, so it can't be used to have 2
> bigs OSes whatever the size of used ROM; Return to reality.

That was just a primitive implementation pulling a single address 
line high or low. So it supported only a fixed size for the 
selection. At design time, 256 ROM seemed more appropriate than 1024 
KB.

> I have also noticed that different SMSQ/E versions may have different
> behaviors on starting. On my system per example, the v3.31 need to be
> restarted with the Reset button after switching On the Power to get SMSQ/E
> correctly started from ROM, while it starts normally when LRESPRed from
> disk. It looks like a timing issue related to Ready State for some devices.

I guess there was no work on the SMSQ/E lowlevel Q40 code for 
external devices since the last version from Tony Tebby. That one 
definitly boots without extra reset.

Could it be your QubATA code? I remember that Qubide was always a 
bit critical on powerup.

> Finally, I returned to the last working configuration with a 512KBytes ROM
> with a recent tuned SMSQ/E version, plus some extra modules and enough free
> space left for the next (10 ?) years needs; Great.

How about the monitor? Or did you find one of the rare Flatscreens 
that can display 1024x512 well?

> By the way, the Turbo switch button is again free on my case. Any idea ?

If not afraid of tinkering, you could use a different address line 
for the switch, allowing two larger OS in ROM. 

You'd have to bend one pin of each EPROM, so they don't connect to 
the socket. Then connect both bent pins by wire with turbo switch 
and a pullup. (The onboard ROM selector jumpered to "Normal 
Operation".)

Peter

PS: I like the word "bouton" in the subject :) sounds french... does 
it mean the same?

___
QL-Users Mailing List

[Ql-Users] Turbo switch-bouton history

[Alain HAOUI]

 

On my old good Q40 platform, I used a very early unusable SMSQ/E ROMed
version. It served only to load a more suitable SMSQ/E version from hard
disk on boot.

 

As I was recently playing with all kind of ATA/ATAPI devices, I needed to
have a working OS starting from ROM without necessary having a working
master device. Then, I decided to burn a new ROM with a good SMSQ/E version;
A real challenge for a novice tinkerer like me.

 

After having prepared all necessary burning material, I discovered that
recent SMSQ/E versions are greater than 256KBytes and can't fit in a
standard ROM on Q40 using 2x27C0124 ships; Grrr Horror.

 

With some help from "a gentleman registrar" and "community", I could have a
good enough working version within the limit of 256KB. I have managed to
burn a new ROM with SMSQ/E version 3.11 and this worked fine; Good start.

 

I was happy with this result until I needed to add a new module to the ROMed
SMSQ/E OS. I wished to add my new QubATA driver as a module and start it
automatically with SMSQ/E. As this module takes about 16KB.; Again, it can't
fit in ROM..

 

Knowing Q40 may support greater ROMs (up to 1 MBytes), I purchased some
27C2048 ships (256KBytes capacity, each) permitting to have a global ROM of
512KB. It wasn't easy to find these ships at reasonable price on the market.
Derek has also managed to find some 27C4096 ships (512KB each) in the back
of a drawer permitting to have a global ROM of 1MBytes; Plenty of ROM space.

 

I have managed to burn the latest SMSQ/E version 3.31 on a big ROM with some
extra modules. This also worked as expected; A new "Quantum Leap".

 

I was happy with this new result.until I have got another idea. While
reading the Q40 manual I noticed the ROM selector which permit to split ROM
with 2 parts for 2 different OSes.

 

I then wanted to have 2 SMSQ/E systems, one for a standard stable use and
the other for test and experimenting use. I was also proud to find some
utility for the Turbo-switch button lurking in my case for years which I can
use to select wanted OS. As I used a dual CF card readers and 2 ISA cards
I/O, I could be able to change easily between different system
configurations without the need to open the case; A dreamful.

 

Then I was discussing for a while with Peter and Derek to learn how to
split/combine all parts and construct the big ROM image with 2 OSes. Very
interesting but we discovered later that ROM selector doesn't permit more
than 128KBytes as continuous space addressing, so it can't be used to have 2
bigs OSes whatever the size of used ROM; Return to reality.

 

I have also noticed that different SMSQ/E versions may have different
behaviors on starting. On my system per example, the v3.31 need to be
restarted with the Reset button after switching On the Power to get SMSQ/E
correctly started from ROM, while it starts normally when LRESPRed from
disk. It looks like a timing issue related to Ready State for some devices.
Some versions don't load at all when launched from Classic QDOS even from
disk; Old history.

 

Finally, I returned to the last working configuration with a 512KBytes ROM
with a recent tuned SMSQ/E version, plus some extra modules and enough free
space left for the next (10 ?) years needs; Great.

 

By the way, the Turbo switch button is again free on my case. Any idea ?

 

Sorry for this long history that I hope someway useful.

 

Alain

___
QL-Users Mailing List

[Ql-Users] TURBO version 5.07

[George Gwilt]

Two faults in TURBO found by Michael Bulford (thanks)  have been corrected in 
v5.07 which is available from my site http://gwiltprogs.info/

George
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [Ql-Users] Turbo Tk Code v3.40

[gdgqler]

Hi Malcolm
On 28 Oct 2011, at 20:42, Malcolm Cadman wrote:

 
 The zip files: trbom, setwp06 and cptrp11 - are giving error report on 
 download.
 

These files download OK for me. Is it the unzipping which gives an error?

George
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [Ql-Users] Turbo Tk Code v3.40

[Malcolm Cadman]

In message 5f173f46-51cb-4472-9e27-2c2883d07...@gmail.com, gdgqler 
gdgq...@gmail.com writes



Hi Malcolm
On 28 Oct 2011, at 20:42, Malcolm Cadman wrote:



The zip files: trbom, setwp06 and cptrp11 - are giving error report 
on download.




These files download OK for me. Is it the unzipping which gives an error?

George


No. When downloaded ... :-(

I will try again.

--
Malcolm Cadman
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

[Ql-Users] Turbo Tk Code v3.40

[gdgqler]

Version 3.40 of Turbo Tk Code is on my site http://gwiltprogs.info/

Version 3.39 allowed COMMAND_LINE to select a daughter SBASIC's channel 0 by 
giving as a parameter the ID of any channel opened to that SBASIC. The opened 
channel did not need to be a CON device.

Version 3.40 additionally allows the parameter to be the Job ID of the target 
SBASIC. COMMAND_LINE looks first to see if the parameter is a Job ID.

George
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [Ql-Users] Turbo Tk Code v3.40

[Malcolm Cadman]

In message 5c638701-a998-4631-bc06-6708d8c69...@gmail.com, gdgqler 
gdgq...@gmail.com writes


Hi George,

The zip files: trbom, setwp06 and cptrp11 - are giving error report on 
download.


trbot, downloaded OK.



Version 3.40 of Turbo Tk Code is on my site http://gwiltprogs.info/

Version 3.39 allowed COMMAND_LINE to select a daughter SBASIC's channel 
0 by giving as a parameter the ID of any channel opened to that SBASIC. 
The opened channel did not need to be a CON device.


Version 3.40 additionally allows the parameter to be the Job ID of the 
target SBASIC. COMMAND_LINE looks first to see if the parameter is a 
Job ID.


George
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm


--
Malcolm Cadman
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

[Ql-Users] Turbo Tk Code v3.39

[gdgqler]

Version 3.39 of Turbo Tk Code is on my site http://gwiltprogs.info/

This version allows COMMAND_LINE to select a daughter SBASIC's channel 0 by 
giving as a parameter the ID of any channel opened to that SBASIC. The opened 
channel does not need to be a CON device.

George
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

[Ql-Users] turbo

[Dilwyn Jones]

I'm trying to compile an old QL program with Turbo.

I need to put in a don't compile this bit, it's only for interpreted 
use instruction (a procedure which saves the program), but can't 
remember how to do this in Turbo.


In QLiberator I just use REMark $$on and $$off directives. Is there an 
equivalent in Turbo?


Dilwyn Jones 




___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [Ql-Users] turbo

[Dilwyn Jones]

Malcolm Lear wrote:

Hi

It's been a long time, but I seem to remember you can use IF NOT 
COMPILED.


Cheers
Malcolm

Ah yes, that's it. Thanks!


Oops! No it wasn't after all.

What I meant was preventing the Turbo compiler from compiling it in 
the first place.


The program has a procedure like this, which lets me quickly save it 
from interpreted basic:


def proc Sa
 save win1_basic_filename_bas:qsave win1_basic_filename
end def

I want the compiler to ignore and not try to compile those three 
lines! So easy in QLib (using REM$$off etc. and it's so long since I 
used Turbo I can't remember how!


Dilwyn Jones 




___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [Ql-Users] Turbo Help Please

[Matrassyl]

 
In a message dated 24/04/2008 00:38:28 GMT Daylight Time,  
[EMAIL PROTECTED] writes:

But  if you try to compile (Turbo or Liberator) some parser error will  
appear...




Hi Gerhard, its a codegen error : Duplicate Label Have you ever  seen that 
error?. Its not mentionned in the manual. The lines in question  compile in 
Qlib. Problems with IF END IF are identified with parser task. What I  am 
wondering is if teh error message indicates a clash between, procedure names  
and 
keywords or perhaps variable definitions although nothing is obvious  obviously.
 
Here are the lines : Its part of a SELect ON value Line 9480 is the  line 
codegen complains about.
 
 
9464=3
9466dv_POS=INT(((zone*12)/(dev_ht%-12))*(free%)):IF  
dv_POS1:dv_POS=1
9468IF  dv_POS=dv_start
9470  scrolls=dv_start-dv_POS
9472  FOR i=1 TO  scrolls
9474Dev_Scroll_down
9476IF dv_start=1 :END FOR  i
9478  END FOR i
9480END IF
9482   IF  dv_POS=dv_end
9484  scrolls=dv_POS-dv_end
9486  FOR i=1 TO  scrolls
9488Dev_Scroll_up
9490  END FOR i
9492   IF  free%-1dv_end:Dev_Scroll_up
9494END IF 
 
 
Duncan



   
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [Ql-Users] Turbo Help Please

[Derek Stewart]

Duncan,

Try putting NEXT i in line 9476

The compiler will be seeing two ends to the FOR loop/

Derek

[EMAIL PROTECTED] wrote:
  
 In a message dated 24/04/2008 00:38:28 GMT Daylight Time,  
 [EMAIL PROTECTED] writes:

   
 But  if you try to compile (Turbo or Liberator) some parser error will  
 appear...
 




 Hi Gerhard, its a codegen error : Duplicate Label Have you ever  seen that 
 error?. Its not mentionned in the manual. The lines in question  compile in 
 Qlib. Problems with IF END IF are identified with parser task. What I  am 
 wondering is if teh error message indicates a clash between, procedure names  
 and 
 keywords or perhaps variable definitions although nothing is obvious  
 obviously.
  
 Here are the lines : Its part of a SELect ON value Line 9480 is the  line 
 codegen complains about.
  
  
 9464=3
 9466dv_POS=INT(((zone*12)/(dev_ht%-12))*(free%)):IF  
 dv_POS1:dv_POS=1
 9468IF  dv_POS=dv_start
 9470  scrolls=dv_start-dv_POS
 9472  FOR i=1 TO  scrolls
 9474Dev_Scroll_down
 9476IF dv_start=1 :END FOR  i
 9478  END FOR i
 9480END IF
 9482   IF  dv_POS=dv_end
 9484  scrolls=dv_POS-dv_end
 9486  FOR i=1 TO  scrolls
 9488Dev_Scroll_up
 9490  END FOR i
 9492   IF  free%-1dv_end:Dev_Scroll_up
 9494END IF 
  
  
 Duncan




 ___
 QL-Users Mailing List
 http://www.q-v-d.demon.co.uk/smsqe.htm


   
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [Ql-Users] Turbo Help Please

[norman]

Morning Duncan,

Hopefully I'm remembering my FOR..NEXT..END FOR syntax correctly, but the 
following looks remarkably suspicious :


9472 FOR i=1 TO scrolls
9474 Dev_Scroll_down
9476 IF dv_start=1 :END FOR i
9478 END FOR i 

I think it should be :

9472 FOR i=1 TO scrolls
9474 Dev_Scroll_down
9476 IF dv_start=1 TEHN NEXT i : END IF
9478 END FOR i 

I can't remember off hand if Turbo is happy with no end ifs on a single line 
IF, so I've always put them in myself, even in SuperBaisc interpreted programs.

I also assume that if DV_STARTS is 1 or less that you want to go around the 
loop again and not exit from the loop itself. If you did want to bale out 
early, then line 9467 would change to :

9476 IF dv_start=1 THEN EXIT i : END IF

Basically, and if I remember correctly, a For loop looks like this :

FOR variable = start TO finish STEP step
  do stuff
  IF condition THEN EXIT variable : END IF : REM - Early exit 
  IF other_condition THEN NEXT variable: END IF : REM - Reloop early
  do other stuff
END FOR variable


Cheers,
Norman.
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [Ql-Users] Turbo Help Please

[Wolfgang Lenerz]

On 24 Apr 2008 at 2:57, [EMAIL PROTECTED] wrote:
(...)
 9476IF dv_start=1 :END FOR  i

This should probably be : EXIT i.


Wolfgang


___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [Ql-Users] Turbo Help Please

[Matrassyl]

Hi Derek,
 
Thanks that was the line. 
 
I used EXIT i as Wolfgang suggested to stop the loop. 
 
Program now compiles and now I have other bugs to fix
 
Duncan



   
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [Ql-Users] Turbo Help Please

[Matrassyl]

Hi Norman,
 
 
Thanks that was the line. 
 
I used EXIT i as Wolfgang suggested to stop the loop. 
 
Program now compiles and now I have other bugs to fix
 
Duncan




   
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [Ql-Users] Turbo Help Please

[Matrassyl]

Hi Wolfgang, Thanks that was the answer. 
 
 
Program now compiles and now I have other bugs to fix
 
Duncan




   
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [Ql-Users] Turbo Help Please

[Malcolm Cadman]

In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes

In a message dated 23/04/2008 19:59:57 GMT Daylight Time,
[EMAIL PROTECTED] writes:

Are you  sure that every IF statement has an END IF ?

Particularly when  nested loops and conditions are coded


Hi Malcolm,
I am fairly sure that they do it is one of the first things I looked  for.

Duncan

Hi Duncan,

Now that I have seen the coding extract, I can see that you do have a 
matching IF and END IF.

However, you also have a FOR loop within the IF statement as a 
whole, so this could be where the error is being thrown up.

I do my FOR loops like this ( the long way )

FOR num%=1 TO 6
 READ an_option$(num%)
END FOR num%

Which is what you have done too.

9472  FOR i=1 TO  scrolls
9474Dev_Scroll_down
9476IF dv_start=1 :END FOR  i
9478  END FOR i
9480END IF

Although you may be better using the EXIT i, rather than as END FOR 
i

I also always use integers for loops with Turbo, so i% rather than 
just i

I use REPeat and END REPeat conditions as the main condition mode, 
which allows any number of IF and END IF conditions to be set up as 
well inside that.

Always use EXIT from a REPeat.

Which may achieve what you are intending to do much better, and allows 
for elegant looking coding.

In addition I find that the SELect ON num% and END SELect again 
gives an elegant listing with endless options from the value of the 
variable.

Another thing to do is to make any variables LOCal to a PROCedure, 
which avoids confusion when using i or i%.

I hope this helps.

-- 
Malcolm Cadman
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [Ql-Users] Turbo Help Please

[Gerhard Plavec]

Hi Duncan :)

 9472  FOR i=1 TO  scrolls

=Beginning of the loop

 9474Dev_Scroll_down
 9476IF dv_start=1 :END FOR  i

=End of the loop

 9478  END FOR i

Here you have one more end of a loop (whitch never was beginning...)
so parser has a big problem dupicate label !!?!

 9480END IF

Wolfgang and some other guys are right, in line 9476 you have to use 
NEXT i or EXIT i instead of END FOR i

Have much fun further debuging

Gerhard

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [Ql-Users] Turbo Help Please

[Matrassyl]

 
In a message dated 24/04/2008 20:57:28 GMT Daylight Time,  
[EMAIL PROTECTED] writes:

Wolfgang and some other guys are right, in line 9476 you have to  use 
NEXT i or EXIT i instead of END FOR i

Have much fun  further debuging







Thanks, I will
 
Duncan



   
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [Ql-Users] Turbo Help Please

[Matrassyl]

 
In a message dated 24/04/2008 20:33:21 GMT Daylight Time,  
[EMAIL PROTECTED] writes:

 I  hope this helps.



It does many thanks as I am now past the it wont compile stage to I  did not 
think there were so many bugs to sort out stage.
 
Duncan



   
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [Ql-Users] Turbo Help Please

[Dilwyn Jones]

 9472 FOR i=1 TO scrolls
 9474 Dev_Scroll_down
 9476 IF dv_start=1 TEHN NEXT i : END IF
 9478 END FOR i

 I can't remember off hand if Turbo is happy with no end ifs on a 
 single line IF, so I've always put them in myself, even in 
 SuperBaisc interpreted programs.

 I also assume that if DV_STARTS is 1 or less that you want to go 
 around the loop again and not exit from the loop itself. If you did 
 want to bale out early, then line 9467 would change to :
In my programs I tend to put a catch-all in for cases like this which 
allows this case to go around the loop again, but also to exit the 
loop if exhausted:

9476 IF dv_start = 1 THEN NEXT i : EXIT i

The exit gets ignored unless the loop is exhausted. Not sure if it's 
good programming style, but it does seem to work.

-- 
Dilwyn Jones

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [Ql-Users] Turbo Help Please

[Rich Mellor]

Dilwyn Jones wrote:
 9472 FOR i=1 TO scrolls
 9474 Dev_Scroll_down
 9476 IF dv_start=1 TEHN NEXT i : END IF
 9478 END FOR i

 I can't remember off hand if Turbo is happy with no end ifs on a 
 single line IF, so I've always put them in myself, even in 
 SuperBaisc interpreted programs.

 I also assume that if DV_STARTS is 1 or less that you want to go 
 around the loop again and not exit from the loop itself. If you did 
 want to bale out early, then line 9467 would change to :
 
 In my programs I tend to put a catch-all in for cases like this which 
 allows this case to go around the loop again, but also to exit the 
 loop if exhausted:

 9476 IF dv_start = 1 THEN NEXT i : EXIT i

 The exit gets ignored unless the loop is exhausted. Not sure if it's 
 good programming style, but it does seem to work.

   
Actually Dilwyn uses the correct style here:

Try:

10 FOR i=1 TO 9
20   PRINT i;  ;
30   IF i MOD 2  THEN NEXT i
40   PRINT i^2
50 END FOR i

Output is: 1 2 43 4 165 6 367 8 649 81

The NEXT is ignored when i=9

It is fixed with
30   IF i MOD 2  THEN NEXT i: EXIT i

-- 
Rich Mellor
RWAP Services
URL:http://www.rwapsoftware.co.uk
URL:http://www.rwapservices.co.uk

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

[Ql-Users] Turbo Help Please

[Matrassyl]

Am trying to compile a program with turbo 5.06. I am getting a codegen  error 
message Duplicate Label line 9480. Line 9480 contains only END  IF of a 
properly constructed IF  END IF expression.
Duplicate Label is not mentioned in the manual as a codegen error report.  
Can anyone clarify what the error means exactly?
 
Thanks
 
Duncan



   
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [Ql-Users] Turbo Help Please

[Malcolm Cadman]

In message [EMAIL PROTECTED], [EMAIL PROTECTED] writes

Hi,

Are you sure that every IF statement has an END IF ?

Particularly when nested loops and conditions are coded.

I know that Turbo does insist on correct syntax, without any shortcuts 
that the BASIC parser may sometimes accept.

Which is all to the good, as it prevents an errors occurring later in 
the compiled code.


Am trying to compile a program with turbo 5.06. I am getting a codegen  error
message Duplicate Label line 9480. Line 9480 contains only END  IF of a
properly constructed IF  END IF expression.
Duplicate Label is not mentioned in the manual as a codegen error report.
Can anyone clarify what the error means exactly?

Thanks

Duncan

-- 
Malcolm Cadman
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [Ql-Users] Turbo Help Please

[Matrassyl]

 
In a message dated 23/04/2008 19:59:57 GMT Daylight Time,  
[EMAIL PROTECTED] writes:

Are you  sure that every IF statement has an END IF ?

Particularly when  nested loops and conditions are coded


Hi Malcolm,
I am fairly sure that they do it is one of the first things I looked  for.
 
Duncan



   
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [Ql-Users] Turbo Help Please

[Gerhard Plavec]

In original SuperBASIC some (dubious) programm like

IF a=b then
   FOR i=a TO b STEP 0.1
ELSE
   FOR i=a TO b STEP -0.1
ENDIF
...
more commands
...
END FOR i

may run without any problem...
But if you try to compile (Turbo or Liberator) some parser error will 
appear...

you have to write something like

FOR i=a TO b STEP sign(b-a)*0.1
...
END FOR i

Give more information, so perhaps someone can help...

GP


[EMAIL PROTECTED] wrote:

  
 In a message dated 23/04/2008 19:59:57 GMT Daylight Time,  
 [EMAIL PROTECTED] writes:
 
 Are you  sure that every IF statement has an END IF ?
 
 Particularly when  nested loops and conditions are coded
 
 
 Hi Malcolm,
 I am fairly sure that they do it is one of the first things I looked  for.
  
 Duncan
 
 
 

 ___
 QL-Users Mailing List
 http://www.q-v-d.demon.co.uk/smsqe.htm
 
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

[ql-users] Turbo and TurboPTR articles

[Dilwyn Jones]

For those who'd like some information about Turbo compiler and 
TurboPTR systems, I've added 2 sets of articles to my QL Documentation 
page. The first is an introduction to the Turbo compiler by David 
Denham, and the second is a set of 4 articles about TurboPTR from 
George Gwilt. All articles were originally published in QL Toady and 
I'm grateful to the authors for permission to make them available.

http://dilwynjones.topcities.com/qldocs/qldocs.html

-- 
Dilwyn Jones

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

[ql-users] Turbo

[John Sadler]

Updated to allow Config Files to be updated at configuration time and not
loaded seperately.

See http://www.jms1.supanet.com/SQLUG/gwilt/gwiltturbo.htm

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [ql-users] Turbo ????????

[gwicks]

- Original Message - 
From: David Tubbs

To: [EMAIL PROTECTED]
Sent: Tuesday, August 09, 2005 9:21 PM
Subject: Re: [ql-users] Turbo

Marvellous! A subject heading of Turbo, but a whole tirade about A4 v A5.

Obviously Mr. Tubbs doesn't know what he is writing about!

Best Wishes,
Geoff


___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [ql-users] Turbo

[David Tubbs]

A4 A5

There is a troglodyte, living far out in the desert, running a solar 
powered  MDV only 128 QL. He does NOT have access to the Internet.


Is there anyone else that does not have a phone line and a PC, or access to 
the web from the office, a library or an Internet caff ?  If these 
resources are not utilised that does not mean they are unavailable.


I am outside a locked door, the key is in my pocket. Whether I enter or not 
I DO have access !


The costs of printing  postage could be saved, the subscription 
slashed,  anyone who wants a paper copy to hang in the little room can 
print it out.


But the real advantage of the down-loadable version is surely that any 
programme content, basic or assembler can used as is without having to type 
it all in  is that an I or an l or a 1 ?


I think a straight forward WORD  doc is better than a pdf, more easily 
modifiable for printout, content, size and/or page order.


And as for GWICKS quote :-
However no one on the Quanta Committee has experience of either so we would 
have to have external expertise.


Says it all in spades  why are they running a computer group ?

I am sure that members  users interests would be better served by a 
coalition of traders, they have the expertise and an active scene is in 
their interest. Online conferenceing via Skype could replace travelling 
expenses too.



--
No virus found in this outgoing message.
Checked by AVG Anti-Virus.
Version: 7.0.338 / Virus Database: 267.10.5/67 - Release Date: 09/08/2005


___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

[ql-users] Turbo Experimental Updates

[jms1]

The latest version of Turbo passing variables by reference is on the site.
Apparently there is a problem with strings with QDOS because the ROM
allocates space for the string instead of using the existing space which is
not allowed in Turbo.
This does not appear to be the case for SMSQE.
Does anybody know whether Minerva or Classic does the same?

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

[ql-users] Turbo

[jms1]

Please note that the old version of Turbo has been placed on the site as the
previous version had a problem with passing string parameters by reference
causing erratic problems with SMSQE and more serious ones with QDOS Roms.

It is not known whether the same problems exist with Minerva or Classic ROMs
and if somebody can test by using Charge with version 10, George and I would
like to know.

There is an experimental version on the site Tr421k which we would
appreciate being tested.

The problem is related to how QDOS and the other operating systems store
string parameters so perhapsSMSQE, Minerva and the Clasic could be altered
to elimate this problem?

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

[ql-users] Turbo Programs SMSQE

[jms1]

Latest version of  the Turbo Compiler, Source, Toolkit  Manuals are on the
site.

George has produced a Gwass assembler version of the latest version of
SMSQE.
Testers who wish to try it please contact me.

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [ql-users] Turbo Programs SMSQE

[Fabrizio Diversi]

Yes , I would like to test it.
Many Thanks

Best regards

Fabrizio
- Original Message - 
From: jms1 [EMAIL PROTECTED]

To: [EMAIL PROTECTED]
Sent: Sunday, May 22, 2005 12:13 PM
Subject: [ql-users] Turbo Programs  SMSQE


Latest version of  the Turbo Compiler, Source, Toolkit  Manuals are on 
the

site.

George has produced a Gwass assembler version of the latest version of
SMSQE.
Testers who wish to try it please contact me.

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm





___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [ql-users] Turbo Programs SMSQE

[Fabrizio Diversi]

Sorry, I replay to the list instead of jms1

Fabrizio
- Original Message - 
From: jms1 [EMAIL PROTECTED]

To: [EMAIL PROTECTED]
Sent: Sunday, May 22, 2005 12:13 PM
Subject: [ql-users] Turbo Programs  SMSQE


Latest version of  the Turbo Compiler, Source, Toolkit  Manuals are on 
the

site.

George has produced a Gwass assembler version of the latest version of
SMSQE.
Testers who wish to try it please contact me.

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm





___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

[ql-users] Turbo Programs SMSQE

[Stuart Jones]

Jochen,

 

When you say.

 

Latest version of  the Turbo Compiler, Source, Toolkit  Manuals are on the
site.

 

What is the address, please?

 

Regards,

 

Stuart

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [ql-users] Turbo Programs SMSQE

[. (Phoebus R. Dokos)]

On Sun, 22 May 2005 18:09:17 -0400, Stuart Jones [EMAIL PROTECTED]  
wrote:



Jochen,




That would be jms1 (J. Sadler) (SQLUG as per the URL I copied to you on my  
private message)


but not JMS (Jochen Merz Software):-)


When you say.


Latest version of  the Turbo Compiler, Source, Toolkit  Manuals are on  
the

site.





What is the address, please?


See my personal message :-)

Ffibys
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

[ql-users] Turbo Programs SMSQE

[Stuart Jones]

Oops, sorry, thanks, Phoebus.

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [ql-users] Turbo v4g21

[Geogwilt]

In a message dated 02/05/05 18:07:18 GMT Daylight Time, [EMAIL PROTECTED] 
writes:

 snip
 I have not tried Turbo on a lower machine than AM Rom plus trump card.
 You mean AH don't you (8-)#
 
 

I mean JM.

George
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [ql-users] Turbo v4g21

[Geogwilt]

In a message dated 01/05/05 10:39:55 GMT Daylight Time, [EMAIL PROTECTED] 
writes:

 
 Hi George,
 
 I have downloaded the new Yurbo v4g21, I will try it on all my programs 
 on the Q60, QXl, QPC2, Atari QL, Trump Card QL...
 
 I would like you to keep in the backwards compatibility within Turbo, as 
 there are still people using a QL that do not use SMSQ/E and GD2.
 
 I think that the backwards compatabilty is important to support these users.
 
 What is the minimum specification of QL that is required to use Turbo now.
 
 Derek
 

I have not tried Turbo on a lower machine than AM Rom plus trump card. AFAIK 
it would only be size of ram that would stop it working on an unexpanded QL.

I agree totally that backwards compatibility is essential and I always have 
that in mind.

Cheers

George
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [ql-users] Turbo v4g21

[Tony Firshman]

On  Mon, 2 May 2005 at 06:10:12,  wrote:
(ref: [EMAIL PROTECTED])

 snip
I have not tried Turbo on a lower machine than AM Rom plus trump card.
You mean AH don't you (8-)#

Tony
-- 
 QBBS (QL fido BBS 2:252/67) +44(0)1442-828255
  tony@surname.co.uk  http://firshman.co.uk
 Voice: +44(0)1442-828254  Fax: +44(0)1442-828255  Skype: tonyfirshman
 TF Services, 29 Longfield Road, TRING, Herts, HP23 4DG

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [ql-users] Turbo v4g21

[Derek Stewart]

AM roms... they must a morning rom...
Derek
Tony Firshman wrote:
On  Mon, 2 May 2005 at 06:10:12,  wrote:
(ref: [EMAIL PROTECTED])
 snip
I have not tried Turbo on a lower machine than AM Rom plus trump card.
You mean AH don't you (8-)#
Tony
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [ql-users] Turbo v4g21

[Derek Stewart]

Bill,
does Joe still have the QL meetings at his Computer Shoppe'
Derek
Bill Waugh wrote:
- Original Message - From: Derek Stewart [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, May 02, 2005 6:18 PM
Subject: Re: [ql-users] Turbo v4g21
Presumable there is no PM rom because THERE JUST IS'NT ALRIGHT
All the best - Bill

AM roms... they must a morning rom...
Derek
Tony Firshman wrote:
On  Mon, 2 May 2005 at 06:10:12,  wrote:
(ref: [EMAIL PROTECTED])
 snip
I have not tried Turbo on a lower machine than AM Rom plus trump card.

You mean AH don't you (8-)#
Tony
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm
--
No virus found in this incoming message.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.11.0 - Release Date: 29/04/2005

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [ql-users] Turbo v4g21

[Bill Waugh]

- Original Message - 
From: Derek Stewart [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Monday, May 02, 2005 6:36 PM
Subject: Re: [ql-users] Turbo v4g21


Bill,
does Joe still have the QL meetings at his Computer Shoppe'
Derek
Sadly no, the North East sub group is to all purposes no more.
I have considered visiting the Scottish sub group at some point but time and 
distance.

Shame
All the best - Bill 

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [ql-users] Turbo v4g21

[Derek Stewart]

Hi George,
I have downloaded the new Yurbo v4g21, I will try it on all my programs 
on the Q60, QXl, QPC2, Atari QL, Trump Card QL...

I would like you to keep in the backwards compatibility within Turbo, as 
there are still people using a QL that do not use SMSQ/E and GD2.

I think that the backwards compatabilty is important to support these users.
What is the minimum specification of QL that is required to use Turbo now.
Derek
[EMAIL PROTECTED] wrote:
In a message dated 30/04/05 16:37:59 GMT Daylight Time, 
[EMAIL PROTECTED] writes:


There is one more change that I have made. That is in the choice of stack
size. EasyPtr and QPTR extensions need more stack than the 350 bytes
default. You

Could the problems I mentioned to you in a private mail (lots of
inexplicable run-time errors) relate to this issue, do you think? I know, I
could just try and figure it out for myself ;) but Im shortly going away for
a week, and perhaps others are struggling with the same problem..
The effects of overwriting items in dataspce because the stack is too small 
are unpredictable. I have usually found that it is particularly hard to debug 
these programs. It is therefore a good idea to bear in mind that some S*BASIC 
extensions use much more stack than normal. This is true of QPTR and, I think, 
EasyPtr as well.

Incidentally I think it would a good idea if a register were available 
showing those extensions which needed a stack size of over, say, 250 bytes.


I have also looked at PEEK(!! etc) which allow easy access to system
variables and (PEEK(\\ etc) which allow access to S*BASIC areas. PEEK and
POKE are
dealt internally by Turbo which is much faster than calling the rom
versions. It
would not be easy to allow for the !! and \\ variations.
However, the system variables is found at SYS_VARS so a slightly extended
PEEK parameter can replace PEEK(!! . .). Also Turbo TK Code has several
BASIC_xxx
functions which should cover a lot od the PEEK(\\ ...) ground.
Im aware of SYS_VARS and BASIC_xxx, but Turbo is supposed to be a S*Basic
compiler, not a language of its own (this is the nature of one of the
arguments I had with Freddy, who appeared to be arguing that it was
SuperBasic that was incompatible!)

I don't think it will ever be the case that Turbo can compile all programs 
written in S*BASIC. If that did come about I guess that the speed advantage 
would disappear and that it would be just as fast running the program in S*BASIC. 
PEEK and POKE are examples of this. Instead of calling the machine code Turbo 
does it internally. Since only two or three assembler instructions are needed 
this is much faster.

There are three areas where, at the moment, programs written to be compiled 
by Turbo are restricted.

1. DATA lines must contain just pure numbers or strings.
2. Variable names can't be used in different places with a different number 
of dimensions.
3. Some integer arithmetic requires careful handling. In some cases Turbo 
assumes that the result will be an integer where S*BASIC assumes floating point.

This shows that Turbo does not aim to compile ALL S*BASIC programs. 


I understand that this could be a wee bit problematic, as these variants
arent SuperBasic. However, Turbo is in a state of flux at the moment it
might be an idea to lay a couple of DP issues to rest now. Afterall, much of
the duplication in Turbo was to try to overcome some of the limitations in
the original QDOS ROMs. Im thinking of things like EXECUTE_x and.. well, I
can remember just now (Im in a bit of a hurry). The place to compensate for
the differences between SBasic and SuperBasic is in their respective Turbo
toolkit extenstions.

I would stringly advise against using EXECUTE_x. The reason is that as they 
stand they make no allowance for parameter strings. EX, EW etc all increase the 
dataspace to accommodate any parameter string supplied, and the length can be 
up to 32K. The EXECUTE_x instructions do not make that allowance. It is 
therefore possible to overwrite the compiled program and probably several 
neighbouring ones as well by :

   a$=FILL$( ,32000)
   EXECUTE_W;a$

So, why not get rid of EXECUTE_xx, BASIC_xx and all that and try to 
simplify
things by reducing the number of different ways of achieving the same thing?
Sbasic has some 400+ commands already! and Turbo_tk_code has 111 commands.
Many people only use about 2000 words in their daily communications, so this
combination might imply that learning Sbasic and Turbo is only about 25% as
difficult as learning an entirely new language. Probably not a meaningful
comparison, but you catch my drift?


I certainly would not want to throw away BASIC_xx becasue they are used in 
parser_task itself! I am not sure why having several extensions doing the same 
thing (or nearly the same thing) is to be avoided. In GWASS I have several 
different names for the same command. For example ENDIF and END_IF are exactly 
equivalent.


There has been much talk of maintaining backward 

Re: [ql-users] Turbo v4g21

[Geogwilt]

In a message dated 28/04/05 19:44:51 GMT Daylight Time, 
[EMAIL PROTECTED] writes:

 
 Turbo is about to take off, I believe. Id recommend those who gave up on it
 many years ago to take a look at it now!
 
 

There is one more change that I have made. That is in the choice of stack 
size. EasyPtr and QPTR extensions need more stack than the 350 bytes default. 
You 
can at the moment configure codegen_task to give more, up to 2048. Marcel 
thinks that may not be enough. I myself don't much like having to re-configure 
codegen_task every time I want a different amount of stack. A large stack needs 
a large data space, which results in a bigger compiled program. The change I 
have made is to allow TURBO_objstk (a new Turbo TK Code extension) to set a 
default stack size which can be changed in Turbo's front panel. The size of 
stack 
can be set from 350 to 9998 bytes. This new version will require an update of 
Turbo TK code if TURBO_objstk is to be used, though the front panel can be 
used to set the stack without it.

I have also looked at PEEK(!! etc) which allow easy access to system 
variables and (PEEK(\\ etc) which allow access to S*BASIC areas. PEEK and POKE 
are 
dealt internally by Turbo which is much faster than calling the rom versions. 
It 
would not be easy to allow for the !! and \\ variations.

However, the system variables is found at SYS_VARS so a slightly extended 
PEEK parameter can replace PEEK(!! . .). Also Turbo TK Code has several 
BASIC_xxx 
functions which should cover a lot od the PEEK(\\ ...) ground.

I hope soon to send out Turbo v4h21.

George
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [ql-users] Turbo v4g21

[P Witte]

George Gwilt writes:

 There is one more change that I have made. That is in the choice of stack
 size. EasyPtr and QPTR extensions need more stack than the 350 bytes
default. You


Could the problems I mentioned to you in a private mail (lots of
inexplicable run-time errors) relate to this issue, do you think? I know, I
could just try and figure it out for myself ;) but Im shortly going away for
a week, and perhaps others are struggling with the same problem..

 I have also looked at PEEK(!! etc) which allow easy access to system
 variables and (PEEK(\\ etc) which allow access to S*BASIC areas. PEEK and
POKE are
 dealt internally by Turbo which is much faster than calling the rom
versions. It
 would not be easy to allow for the !! and \\ variations.

 However, the system variables is found at SYS_VARS so a slightly extended
 PEEK parameter can replace PEEK(!! . .). Also Turbo TK Code has several
BASIC_xxx
 functions which should cover a lot od the PEEK(\\ ...) ground.

Im aware of SYS_VARS and BASIC_xxx, but Turbo is supposed to be a S*Basic
compiler, not a language of its own (this is the nature of one of the
arguments I had with Freddy, who appeared to be arguing that it was
SuperBasic that was incompatible!)

I understand that this could be a wee bit problematic, as these variants
arent SuperBasic. However, Turbo is in a state of flux at the moment it
might be an idea to lay a couple of DP issues to rest now. Afterall, much of
the duplication in Turbo was to try to overcome some of the limitations in
the original QDOS ROMs. Im thinking of things like EXECUTE_x and.. well, I
can remember just now (Im in a bit of a hurry). The place to compensate for
the differences between SBasic and SuperBasic is in their respective Turbo
toolkit extenstions.

So, why not get rid of EXECUTE_xx, BASIC_xx and all that and try to simplify
things by reducing the number of different ways of achieving the same thing?
Sbasic has some 400+ commands already! and Turbo_tk_code has 111 commands.
Many people only use about 2000 words in their daily communications, so this
combination might imply that learning Sbasic and Turbo is only about 25% as
difficult as learning an entirely new language. Probably not a meaningful
comparison, but you catch my drift?

There has been much talk of maintaining backward compatibility with Qdos.
Also, lowering the threshhold for any potential newcomers (fat chance!)
would be great. Here is a chance of doing that.

The toolkit is something I would be willing to help with. (In fact I already
have written a toolkit or two to fill in some of the gaps between Qdos and
Smsqe.)

 I hope soon to send out Turbo v4h21.

Bring it on!

Per

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [ql-users] Turbo v4g21

[Geogwilt]

In a message dated 27/04/05 13:12:26 GMT Daylight Time, 
[EMAIL PROTECTED] writes:

 
 Marcel Kilgus writes:
 
 First of all I'd like to note that whatever feature I thought it
 would be cool if Turbo could do this Turbo could already do, one just
 has to read the documentation.
 
 Just is a pretty big word here ;) But you are right!
 

I wonder if anyone else thinks that the Turbo Manual is perhaps too long. I 
myself would like a condensed version of what it can do. I have tried to 
provide that for the additional features for which I was responsible in the 
Changes 
file.

 
 200 IF NOT(COMPILED) THEN
 210   LRESPR win1_easy_app_appman_cde
 220   LRESPR win1_easy_app_fapp_cde
 230   LRESPR win1_easy_app_mkapp_cde
 240   LRESPR win1_easy_app_qcfx001_cde
 250 END IF
 
 From my quick skim through the documentation Id say
 
 200 DEBUG 9
 210   LRESPR win1_easy_app_appman_cde
 220   LRESPR win1_easy_app_fapp_cde
 230   LRESPR win1_easy_app_mkapp_cde
 240   LRESPR win1_easy_app_qcfx001_cde
 250 DEBUG 0
 
 was much better, as that code would then not appear in the binary. Super!
 
 

I am glad that someone else has thought of using this technique which I use 
in Parser itself.


George
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [ql-users] Turbo v4g21

[Dilwyn Jones]

Something nice and terse for reference in true Tebby style would be 
handy
(too?) However, Im not volunteering.. (Nothing - as one of Dilwyn's
collections of sage sayings has it - is impossible for the man who 
doesnt
have to do it himself ;)
Don't. Reminds me too much of my boss at work.
--
Dilwyn Jones

--
Internal Virus Database is out-of-date.
Checked by AVG Anti-Virus.
Version: 7.0.308 / Virus Database: 266.9.18 - Release Date: 19/04/2005
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [ql-users] Turbo v4g21

[Dilwyn Jones]

Marcel Kilgus wrote:
 Just to see how Turbo developed I tried to compile EasyPtr's AppMan
 with it. I'd like to tell some of my quest in case anybody else wants
 to try it, too.
 
 First of all I'd like to note that whatever feature I thought it
 would be cool if Turbo could do this Turbo could already do, one just
 has to read the documentation.
This has been mentioned to me already. Many people using the current Turbo are 
working from memory or from DP's old documentation. So much has changed that 
you really need to download and familiarise with the new documentation. Some of 
the compiler directives were introduced by Chas Dillon in later versions of 
Turbo sold by Freddy of DP Ltd but generally not documented or only in readme 
files. AT some point, the various people who've been involved with the project 
to update Turbo and its documentation (David Gilham, Mark Knight, George Gwilt, 
Tim Swenson etc) have introduced new documentation for facilities which were 
either undocumented before or which have since been introduced in the compiler 
and toolkit by George, David and Mark Knight.

[snip]
 from a software
 engineer point of view I actually prefer the way Turbo works, because
 it can prevent bugs in the code. The downside is that some code
 probably needs to be rewritten, but usually it's sufficient to just
 rename some variables, so should not be that big a deal.
I think Freddy and Simon Goodwin said this to some extent in the past when 
people were critical that Turbo was stricter and less changes were needed for a 
QLib compiled program. As you say, although Turbo is stricter, once you get 
used to it, you start to appreciate it does make for better programming in the 
end.

Above all, George is improving Turbo at such a rate and QLiberator is not being 
updated at the moment, plus Turbo is free of course, so it will soon be a 
potential replacement for QLiberator. I will be watching this with interest, I 
make heavy use of QLiberator+Easyptr so once I feel Turbo can compile my 
programs and I have familiarised enough with the new facilities it's quite 
likely I'll look at using Turbo to compile easyptr apps.

 I hope this description might help some people get a start with Turbo,
 I personally am not a big Basic programmer myself but it looks to me
 as though Turbo gets ready for prime time.
Indeed. The time and thought you've clearly put into this one subject alone is 
greatly appreciated. The level of work you've put into Easyptr and which George 
has put into Turbo and its companion programs is fantastic. You both seem 
unable to resist challenges!

Dilwyn Jones

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [ql-users] Turbo v4g21

[P Witte]

Marcel Kilgus writes:

 First of all I'd like to note that whatever feature I thought it
 would be cool if Turbo could do this Turbo could already do, one just
 has to read the documentation.

Just is a pretty big word here ;) But you are right!


 200 IF NOT(COMPILED) THEN
 210   LRESPR win1_easy_app_appman_cde
 220   LRESPR win1_easy_app_fapp_cde
 230   LRESPR win1_easy_app_mkapp_cde
 240   LRESPR win1_easy_app_qcfx001_cde
 250 END IF

From my quick skim through the documentation Id say

200 DEBUG 9
210   LRESPR win1_easy_app_appman_cde
220   LRESPR win1_easy_app_fapp_cde
230   LRESPR win1_easy_app_mkapp_cde
240   LRESPR win1_easy_app_qcfx001_cde
250 DEBUG 0

was much better, as that code would then not appear in the binary. Super!
 
Per
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

[ql-users] Turbo v4g21

[Marcel Kilgus]

Just to see how Turbo developed I tried to compile EasyPtr's AppMan
with it. I'd like to tell some of my quest in case anybody else wants
to try it, too.

First of all I'd like to note that whatever feature I thought it
would be cool if Turbo could do this Turbo could already do, one just
has to read the documentation.

It's for example very convenient that all compiler settings can be
specified in the BASIC program itself. It pissed me off to no end that
I couldn't specify the No winds option, or the job name in
Qliberator on a per-program basis. With Turbo it's all there:

100 TURBO_objfil 'ram1_appman' - name of resulting EXE file
110 TURBO_taskn 'APPMan4'  - job name
120 TURBO_diags 2
130 TURBO_windo 0  - No winds
140 TURBO_objdat 32- Dataspace size
150 TURBO_buffersz 64
160 REMark %%win1_easy_app_appman_cde,4,82
170 REMark %%win1_easy_app_fapp_cde,0,4
180 REMark %%win1_easy_app_mkapp_cde,0,10
190 REMark %%win1_easy_app_qcfx001_cde,0,10
200 IF NOT(COMPILED) THEN
210   LRESPR win1_easy_app_appman_cde
220   LRESPR win1_easy_app_fapp_cde
230   LRESPR win1_easy_app_mkapp_cde
240   LRESPR win1_easy_app_qcfx001_cde
250 END IF

The REMark lines will be quite familiar to QLiberator users and they
work exactly the same as $$asmb.

With the settings all in the basic file a simple charge , command
will automatically compile and create the resulting EXE file.

Another feature that I missed for example in Qliberator was support
for hexadecimal values using the $ notation. I thought I should
probably ask George to include support for them. Once again, after
browsing the changes files I saw that Turbo already supports them...

After that AppMan did already start, but when trying to access the
Files menu the line
 1760   MITEM#wdef1,-9,,appnum$
gave an error not found. Changing it to
 1760   MITEM#wdef1,-9,0,appnum$
helped, so not much of a problem, but I've told George about it
and he has fixed it in 4e21.

After this the files menu opened up, I could select something, the
file select menu opened up, it loaded the appendix and then booom,
another problem. Turned out some variable values were really messed
up. To make a very long story short: the application did simply run
out of stack space on the file select call and subsequently
overwrote some variables of the program. If you do compile programs
for EasyPtr, make sure to crank up the stack by configuring
codegen_task to a higher value (using MenuConfig). 1024 should be
pretty safe, but 2048 can't do any harm either.
In any case, Turbo was working correctly, tough a higher default value
might be in order.

After THAT I could load an appendix and... Sysmon went mad about a
memory corruption. God, those are hard to track down! To make an
equally long story short, Appman simply had a bug that corrupted the
heap! Why it didn't show up in SBasic or in the Qliberated version I
don't know, probably chance, but once again Turbo was just fine.

After that there was a problem with the MINPUT function of EasyPtr. It
has to do with the way Turbo handles strings (only fixed dimensioned
strings which EasyPtr didn't accept) but I could easily make the
EasyPtr Basic extension compatible, so that's fine then, too. Please
note that this EasyPtr version has not yet been released but might be
acquired if you really need it.

And that really was all of it, Appman works now as fine with Turbo as
it did with Qlib, so I think it's really time for you to check out
Turbo, too. ;-)

This was all some weeks ago, today I did a quick check of the array
slicing and it seemed to work perfectly well, too! Well done.

One more thing, I tried to compile a very large EasyPtr program with
Turbo and got hundreds of errors. The reason being that the same
variable names sometimes had different definitions, like

100 DIM a$(10,10): REMark a$ two dimensional
110 Test
120 :
130 DEFine PROCedure Test
140   LOCal a$: REMark a$ is one-dimensional
150   a$=xyz
160   PRINT a$
170 END DEFine

This will be honoured by Turbo with the error

 ERROR at 100: Ambiguous declaration of name.

and some errors

 ERROR at 150: Ambiguous name used.

The reason is simple, consider the extended version of this program

100 DIM a$(10,10)
110 Test
120 Test2
130 :
140 DEFine PROCedure Test
150   LOCal a$
160   a$=xyz
170   PRINT a$
180   Test2
190 END DEFine
200 :
210 DEFine PROCedure Test2
220   PRINT a$
230 END DEFine

I guess Turbo cannot know what code to produce for Test2. When called
from line 120, a$ is two-dimensional, when called from Test, a$ is
one- dimensional. SBasic handles this at runtime, but from a software
engineer point of view I actually prefer the way Turbo works, because
it can prevent bugs in the code. The downside is that some code
probably needs to be rewritten, but usually it's sufficient to just
rename some variables, so should not be that big a deal.

I hope this description might help some people get a start with Turbo,
I 

Re: [ql-users] Turbo v4g21

[Geogwilt]

In a message dated 25/04/05 01:49:17 GMT Daylight Time, 
[EMAIL PROTECTED] writes:

 
 Spurred by Per, I have produced a version of Turbo which allows slicing of
 arrays used as parameters of machine code extensions.
 
 Turbo v4g21 should be on the SQLUG site in a few days.
 
 When you say spurred I hope you mean encouraged rather than bullied ;)
 

Certainly encouraged. The more difficult a project appears to be the more 
it appeals to me.

George
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

[ql-users] Turbo

[jms1]

Experimental version version 4g21 is on the site for downloading
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [ql-users] Turbo v4g21

[P Witte]

George Gwilt writes:

  Spurred by Per, I have produced a version of Turbo which allows slicing
  of arrays used as parameters of machine code extensions.
  
  Turbo v4g21 should be on the SQLUG site in a few days.
 
  When you say spurred I hope you mean encouraged rather than
  bullied ;)

 Certainly encouraged. The more difficult a project appears to be the
 more it appeals to me.

Last week I tried Turbo again, but most of my programs woudnt compile due to
the lack of array slicing. However, those were the only errors that showed
up, so Im really hopeful ;)

Per

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

[ql-users] Turbo v4g21

[Geogwilt]

Spurred by Per, I have produced a version of Turbo which allows slicing of 
arrays used as parameters of machine code extensions.

Turbo v4g21 should be on the SQLUG site in a few days.

George
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [ql-users] Turbo v4g21

[P Witte]

George Gwilt writes:

 Spurred by Per, I have produced a version of Turbo which allows slicing of
 arrays used as parameters of machine code extensions.

 Turbo v4g21 should be on the SQLUG site in a few days.

When you say spurred I hope you mean encouraged rather than bullied ;)

Looking forward to try it out!

Per

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

[ql-users] Turbo Compiler

[jms1]

The latest beta version passing parameters by reference is available on the
site.

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [ql-users] Turbo v4b21

[gwicks]

- Original Message - 
From: Phoebus R. Dokos ( . )
To: [EMAIL PROTECTED]
Sent: Sunday, March 20, 2005 2:07 AM
Subject: Re: [ql-users] Turbo v4b21

As for EasyPTR... :-) I personally don't care :-) Although I do think it 
works... sort of (Ask Rich for details. I think he's using a part of 
EasyPTR for QWord)

It is possible to compile some EasyPtr programs with Turbo. I have done it. 
However, there is a big restriction and that is that Turbo cannot compile 
EasyPtr programs that contain Application Window Menus.

I forget the technical point now, but is similar to the fact that you can 
compile a simple RESTORE command in Turbo, but not a RESTORE with a 
variable. (I.e. RESTORE 1000 is possible , but not RESTORE 1000+x). George 
once explained the reason for this, but I don't  really understand it.

The bad news is that there is unlikely to be a way of fixing it,
Best Wishes,
Geoff 

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [ql-users] Turbo v4b21

[P Witte]

Ffibys writes:

  I need a break from testing software as Ive got some pressing stuff of
my
  own to do, but Im very interested to hear how this goes. The day Turbo
  can be used with EasyPtr I may jump ship..
 
  Per

 Passing by reference works RIGHT now (Q-Word is working with that :-)

 Ffibys

 As for EasyPTR... :-) I personally don't care :-) Although I do think it
 works... sort of (Ask Rich for details. I think he's using a part of
 EasyPTR for QWord)

I only mentioned EasyPtr as this would make a good test of compatibility.
The same applies to Qptr, of course. Use Tptr! I hear you say. My only
complaint of Tptr, over and above the issues I mentioned regarding Qptr, is
the nomenclature. It is unlearnable due to the way my brain is configured.

Per

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

[ql-users] Turbo v4b21

[Geogwilt]

I have produced a second testing version of Turbo. This should shortly be on 
the SQLUG site.

This version of Turbo corrects a fault in the earlier version which occurred 
with a program using MANIFEST. The new version, as did the previous one, 
allows parameters to be passed by reference so that new values can be set by 
the 
machine code routine. It also allows the passing of arrays to machine code 
procedures and functions.

I would be glad of any feedback so that a final version can be produced.

George
___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm

Re: [ql-users] Turbo v4b21

[Phoebus R. Dokos]

On Sun, 20 Mar 2005 01:13:27 -, P Witte [EMAIL PROTECTED]  
wrote:

George Gwilt writes:
I have produced a second testing version of Turbo. This should shortly  
be
on
the SQLUG site.
This version of Turbo corrects a fault in the earlier version which
occurred
with a program using MANIFEST. The new version, as did the previous one,
allows parameters to be passed by reference so that new values can be
set by the
machine code routine. It also allows the passing of arrays to machine  
code
procedures and functions.

I would be glad of any feedback so that a final version can be produced.
If (when) this works it will remove a major deterrent to using Turbo  
(theres
still the Vaccha-effect to overcome, but that should be minor in the  
scale
of things ;)

I need a break from testing software as Ive got some pressing stuff of my
own to do, but Im very interested to hear how this goes. The day Turbo  
can
be used with EasyPtr I may jump ship..

Per
Passing by reference works RIGHT now (Q-Word is working with that :-)
Ffibys
As for EasyPTR... :-) I personally don't care :-) Although I do think it  
works... sort of (Ask Rich for details. I think he's using a part of  
EasyPTR for QWord)

___
QL-Users Mailing List
http://www.q-v-d.demon.co.uk/smsqe.htm