Q_Liberator malaise

[Mark Swift]

Hi RalfR,

The Qlib/Copyback problem will exist on QDOS Classic too although I haven't had any time recently to confirm.
If I get a chance to test I'll post results.

As was mentioned in this thread somewhere the issue is likely due to having separate data and instruction caches.
Data in the data cache is unknown to instruction-fetches, and instructions in the instruction cache are unknown to data-reads.

A lot of QL code was written before this separation was a thing, At that time, it wasn't unreasonable to assume that code copied to memory would be available to fetch and to execute (LRESPR, etc).

Cache aware QL systems flush and invalidate caches during operations that can be affected.

[pjw]

I happened upon this ancient post on ql-developers:

On 03/02/2002 12:47, Peter Graf wrote:
<>
> [pjw] A sticker on the ROM chips say "SMSQ/E 2.98 patched".
So you have the best SMSQ/E version there currently is for Q40/Q60.
On a Q40, version 2.98 with Richards patch handles qlib code quite nice.

But I have now tried myself, and indeed on 68060 I to need to go back to
writethrough. On 68040 everything is fine with copyback. Weird.

Unfortunately Tony Tebby has not yet responded my offers to upgrade him to
a Q60. Looks like again we have a problem with our commercial closed-source
OS, and the only person who has the means to look & change, well, ...
<>

(My underlining)
So, is Richard's patch incorporated into current versions of SMSQ/E now, and is it the case
that Q40/QXL40 work fine with Qlib and copyback? It would be useful to understand this.

[RalfR]

If I have read everything from Mark and Peter correctly, copyback cache with QLib programs definitely does not work on the 68060.

It was also new to me that SMSQ/E 2.98 (patched, as Peter says) works with the 68040 and QLib programs with copyback cache. Peter's message is from 2002(!), no idea which patch from Mark he is referring to.

[pjw]

<>
It was also new to me that SMSQ/E 2.98 (patched, as Peter says) works with the 68040 and QLib programs with copyback cache. Peter's message is from 2002(!), no idea which patch from Mark he is referring to.

Note: Only SMSQ/E was patched, not Qlib..

In the message Peter seems pretty adamant that the Q40 worked fine with Qlibbed programs after the patch!

I think the patch refers to the attached:

patch298.zip

Q40 SMSQ/E V2.98 ROM patch

(383 Bytes) Downloaded 18 times

The patch program was made by Richard Zidlicky, not Mark. Presumably it only applies to SMSQ/E V2.98.

Some clarification would be welcome!

[RalfR]

Then someone would have to use 2.98 and disassemble and compare the places. Unfortunately there is no public source code for 2.98. There is no binary version of it on Wolfgang's site either.

Does Richard still know what he did? You would have to ask him.

[pjw]

<>
Does Richard still know what he did? You would have to ask him.

The last address I have for Richard is at ..uni-erlangen.de. It is out of date. Someone here must have a more recent address. They should write.

[RalfR]

Richard replied to me and can still remember the patch well. Apparently one instruction was wrong:

Move number, cacr (=cache control register)

instead of

Move #number, cacr

He wants to take another detailed look at his archive folders.

[RalfR]

There is a file in the source files of SMSQ/E 2.99 (2.98 not available) and 3.41 that handles the copyback cache of the Qx0. It is smsq/smsq/cache40c.asm.

In the v3.41 file (or rather, sometime after V2.99), Thierry Godefroy corrected the code at the time, as he writes. Perhaps there is a general problem with the handling of the cache in this file.

Both versions are included in the ZIP file, if someone like, he can take a look there.

Unfortunately, Thierry did not comment on all of his changes (a general problem with the SMSQ/E source code regarding changes), or where he made changes. You can only see this by directly comparing the source code.

[pjw]

An interesting note from Tony Tebby on caches (QXL-User.doc):

The performance of the more powerful machines depends on the use of the internal cache memory. For the MC680x0 series processors, the implementation of the caches is less than perfect. As well as introducing unnecessary overheads on operating system calls (slightly improved in the MC68040) the MC680x0 cache policy is incompatible with certain programming techniques. It may, therefore, be necessary to disable the internal caches.

No provision is made for disabling the external caches (where these exist) as none of these external caches seem to suffer from the design flaws of the MC680x0 series.

No mention of any intention of doing anything about it. Make of it all what you will..

As I am no longer the proud owner of any 6800x0 computers, theres not much I can do. Those who have such computers could perhaps be more forthcoming. For example the simple question: Does or does not the Q40 run Qlibbed programs with copyback switched on, as stated, under the patched SMSQ/E V2.98? If it does, then whatever that patch does shouldnt be too hard to replicate in the current SMSQ/E source code. The number of problems would then be reduced by 50% - 75%!

[Peter]

Hi, for those who are not subscribed to the ql-users mailing list:

Wolfgang may have found a solution that allows QLiberated programs to run on a Q40/Q60 that is using copyback mode.

It does not modify the QLiberated program so that itself can run in copyback mode. But when such a program gets a slice of CPU time by the SMSQ/E scheduler, the CPU is put in writethrough mode and then put back into copyback mode when another program gets its time slice.

In oder to let the SMSQ/E scheduler know that a program requires writethrough mode, Wolfgang has implemented two methods, either patching it permanently, or starting it with special commands. The permanent patch does not hinder execution on other platforms in any way.

The new version of SMSQ/E for the Q40/Q60 and the patches can be downloaded here for testing:
https://www.wlenerz.com/qlib4qx0/Qlib4Qx0.zip

Please read the "readme_txt" carefully.

All the best, Peter

Edit: Link updated