The Sinclair QL Forum

Popopo wrote: Wed Jan 01, 2025 3:24 pm I have 640KB if necessary in real QL. But I use for first testing QEmulator in free version.
It has a floppy option but I couldn't make it work. All time error message "not a QDOS disk". Without even allows me to choose a directory or ZIP or MDV image to treat it as Floppy.

As Popopo states, He's using the unregistered Qemulator.

So all the suggestions about using QXL.WIN files, floppy disk images, and RAM disks is a bit of a problem. As they are not supported in the free version of Qemulator.

If you have a floppy disk drive connected to the PC you could use an actual floppy disk with Qemulator. You could install a ram disk driver, and a floppy disk image driver (with a little bit of messing about). But I don't know of a way to connect a QXL.WIN file to the unregistered Qemulator.

Also in the screen shot, all the files have a '.' seperator instead of a '_'. Which will upset QDOS unless you put the file names in quotes. I suspect the zip files were unzipped in windows rather than inQDOS/SMSQE and have probably lost their executable headers, so will no longer run.

Hi Martin,

the container file *.win I prepared and shared is working on QPC2 as well. Also from there the files can be copied to physical disc and then used on a real QL. Which was the intention if not mistaken.

unzip on PC instead of QL -> Solved
'.' seperator instead of a '_'. -> Solved

So remains:

Register QemuLator which is really worth its money
Use QPC2 instead or uQLx under Linux.
Buy QIMSI and use the container on real QL

Best regards,

Stephan

Edit: adding FLP image unzip on PC. Created with Martins tool!

If the BASIC program is intended to run on both SuperBASIC and SBASIC then the simple answer is supply both BASIC and QLiberated versions. In this day and age there is no real need to compile the source BASIC for SMSQ/E - the only conceivable reasons for not doing so are:
(1) if the source BASIC is complex and expected to lead to an unmanageable number of support queries as people try to tinker with it themselves (I know from experience it does, people just don't read manuals these days and always try to run before learning to walk)
(2) if the program doesn't really run uncompiled for whatever reason, and
(3) programs which need loads of extensions which are linked to the compiled program. Although such extensions can be locally lrespred in an SBASIC job it gets messy and leads to all sorts of extremely time-consuming queries again.

The QLiberated program would provide good speed increase for QDOS/SuperBASIC systems, and the uncompiled version OK for those who wish to use on SMSQ/E systems.

Of course, the ultimate answer is to resolve the QLiberator issue.

Hi Dilwyn,

dilwyn wrote: Thu Jan 02, 2025 12:52 pm Of course, the ultimate answer is to resolve the QLiberator issue.

Until then, is there any chance for Q-Dock or a few other of your compiled BASIC programs for Q40/Q60? Turbo is no option?
All the best
Peter

No. None whatsoever unless QLib is fixed.

As was said, there is little to gain, speedwise, from Qliberating programs
on SMSQ/E systems as SBASIC refines the code to a much higher degree than
SuperBASIC. However, under Qdos there is a definite speed advantage. But
the main thing, to my mind, is the ability to pack the BASIC code together
with any toolkits as a single unit, and to leave the machine "clean" once
the program terminates.

Although Qlib has been decompiled it is not easy to understand what it
does; there is no map, no high-level thesis or plan that explains how it
works.

The person or persons who decompiled it initially made a considerable
effort to try to analyse the program and give the various functions and
variables meaningful names. But one cannot be certain that these are
accurate or meaningful in all cases.

Another thing is that some of the functionality of the program has been
relegated to various binaries, most of which have not been thoroughly
analysed. Some of the binaries are just simple extension toolkits, but some
are integral and specific to the workings of the compiler.

It may be possible to find out what the issue is wrt to the Q40/Q60 if one
knew what to look for. Perhaps the reasons are trivial?

What about a program could interfere with the Q40/Q60 caches?

I doubt there is any selfmodifying code in Qliberated programs. Perhaps
there is during initialisation, as with C programs, but not thereafter.

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?

If one could have a better idea of what one were looking for it might be
possible to do something about it..

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.

pjw wrote: Thu Jan 02, 2025 2:26 pm It may be possible to find out what the issue is wrt to the Q40/Q60 if one knew what to look for. Perhaps the reasons are trivial?

It could be trivial, but I have zero knowledge about QLiberator. The problem is a general incompatibility with the 68040 and 68060 CPUs, not Q40/Q60 specific. These CPUs contain two independent on-chip caches for instruction and data. Accessing instructions and data simultaneously through separate caches increases performance a lot. However, the instruction cache does not expect executable code to be changed by data write accesses during operation, as these are only written to the data cache at first.

A program which for some reason wants to modify its executable code must therefore take care about coherency between the two caches. For example by temporarily using Writethrough mode where write accesses always write through to external memory and thereby update matching instruction cache lines.

pjw wrote: Thu Jan 02, 2025 2:26 pm I doubt there is any selfmodifying code in Qliberated programs. Perhaps there is during initialisation, as with C programs, but not thereafter.

I have of course tried to initially switch off copyback cache, and back on later. That still resulted in crashes and odd behaviour once the cache operates again. Which could be specific to the program I used, for example Q-Dock, but that is not very likely. Could it be that initialisations happen later at runtime, not only during the start?

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.

pjw wrote: Thu Jan 02, 2025 2:26 pm But the main thing, to my mind, is the ability to pack the BASIC code together with any toolkits as a single unit, and to leave the machine "clean" once the program terminates.

Stupid question, but couldn't this be solved by a "packer" software instead of QLiberator?
Possibly also obfuscating the sourcecode for those who do not want to release open source?

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

pjw wrote: Thu Jan 02, 2025 2:26 pm But the main thing, to my mind, is the ability to pack the BASIC code together with any toolkits as a single unit, and to leave the machine "clean" once the program terminates.

Stupid question, but couldn't this be solved by a "packer" software instead of QLiberator?

What is "packer" software?

Could Turbo not used, as George Gwilt altered the compiler to compile QPTR programmes that pass data via arrays.