Q_Liberator malaise

[tofro]

<>
(See the 1 bit diff? )

I do indeed. But are you saying this is the problem, or that this was the problem?

This is just a wild guess, but "a 1-bit error" to me implicates that it was about the contents of the translation registers. I'm not too familiar with the '040, but would assume (under the assumption that QLib is really useing self-modifying code) the caching mode would indeed need to be write-through. So: Don't know

[Derek_Stewart]

Hi,

The details of SMSQ/E cache system is detailed in the SMSQ/E Reference Manual Section 19.3 SMSQ CACHE SYSTEM.

This detsils the way the SMSQ/E Cache System should work on 68000, 68020, 68030, 68040, 68060.

The Reference Manual is available form: https://www.wlenerz.com/qlstuff/SMSQL_Guide_4.8.zip

I am just trying to centralise information in the thread.

[Mark Swift]

Hi Derek,

(See the 1 bit diff? )

I am just trying to centralise information in the thread.

Noted. I include some info below that could be useful.

The registers DTT0, DTT1, ITT0 and ITT1 have the following format:

AAAAAAAAMMMMMMMMESS000UU0CC00W00

A – Address (bits 31-24) – compared with bits A31-A24 of address to match.
M – Mask (bits 23-16) – Mask for address. Setting a bit causes corresponding address bit to be ignored
E – Enable Bit (bit 15) – 1 = translation enabled, 0 = disabled
S – Supervisor Mode (bits 14-13) – 00 = match user mode, 01 = match supervisor mode, 10 and 11 = ignore mode
U – User Page Attributes – ignored
C – Cache mode (bits 6-5) – 00 = Cacheable Write-through, 01 = Cacheable Copyback, 10 = Noncacheable Serialized, 11 = Noncacheable
W – Write protect (bit 2) – 0 = write permitted, 1 = write disabled

Code: Select all

The value #$00ffe020 corresponds to the following:

00000000 11111111 1 11 000000 01 00 0 00
AAAAAAAA MMMMMMMM E SS 000UU0 CC 00 W 00

= Address $00000000 to $ffffffff
= Enabled
= Match both user and supervisor mode
= Cacheable Copyback
= write permitted

Note, where there is a clash in addresses, DTT0 and ITT0 take precedence over DTT1 and ITT1

[RalfR]

... in QL Today vol 7 issue 4, the famous Tony Tebby article "Pirates and Mad Sheep", on page 25, Tony Tebby gives details of a bug in the Q40 hardware initialisation routine, maybe this a clue to what is going on.

I'm putting the relevant part of the article here so that everyone knows what is being talked about.

What surprised me most about the content: The 68060 cannot do MOVEP, TT expressly points out that there should be different versions for 680x0 and 68060 (the registrar is responsible for this, writes TT) and the emulation of the command on the 68060 (according to the Motorola manual only in emulation, not in hardware) would make the version slower in graphics output. Ultimately there is only one Q40 version of SMSQ/E (which is certainly used for both Q40 and Q60, there is no specific Q60 version in WL's binary ZIP).

So does this mean that the Q40 with 68040 (which can do MOVEP in hardware) is also slower than it could be?

[Artificer]

RalfR wrote "The 68060 cannot do MOVEP, TT expressly points out that there should be different versions for 680x0 and 68060 (the registrar is responsible for this, writes TT) and the emulation of the command on the 68060 (according to the Motorola manual only in emulation, not in hardware) would make the version slower in graphics output. Ultimately there is only one Q40 version of SMSQ/E (which is certainly used for both Q40 and Q60, there is no specific Q60 version in WL's binary ZIP)."

The MOVEP instruction was removed from smsq/e from version 3.00 onwards so there was/is no need to have separate versions of smsqe for the Q40 and Q60. I doubt that the MOVEP instruction could be the cause of the QLib problem with copyback. Because there are MOVEP insructions in Text87 I still LRESPR the software patch for this program and no as there are no MOVEP instructions in smsqe it does not slow the Q60 as I get benchmark speeds like Peter Graf on his Q60.

Cheers

[RalfR]

RalfR wrote "The 68060 cannot do MOVEP, TT expressly points out that there should be different versions for 680x0 and 68060 (the registrar is responsible for this, writes TT) and the emulation of the command on the 68060 (according to the Motorola manual only in emulation, not in hardware) would make the version slower in graphics output. Ultimately there is only one Q40 version of SMSQ/E (which is certainly used for both Q40 and Q60, there is no specific Q60 version in WL's binary ZIP)."

The MOVEP instruction was removed from smsq/e from version 3.00 onwards so there was/is no need to have separate versions of smsqe for the Q40 and Q60. I doubt that the MOVEP instruction could be the cause of the QLib problem with copyback. Because there are MOVEP insructions in Text87 I still LRESPR the software patch for this program and no as there are no MOVEP instructions in smsqe it does not slow the Q60 as I get benchmark speeds like Peter Graf on his Q60.

I didn't even say that the MOVEP instruction was responsible for this, my primary concern was that the 68040 could do that and therefore might be faster.

What patch is there for text87 and where can you get it?

[tofro]

MOVEP is only relevant for MODE 8 and MODE 4 (i.e. the "original" QL color modes) on the Qx0, because the weird layout of the QL pixel colours fits the (also weird) MOVEP instruction very well. For high-color modes, MOVEP is neither relevant nor useful.

That means, yes, in original QL color modes, the Q40 screen driver is somewhat slower than it could be. The original QL ROM's screen driver, however, is also slower than it could be - It uses MOVEP only for window PANning, apparently.

[XorA]

Surely a movep error would be really easy to debug, you'll get a trap.

[Derek_Stewart]

... well producing the Q60 from a perfect hardware design in 2002, I had to use a bugged and bearly functional operating system.

In retrospect QDOS Classic by Mark Swift mag of been better. But I preferred to use SMSQ/E.

The MOVEP issue has nothing to do with the 68040, 68060 Cache problem, that was not another bodge done by the SMQ/E programming team. Which I was keep out of the group and had no input, till recent times.

The problem looks to me lack of understanding of the Cache instructions, but the use and definition is clearly outlined in the SMSQ/E Reference Manual. Quite strange.

I will do an analysis of the setup of the Q60 caching in the SMSQ/E source code.

[RalfR]

The MOVEP isxue has nothing to do with the 68040, 68060 Cache problem

This was just a comment on the text you mentioned, because I noticed it.