Page 1 of 3

QLiberator v3.38

Posted: Wed Apr 15, 2020 11:52 am
by EmmBee
Hi all,

Attached is QLIB v3.38. I've added to the Release notes in the README file. Here is what I say ...
RELEASE 3.37 March 2020
-------------------------

The past 27 years have witnessed huge strides in technology. Television and
Monitor screen sizes have increased far beyond the original QL's 512x256.
Emulators have appeared and allow many thousands of QL files to be stored on
PCs hard drives, requiring longer filenames. Hex values (base 16) and Bin
values (base 2) can now be used with the latest SMSQ/E SBASIC language. This
update is an attempt to keep QLIB fully abreast of the latest in technology.

+ Now able to detect larger screen sizes than the original QL's 512x256

+ Able to move QLIB's front panel outside of 512x256

+ Filename entries up to 41 chars can be entered

+ Hex and Bin values now recognised. Eg. $FF = 255 %1111 = 15

+ REMark's can now be placed anywhere - as with S*BASIC.

+ QLIB_Patch now writes a "Written" message to confirm successful patching.


RELEASE 3.38 April 2020
-------------------------

An update to cure a bug introduced in the previous version, and to make some
improvements to the existing code.

+ Checking of REMark on top line of structures now correctly written.

+ Binary-chop method added to screen size detection - improving start-up time.

+ Environment Vars record the front panel position, even outside of 512x256.

+ er = Q_ERR : IF er .. is now used to improve error messages.

+ Ambiguous names are now reported - instead of just saying so.

+ Missing names in FOR/REPeat loops (allowed in SBASIC) now reported.

+ The name after END DEFine is now spell checked .. Reported if incorrect.

+ Literal strings over 512 chars now detected and reported.

+ "ED", "LIBERATE" and "INSTR_CASE" added to list of names which don't compile.

+ Work file now DELETED AT END to enable several compiles in one QLIB session.

+ Patch program now avoids odd-sized object files to avoid QL crashing.

+ Can now be called with an object filename (optional).

+ "_obj" added to the end of filename if not entered.

+ Job name limited to 22 chars as in v3.36 and previous versions.

+ QLIB Compiler and Patch program now more fully integrated.
Note that the ENV_BIN should be LRESPRd in the Boot file, as all programs in the QL can use it.
Qlib_338.zip
(96.85 KiB) Downloaded 93 times

Re: QLiberator v3.38

Posted: Wed Apr 15, 2020 12:05 pm
by RalfR
Many thanks, I am looking forward to give it a try.

Re: QLiberator v3.38

Posted: Wed Apr 15, 2020 1:12 pm
by Derek_Stewart
Hi,

Thank you for the great work, once I had changed my boot file, every thing worked great.

Is there an environmental variable that can be preset to define the screen location of the compiler front end?

Re: QLiberator v3.38

Posted: Wed Apr 15, 2020 1:23 pm
by pjw
Thank you! Looking forward to take it for a spin :)

Re: QLiberator v3.38

Posted: Wed Apr 15, 2020 2:38 pm
by EmmBee
Derek_Stewart wrote:Hi,

Is there an environmental variable that can be preset to define the screen location of the compiler front end?
Yes, use ... SETENV "QLIB_wA=" & wA : SETENV "QLIB_wD=" & wD where wA is the front end left x and wD is the top y position. I.e. top left corner.

Re: QLiberator v3.38

Posted: Wed Apr 15, 2020 3:19 pm
by RalfR
BTW: Line 32558:

SCRXLIM = x : SCRYLIM = y

Both VAR names will clash with Dilwyn's "scxlim.zip", where he used SCRXLIM and SCRYLIM as functions.

You should also patch QLib7.bin, that is the config block. Change "3.30" to "3.38" ;)

Re: QLiberator v3.38

Posted: Wed Apr 15, 2020 7:52 pm
by EmmBee
RalfR wrote:BTW: Line 32558:

SCRXLIM = x : SCRYLIM = y

Both VAR names will clash with Dilwyn's "scxlim.zip", where he used SCRXLIM and SCRYLIM as functions.
I was perhaps going to use Dilwyn's code, but he has pointed out in his notes that it might not work for the uQLx emulator, which is an exception. Since QLIB is designed to work on all platforms, perhaps we should use my simple detection method, instead.
You should also patch QLib7.bin, that is the config block. Change "3.30" to "3.38" ;)
I was also thinking that since the QLIB Patch program is now so much integrated with the compiler QLIB_obj, we should rename all three of these with the Version number v3.38.

Re: QLiberator v3.38

Posted: Wed Apr 15, 2020 11:02 pm
by mk79
EmmBee wrote:I was perhaps going to use Dilwyn's code, but he has pointed out in his notes that it might not work for the uQLx emulator, which is an exception.
I'm sure when the PE is loaded uQLx would work like any other platform.
In any case, this is Since QLIB is designed to work on all platforms, perhaps we should use my simple detection method, instead.
If the method is "increase a channel until it hits the limit" then please, for the love of god, don't do this. Really. Pretty please! :roll: I've been working so hard on everything from the PE to SMSQ/E to avoid nonsense like this.

Marcel

Re: QLiberator v3.38

Posted: Wed Apr 15, 2020 11:23 pm
by tofro
Proposal:
  • Check if PE is there (an iop_pinf call will do - If it comes back with no error, it's there. If not, it will simply return an error.
  • If yes, use an iop_flim PE call to determine the screen size. PE knows best how big the screen is (and, it's much faster)
  • If no, fall back to your method,
Tobias

Re: QLiberator v3.38

Posted: Thu Apr 16, 2020 8:31 am
by RalfR
EmmBee wrote:I was perhaps going to use Dilwyn's code, but he has pointed out in his notes that it might not work for the uQLx emulator, which is an exception. Since QLIB is designed to work on all platforms, perhaps we should use my simple detection method, instead.
I think, you have misunderstand Dilwyn's REMark.

---------
Standard QDOS without pointer environment does not support higher resolutions,
although there are exceptions such as the uQLx emulator which supports a
small set of higher resolutions under QDOS)
---------

This just means, that higher resolutions without PE are possible under uQLx. So there is no reason, why it should not work. With Q_ERR_ON "WM_Rptr" you have checked the presence of PE, so you can safely use Dilwyn's extensions. For non-PE you can stick with your other way.