[Ql-Users] (no subject)
Ql    https://bitly.com/3v6iFgH     Michael Bulford  ___ QL-Users Mailing List
Re: [Ql-Users] Select on
If we are talking about Selecting on single-character strings, such as when coding actions depending on some keypress, I would like to tell you about how I get around this problem. At the very beginning, I would declare some constants of the codes of all the alphabetical characters, all 52 of them. Underscores are used in the names to highlight these vars are constants and their initial values should not change. I will give what the code would look like under Minerva, and then how this would look in SMSQ/E. Note that when Selecting on strings, both cases, capitals and lower case letters are considered equivalent. This has to be taken into account. 100 : 110 : 120 REMark In Minerva SuperBASIC 130 case$ = "" : REMark "a" == "A" - both cases 140 SELect ON case$ 150 = "a" : PRINT 'Choice is "A"' 160 = "b" : PRINT 'Choice is "B"' 170 = "c" : PRINT 'Choice is "C"' 180 = "d" : PRINT 'Choice is "D"' 190 = "e" : PRINT 'Choice is "E"' 200 = "f" : PRINT 'Choice is "F"' 210 = CHR$(27) : PRINT 'Esc pressed' 220 END SELect 230 : 2000 REMark In SMSQ/E S*BASIC 2010 REMark Note: MANIFEST is optional TURBO command for extra constant checking 2020 : 2030 MANIFEST : _a = 97 : A_ = 65 2040 MANIFEST : _b = 98 : B_ = 66 2050 MANIFEST : _c = 99 : C_ = 67 2060 MANIFEST : _d = 100 : D_ = 68 2070 MANIFEST : _e = 101 : E_ = 69 2080 MANIFEST : _f = 102 : F_ = 70 2090 MANIFEST : ENTER = 10 : Esc = 27 2100 CLS 2110 REPeat loop 2120 PRINT 'Choose case: Press a letter between "a" and "F" '; 2130 case = CODE(INKEY$(#1,-1)) : IF case <> ENTER : PRINT CHR$(case); " "; 2140 SELect ON case 2150 = _a,A_ : PRINT 'Choice is "A"' 2160 = _b,B_ : PRINT 'Choice is "B"' 2170 = _c,C_ : PRINT 'Choice is "C"' 2180 = _d,D_ : PRINT 'Choice is "D"' 2190 = _e,E_ : PRINT 'Choice is "E"' 2200 = _f,F_ : PRINT 'Choice is "F"' 2210 = Esc : PRINT 'Esc pressed' : EXIT loop 2220 = REMAINDER : PRINT 'Try again' 2230 END SELect 2240 END REPeat loop 2250 PRINT 'Test complete' 2260 PRINT #0,'Test complete' Michael ___ QL-Users Mailing List
Re: [Ql-Users] Select on
If we are talking about Selecting on single-character strings, such as when coding actions depending on some keypress, I would like to tell you about how I get around this problem. At the very beginning, I would declare some constants of the codes of all the alphabetical characters, all 52 of them. Underscores are used in the names to highlight these vars are constants and their initial values should not change. I will give what the code would look like under Minerva, and then how this would look in SMSQ/E. Note that when Selecting on strings, both cases, capitals and lower case letters are considered equivalent. This has to be taken into account. 100 : 110 :120 REMark In Minerva SuperBASIC130 case$ = "" : REMark "a" == "A" - both cases140 SELect ON case$150 = "a" : PRINT 'Choice is "A"'160 = "b" : PRINT 'Choice is "B"'170 = "c" : PRINT 'Choice is "C"'180 = "d" : PRINT 'Choice is "D"'190 = "e" : PRINT 'Choice is "E"'200 = "f" : PRINT 'Choice is "F"'210 = CHR$(27) : PRINT 'Esc pressed'220 END SELect230 :2000 REMark In SMSQ/E S*BASIC2010 REMark Note: MANIFEST is optional TURBO command for extra constant checking2020 :2030 MANIFEST : _a = 97 : A_ = 652040 MANIFEST : _b = 98 : B_ = 662050 MANIFEST : _c = 99 : C_ = 672060 MANIFEST : _d = 100 : D_ = 682070 MANIFEST : _e = 101 : E_ = 692080 MANIFEST : _f = 102 : F_ = 702090 MANIFEST : ENTER = 10 : Esc = 272100 CLS2110 REPeat loop2120 PRINT 'Choose case: Press a letter between "a" and "F" ';2130 case = CODE(INKEY$(#1,-1)) : IF case <> ENTER : PRINT CHR$(case); " ";2140 SELect ON case2150 = _a,A_ : PRINT 'Choice is "A"'2160 = _b,B_ : PRINT 'Choice is "B"'2170 = _c,C_ : PRINT 'Choice is "C"'2180 = _d,D_ : PRINT 'Choice is "D"'2190 = _e,E_ : PRINT 'Choice is "E"'2200 = _f,F_ : PRINT 'Choice is "F"'2210 = Esc : PRINT 'Esc pressed' : EXIT loop2220 = REMAINDER : PRINT 'Try again'2230 END SELect2240 END REPeat loop2250 PRINT 'Test complete'2260 PRINT #0,'Test complete' Michael ___ QL-Users Mailing List
Re: [Ql-Users] QED v2.01 released!
* TAB compression and expansion supported * Raw and cooked LOADing and SAVing of files for CR/LF conversion Hi Jan, Many thanks, this is highly welcome.I use your software quite a lot. Michael ___ QL-Users Mailing List
Re: [Ql-Users] QPC2 4.04 BUG (RWAP Software)
> Does anyone know why the following in QPC2 reports "Invalid Channel ID" > > WINDOW 448,200,32,16 > PAPER #1,3 >> In fact, any attempt to change #1 after the WINDOW command reports an > invalid channel.>> I also found some of the character combinations were not > working in > v4.04 (eg CTRL SHIFT - did not produce a down arrow). > That also now works in v4.05 but CTRL \ does not produce the left arrow > still. Hi, I am using both QPC2 4.04 SMSQE/E 3.26 and also QPC2 4.05 > SMSQE/E 3.31.They both seem to work the same.I cannot replicate any of the > errors mentioned, except that I cannot produce the left arrow. As Dilwyn > points out, doing an OPEN #1, would do an automatic CLOSE #1 first, and > perhaps that has caused the problems. > On QPC2 v4.04 here I didn't have > to close anything - I just entered the > two commands above as soon as it started Perhaps there is something in > the Boot file causing the issue? Michael ___ QL-Users Mailing List
Re: [Ql-Users] EXT_PROC
On Wed, 8 Nov 2017 21:05:55, Per Witte wrote: > I was just made aware of a number of features in Q-Lberator that I havent > seen documented anywhere: EXT_PROC, EXT_FN, GLOBAL, and possibly others. I > believe I have a general idea of what theyre about, but should like to see > some documentation. Ive been told there is a chapter 14 in some manuals? > The two pdf manuals I found online, one of them claiming to be of V3.36, > dont mention these keywords, and my printed one is altogether of an older > vintage. Hi Per, See this link .. http://www.dilwyn.me.uk/qlib/index.html There are a couple of v3.36 manuals that clearly document these EXT_FN, EXT_PROC and GLOBAL keywords. They might not work as expected on QPC2, as SMSQ/E is being used. But these should work on Q-emulator. Michael ___ QL-Users Mailing List
Re: [Ql-Users] CPORT
Hi Norman, I have both CPORT and CFIX. I find that CFIX doesn't work correctly in QPC2, so to get around that problem, I use Q-emulator for that one. CPORT does work well in QPC2, provided that memory is limited to 16M. There's also some other related files. I'll dig them out. How can I get them to you? Kind regards, Michael ___ QL-Users Mailing List
Re: [Ql-Users] TYPE_IN
Hi Lee,
Yes, I am most satisfied, thanks so much, yours is a very nice reply.
I was thinking first off perhaps you was up to doing some SBASIC
self-modifying code - I wonder if anyone has ever tried this. There
could be some instances where doing this could make the code more
efficient - who knows?
It turns out though you are using this for REM statements - apparently
simple stuff. Nevertheless these ideas that start out being easy in nature
can sometimes produce lots of bugs. It can be very nerve-wracking at
times. We write code to do something in particular - and it doesn't work,
and can take ages to fathom out. Anyway, I hope my attempts at trying
to resolve this particular issue turns out to be helpful.
All the best,
Michael
> On Wed, 4 Oct 2017 at 10:49, Lee Privett wrote:
> 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&":"&CHR$(10)
> > 1930 TYPE_IN (An+1)&Top$&CHR$(10)
> > 1932 TYPE_IN (An+2)&Final$&CHR$(10)
> > 1940 TYPE_IN (An+3)&Top$&CHR$(10)
> > 1950 TYPE_IN "CLS#2:LIST"&CHR$(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&":"&CHR$(10) :IF NOT COMPILED:TYPE_IN
> > "CONTINUE"&CHR$(10):STOP
> > 1930 TYPE_IN (An+1)&Top$&CHR$(10) :IF NOT COMPILED:TYPE_IN
> > "CONTINUE"&CHR$(10):STOP
> &
Re: [Ql-Users] TYPE_IN
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&":"&CHR$(10)
1930 TYPE_IN (An+1)&Top$&CHR$(10)
1932 TYPE_IN (An+2)&Final$&CHR$(10)
1940 TYPE_IN (An+3)&Top$&CHR$(10)
1950 TYPE_IN "CLS#2:LIST"&CHR$(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&":"&CHR$(10) :IF NOT COMPILED:TYPE_IN
"CONTINUE"&CHR$(10):STOP
1930 TYPE_IN (An+1)&Top$&CHR$(10) :IF NOT COMPILED:TYPE_IN
"CONTINUE"&CHR$(10):STOP
1932 TYPE_IN (An+2)&Final$&CHR$(10):IF NOT COMPILED:TYPE_IN
"CONTINUE"&CHR$(10):STOP
1940 TYPE_IN (An+3)&Top$&CHR$(10) :IF NOT COMPILED:TYPE_IN
"CONTINUE"&CHR$(10):STOP
1950 TYPE_IN "CLS#2:LIST"&CHR$(10) :IF NOT COMPILED:TYPE_IN
"CONTINUE"&CHR$(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
are being added to SuperBASIC.
This is indeed intriguing!
Michael
___
QL-Users Mailing List
Re: [Ql-Users] TYPE_IN
> 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&":"&CHR$(10) > 1930 TYPE_IN (An+1)&Top$&CHR$(10) > 1932 TYPE_IN (An+2)&Final$&CHR$(10) > 1940 TYPE_IN (An+3)&Top$&CHR$(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 If this is a compiled Turbo program, then there should be no problems as each of the typed-in commands would be processed separately. Running this under the Interpreter is slightly different. Each of the typed-in commands will only get to be processed once the SuperBASIC program has come to a stop. Before this stop happens, everything typed in to SuperBASIC's #0 will be stored in #0's buffer. If there are many commands to be processed, then this buffer could be exceeded, resulting in one of the commands being truncated and the remainder being lost. There is a simple way to overcome this problem. The program can be deliberately stopped after each of the TYPE_INs, and then be made to continue afterwards. To get the program to stop, use the STOP command, and to get the program to continue, use the CONTINUE command. This idea can be implemented by extending each of the TYPE_IN commands in the program, as follows .. : IF NOT COMPILED : TYPE_IN "CONTINUE" & CHR$(10) : STOP Notice the STOP command at the end. This is important and is the secret. The STOP command stops the program and allows the typed_in command to execute, after which the CONTINUE command causes the program to continue. By doing it this way, all commands will be executed separately, similar to how a compiled program would work. Lee, can you please try the above suggestion and let us know how you get on. Best wishes, Michael ___ QL-Users Mailing List
Re: [Ql-Users] Lear PCB Design v7.55
On Mon, 18 Sep 2017 at 14:26, Dilwyn Jones wrote: > A new update of Malcolm Lear's PCB Design is available from the Graphics page > on my website. Details of the little bug fix in the REVISIONS.TXT file. > > version 7.55 Fixed 1 mil offset correction for snake shape with odd offset. > > download free of charge from http://www.dilwyn.me.uk/graphics/index.html > > Dilwyn Sorry - I meant line 31850, this hasn't been called - the procedure FreeRotate. Michael ___ QL-Users Mailing List
Re: [Ql-Users] Lear PCB Design v7.55
On Mon, 18 Sep 2017 at 14:26, Dilwyn Jones wrote: > A new update of Malcolm Lear's PCB Design is available from the Graphics page > on my website. Details of the little bug fix in the REVISIONS.TXT file. > > version 7.55 Fixed 1 mil offset correction for snake shape with odd offset. > > download free of charge from http://www.dilwyn.me.uk/graphics/index.html > > Dilwyn I have noticed that the procedure FreeRotate, defined at line 1850, is never called. - Just thought I'd point this out. Michael ___ QL-Users Mailing List
Re: [Ql-Users] Function type error
> > On 7 Sep 2017 at 15:15, George Gwilt wrote: > > > > Subject: Re: [Ql-Users] Function type error > > > > On 10 Aug 2017, at 22:49, Michael Bulford via Ql-Users > > wrote: > > > > Thanks for your explanations. This is all specific to SBASIC. > > Tobias gives an example with a LOCal name the same as the function name. > > Although this is possible, it cannot be recommended. You will not be able > > to call the function recursively. And it won't compile with either > > QLiberator or Turbo! > > Actually TURBO does compile the program and gives the answer 331. > > George Indeed, yes. I've also tested this with Minerva on Q-emuLator. Both under the Interpreter and Turbo, the result is again 331. However, Q-Liberator gives only 330.7 With both compilers now free, and with more and more people using them, it should follow that these functions need to be written with greater care in the future. Michael ___ QL-Users Mailing List
Re: [Ql-Users] TURBO and testing it exists
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] EXEP_W
On Wed, 16 Aug 2017, Duncan wrote: Question : are you using QDOS or smsqe? with smsqe it should be possible to create a wrapper basic executable program that will EXEP "task; parameters" then continue to run and check the jobs list (you will know the task name) until the task it EXEP has finished before continuing with what you want to do next. Hi Duncan, Thanks for your suggestion, I did think of that idea. Also, I have found FEP(...) which returns the id of the job created. So, I'm guessing I could do something along these lines ... id = FEP(etc) REPeat wait SUSPEND_TASK 25 IF PJOB(id)=0 : IF OJOB(id)=0 : IF JOB$(id)="" : EXIT wait END REPeat wait I haven't tried this yet. Doing it this way, the task name would not need to be known. Michael ___ QL-Users Mailing List
[Ql-Users] EXEP_W
Hi, I am wanting to use EXEP some_turbo_task; arg$, "i", "u" and then wait until that job completes before continuing. Is there such a command that does this? If not, then how can this be implemented? Any ideas please Michael ___ QL-Users Mailing List
Re: [Ql-Users] Function type error
Thanks for your explanations. This is all specific to SBASIC. Tobias gives an example with a LOCal name the same as the function name. Although this is possible, it cannot be recommended. You will not be able to call the function recursively. And it won't compile with either QLiberator or Turbo! Michael On Thu, 10 Aug 2017 20:33:58, Tobias Fr?schle via Ql-Users wrote: The type of a function is not determined by the function name ending in a $ or % sign, but rather by what it returns - You can even write a function STRING% that returns a string or a function a$ that returns an integer value. The name you give your function is simply a hint to yourselves on what it might return. What you actually return in your original function is the result of an /expression/ - and numerical expressions in S*BASIC are of type floating point. If you assign the value to the expression to a LOCal integer value and return that, you will actually get your desired result. 1000 DEFine FuNction x% (param) 1010 LOCal x% 1020 x% = param / 10 1025 REMark assign to integer variable x% to make sure INT is returned 1030 RETurn x% 1040 END DEFine x% ___ QL-Users Mailing List
[Ql-Users] Function type error
Hi all, I've no idea whether this has been mentioned before, but consider this … 100 :110 PRINT #0, Min_Int%(330.7, 440.7)120 PAUSE -1130 STOP140 :150 DEFine FuNction Min_Int%(x%,i)160 IF x% < i : RETurn x% : ELSE : RETurn i170 END DEFine The correct result should be 331, sincethis is an integer function.On QPC2, SBASIC gives the result as 330.7QLiberator likewise also gives 330.7 Can anything be done? Michael ___ QL-Users Mailing List
[Ql-Users] Subject: Re: PCB Design v7.52
Whenever I try to run any new SBASIC code, there is this overlapping problem of some variable names used are possibly already installed as resident procedures. The code then either does not work as intended, or can stop with an error message. In these circumstances, I usually have to go through the code and rename the variables. Compiling into machine code can solve the above mentioned problem. I first of all compiled using Turbo. There was one REFERENCE statement that had to be inserted for the procedure Rotation, which passes back the values x and y to the caller, FreeRotate, which by the way is not even called. There was just one expression at line 1230 that had to be re-written, to avoid Turbo using integer arithmetic and stopping with an overflow error. The resulting task seems to work as well as the SBASIC version. Next I tried Q-Liberator, which compiled the code easily enough. The resulting object file fails to display the x and y coordinates at the bottom of the screen. Both Turbo and Q-Liberator issued a Warning at line 23030 of .. END IF without an IF. A few weeks back I made mention about a new proposed update to the Turbo parser, which I have almost finished tweaking. I tried this new version on the code, and this did not warn of the above condition. It did however, give information messages about how variables are being used - being the difference between Interpreted code and Turbo code. It transpires that if one wants the SBASIC code to match exactly what the Turbo version does, then a great deal of changes will need to be made. I only have one criticism of the program so far. When the program ends it does a NEW. I may have made some changes or added some REMarks, and before closing down I would SAVE the code. But after a NEW, all the code has gone! The existing file is replaced with a blank one. Michael ___ QL-Users Mailing List
Re: [Ql-Users] Quanta Magazine
I've received two issues this year, up to the Feb/March issue. None received since then. I did email John Gilpin last week, but no reply as yet. Michael Dilwyn wrote: > I've forwarded this to committee members (don't know the answer myself), > hopefully a reply soon. > > Dilwyn > > -Original Message- > From: sba1derson via Ql-Users > Sent: Sunday, July 23, 2017 9:08 AM > To: ql-us...@q-v-d.com > Subject: [Ql-Users] Quanta Magazine > > Has anyone received an electronic copy of Quanta magazine since the > January/February 2017 issue? I've not received one since. I've contacted > Quanta via their website but so far have had no response. ___ QL-Users Mailing List
Re: [Ql-Users] PCB Design v7.52
Hi, Wolf wrote: > In the boot all file separators are "." (eg. "tk.bin"), but when > dezipped, the file separators are "_" as they should be, so the boot > can't find them. There is the -Q1 option in unzip to reverse the "_" <-> "." Eg. EX unzip,#1; "-Q1 dos7_PCBDesign752.zip -d ram6_" and they all come out with dots in them ! I have run the code and this does work well using QPC2, in extended screen size. As a matter of interest, I tried my new Turbo parser on the BASIC code, and this was the result .. ERROR at 32210: Variable assignment expected. Warning at 2570: Not assigned: global WinW2 Warning at 2570: Not assigned: global WinH2 Warning at 2570: Not assigned: global WinX2 Warning at 2570: Not assigned: global WinY2 Warning at 15290: Not assigned: global GScale TURBO: Parsing done, at 197440 statements per minute. 1 error and 5 warnings. The 1 ERROR refers to "CD" which presumably is CHANGE_DIR, or DATA_USE The 5 variables would have been initialised to zero, which may be acceptable, unless you are using "AH" or "JM", in which case you'll get an "error in expression". Michael ___ QL-Users Mailing List
[Ql-Users] Turbo Parser
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
