Q_Liberator malaise

[Derek_Stewart]

Hi,

My, comment with regards to compiling programs with Turbo for use the Q60.

Turbo always had problems compiling programs containing machine code extensions to S*BASIC which either alter their parameters or require ar-rays as parameters.

I noticed in QL Today Vol 11 Issue 14, George Gwilt showed how to compile thd QPTR Demo program with Turbo v4.21

This maybe an alterative to Qliberator, I will do some investigation work on this.

[RalfR]

[ot_on]Hi Derek,

it is Vol. 11 issue 4, not 14 .

When I read this article, I sometimes have the feeling that S*BASIC is not very compatible with Turbo, not vice versa. [ot_off]

[RalfR]

I wonder, if Peter have sent them details of the remaining problems (perhaps he did, I do not know), so they were able to correct them.

No I did not. The problem is not specific to Q40 or Q60 at all.
It is a general issue with separate caches for code and data, affecting all 68K CPUs > 68030.
Also, I had no idea there was work in progress toward a more clean QLiberator implementation.

I think, the problems with the cache should have been noticed from the start (In fact, I have read it here for the first time).

[Derek_Stewart]

Hi Ralf,

I misread the title of the QL Today issuse: V11 I4

When I was building the Q60 with a friend, the Qliberator problem was well known, but, due politicial issues on the QL Trading Cabal, there was a lot of resistance to the Q60.

Roy Wood use QL Today to create bad feeling towards the Q60, rather like the way way Elon Musk uses X to create "fake news".

So the solution the Qliberator was a patch program that I coukd get to work or switch the cache off. So much for experts.

I had hoped that with Qliberator been decompiled an a source produced, that this problem could be identified.

Back to the drawing board...

[OT_help]???[OT_off]

[Peter]

If we could manage to narrow down where the problem could lie, it might be possible to do something.

Maybe in a first step, we should define a simple BASIC program on which to reproduce it, rather than a large executable like Q-Dock?
Do you own a 68040 or 68060 machine?

[RalfR]

Would be interesting to see, if Q_Liberator itself gives cache problems during compiling.

If a compiled program "10 PRINT 'Hello World' : PAUSE" gives an error, the runtime system seems to be the problem and also to test, if they are resident or inbuilt in the compiled file.

Unfortunately, although MK has commented a few of QLib's extensions, the runtime system is not.

[Peter]

Would be interesting to see, if Q_Liberator itself gives cache problems during compiling.

Yes, but I'd be glad if someone else could do that. I have no interest in QLiberator as such, just in using software which is "disabled" by it. As you can imagine, the design work (or even concept) for a potential new 68060 machine requires a lot of concentrated thought, and I can not recurse into too many sub-projects.

If a compiled program "10 PRINT 'Hello World' : PAUSE" gives an error, the runtime system seems to be the problem and also to test, if they are resident or inbuilt in the compiled file.

If you upload a QL-side zipped executable, I can test. Maybe another one that continues to generate output, too.

[RalfR]

If you upload a QL-side zipped executable, I can test.

Ok, here is a very simple program, which waits for you to press a key, then print something. How do you detect a cache problem?

The ZIP contains the QLib runtime system, one file compiled with (_run), one file compiled without runtimes. If you need other things for your test, please let me know.

The source:

10 OPEN#3,"con_100x50a100x100"
20 PAPER#3,3: INK#3,0: BORDER#3,2,255: CLS#3
30 FOR i=1 TO 20
40 PRINT#3, "This is number ";i
45 PAUSE#3
50 END FOR i
60 CLOSE#3
70 STOP

[Peter]

Ok, here is a very simple program, which waits for you to press a key, then print something.

Thanks. This simple program worked with copyback cache on a 68060. No misbehaviour that I noticed. (Which does not mean that we can exclude memory corruption.)

How do you detect a cache problem?

This becomes a good question now. Usually the system crashes or visibly misbehaves on screen. But apparently that requires some degree of complexity, which is not reached yet.

[RalfR]

No misbehaviour that I noticed. (Which does not mean that we can exclude memory corruption.)
But apparently it requires some degree of complexity.

Do you invoke Qmon during tests? Perhaps the error occure during the use of a special SB keyword. In my opinion, testing only makes sense if someone does it with a Qxx and also programs without toolkits.

In principle, this was a first attempt to see whether the runtimes in general were causing a problem.