Q_Liberator malaise

[Peter]

Do we even know if the cache handling code in SMSQ/E is working as it should?

At least we know that it switches to the right cache modes.

In 2005 any problems with Qlib and copyback caches on Q40/60 must have been known! Doesnt anyone recall? Does anyone have contact with Thierry?

Last time I had contact was several years ago.

[Mark Swift]

Hi All,

Do we even know if the cache handling code in SMSQ/E is working...

With Copyback enabled the data cache would need to be flushed out to RAM before code was executed after an LRESPR or EXEC_W etc, otherwise the system would crash. If SMSQ/E is not constantly crashing with copyback on, then cache handling is almost definitely working.

there is a file "Cache Management for SMSQ/E" by Mark Swift...
...found at Dilwyn's site.

I believe this is legacy code that was put together before SMSQ/E had cache handling built in.

With time, patience and luck a solution or workaround will be found, Im sure. So to everyone following this thread: Work your corner!

It's a problem that's worth trying to crack. But I guess we all have lots already to fill our time.

[pjw]

Hi All,

Do we even know if the cache handling code in SMSQ/E is working...

With Copyback enabled the data cache would need to be flushed out to RAM before code was executed after an LRESPR or EXEC_W etc, otherwise the system would crash. If SMSQ/E is not constantly crashing with copyback on, then cache handling is almost definitely working.

Well, theres working, and working better - or worse. Why else would there be a version 2.01? And, clearly, there is something amiss between Qliberated programs and copyback. If we could do a binary chop and 100% eliminate SMSQ/E as the problem, then theres only the other half left to figure out..

<>

With time, patience and luck a solution or workaround will be found, Im sure. So to everyone following this thread: Work your corner!

It's a problem that's worth trying to crack. But I guess we all have lots already to fill our time.

Yup. Like spending the morning digging my car out of the snow..

[RalfR]

Yup. Like spending the morning digging my car out of the snow.

You lucky thing, there's only slush here.

[Peter]

Hi Per,

But now my time is up.

I'll try to provide someone willing to debug QLib with Qx0 hardware, although I have only moderate hope in a QLiberator fix. But to solve the practical problem under SMSQ/E, a new tool could just pack the BASIC code together with any toolkits as a single unit. Which is - also according to your own assessment - quite the only benefit in using QLiberator under SMSQ/E at all.

If such a tool was written, the affected BASIC programs could just be "packed" instead of compiled. For the development of such a tool, one does not need Qx0 hardware, nor QLiberator knowhow. Rather system knowledge of SMSQ/E. Something you could look at? Or something you have no time/interest for? I was not quite sure how to interpret your post there.

All the best
Peter

[pjw]

Hi Peter,

One of the things to check might be to try out earlier versions of SMSQ/E
to see whether copyback cache stopped working properly with Qliberated
programs at some point. The file dev8_smsq_smsq_version_asm shows that
alterations were made to copyback code at various times. There is also a
note about MMU and Qlib. I dont know whether that could have any bearing..

No special "packer" other than a zip file or a WIN container are necessary!
Simply unzip or copy the archive into a folder. Under SMSQ/E SBASIC files
can be dispatched in the same way as executables. A simple

Code: Select all

IF PEEK$(\\ -4, 4) = 'SBAS' THEN
 LRESPR any toolkits required
END IF

within the SBASIC program takes care of any ad hoc toolkits required.

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!

[Peter]

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.

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).

[Derek_Stewart]

Hi,

I am willing to have a look at this, I have my own Q60 hardware.

I think my interest should not deter anyone else, if fact the more people looking at this problem the better.

[RalfR]

One of the things to check might be to try out earlier versions of SMSQ/E
to see whether copyback cache stopped working properly with Qliberated
programs at some point.

That seems to me to be an important point.

Does the error also appear with the SMSQ/E version with which the Qxx were delivered (v2.94 or similar [seems so, as Derek stated earlier])? This should be easy to check. Perhaps this required the extension of Mark Swift (Cache Management for SMSQ/E) that I discussed above (Mark replies it does not). Or was the Cache theme not an issue at all in the beginning? Or maybe not for both caches?

Any differences if SMSQ/E is running in RAM or ROM?

According to the official log, the last change for caches in Qxx was in v3.12 by Thierry. There were also changes in 3.09 (WL), 3.03 (based on Mark Swift), 2.94 (TT).

TT has always taken great care to ensure that QLib programs run (hence the effort in SMS2). I would be surprised if he hadn't done that with the Qxx. And I assume he had a Qxx on hand to test.

[pjw]

Peter,

I was being serious. There is virtually no difference between EXecuting an
OBJ file or a BAS file in SMSQ/E. There may be an issue with code sharing,
ie where multiple instances of a program use the same program code but
separate data areas (I havent thought this through yet,) but otherwise not
much.

Regarding Qlib, I find it hard to believe that people as smart and
knowledgable as those who created Q_Liberator would end up producing what
was then commonly known as "impure code", ie code that modifies itself
during runtime. For starters such code cant be shared, viz what I wrote
above. But Qlibbed code can be shared without a problem, unless some ad hoc
toolkit prevents it!

Of course, I know too little about how the cache works, whether there may
be other factors in Qlib code that conflict with cache operation, so thats
best left to others to figure out.