QLiberator v3.42

[RalfR]

I think the patch programs only touch the embedded MC extensions from QLiberator.

[RalfR]

Has anyone tried to load a QSAVEd file from SMSQ/E under QDOS with Liberation's QLOAD_bin? Per has told me, that this crashes QDOS, which makes me wonder as I haven't find any place in SMSQ/E manual, which states any incompatibilities.

So it seems to be possible, that both QSAVEd files are a bit different, though QLib 3.36 is able to compile the SMSQ/E one.

[pjw]

Has anyone tried to load a QSAVEd file from SMSQ/E under QDOS with Liberation's QLOAD_bin? Per has told me, that this crashes QDOS, which makes me wonder as I haven't find any place in SMSQ/E manual, which states any incompatibilities.<>

On closer inspection the crashes with the standard Qloadref toolkit (V1.9) on QL JS were almost certainly due to the SMSQ/E QSAVEd files containing $xxxx and %xxxx literals!
So I tried what I thought was a version of Qload_bin patched to cater for non-decimal literals on Qdos (by simply converting their tokens to decimal), but that crashed too, although differently.
I'll dig deeper when I get the time - unless somebody already has the answers.

[EmmBee]

Has anyone tried to load a QSAVEd file from SMSQ/E under QDOS with Liberation's QLOAD_bin? Per has told me, that this crashes QDOS, which makes me wonder as I haven't find any place in SMSQ/E manual, which states any incompatibilities.<>

On closer inspection the crashes with the standard Qloadref toolkit (V1.9) on QL JS were almost certainly due to the SMSQ/E QSAVEd files containing $xxxx and %xxxx literals!
So I tried what I thought was a version of Qload_bin patched to cater for non-decimal literals on Qdos (by simply converting their tokens to decimal), but that crashed too, although differently.
I'll dig deeper when I get the time - unless somebody already has the answers.

From the QDOS_SMS Reference Guide v4_5.pdf dated 27 March 2020 under SMSQ/E Troubleshooting ...

QLOADed files look strange - the numbers are gone
If you QLOADed files which were saved with Minerva Integer tokens, then you will see funny effect like
WINDOW , < , , ,
then you have to go back to a Minerva machine, QLOAD it there and SAVE it back in ordinary ASCII. Then
you can load it into SMSQ/E. If you QSAVE it here, you can QLOAD it into any system.

[RalfR]

As I have understand it, Per has made his test with a JS ROM.

[EmmBee]

I've downloaded the v1.9 QLOAD from Dilwyn's website,
and have tried this on a small program QSAVED on QPC2,
on JS ROM with Q-emuLator. This all seems to work out okay.

Of course, if you're using $ or % literals then there'll be a problem,
as QDOS will reject them.

EmmBee

[dilwyn]

Makes sense, EmmBee.

The READ_ME file with the Qload utility mentions that QLOAD v1.8 was tested with Minerva integer tokenised basic files, and the SMSQ/E reference texts state that the only changes the patch makes is for QREF and QLOADREF to handle the $ and % hex and binary constants (i.e. QREF part only).

And integer tokenised qsaved basic can only be compiler with QLiberator 3.32 or higher, and the release notes for QLib 3.32 state that if you wish to compile directly from _sav QLOAD files then they must have been created with QLOAD v1.7 or later. Does not explain why. Life never simple!

[RalfR]

Thanks for testing, seems to be ok. Just missing "Extensions missing" in SMSQ/E's QLOAD, which TT has not incorporated...for unknown reasons.

[EmmBee]

My point is, that if applying some or all of these patches simply
updates Qlib_run, whilst maintaining backward compatibility, then they
should be applied and the resulting code disassembled and re-
assembled into a new, universal toolkit called, eg Qlib342_run.

This I have now done, and am currently testing it out. Naturally, I'll
share this when it is in a fit state to be shared. I dont intend to offer
a detailed analysis of how everything works, although Ive added back
some of Martin's remarks. Further commentary can be added over time
by different actors as and when the need arises.

How's the testing coming along?

The next patcher, qlib_obj_bas from TT says:

"This patch allows QLiberator externals to be used with SBASIC. It
removes the address sensitivity and allows externals to be LRESPRed
from any SBASIC Job (the check for Job 0 is replaced by a check for
'NOT EXECUTED' - (a6).b = $00 or $ff. The patch can be used on
QLIB_OBJ so that all future externals be less fussy, or it can be used
on externals which have already compiled."

I guess this should be of interest to EmmBee: Can he see what the
patch does and just replicate its results in the Q-Liberator source
code? Then its in there for all time and the patcher becomes
redundant, except for updating other programs already compiled.

Watch this space!

I believe Martin had already applied the above patch to Qlib_obj before decompiling it. The reason I believe
this is because I have just created a Qlib external in QPC2, and after LRESPR ing the _obj file, it worked.
No further patches were required. I am wondering where, in the program, what line the change was made on.

These Qlib externals can be so useful. The idea is to create your own KEYWORDS, along with any parameters.
This is written in S*BASIC. All that is needed is to place a REMark $$external before the PROCedure or FuNction
you want to be made resident. These can be made in both QDOS and SMSQ/E.

EmmBee

[pjw]

EmmBee,
These things take time.. Im also preparing to head off to the wilds. Hopefully Ill have some time once I get there. In the mean time: Youve had the first draft from me. At least Qlib342_run should be uncontroversial. Its basically Qlib_run336mod patched with TT's patcher with a new version string, dissembled, and re-assembled. Perhaps that could be shared and tested in that way? Many hands make light work, and all that.