Compiling a SuperBasic program

[Mark Swift]

...I'm not sure if this is strictly on topic.

I wonder if those clever chaps mentioned above have any thoughts about Qlib and
suggestions for a remedy?

I don't remember any direct involvement in TurboPatch, but it's possible that I've forgotten more than I know.

You could try patching the QLIB code with SYSREF_task.
It hasn't been updated in quite a while and I didn't do a very good job of documenting what it actually patches.
It's similar to TurboPatch and supports QLIB code.

SYSREF.zip

(21.2 KiB) Downloaded 49 times

It requires "D68K" from D68K_rext, plus "LONGINT$" and "STRINGL" which can be found in PDTK_rext or elsewhere.

Code: Select all

LRESPR D68K_rext
LRESPR PDTK_rext
PDTK_ext
EXEC_W SYSREF_task

If there's a question about a patch, it'll ask if it should be applied.
For example this one that may pop up when looking for $28000 should not be patched.

Code: Select all

00000E96 15BC00028000 move.b #$2,$0(a2,a0.w)

There's no guarantee it will fix the QLIB issues mentioned though.

[RalfR]

I don't know a 68030 QL.

Oh, it was my MegaST4 with an hyperCache 030 accellerator card .

[Derek_Stewart]

I don't know a 68030 QL.

Oh, it was my MegaST4 with an hyperCache 030 accellerator card .

The only other 68030 based QL system, is an Atari TT030, which needs a QVME graphics card to make it hardware.

But the QVME was closed source so no way to reduce.

Which is why my TT stays in storage.

Anyway, I rather have a 68060 based QL, which how the Q60 production came about with Peter's excellent design work.

[Derek_Stewart]

Sorry, I did not mean to cause problems.

Changed my mind on this, I am not sorry for the comment of suggesting open source.

This seems to work very nicely in the Linux world so why not in the QL World ( not the magazine )

Or do we go back to the days of Qjump and dark secrets, no user development.

A bit like the Spectrum Next Core release without documentation.

[NormanDunbar]

Hi Derek.

As Dilwyn pointed out, he has a lot of trouble with people asking for support for things which are in the manual. Many/most people these days want instant gratification without effort. Reading a manual is too difficult for them, they can't even be bothered to Google/DuckDuckGo for it.

I'm a moderator on the Platformio.org forums, and I see this all the time. Nobody seems to read the docs.

Now, if Dilwyn, or anyone else, open sourced their code, that's fine, but be prepared for lots of support calls from people who don't read the code, the docs, the algorithm or whatever.

That's why Dilwyn hasn't open sourced his code because of the support problem which he is struggling with even before it is open.

My stuff is out there in the wilds, QL, Arduino, Oracle etc, and I give the source away too. I get issues raised for problems which are clearly documented, plus, I get source code problems too, from people who don't read.

It's frustrating, and it's frustrating to see useful apps that might be upgradable going to "waste" but that's how it is.

Sorry.

Cheers,
Norm.

[dilwyn]

Sorry, I did not mean to cause problems.

Changed my mind on this, I am not sorry for the comment of suggesting open source.

This seems to work very nicely in the Linux world so why not in the QL World ( not the magazine )

Or do we go back to the days of Qjump and dark secrets, no user development.

A bit like the Spectrum Next Core release without documentation.

No need to be sorry - it will suit some people, not others like me since I won't be able to guarantee to support it (and I know from painful experience that will happen). Nothing to do with dark secrets.

If anyone wants to decompile my programs with DisCharge, that's fine, I'm assuming if you can handle that, you'll have the knowledge not to need much support.

[Derek_Stewart]

OKay, point taken and understood.

[Artificer]

Mark Swift wrote : You could try patching the QLIB code with SYSREF_task.
It hasn't been updated in quite a while and I didn't do a very good job of documenting what it actually patches.
It's similar to TurboPatch and supports QLIB code.

Today, I tried patching 7 qliberator compiled programs this morning with the SYSREF_task. For 3, SYSREF_task made no changes and for the remainder it patched 2 locations and then modified other parts of the code to be 32 bit compatible. It made not one compatible with the copyback cache setting on my Q60. Those that it patched all reported the QLib runtime error "FOR type error" regardless of cache setting.

So no solution yet.

It is true that the Q60 is faster with copyback enabled and it would be great to run at full speed. The cache setting on the Q60/Q40 is only one factor in the speed it achieves with screen size and colour mode hitting performance as it does with the Q68. With the cache writethough setting on the Q60 it is still no slouch and with the dhrystone bench mark approximately 12 times faster than the Q68 with the same screen and colour settings. With mode 4 colour and 512x256 screen size and copyback cache settings (optimised for speed) the Q60 is approximately 31% (QTOP index) faster than with the writethrough cache settings. With the Q60 with a standard boot with several tasks running including QDock and Launchpad and Qcascade the differential between the 2 cache settings is reduced to approxinately 11% (QTOP index).

With the writethrough cache setting Dilwyn Jones excellent QDock and Launchpad have no difficulty performing. Thanks, Dilwyn for these excellent freeware programs.

Cheers

[RalfR]

As far as I remember (but I may be wrong), Liberation Software were still in their QLiberator programming process when the Qxx were launched. They have done a lot of corrections during TT's Atari phase and the Minerva phase. 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.

And if so, why didn't they do it?

[Maskenlos]

I wonder a little bit how all this information will help to answer Popopos question how to compile a S*Basic program?

@ Popopo

did you manage to get Turbo-Compiler running using the container file I prepared for you together with QPC2?