The Sinclair QL Forum

Posted: **Sun Sep 21, 2025 4:34 pm**

New topic to avpoid flooding a different one, with mainly irrelevant stuff (Irrelevant to that other topic I mean!)

pjw wrote:I havent tested extensively but DECODE_SAV seems not to work with integer
tokens produced by Qloadref V1.9 and possibly other, not ancient, versions
of QSAVE. V1.9 is the current version of QLOAD/QSAVE that came with
Q_Liberator V3.36 and beyond. The SMSQ/E version works fine.

Do you know what the token codes that are being missed/messed are please? EDIT: $89 and $86 for 2 and 4 byte integers. However, I'm puzzled by the range of these as per your LIST document. two bytes covers values -128 through +127 and 4 byte integers are for 128 and above? Sadluy, I don't have Mievra to test with though. Could you upload me a quick and dirty test sample please? Much obliged.

pjw wrote: Note that these utilities are pretty useless. All they do is convert
tokenised S*BASIC programs (SAV files) into their human-readable form -
something the S*BASIC interpreters manage perfectly well on their own!

Of course they are! I knew that when I wrote mine many, many years ago. However, I was working on something or other back then---I forget what---and I needed the RAM to be able to do something with a SuperBASIC program. I didn't have enough RAM to have the source program and the proposed utility/program/application/whatever it was, loaded together.

The decode_sav mini-program was my starting point to decode a QSAVEd program which, if I had ever got around to finishing it, would have been converted to whatever the thing I was writing, back then, would have been!

Getting old is a PITA, you forget a lot of things!

Let's, for the sake of argument, say I had been planning to write a new version of Turbo. However, instead of compiling the source program already loaded, the plan was to QSAVE it and then compile the QSAVEd version, more memeory and/or bigger source programs could be compiled in that way. At least, that was my thinking. But no, I wasn't planning on rewriting Turbo!

Cheers,
Norm.

Posted: **Sun Sep 21, 2025 5:29 pm**

NormanDunbar wrote: Sun Sep 21, 2025 4:34 pm New topic to avpoid flooding a different one, with mainly irrelevant stuff (Irrelevant to that other topic I mean!)

pjw wrote:I havent tested extensively but DECODE_SAV seems not to work with integer
tokens produced by Qloadref V1.9 and possibly other, not ancient, versions
of QSAVE. V1.9 is the current version of QLOAD/QSAVE that came with
Q_Liberator V3.36 and beyond. The SMSQ/E version works fine.
Do you know what the token codes that are being missed/messed are please? EDIT: $89 and $86 for 2 and 4 byte integers. However, I'm puzzled by the range of these as per your LIST document. two bytes covers values -128 through +127 and 4 byte integers are for 128 and above? Sadluy, I don't have Mievra to test with though. Could you upload me a quick and dirty test sample please? Much obliged.

I havent quite finished. I havent tested the range for the four byte variant yet.

NormanDunbar wrote: Sun Sep 21, 2025 4:34 pm
pjw wrote: Note that these utilities are pretty useless. All they do is convert
tokenised S*BASIC programs (SAV files) into their human-readable form -
something the S*BASIC interpreters manage perfectly well on their own!
Of course they are! I knew that when I wrote mine many, many years ago. However, I was working on something or other back then---I forget what---and I needed the RAM to be able to do something with a SuperBASIC program. I didn't have enough RAM to have the source program and the proposed utility/program/application/whatever it was, loaded together.

I know you know, Norm ;o) My audience was those who dont.

NormanDunbar wrote: Sun Sep 21, 2025 4:34 pm The decode_sav mini-program was my starting point to decode a QSAVEd program which, if I had ever got around to finishing it, would have been converted to whatever the thing I was writing, back then, would have been!

Getting old is a PITA, you forget a lot of things!

Let's, for the sake of argument, say I had been planning to write a new version of Turbo. However, instead of compiling the source program already loaded, the plan was to QSAVE it and then compile the QSAVEd version, more memeory and/or bigger source programs could be compiled in that way. At least, that was my thinking. But no, I wasn't planning on rewriting Turbo!

