Re: [Ql-Users] TYPE_IN

[Lee Privett via Ql-Users]

Thanks guys and especially to Michael, and to his last few questions.
Firstly I placed the query (cut down) to avoid a lengthy and possibly
boring explanation
I am periodically (while I can) in pre-production of a lengthy project that
I have dabbled in over the last two years and as I think about aspects of
the project, mini projects pop into mind. These result in functions or
procedures that I test out and if useful, I publish in QUANTA.

One such project is so large that the programming for it has to be fairly
rigorously planned out, which amongst other things includes plenty of REM
statements.
So I am writing a procedure called AutoREM which asks two questions, what
line to start at (An) and what it is all about (Final$), it will then
create REM statements and eventually DEF PROC and END PROC lines
automatically, all within the SMSQ/e environment. Specifically at the
moment QPC2. Although not compiled a version of this will be used in the
"big project" which will be.

I hope that satisfies your intrigueness (not a real word) Michael.

Lee



Lee




On Wed, Oct 4, 2017 at 9:42 AM, Michael Bulford via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Hi all,
>
>
> I am hoping now to explain what is going on.  First, here is some code
> that does work ..
>
> 100 DIM Top$  (100) : Top$   = "REMark " & FILL$( "*"  ,20)
> 110 DIM Final$(100) : Final$ = "REMark " & FILL$("text",20)
> 120 An = 2
> 1920 TYPE_IN An&":"$(10)
> 1930 TYPE_IN (An+1)$$(10)
> 1932 TYPE_IN (An+2)$$(10)
> 1940 TYPE_IN (An+3)$$(10)
> 1950 TYPE_IN "CLS#2:LIST"$(10)
> 1960 PRINT #0,"Program completed successfully"
>
> After running the above code, you may notice that the “completed” message
> does not appear.
> To explain why, we have to consider how this code works.  If this code is
> compiled, then SuperBASIC will act immediately upon each of the TYPED_IN
> commands.  Under the Interpreter, they will not be acted upon, but will get
> to be stored in #0’s buffer.  After the “completed” message gets printed to
> #0, the code comes to an end, and the SuperBASIC cursor comes back to
> life.  The contents of the #0 buffer then gets entered into the command
> line, and will be acted upon, scrolling the “completed” message out of the
> way.
>
> Now consider what can happen if we change the first line to read
> FILL$(“*”,60).  Running the code again with this larger figure will lead to
> it “locking up”, with nothing apparently happening.  What has happened is
> that #0’s buffer has become full, and it is waiting there for some
> characters to be removed, which never happens.  The only thing to do is to
> press Ctrl-SPACE and Ctrl-c to abort.
>
> As long as the buffer length of 128 bytes is not exceeded during a
> TYPE_IN, all should be well.
> Each TYPE_IN will need to be made separately, with the QL stopping, then
> continuing.
> The need to STOP is necessary to force the #0 buffer to empty its contents.
> Notice that we do not STOP if COMPILED, as doing that would remove the
> task.
> Here is the same code as above with these amendments …
>
> 100 DIM Top$  (100) : Top$   = "REMark " & FILL$( "*"  ,60)
> 110 DIM Final$(100) : Final$ = "REMark " & FILL$("text",60)
> 120 An = 2
> 1920 TYPE_IN An&":"$(10)   :IF NOT COMPILED:TYPE_IN
> "CONTINUE"$(10):STOP
> 1930 TYPE_IN (An+1)$$(10)  :IF NOT COMPILED:TYPE_IN
> "CONTINUE"$(10):STOP
> 1932 TYPE_IN (An+2)$$(10):IF NOT COMPILED:TYPE_IN
> "CONTINUE"$(10):STOP
> 1940 TYPE_IN (An+3)$$(10)  :IF NOT COMPILED:TYPE_IN
> "CONTINUE"$(10):STOP
> 1950 TYPE_IN "CLS#2:LIST"$(10) :IF NOT COMPILED:TYPE_IN
> "CONTINUE"$(10):STOP
> 1960 PRINT #0,"Program completed successfully"
>
> The above code works as expected in SMSQ/E.  It should not work under QDOS
> as after entering any new line in the code, QDOS will lose its place and
> would not be able to continue.  For QDOS it is best to compile the code.
> Another point to bear in mind is that any line TYPED_IN with invalid syntax
> will lead to the SuperBASIC cursor being re-entered to enable the faulty
> line to be edited.  There is a simple way to cope with this condition, by
> starting each TYPE_IN with a CHR$(27) - the Escape key.
> This kind of code can be far easier to write and get working if it is
> compiled with Turbo.  After any TYPE_IN to SuperBASIC, Turbo could wait in
> the background, in a loop, monitoring the SuperBASIC cursor position, and
> determining whether the typed-in line was successful or not.  This
> arrangement would allow the user to correct the command line and press
> ENTER.  Only when everything is okay could Turbo decide to exit the loop
> and continue.  If the 128-character limit is too restrictive, one could use
> a temporary MERGE file instead of using TYPE_IN.
>
> This discussion would be more entertaining if we had more details of what
> is trying to be achieved.
> What is being used? - The QL, Q-emuLator or QPC2? - also is this
> compiled?  I notice that each TYPE_IN starts with an integer, which would
> mean that lines 

