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