Q_Liberator malaise

[RalfR]

Here the corrected link:

https://www.wlenerz.com/qlib4qx0/Qlib4Qx0.zip



I have tested some permanent patched programs and they also run on QPC2.

[Peter]

Regarding the cause of the problem: As I wrote earlier, a writethrough requirement can also be caused by timing or hardware related issues, not just generating/modifying executable code. I did not find a hardware issue very likely, but on second thought, it might also play a role.

Apparently QLiberator abuses the top three address bits, relying on the hardware not to treat them as different addresses. Again a method as "clean" as the average public toilet in Frankfurt railstation. So QLiberated executables can work, the hardware must read or write the same data for up to eight different addresses. The external DRAM of a Q40/Q60 will partially do that, because of incomplete address decoding (luck that I didn't have enough PLD pins). But the caches don't. They will use different entries for different addresses, as they should. The malaise might also be related to that.

[Derek_Stewart]

Hi,

There seems to be a possibke solution from Wolfgang Lenerz on the QL-USERS mailing list, witha patched ROM and patched Qliberator program.

[XorA]

Hi,

There seems to be a possibke solution from Wolfgang Lenerz on the QL-USERS mailing list, witha patched ROM and patched Qliberator program.

You mean the one 3 posts up?

[RalfR]

You mean the one 3 posts up?

I'm sure!

[Derek_Stewart]

sorry, did not see that update.

Is it possible to alter the Qliberator compiler to produce the code the patch does?

[RalfR]

Is it possible to alter the Qliberator compiler to produce the code the patch does?

Theoretically, this can be integrated. At the moment, Wolfgang inserts a piece of code at the end of the program (qpatch_bas), there is no other option with a finished program.

At the beginning of the program, he makes a JMP or BRA at the end of the program (depending on the length of the program) and then back again. The program treated in this way is given a permanent identifier that is queried by the modified scheduler in SMSQ/E v3.42 in order to switch off the copyback cache for just this program. The programs treated in this way also run on standard QDOS and/or QPC2. The treatment can also be carried out with any normal machine code JOB and should also work with C or Turbo programs.

This could also be done during the compilation process and JMP or BRA could be dispensed with if the code snippet was integrated directly (there is no source at the moment).

The QEX/QEXEC/QEXEC_W/QEW (qexec_bin) that Wolfgang also made do not change the program code, but add the code when the program starts.

Personally, I prefer permanent treatment of a existing program, then it runs everywhere without problems.

[tofro]

Is it possible to alter the Qliberator compiler to produce the code the patch does?

Theoretically, this can be integrated. At the moment, Wolfgang inserts a piece of code at the end of the program (qpatch_bas), there is no other option with a finished program.

At the beginning of the program, he makes a JMP or BRA at the end of the program (depending on the length of the program) and then back again. The program treated in this way is given a permanent identifier that is queried by the modified scheduler in SMSQ/E v3.42 in order to switch off the copyback cache for just this program. The programs treated in this way also run on standard QDOS and/or QPC2. The treatment can also be carried out with any normal machine code JOB and should also work with C or Turbo programs.

This could also be done during the compilation process and JMP or BRA could be dispensed with if the code snippet was integrated directly (there is no source at the moment).

The QEX/QEXEC/QEXEC_W/QEW (qexec_bin) that Wolfgang also made do not change the program code, but add the code when the program starts.

Personally, I prefer permanent treatment of a existing program, then it runs everywhere without problems.

Well, ideal would be a solution that identifies the problem areas in QLiberated code and only patches those instead of slowing down all of the program - But what Wolfgang has done is still a great improvement and maybe "just good enough".

[RalfR]

I think you will hardly notice the slowdown with normal programs. Better than nothing.

Unfortunately, nobody can say at the moment what the QLiberator does. In my opinion, it is more of a type of interpreter in connection with the runtimes, but nothing is known for sure.

My only fear is that if Adrian Soundy (compiler) or Ian Stewart (runtimes) can't tell us what's being done, we'll probably never know.

[pjw]

I was just going through a few points in this thread. I had forgotten about this objection, which can easily be answered:

Simply unzip or copy the archive into a folder.

That's equivalent to providing a pile of individual BASIC files, which is not intended by the QLib users. I thought you saw keeping things in one file as the goal.

A lot of programs, whether compiled or not, come with various extraneous files: sound files, config files, palettes, etc. Nothing scary there. The only extra in this case would be an ad hoc toolkit or two.

I have provided a sample (attached). Please check it out and let me know what you think.

Anyone writing code that theyre planning to compile, and that is also meant for running under SMSQ/E, could also take note. The example is very basic, but contains most of the elements needed.

Qlibbed.zip

QL-type zip file

(2.5 KiB) Downloaded 17 times

Unzip to ram1_ and EXecute the file ram1_Qlibbed_bas. Then EXecute Qlibbed_obj (copyback off where relevant, of course) Then check out the text file for info.

If anyone feels a need to obfuscate their code (for shame or to protect IP) then Im sure there are plenty here whod love the challenge of writing a code obfuscator!

You know there are almost no developers left. You also know that just obfuscating a pile of individual BASIC files will not be an acceptable alternative to those who now use QLiberator. So why that ironic remark? I was seriously looking for a way not to cripple a 68060 system to half speed, searching for an acceptable alternative to QLib under SMSQ/E (if it can not be fixed which is likely).

No sarkiness here. I meant what I wrote. It would be dead easy to write a code obfuscator: go through the tokenised S*BASIC program, pick out all unique non-mc names and then replace them with a letter + a sequential number, followed by the relevant suffix (%, $, or none, as appropriate).

The reason I wont do this is because Im busy and not interested. In fact, I dont really agree with the reasons to do so.