Re: [Ql-Users] TYPE_IN

[Lee Privett via Ql-Users]

Yes the string is about 60 characters long which is probably why it fails
on the third TYPE_IN

tried using Pause to no effect :(

Lee





Virus-free.
www.avast.com

<#m_2324895060461743699_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Lee




On Sat, Sep 30, 2017 at 12:38 PM, Wolfgang Lenerz via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Hi,
>
> I have a slight problem with TYPE_IN
>>
>> Using it to put some commands in #0, works well in an instance until I
>> reach what appears to be a maximum set of characters, where the QL just
>> hangs.
>>
>> e.g.
>>
>> 1920  TYPE_IN An&":"$(10)
>> 1930  TYPE_IN (An+1)$$(10)
>> 1932  TYPE_IN (An+2)$$(10)
>> 1940  TYPE_IN (An+3)$$(10)
>>
>>
>> An is an integer
>> Final$ is just text
>> Top$ is a string of asterisks
>>
>> it locks up displaying halfway through 1940
>>
>> Is there a buffer I can clear after using TYPE_IN?
>>
>
> How long i the string in line 194?
>
> IIRC, the Ql's keyboard buffer is 128 bytes long... You cannot increase
> this, AFAIK.
>
> I don't think you can clear this.
> Perhaps a pause after the earlier TYPE_In instructions will leave the
> system time to clear it.
>
>
>
> HTH
>
> Wolfgang
>
> ___
> QL-Users Mailing List
>
___
QL-Users Mailing List

[Ql-Users] TYPE_IN

[Lee Privett via Ql-Users]

Fellow QL'ers

I have a slight problem with TYPE_IN

Using it to put some commands in #0, works well in an instance until I
reach what appears to be a maximum set of characters, where the QL just
hangs.

e.g.

1920  TYPE_IN An&":"$(10)
1930  TYPE_IN (An+1)$$(10)
1932  TYPE_IN (An+2)$$(10)
1940  TYPE_IN (An+3)$$(10)


An is an integer
Final$ is just text
Top$ is a string of asterisks

it locks up displaying halfway through 1940

Is there a buffer I can clear after using TYPE_IN?

or can I increase the length of the number of characters TYPE_IN can use?

Many thanks in anticipation

Lee





Virus-free.
www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
QL-Users Mailing List

Re: [Ql-Users] Q68 Advanced Notice

[Lee Privett via Ql-Users]

Put me down for one
Regards Lee
On Sat, 2 Sep 2017 at 09:52, Derek Stewart via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Q68 Advanced Notice
> ---
>
> PCB Photograph available at:
>
> http://qlforum.co.uk/viewtopic.php?f=2=2082#p18729
>
> Features:
>
> - Operating System: SMSQ/E
> - CPU: 68000 compatible
> - Speed: 40Mhz
> - RAM: 32 MB
> - SDHC: Two fullsize slots, hot plugging
> - QXL.WIN style storage container format
> - Keyboard and mouse: Combined PS/2 Connection, scrollwheel support
> - VGA: 1024x768 VESA for flatscreen, CRT or HDMI converter
> - Graphic modes:
>  -  256x256 QL Mode 8
>  -  512x256 QL Mode 4
>  -  512x256 Q60 65536 colour
>  - 1024x512 Q60 65536 colour
>  - 1024x768 QL Mode 4
>  -  512x384 Q60 65536 colour
> - Serial port
> - Stereo sampled sound, 3.5 mm output socket
> - Buffered real time clock
> - I2C interface
> - Ethernet, no software support yet
> - QL style LED colours
> - PCB Size: 8x10 cm
> - Recommended power supply: 5V @ 1A
> - Silent operation, no fans or heat
> - Case: Optional
>
> Available: Mid October 2017
> Price: To be decided
> ___
> QL-Users Mailing List
>
___
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 thi

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

[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

Re: [Ql-Users] Bill Newell

[Lee Privett via Ql-Users]

Please send our wishes John, my own father in law suffers from Alzheimers
Disease as well as advance bowel cancer and I, as one of his carers know
too well the effects this terrible disease has on the person and their
loved ones.

regards
Lee Privett

Lee




On Mon, Jun 5, 2017 at 4:18 PM, John Taylor via Ql-Users <
ql-users@lists.q-v-d.com> wrote:

> Bill Newell is ill.
>
> I have tried to avoid pestering Babs, Mrs Newell, but today I called her
> and asked for an update.
> As it stands at present.
> Mental Health.  Still very poor due to Alzheimers Disease.
> Babs say that on very rare occasions ,Bill does recognise her, but the
> recognition does not last above a few minutes.
>
> Physical Health. There is no concern now with Sepsis. The Antibiotics
> worked.
> However Bill must remain bed ridden.
> When ever he leaves his bed, if only to stand, his Blood Pressure crashes
> down, so the medics have decided, permanent bed.
> No one has offered any explanation.
>
> I will try to get to Bill, currently in a Nursing Home, when I can get
> some support from my family.
> I do not drive now as my eyesight is lacking and I expect the visit will
> require a full day, most of it spent travelling.
>
> I hope I can keep you informed of Bill’s wellbeing in the future.
>
> All the best.
>
> John Taylor.
> ___
> QL-Users Mailing List
___
QL-Users Mailing List