Q_Liberator malaise

[RalfR]

The old keywords are switched off by default in FI2 but if a program expects the old ones they can be switched on again.

I find it strange why the existing keywords always have to be changed just because someone had another idea for SMSQ/E.

[tofro]

The old keywords are switched off by default in FI2 but if a program expects the old ones they can be switched on again.

I find it strange why the existing keywords always have to be changed just because someone had another idea for SMSQ/E.

"always" <> once in forty years. And that one time, that was handled like the fall of the Roman Empire by some people back then...

[dilwyn]

The old keywords are switched off by default in FI2 but if a program expects the old ones they can be switched on again.

I find it strange why the existing keywords always have to be changed just because someone had another idea for SMSQ/E.

I suppose that Sbasic has so many keywords, it's bound to happen sooner or later. There are lists of keyword names used out there, but I don't remember if they existed at the time. And when it comes to operating system (or rather, Basic interpreter) versus an application for who gets to use a name, the operating system will usually win, I guess. Although as Wolfgang has been involved with both, it's a bit of an unusual situation with this one!

[Artificer]

Hi Martin,

Have finally been able to tryout RUNQ603 runtimes, copyback on smsqe 3.42.

The programs I have tried so far are:
QCoCo, ACP, EddIcon, Screen copy, Fontview, SQRView, Qtrans, QCP, Xchange, SpriteView

SQRview on attempt to load an image file produces the qlib FOR type error message with RUNQ602 but with RUNQ603 it reports unknown file type with both pic files and bmps.

Qtrans behaviour is similar with both versions of the runtimes, that is it will execute a test file via FI2 to QD but locks up when a job is launched via FI2. I have had to "bodge" Qtrans
as it has runtimes incorporated, whether this contributes to the problem is a question. A version of Qtrans without incorporated runtimes would help, or not

ACP now locks up with the RUNQ603 runtimes when attempting to read a zip file catalogue, but ACP runs perfectly with RUNQ602 runtimes.

All the other programs tried are OK with either as far a I can tell. The RUNQ603 runtimes don't appear to be an improvement on the RUNQ602 runtimes with the
additional problem with ACP.

At the moment I am sticking with the RUNQ602 runtimes. Many thanks for them.

[Martin_Head]

If I can find some time, it may be worth trying to decompile SQRview\Qtrans\ACP to try to isolate where things go wrong. And unlink any included runtimes.

[Martin_Head]

I have tried coming at the Q60 runtimes problem by approaching from a different angle.

Instead of trying to work around these 2 flag bits in an address register. I have tried to do away with the flag bits. If they never get set, then they can't confuse the cache?

It means that AUTOF will no longer work in this runtime.

There is no 'FOR Type error' checking any more. I don't think this should be a problem if the object files does not normally give 'FOR Type' errors.

All LOCal variables (integer/float/FOR control) default to the size of a FOR control variable. So if a program is very short of stack/data space, then you might get an error. (I found that LOCal also looks for the flag bits)

The runtime seems to work OK in QPC with SQRview, QTrans2, ACP, and others I tried. I can't get QTrans2 to work with FileInfo2. It throws up a QLib error, but does not hang. This may be down to me, as I don't know what I am doing with FileInfo2. And I may have just set it up wrong.

[Artificer]

Many thanks Martin for continuing to work on this problem. I am looking forward to again testing the new runtime. But I am not able to access my Q60 until the end of this month.

Cheers

[Artificer]

Hi Martin,

Have finally been able to tryout Q604F runtimes, copyback on smsqe 3.42.

The Q604F runtimes appear to be a major improvement.

When programs don't have runtimes incorporated or have their older runtimes "bodged off", the successes were many including,
Viewer_rtm, QcdEze and QcdEze2, EddIcon, Launchpad, qdock, picview, calc, fontview, FATLFNs, QTImage, ACP, Qcoco, spriteview,
PicView.

Many small programs even with older runtimes incorporated were OK.

qtrans was OK but slightly odd, in that it browses files, directories and execs files via FI2 but when asked to view a
file via its own internal viewer it hung up, otherwise it was OK.

PROCmanager, DEVman would only run after QEXEC, and PTRview opened it's window but could not display a text file.

SQRview remains a standalone. No error messages this time. Everything seems fine until an attempt to load a file causes it to
lock up, interestingly SQRview does not have runtimes incorporated.

At the moment the Q604F runtimes are a major, major improvement.

Cheers and thanks

[Peter]

Impressive how much work is still invested into a fully copyback compatible solution. Many thanks

[Martin_Head]

I have an idea about the programs with incorporated runtimes. Not tried it, just an idea at the moment.

If I can make the 'new' runtimes smaller than the incorporated one. Then I think you could overwrite the incorporated runtimes with the 'new' one, With just a SuperBASIC program.

In the 604F runtime I have bypassed some code, so that could be removed to make room. Also there is some code in the runtimes that does not appear to get called from anywhere. Some of it may be the leftovers from patches.

I have spent a lot of time lately commenting all the assembly files for Qliberator, and passing them on to Per. And I'm trying to take a bit of a break from Qliberator at the moment.