The Sinclair QL Forum

RalfR wrote: Thu Jul 31, 2025 11:37 am As I understand it so far, the problem lies in the Q_ERR mechanism and also in the handling of integer FOR loops.

So any program that doesn't use either should work?

QLiberator uses the top 3 bits of the 'value' long word pointer in name table entries as flags.

One bit flags that this name table entry is currently under Q_ERR control.

Another bit flags that 'AUTOF' is active on that name table entry. So the runtimes can 'on the fly' change a floating point FOR into an integer FOR, if the start, end, and STEP values are integers.

And the third bit flags that this name table entry is a FOR control variable. Normally in QDOS, this name table entry would have it's 'type' word set to $0702, As a floating point loop counter. But the runtimes set the 'type' word to be an integer or float normal variable. I don't know why Liberation Software did it this way, and did not set the type to $0702 or $0703.

This 'value' long word pointer in the name table is usually a memory address, so messing with the top 3 bits is going to make the address wrong. I assume that Liberation Software relied on incomplete address decoding in the hardware. So that the wrong address actually pointed at the correct memory location. This seems to work OK in the Q60, so long as the cache is turned off, But it falls apart with the cache on. I don't know why this happens. Does SMSQ/E decide what gets moved in and out of the cache, or the 68060? Does QSSQ/E or the 68060 also use these bits during caching?

Ah, ok, I understand, thank you

But it falls apart with the cache on. I don't know why this happens.

Think of the cache as a lookup table.

You have a cacheline referenced by address so if you had

X = 0x1000XXXX
Y = 0x0000XXXX

Then even though XXXX is the same on both the cache has two different copies. So if you write through X and read through Y you won't see what X wrote.

If you put a cache flush between the two operations then it actually gets written to memory. And invalidates the lookup table so both would end up reading from memory again and getting the correct value.

XorA wrote: Fri Aug 01, 2025 2:15 pm

But it falls apart with the cache on. I don't know why this happens.

Think of the cache as a lookup table.

You have a cacheline referenced by address so if you had

X = 0x1000XXXX
Y = 0x0000XXXX

Then even though XXXX is the same on both the cache has two different copies. So if you write through X and read through Y you won't see what X wrote.

If you put a cache flush between the two operations then it actually gets written to memory. And invalidates the lookup table so both would end up reading from memory again and getting the correct value.

So are you suggesting that whenever one of these 3 bits gets set (or reset), but only when they are changed, then a there should be a cache flush done. And this may fix the problem.

If I can find some time, maybe I will try to do a runtimes that does this.

I have thrown together a BASIC program that takes a Qliberated object program. And if the runtimes are included, it overwrites the runtimes with my Q604F runtimes (renamed for this program as runQ60). By luck, the new runtimes are slightly smaller than the old runtimes, so it will fit over the old ones.

The program will also scan the object file looking for the Q_ERR commands. And if found will rename them as Q_XXX. So the QERR601B_bin will need to be LRESPRed before starting the object file.

I did a quick test with Qtrans2 and SQRview, and they still seemed to work OK in QPC2.

Note this program will probably not work with Qlib object files made with versions 1 and 2 of QLiberator.

Martin_Head wrote: Sat Aug 02, 2025 11:34 am

XorA wrote: Fri Aug 01, 2025 2:15 pm

But it falls apart with the cache on. I don't know why this happens.

Think of the cache as a lookup table.

You have a cacheline referenced by address so if you had

X = 0x1000XXXX
Y = 0x0000XXXX

Then even though XXXX is the same on both the cache has two different copies. So if you write through X and read through Y you won't see what X wrote.

If you put a cache flush between the two operations then it actually gets written to memory. And invalidates the lookup table so both would end up reading from memory again and getting the correct value.

So are you suggesting that whenever one of these 3 bits gets set (or reset), but only when they are changed, then a there should be a cache flush done. And this may fix the problem.

If I can find some time, maybe I will try to do a runtimes that does this.

That is certainly possible, it would hit performance obviously (I dont know how much on a simple CPU like 68k, Im used to ARM).

Q60Patch : Qtrans_obj, SQRview102_obj and Launchpad_obj after patching and looking good. Early days.

Cheers