Page 29 of 30
Re: Q_Liberator malaise
Posted: Sat Jul 12, 2025 3:50 pm
by 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
Re: Q_Liberator malaise
Posted: Sun Jul 13, 2025 10:46 am
by 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.
Re: Q_Liberator malaise
Posted: Sun Jul 13, 2025 1:03 pm
by Martin_Head
Mark Swift wrote: Sat Jul 12, 2025 1:01 pm
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.
Re: Q_Liberator malaise
Posted: Sun Jul 13, 2025 2:39 pm
by Mark Swift
Hi Martin,
Martin_Head wrote: Sun Jul 13, 2025 1:03 pm
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.
Martin_Head wrote: Sun Jul 13, 2025 1:03 pm
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
Re: Q_Liberator malaise
Posted: Sun Jul 13, 2025 10:17 pm
by janbredenbeek
Mark Swift wrote: Sun Jul 13, 2025 2:39 pm
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.
Re: Q_Liberator malaise
Posted: Mon Jul 14, 2025 4:19 pm
by 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.
Re: Q_Liberator malaise
Posted: Tue Jul 15, 2025 2:17 pm
by 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.
Re: Q_Liberator malaise
Posted: Wed Jul 16, 2025 4:51 pm
by 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.
Re: Q_Liberator malaise
Posted: Thu Jul 17, 2025 8:51 am
by Martin_Head
Artificer wrote: Wed Jul 16, 2025 4:51 pm
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.
Re: Q_Liberator malaise
Posted: Thu Jul 17, 2025 9:28 am
by 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.