The Sinclair QL Forum

Derek_Stewart wrote: Thu Jan 02, 2025 3:50 pm What is "packer" software?

It would have to pack the BASIC code together with any toolkits as a single unit. Just a probably stupid idea from me.

Peter wrote: Thu Jan 02, 2025 3:53 pm

Derek_Stewart wrote: Thu Jan 02, 2025 3:50 pm What is "packer" software?

It would have to pack the BASIC code together with any toolkits as a single unit. Just a probably stupid idea from me.

Not at all stupid. It would be worth investigating how that might be done.

Derek_Stewart wrote: Thu Jan 02, 2025 2:35 pm

dilwyn wrote: Thu Jan 02, 2025 2:00 pm No. None whatsoever unless QLib is fixed.

Why not make Q-Dock open source, maybe there other people how can help.

No way, Derek. That just shows your lack of understanding of the issue. Making it open source would just increase support requests I can't handle. You must know how long it is since I last released any major program. Writing QL software is what I like to do, I just don't get time to do so nowadays.

Anyone who suggests making those programs open source simply has no clue what I go through with people who try to run before learning to walk. The endless same old queries when the answers are readily available with a bit of searching. Supporting users and fixing bugs is one thing, trying to support the sources is an absolute no-no for me. At least if the sources were assembler or C a certain level of competency is needed before you even get into that level.

Giving it to someone else to maintain is all well and good, but as I found out when Bob Spelten took over the BMP program it was me who ended up with all the help requests, which I couldn't handle as I didn't have time to learn what Bob had done to the program. Ended up just telling people to contact Bob. In one or two cases, I did so very rudely and bluntly because they persisted, refused to go away as it was "my program, on my website, I should be supporting it as it's such a complicated program." (since when is BMP complicated to use?) And that was just using the program, imagine what it would be like if they had the sources! Bob is a well respected and prolific QL programmer, I had no qualms about giving him the sources and indeed he greatly improved the program with hardly any input from me, but I don't think we anticipated the time the update cost me afterwards.

Another example: I learned the hard way over the Christmas period when two people using the Next QL Core got in touch with what looked like a Launchpad bug or six (or at the very least significant compatibility issues). Turned out after extensive communications over several days which took several hours I realised they didn't even know what an EXEC command was and had never read a QL manual. At that point one time-wasting user in particular got blocked.

The admins here will know I blocked one other person years ago, who always started such messages with "Can you help me...". He eventually packaged up one of my programs and tried to sell it as a "QL operating system" for a while before being told not to in no uncertain terms. The amount of time that guy cost me...

Programs like QDock, Launchpad and Q-Bar (and a few others like the MaQnify program) work somewhat at the limits of what can sensibly be done from BASIC in QDOS/SMSQ without a lot of "lateral thinking" programming, e.g. the popup taskbars or the dock popup/autohides, or the popup help system. They generate more than enough support queries as it is, usually through not reading the manuals. A classic applies to Q-Bar and Q-Dock when I get regular emails saying "it doesn't work on my system, it flashes up briefly then vanishes". Not realising through not reading that they are popup programs, you hold the pointer at the edge of the screen and it appears (and in such programs you can usually turn that off or on anyway)

No way am I getting involved in correspondence on the internals of those, which I know will happen, it's bad enough as it is. It's as much as I can cope with to support end users of my software, I just would not be able to cope with what would happen if people had the sources.

The only way I'd do anything like that now is to provide the sources to someone as competent as yourself to develop a newer and more up to date version on the specific condition that my name is in no way associated with the new version, that it looks sufficiently different that it's obvious it's YOUR program, not mine.

Anyone who doesn't agree with what I've written in this message just simply doesn't understand.

I expect that just like on social media, just for saying the blunt truth I'll get flamed and abused by people who only understand their own point of view. If that happens, I just take down my website and leave the QL scene completely, which I've nearly done several times over the years because of all this.

Happy new year to everyone.

Peter wrote: Thu Jan 02, 2025 3:28 pm <>

pjw wrote: Thu Jan 02, 2025 2:26 pm I once overheard a discussion at some QL event about Qliberator using the upper byte of some addresses to store flags or codes, leaving only 24 bits
for addressing. I wasnt paying it much attention at the time, so I dont know any details. Could that have something to do with it?

