Q_Liberator malaise

[Mark Swift]

Hi all,

I hesitate to post untested code, but I am unlikely to get time to check this on my own hardware this weekend.
It's a patcher program which inserts code that flushes the data and instruction caches before suspicious instructions.
It does this by appending some routines to the end of the file, which I expect some code won't like.

cpushaid.zip

(2.62 KiB) Downloaded 30 times

Suspect code can be listed in a DATA statement at line 1100.
The example code "4EB13800", is the "jsr $00(a1,d3.l)" instruction that tofro suspected here
I find this a useful reference if I want to quickly hand code instead of assemble.

I don't know if it will fix anything, but if not it might be a useful starting point.
BTW, once patched there's no going back so make sure you keep your originals safe.

[Derek_Stewart]

HI:

Miracle Systems had a projected product called QXL Gold, which connected a Super Gold Card to a QXL, the project never came to sale, and Stuart Honeyball, was always a little evasive on the details of the hardware.

Back on topic:

But maybe a simpler project would be to build an existing 68040-68060 adapter on the QXL. But the problem of the QLliberator Cache Mode would still be a problem.

So is the lack of COPYBACK Cache mode on the 68060 attributed to the SMSQ/E operating system, or the Qliberator Runtimes.

SMSQ/E source code is commented, so we should know understand it, but the disassembly of QLIB_RUN is not, I can start commenting the disassembly. As all the SMSQ/E technical documentation is now available.

[RalfR]

Hi all,

I hesitate to post untested code, but I am unlikely to get time to check this on my own hardware this weekend.
It's a patcher program which inserts code that flushes the data and instruction caches before suspicious instructions.
It does this by appending some routines to the end of the file, which I expect some code won't like.

I ran the program once with the current Q_Liberator runtimes, here is the result:

Loading win1_system_qlib_run
Code len 10552
Preparing cpush code patch at 10560
Suspect code found at 1198
Creating new code patch at 10634
Patched code len 10644
Saving ram1_test_run

The patched runtimes run without problems (in QPC!).

I also tried it with my own editor just to try a program without linked runtimes:
Loading win1_sedit63_obj
Code len 70488
Preparing cpush code patch at 70496
Nothing to do

QLib_obj itself also wasn't patched.

[Peter]

So is the lack of COPYBACK Cache mode on the 68060 attributed to the SMSQ/E operating system, or the Qliberator Runtimes.

QLiberator. My problem with SMSQ/E is just that it did not default to copyback after 2.98p - thereby concealing the QLiberator malaise for decades at the cost of crippling the Q60 to half speed.

[Peter]

Hi Mark,

I hesitate to post untested code, but I am unlikely to get time to check this on my own hardware this weekend.

Many thanks! Great that you have a go!
I'm in the process of building a new Q60 for someone to have a more in-depth look eventually.
In the short term that means I lack time to test myself.

All the best
Peter

[pjw]

Hi all,

I hesitate to post untested code, but I am unlikely to get time to check this on my own hardware this weekend.
It's a patcher program which inserts code that flushes the data and instruction caches before suspicious instructions.
It does this by appending some routines to the end of the file, which I expect some code won't like.


cpushaid.zip


Suspect code can be listed in a DATA statement at line 1100.
The example code "4EB13800", is the "jsr $00(a1,d3.l)" instruction that tofro suspected here
I find this a useful reference if I want to quickly hand code instead of assemble.

I don't know if it will fix anything, but if not it might be a useful starting point.
BTW, once patched there's no going back so make sure you keep your originals safe.

Has anyone tested this yet? Especially those with a Qx0 who are so eager for a solution. It should take no more than minutes to get an answer and yet we are still waiting to hear..

[RalfR]

Has anyone tested this yet? Especially those with a Qx0 who are so eager for a solution. It should take no more than minutes to get an answer and yet we are still waiting to hear..

Yes, I, it's higher up. Of course I can't test this on a Qx0 (just QPC), I don't have one. But it can be tested there by Derek, Mark or Tobias.

[Derek_Stewart]

Hi

I have 4 Q60 boards, that have minor startup faults,I will get this repaired and be able to help with the testing.

[Derek_Stewart]

Hi

Ralf asked in a PM, about is a Config Block entry to Enable/Disable MMU for Qliberator.

I have all the issues of SMSQ/E going back to v2.92 for the Q40. I had a look at the old SMSQ/E Q40.ROM files, to see when this Config Block entry was added. The Q40 the MMU config block option first appear in SMSQ/E v2.95.

SMSQ/E was handled over to Marcel at SMSQ/E v2.99, so the MMU config switch was probably done by Tony Tebby, so any information may not have been handled over.

I will have read the early documents again.

[pjw]

Has anyone tested this yet? Especially those with a Qx0 who are so eager for a solution. It should take no more than minutes to get an answer and yet we are still waiting to hear..

Yes, I, it's higher up. Of course I can't test this on a Qx0 (just QPC), I don't have one. But it can be tested there by Derek, Mark or Tobias.

Im aware that you tested the program, but not its material effects. That is the issue now,