Q_Liberator malaise

[Artificer]

pjw wrote:
Q_ERR_xxx figures largely in the Qlib compiler itself..

True, and QLib unmodified does not run on the Q60 with copyback enabled, at the moment it needs Wolfgang Lenerz's patch programs.

Cheers

[RalfR]

Aha, so the whole problem could also be related to the handling of Q_ERR_xx?

That reminds me of a tool by Steve Jones that was included on the "Sidewinder de Luxe" disk. It allowed you to generate a function from any MC procedure(!) and then have a new keyword.

[Martin_Head]

Hi,

It's likely that the data cache will need to be flushed out to memory after this routine; before it can be executed as code.

Code: Select all

; Make 28 copies of this code in allocated buffer
L014E   clr.l   (a0)+
        move.l  #$207AFFFA,(a0)+     ;movea.l  $01FFFC(pc),a0
        move.l  #$4E903D40,(a0)+     ;jsr  (a0)
        move.l  #$00C27000,(a0)+     ;move.w  d0,lv_qerno(a6)
        move.w  #$4E75,(a0)+         ;moveq  #$00,d0
                                     ;rts
        dbf     d1,L014E             ;loop

Thanks

Is there a system trap, or vector to do this.
Or is it a processor instruction

And is it 68060/Q60 specific. If so, how could I test for a Q60.

[Mark Swift]

Hi Martin,

Is there a system trap, or vector to do this.

I may be wrong, but I don't believe that there is a system trap.

And is it 68060/Q60 specific. If so, how could I test for a Q60.

Copyback is only available on 68040+. Offset 161 in the system variables should hold the processor type (68040=$40).

This code should work if called from supervisor mode, with a6 pointing to the system variables.

Code: Select all

        cmpi.b  #$40,$A1(a6)
        bls.s   NOPUSH               skip if 040 or less

        dc.w    $4E7A,$0002          movec cacr,d0
        tst.w   d0                   check 040 bits
        bpl.s   NOPUSH               branch if data cache off

        dc.w    $F478                cpusha dc ; update memory from cache
NOPUSH:

BTW; another possible problematic bit of code is this.

Code: Select all

        move.w  sr,d6                ;save the status register
        trap    #$00                 ;enter supervisor mode
        adda.l  a6,a1                ;make A1 absolute
        moveq   #$00,d2
        move.b  (a1)+,d2             ;get names length byte
        suba.l  a0,a0                ;zero A0
        moveq   #-$01,d3             ;timeout
        moveq   #iob.smul,d0         ;IO.SSTRG  Send MULtiple bytes
        trap    #$03
        move.w  d6,sr                ;restore status register, and back into user mode

Moving to and from the SR is a privileged instruction on 68010+
Although; QDOS Classic emulates the instruction and I assume that SMSQ/E will do the same.

Thanks, Mark

[janbredenbeek]

Moving to and from the SR is a privileged instruction on 68010+
Although; QDOS Classic emulates the instruction and I assume that SMSQ/E will do the same.

Move to SR is always privileged, move from SR is privileged on the 68010+.
Minerva and SMSQ/E emulate the latter by converting it to MOVE CCR,x (which doesn't exist on the 68000/8).
QDOS Classic doesn't emulate and bails out with privilege violation.

[Martin_Head]

I have done some rework to the Q_ERR_xx SuperBASIC extensions.

There is qerr601A, which has no cache flush. And qerr601B, which has a cache flush.

They both seem to work OK in QPC2, could someone test them in a Q60.

The code is a bit inefficient, but I just want to know if it fixes the problem.

I just tried to incorporate it into QTrans2. There's an extension file that contains QLIB_EXT, QPIPE,and QERR. I tried to replace it with 3 separate files.

QTrans compiles OK, but now won't run, It throws up errors. A job for another day.

[Martin_Head]

Tried doing a build of QTrans2 again with the replacement Q_ERR commands.

And today it all went fine. I don't know what I was doing wrong yesterday.

Here are two versions of QTrans2. The DB3A has the new Q_ERR, without any data cache flush. And DB3B has the data cache flush.

I don't know if the cache flush is needed or not. Also all the debugging stuff is still there as before.

[Artificer]

I have found time to test qtrans2DB3A and qtrans2DB3B on my Q60.
The DB3A version when using the internal viewer stops at line 18232 with the program hanging as before. No channel open to the chosen file.

TheDB3B version steps through all the debugs steps and displays the chosen file. The file can be scrolled up and down and the internal viewer will
return to the main file windows to allow further actions on other files.

With both the DB3A and BD3B if when viewing a file the FI2 option is chosen the program stops the QLIB error message " Line 13100 Error 19 indices wrong".
This seems to be a bug that has been introduced somewhere as when I run the original version of qtrans with the old runtimes bodged off file viewing via FI2
works perfectly, although the internal viewer hangs as before.

[Martin_Head]

I have found time to test qtrans2DB3A and qtrans2DB3B on my Q60.
The DB3A version when using the internal viewer stops at line 18232 with the program hanging as before. No channel open to the chosen file.

TheDB3B version steps through all the debugs steps and displays the chosen file. The file can be scrolled up and down and the internal viewer will
return to the main file windows to allow further actions on other files.

So it looks like the cache flush is needed.

With both the DB3A and BD3B if when viewing a file the FI2 option is chosen the program stops the QLIB error message " Line 13100 Error 19 indices wrong".
This seems to be a bug that has been introduced somewhere as when I run the original version of qtrans with the old runtimes bodged off file viewing via FI2
works perfectly, although the internal viewer hangs as before.

My decompile of QTrans2 has not been tested, so there is probably a few problems lurking in it.

[dilwyn]

Assuming that line numbers have remained the same as in the sources, here's the bit of source around that line:

Code: Select all

13080       REMark we are using File Info 2 for viewing
13090       IF CHECK('FI2_FCALL') THEN
13100         fer = FI2_FCALL(src$&file_name$)
13110       ELSE
13120         fer = FEXF(src$&file_name$)
13130       END IF

To call FileInfo2 from BASIC, there was an old, deprecated method (FEXF, which I think clashed with a new SBASIC keyword or something) and the approved method using the keyword FI2_CALL, which doesn't exist in older FileInfos.

When I first released QTrans people complained it "didn't work" with FileInfo 2. After long drawn out conversations (people who vaguely report bugs are no good at explaining themselves) it turned out they used older FIleInfos and didn't know/weren't prepared to update. So I had to come up with a method of using the later version but falling back onto the older version if need be. CHECK looks for the FI2_CALL keyword (returns 1 if it exists and 0 if it doesn't - it's a function in DJToolkit).

To recompile you'll need to have the CHECK keyword installed and make sure it doesn't clash with any other system names as it's a commonly used name.