I'd say no, because the programs work fine, if data writes always go to external memory instead of being cached.

Right. But if true, such a scheme could still cause trouble with larger memory models. Perhaps I misremembered about the whole top byte being used as that would limit programs to run in no more than 16Mb of memory. Perhaps it was only a few bits. The nub of it, as I understood it, was that if the wiring to the complete address space was limited the CPU would simply ignore those bits and they could thus be used for other purposes.

However, that seems now to be a different topic.

Still playing detective here.. I found something called TurboPatch by Mark Knight,
including code by Davide Santachiara and Mark Swift. In the instructions they write:

TurboPatch is a small utility to patch programs compiled with the last
official version of the Turbo SuperBASIC compiler. It alters the EXECutable
file by adding a public domain patch to the program which modifies the Turbo
startup code; this code was written by Davide Santachiara and later improved
by Mark Swift. Mark's additions include code to flush the data cache and
invalidate the instruction cache on later processors like the 68040 and
68060; without Mark's improvements Davide's code didn't work on these
processors.

(My emphasis.) Could there be a similar problem with Q_Liberator code?

Further on they write:

In addition Mark Swift provided some code used in TurboPatch that makes
patched programs 32-bit clean; without this Turbo compiled programs are only
24-bit clean and may not work on the latest hardware. Most old QL and
compatible systems had 24-bit addresses wrapping around ad infinitum
throughout memory, but the Q40 and some others now available use true 32-bit
addresses. After patching with TurboPatch programs will work on these new
systems.

I guess I may have mixed up Turbo and Qlib, or perhaps both have/had the same
issue..

The problems TurboPatch attempts to address should be moot for anyone using
Turbo now; I guess George Gwilt, of blessed memory, will have weeded out all
of that in the latest(?) version of Turbo (Parser 5.09, codegen 4.10, and TK 3.44),
although it may still be of use to patch any old programs that cant be recompiled.

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

Just to harp on about favourite bug-bear I have been ranting about elsewhere, they
also write:

The startup code in Turbo makes an assumption in two places about where the
system variables are, and accesses them directly, which stops programs
working in Minerva two-screen mode. The patch makes the program check (using
the correct operating system trap) where the system variables actually are
before reading or altering them. Potentially this makes the Turbo compiled
program work on other systems that do or may in future put their system
variables at a different place from the normal location on a QL.

Even DP were at it! Wouldve thunk they knew better!

dilwyn wrote: Thu Jan 02, 2025 4:11 pm

Derek_Stewart wrote: Thu Jan 02, 2025 2:35 pm

dilwyn wrote: Thu Jan 02, 2025 2:00 pm No. None whatsoever unless QLib is fixed.

Why not make Q-Dock open source, maybe there other people how can help.

No way, Derek. That just shows your lack of understanding of the issue. Making it open source would just increase <>

Poor you, Dilwyn, but with the title here of Mr QL, what do you expect! youre a celebrity, man!
I never get any service questions, which either means 1) my programs are easy to use, 2) my programs dont work at all so no one bothers, 3) my clientele is different, 4) my programs dont appeal to anyone, so no one bothers to try.
Too much of a thing, or too little, can both be a bad thing..
I wish you a happier 2025!

pjw wrote: Thu Jan 02, 2025 5:13 pm

Mark's additions include code to flush the data cache and invalidate the instruction cache on later processors like the 68040 and
68060; without Mark's improvements Davide's code didn't work on these processors.

(My emphasis.) Could there be a similar problem with Q_Liberator code?

Yes, likely. That is exactly the self-modifying code issue I suspect. Unfortunately for QLiberator is does not only seem to affect initial startup, but also later runtime (which is not 100% sure as it might be project specific).

Regarding lack of 32 bit cleanliness: I think SMSQ/E caters for that. Likely independent from our problem, as QLiberated programs do work with copyback cache off.

Sorry, I did not mean to cause problems.

Peter wrote: Thu Jan 02, 2025 6:48 pmas QLiberated programs do work with copyback cache off.

Not knowing it, is that the reason, why QLib programs run without problems with a 68030 and Caches on?

I don't know a 68030 QL. But yes the 68030 has no write cache and would not be affected by self-modifying code.
It is several times slower than a 68040 with copyback cache on.