The Sinclair QL Forum

I could start by taking a look at NEXT_TOKEN. Im no assembler ace, mind you! so if anyone more capable wants to volunteer say so now, otherwise I'd like to put a lock on it until further notice. EmmBee, perhaps you could PM me your email address so we can confer?

EmmBee wrote:I've also found out how to move the console around outside of the 512x256 rectangle, except for the QLIB_USE giving an error message when the window is closed.

I think, this error comes, because QLib's Pointer I/F extensions use a little data block in memory to save the main windows position on screen, so if you end QLib, it appears at the same position at the next start. This may be read by QLIB_BIN, which perhaps generates the error.

Perhaps it had been better with a kind of QLib_ini file, where the last position is saved.

This is a continuation from the thread .. viewtopic.php?f=3&t=3123

pjw wrote:I could start by taking a look at NEXT_TOKEN. Im no assembler ace, mind you! so if anyone more capable wants to volunteer say so now, otherwise I'd like to put a lock on it until further notice. EmmBee, perhaps you could PM me your email address so we can confer?

Hi, Just sent you a PM.

Ralf R. wrote:

EmmBee wrote:I've also found out how to move the console around outside of the 512x256 rectangle, except for the QLIB_USE giving an error message when the window is closed.

I think, this error comes, because QLib's Pointer I/F extensions use a little data block in memory to save the main windows position on screen, so if you end QLib, it appears at the same position at the next start. This may be read by QLIB_BIN, which perhaps generates the error.

Perhaps it had been better with a kind of QLib_ini file, where the last position is saved.

At line 350 in QLIB_obj, there appears this ... POKE_L (224 + RA6 ), ALCHP (64).
If, every time a new QLIB compile is started, the above line is executed, then that location would be overwritten with zeroes.
Does it perhaps need to be used once only in a BOOT file? That way, all the info would remain intact.

EmmBee wrote:If, every time a new QLIB compile is started, the above line is executed, then that location would be overwritten with zeroes.
Does it perhaps need to be used once only in a BOOT file? That way, all the info would remain intact.

But if you have ended the compilation, press space, move the window, stop the program, EX it again, the position is as you have left. So the data must be written after every move and return to QLIB_BIN (as QLibs ALCHP is lost of course when you stop the program).

Ralf R. wrote:

EmmBee wrote:If, every time a new QLIB compile is started, the above line is executed, then that location would be overwritten with zeroes.
Does it perhaps need to be used once only in a BOOT file? That way, all the info would remain intact.

But if you have ended the compilation, press space, move the window, stop the program, EX it again, the position is as you have left. So the data must be written after every move and return to QLIB_BIN (as QLibs ALCHP is lost of course when you stop the program).

Rather than use ALCHP, we could instead use RESPR in a BOOT file, which would be safer as the area allocated would not get to be deallocated until the end of the QL session.

EmmBee wrote:

Ralf R. wrote:

EmmBee wrote:If, every time a new QLIB compile is started, the above line is executed, then that location would be overwritten with zeroes.
Does it perhaps need to be used once only in a BOOT file? That way, all the info would remain intact.

But if you have ended the compilation, press space, move the window, stop the program, EX it again, the position is as you have left. So the data must be written after every move and return to QLIB_BIN (as QLibs ALCHP is lost of course when you stop the program).

Rather than use ALCHP, we could instead use RESPR in a BOOT file, which would be safer as the area allocated would not get to be deallocated until the end of the QL session.

For that, I think, you have to change the Pointer I/F extensions of QLib not to use a data block and QLIB_BIN (if that reads it). Its a question, whether it's worth it.

Ralf R. wrote:But if you have ended the compilation, press space, move the window, stop the program, EX it again, the position is as you have left. So the data must be written after every move and return to QLIB_BIN (as QLibs ALCHP is lost of course when you stop the program).

QLibs ALCHP does not get lost - as they seem to have forgotten to do a RECHP at the end. I'll have to make a note of adding this bit in.
As I understand it now, the position gets updated to QLIB_USE every time QLIB finishes. I would guess QLIB_USE is using the 512x256 rectangle to judge whether to give an error or not. So, some machine-code is required to give QLIB_USE more accurate information about the new larger sizes possible.

EmmBee wrote:

Ralf R. wrote:But if you have ended the compilation, press space, move the window, stop the program, EX it again, the position is as you have left. So the data must be written after every move and return to QLIB_BIN (as QLibs ALCHP is lost of course when you stop the program).

QLibs ALCHP does not get lost - as they seem to have forgotten to do a RECHP at the end. I'll have to make a note of adding this bit in.
As I understand it now, the position gets updated to QLIB_USE every time QLIB finishes. I would guess QLIB_USE is using the 512x256 rectangle to judge whether to give an error or not. So, some machine-code is required to give QLIB_USE more accurate information about the new larger sizes possible.

I agree, but if you use ALCHP or RESPR (which I think is changed to ALCHP) in a QLiberated job, I think you reserve space in the job's space (does the manual stated it ?), so, if the the program stops, all is lost. So I think, QLiberator transfers the values of its data block (the PE I/F extensions) to QLIB_BIN, so the program starts next with the changed screen values.

Hi everybody,

After 27 years we now have an update to Q_Liberator. The last version was v3.36.
There are 4 main additions with this latest v3.37 update …

+ Now able to move QLIB’s front panel around outside of the previous 512x256 limit.

+ Longer filename entries - up to the maximum of 41 chars allowed. This fits into the screen nicely and did not require any change to the front panel.

+ $Hex and %Bin values can now be used. Things like x = $FF + %1010 are now handled correctly.

+ REMarks can now be added anywhere – just as with S*BASIC. In previous versions, if you added a Remark to the top line of any IF SELect WHEN REPeat FOR structure, it would turn that into a single line construct, and would not then work as intended.
Qlib_Patch has also been updated from v3.35 to v3.36
It is now a bit more user-friendly, with a ”Written” message appearing when “Patch” is clicked.
Q_Liberator was made freeware 3 years ago; Martin Head decompiled the object files back into QL SuperBASIC source, and I did the renaming. With this source code now in our hands, this should pave the way to having some further updates in the future. I have chosen the name, “The Sinclair QL Forum Edition 2020”, as this does seem to be an appropriate name. Will this be acceptable?
The source files are included along with every file needed.