That could work, and maybe it wouldnt be too hard either. But I dont think there is any need for it these days.
Heres the test program:

Code: Select all

100 Sel on x
102 = -300: print -300
104 = -257: print -257
106 = -258: print -258
108 = -1: print -1
110 = -100: print -100
112 =  0: print 0
114 =  1: print 1
116 =  126: print 126
118 =  127: print 127
120 =  128: print 128
122 =  129: print 129
124 =  130: print 130
126 =  131: print 131
128 =  132: print 132
130 =  254: print 254
132 =  255: print 255
134 =  256: print 256
136 =  257: print 257
138 =  300: print 300
140 =  500: print 500
142 end sel

I had to zip the SAV version:

demo.zip: Demo; (666 Bytes) Downloaded 3 times

It was QSAVEd with QLOADREF under Qdos, with QSAVE being version 1.9. I think it is identical if saved under Minerva with the same QLOADQREF. Ive just tried so many variants I no longer know which is which..

Posted: **Sun Sep 21, 2025 5:45 pm**

Talking of ambitious projects, I started to write an S*BASIC editor with syntax colouring and various other bells and whistles using my decoder as the starting point. Viewing code in glorious colour wasnt too hard, but editing was a lot more difficult (re-parsing each line, etc), so I abandoned the project and ended up merely outputting the code as HTML instead.

Posted: **Mon Sep 22, 2025 9:36 am**

Morning Per.

Many thanks for the test code. I'll see what I can make out of it soon.

Regarding a syntax highlighting editor, yes! Having watched a few of those in action, it looks like they watch every key press as the highlighting changes as the user types more of the word into the editor. After a space or other word delimiter, it takes its final form.

Difficult!

However, I'm sure someone on here has created a highlighter for S*BASIC for the Notepad++ editor on the PC.

Cheers,
Norm.

Posted: **Mon Sep 22, 2025 10:44 am**

NormanDunbar wrote: Mon Sep 22, 2025 9:36 am
However, I'm sure someone on here has created a highlighter for S*BASIC for the Notepad++ editor on the PC.

Cheers,
Norm.

https://dilwyn.theqlforum.com/basic/SuperBASIC_npad.zip

Posted: **Mon Sep 22, 2025 12:08 pm**

NormanDunbar wrote: Mon Sep 22, 2025 9:36 am Morning Per.

Many thanks for the test code. I'll see what I can make out of it soon.

I found a different version of the QLOAD suite. It doesnt have an embedded
version number, so Im calling it V1.8, as all the other non-SMSQ versions
Ive found are 1.9. The SMSQ/E version is 2.0

QSAVE V1.8 appears to produce the same output as V1.9 on the few files I
tried. I vaguely, perhaps erroneously, recall that there were other
versions out there that caused my LIST program some problems, but I cant
find any of those.

I can confirm that the LIST program published yesterday appears to have
correctly cracked the literal integer issue. I tested it against the
following list of numbers, QSAVED using all three versions of QSAVE found,
1.8 and 1.9 on Qdos and Minerva, and 2.0 on SMSQ/E.

Code: Select all

100 Sel on x
102 = -257: print -257
104 = -256: print -256
106 = -255: print -255
108 = -254: print -254
110 = -1: print -1
112 :
114 =  0: print 0
116 =  1: print 1
118 :
120 =  126: print 126
122 =  127: print 127
124 =  128: print 128
126 =  129: print 129
128 =  130: print 130
130 :
132 =  254: print 254
134 =  255: print 255
136 =  256: print 256
138 =  257: print 257
140 =  258: print 258
142 :
144 =  32765: print 32765
146 =  32766: print 32766
148 =  32767: print 32767
150 =  32768: print 32768
152 =  32769: print 32769
154 :
156 =  65534: print 65534
158 =  65535: print 65535
160 =  65536: print 65536
162 =  65537: print 65537
164 =  65538: print 65538
166 :
168 =  1E6: print 1E6
170 end sel

I have removed some debugging code from LIST V0.07 and reupped it. No version change, though.

