Page 11 of 26
Re: Q_Liberator malaise
Posted: Sat Jan 18, 2025 1:10 am
by 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.
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.
Re: Q_Liberator malaise
Posted: Sat Jan 18, 2025 7:08 am
by 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.
Re: Q_Liberator malaise
Posted: Sat Jan 18, 2025 7:53 am
by RalfR
Mark Swift wrote: Sat Jan 18, 2025 1:10 am
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.
Re: Q_Liberator malaise
Posted: Sat Jan 18, 2025 10:16 am
by Peter
Derek_Stewart wrote: Sat Jan 18, 2025 7:08 am
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.
Re: Q_Liberator malaise
Posted: Sat Jan 18, 2025 10:20 am
by Peter
Hi Mark,
Mark Swift wrote: Sat Jan 18, 2025 1:10 am
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
Re: Q_Liberator malaise
Posted: Sun Jan 19, 2025 2:10 pm
by pjw
Mark Swift wrote: Sat Jan 18, 2025 1:10 am
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..
Re: Q_Liberator malaise
Posted: Sun Jan 19, 2025 2:19 pm
by RalfR
pjw wrote: Sun Jan 19, 2025 2:10 pmHas 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.
Re: Q_Liberator malaise
Posted: Sun Jan 19, 2025 2:44 pm
by 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.
Re: Q_Liberator malaise
Posted: Sun Jan 19, 2025 2:48 pm
by 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.
Re: Q_Liberator malaise
Posted: Sun Jan 19, 2025 2:56 pm
by pjw
RalfR wrote: Sun Jan 19, 2025 2:19 pm
pjw wrote: Sun Jan 19, 2025 2:10 pmHas 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,