The Sinclair QL Forum

ql_freak wrote: Here is the source code (unfortunately not finished, indeed not even one line of the real code is implemented):

Code: Select all

* SuperBASIC/SBASIC function string$ = GETLINE$(channel_number):REMark # optional
*
* Copyright (c) 2016 Dec 25, Peter Sulzer, Fuerth (Germany) - ALL RIGHTS RESERVED

* Definitions:
BP.INIT    EQU    $110        Initialise SuperBASIC/SBASIC PROCedures and FuNctions

            SECTION CODE


* Initialise SuperBASIC/SBASIC Extensions:
            LEA PROC_DEF,A1
            MOVE.W BP.INIT,A2  Note: In SMS(/Q) BP.INIT has a different name
            JSR (A2)

PROC_DEF
            DC.W    0           No of PROCedures
            DC.W    0           END of definitition of PROCedures
            DC.W    1           One (1) FuNction
            DC.W    GETLINE-*   FuNction GETLINE$(channel_number)
            DC.B    8           Name of GETLINE$ is 8 characters long
            DC.B    'GETLINE$'  The characters (8) of GETLINE$
            DC.W    0           END of definitions of FuNctions
            DC.L    0           For safety (LEN(GETLINE$) is longer than 7 chars)

GETLINE
*           Start below with the code of the GETLINE$() function
*            START HERE WITH OUR CODE

            END                 This signals to QMAC that this is the end

* Anything after the END directive (which doesn't produce any code) is ignored

It was, albeit I have programmed a lot of SB-Extensions in my old QDOS days, quite difficult after so much years. So I would be pleased, if you could tell me, if the above code is (PRINCIPALLY) correct.

p.s.: After some corrections (especially replacing the string delimiters from " to ') this source was assembled without errors with QMAC. Unfortunately it produces a "_rel" (relocatable object file), but I want to get a "_bin" file, so that I must not link. I have specified "-bin" in the command line - what's my fault?

ql_freak wrote:Next problem I try to find the "Name Table" of SuperBASIC (for then to find the address of the INPUT command), for testing I write it just in SuperBASIC, here is my code, but it returns 0, what's my fault:

Code: Select all

100 REMark Find Address of SuperBASICs INPUT Routine
200 :
300 SVS=VER$(-2):REMark  SVS is address of the system variables - ABSOLUTE!
400 SV_BASIC=HEX('10'):BV_NBAS=HEX('18'):BV_NLBAS=HEX('20')
900 :
1000 nt=PEEK_L(PEEK_L(SVS+SV_BASIC)+BV_NBAS):REMark get address of BASIC name table
1100 PRINT nt:REMark PRINT address of SuperBASIC Name Table - this prints 0 :-(

nt=PEEK_L(PEEK_L(SYS+SV_BASIC)+HEX('68')+BV_NBAS)

100 REMark ntdump_bas NameTable Dump Utility
110 REMark v0.0 20160720 Jan Bredenbeek
120 REMark requires: TK2 extensions AND Minerva OR SMSQ
130 DEFine PROCedure ntdump(ch$)
140 LOCal l,nt,ty,no,nl,nl$,ch
150   IF PARSTR$(ch$,1)<>"" THEN
160     ch=FOP_NEW(PARSTR$(ch$,1))
165     IF ch<0:PRINT#0;'Error opening file':RETurn
170   ELSE
180     ch=1
190   END IF
200   REMark loop for all NT entries
210   PRINT#ch;'Type','Pointer','Name'
220   FOR nt=0 TO PEEK_L(\\28)-PEEK_L(\\24)-8 STEP 8
230     ty=PEEK_W(\24\nt):REMark type
240     no=PEEK_W(\24\nt+2):REMark namelist offset
250     IF no>=0 THEN
260       nl=PEEK(\32\no):nl$=""
270       FOR l=1 TO nl:nl$=nl$&CHR$(PEEK(\32\no+l))
280     ELSE
290       nl$="*NO NAME*"
300     END IF
310     PRINT#ch;HEX$(ty,16),HEX$(no,16),HEX$(PEEK_L(\24\nt+4),32),nl$
320   END FOR nt
330   IF ch<>1:CLOSE#ch
340 END DEFine ntdump

1. Move away from strings completely. This would allow you to read data into raw memory, allocated using RESPR or ALCHP. This would remove all of the limits you currently see with strings. Turbo Toolkit has functions to PEEK$ strings from such memory, but then again you would duplicate your memory overhead. Makes the BASIC programming a bit more awkward, though. This is how DP's EDITOR works, if I recall it right.
2. Require your calling program to allocate the strings using DIM and pass that string into the MC procedure by reference - This is maybe the best approach. Get the variable in the MC procedure, look it up in the name table and check the amount of dimensions and the size of the allocation (first and second word entry in the name table's array descriptor after the value pointer). You would then only read as much bytes as fit into the DIMed string and read directly into the target string, without a temporary buffer, the user of your MC routine could decide how much memory he wants to spend, your MC routine would not have to deal with allocation at all. Add some reserved return value when your code detects "there's more to read" to signal to the user "your string is too small, come back to read more". There is a relatively precise description of the structure of DIMed strings and arrays in the DIY toolkit documentation on the MAX and MIN keywords. Such an approach does, however, rely on a valid name table structure and could thus not be compiled with Turbo (QLiberator would cope, though, I think). It might be a bit awkward to use, as you need to DIM a string before you can GETLINE$ a value into it, but I don't currently know a portable method to grow an S*Basic string in memory from an MC procedure.
3. Stay with your approach and allocate memory to the Ari stack in chunks of, e.g. 1024 bytes as you go. This can be relatively tedious and slow for long strings, as you'd have to move the whole string allocation maximum 32 times downwards when you re-allocate the target memory area for the growing string - And it would still duplicate memory: If you do a x$=GETLINE$, you need the memory for the string twice, once for the temporary return value on the arithmetic stack, the other for the target variable.
   target string in the assigned variable. This might look like a way to go at first but collects all the possible downsides of return value passing