NormanDunbar wrote: Mon Sep 22, 2025 9:36 amRegarding a syntax highlighting editor, yes! Having watched a few of those in action, it looks like they watch every key press as the highlighting changes as the user types more of the word into the editor. After a space or other word delimiter, it takes its final form.

Difficult!

Too right! You basically have to write your own parser. When SBASIC came out I thought I could perhaps use a hidden SBASIC daughter job to do the single line parsing. It works, but is a bit clunky. Anyway, not worth doing anymore for one and a half user..

NormanDunbar wrote: Mon Sep 22, 2025 9:36 amHowever, I'm sure someone on here has created a highlighter for S*BASIC for the Notepad++ editor on the PC.

I tried Notepad++ but there were things I didnt like. I bought TextPad back in the late 90s and that has served me well for the PC side of things. I never use it for S*BASIC programming.

Posted: **Mon Sep 22, 2025 1:36 pm**

pjw wrote: Mon Sep 22, 2025 12:08 pm Too right! You basically have to write your own parser. When SBASIC came out I thought I could perhaps use a hidden SBASIC daughter job to do the single line parsing. It works, but is a bit clunky. Anyway, not worth doing anymore for one and a half user..

There are a few undocumented vectors to the S*BASIC parser which are used by TK2's ED command. I used these to translate BASICODE to S*BASIC. The code for this is quite straightforward (assumed your line is in the BASIC buffer):

Code: Select all

* Enter line into S*Basic system
* uses rather obscure vector calls (credits to TK2's ED command)

P2_PARSE  MOVEM.L   A4-A5,-(A7)         must save A4 too on SMSQ/E!
          QDOS      MT.INF
          MOVE.W    $13A,A2             vector for pa_init routine
          CMPI.L    #'1.03',D2          QDOS version
          BHI.S     P2_E_2              if >1.03, routine is vectored
          MOVE.W    $12C,A2             ... but on <=1.03, it's not vectored
          ADDA.W    #$138,A2            so we have to find it using pa_graph
P2_E_2    JSR       $4000(A2)           initialise parser work areas
          MOVE.W    $12E,A2             parser's syntax table
          ADDA.W    #$4000,A2           add offset
          
* NEW: Test for JMP instruction at location of table
* This is silly, but necessary as SMSQ/E's SBASIC has the vector to the real
* location stored after the JMP (it's a table, not a subroutine!)

          CMPI.W    #$4EF9,(A2)         opcode for JMP.L?
          BNE.S     P2_E_2A             No, it's the real table
          MOVE.L    2(A2),A2            else, get table from JMP destination
P2_E_2A   MOVE.W    $12C,A0
          JSR       $4000(A0)           parse the line
          BEQ.S     P2_E_3              syntax ok? branch if yes
          MOVE.W    $134,A2             
          JSR       $4000(A2)           else, insert 'MISTake'
P2_E_3    MOVE.W    $132,A2             
          JSR       $4000(A2)           remove forced spaces
          MOVE.W    $136,A2
          JSR       $4000(A2)           and enter line into system
          NOP                           error return - ignored
          MOVEM.L   (A7)+,A4-A5
          RTS

pjw wrote: Mon Sep 22, 2025 12:08 pm I tried Notepad++ but there were things I didnt like. I bought TextPad back in the late 90s and that has served me well for the PC side of things. I never use it for S*BASIC programming.

It's actually great for moving and renumbering lines - just select the line numbers column using ALT and use the column editor to renumber.

Posted: **Mon Sep 22, 2025 2:05 pm**

janbredenbeek wrote: Mon Sep 22, 2025 1:36 pmThere are a few undocumented vectors to the S*BASIC parser which are used by TK2's ED command.

Fine, so Per can continue with his ColourED.

The Sinclair QL Forum

Decoding QSaved Files

Decoding QSaved Files

Re: Decoding QSaved Files

Re: Decoding QSaved Files

Re: Decoding QSaved Files

Re: Decoding QSaved Files

Re: Decoding QSaved Files

Re: Decoding QSaved Files

Re: Decoding QSaved Files