My "from PACKAGE import *" (Python) simulation project (reflection)

[Derek_Stewart]

Hi,

With regards, to numberless boot programmes, I asked Laurence Reeves at a Quanta Workshop I organised in 1993, in Whitley Bay, Newcastle Upon Tyne, about numberless programmes, he seemed non-committal and seemed to like the idea, but maybe the control structures would have problems.

I stopped using this in SMSQ/E, where various experts said it was a bug fix, sorry I forget who, too many years ago.

I am interested in this Simulation Project, and it is refreshing to talk to professional people like Peter, who can programme computers correctly, I mean criticism.

Not a STOP statement, maybe PAUSE 10e100

[tofro]

Me, personally, I see numberless BOOT programs (or numberless S*BASIC programs in general) more of an oversight sold as a "feature" (in Jan Jones' book) after the fact. But that's just an opinion fed by the hint that no original QL manual ever mentioned numberless BASIC files, and the first mention came up with the TK2 "DO" command (which used to have its own quirks in versions before 2.50). With numberless programs used with anything else but (a working) DO you can also run into all sorts of problems like files left open and be no longer editable,....

On the other hand, I have no problem if someone wants to use this quirk for something not possible otherwise - As long as it is made sure that all files are properly closed on all QDOS versions, which would be quite a feat. (As BOOT programs are, for most users, a "private thing" not distributed broadly, I'm not too fundamentalistic about that. But if you want to build a program feature based on them that could become widely distributed, you'll likely not do yourself a favour - You'll very probably produce a "works on my machine" program.)

[polka]

Hum ! I did not want to show MY boot program, only to use a typical boot program as an example to show how a little "Add_Line_Numbers" FuNction could together with all the power of MERGE, MRUN etc. let develop SuperBasic programs as an assemblage of unnumbered modules that are numbered and eventually managed only with SuperBasic IF ... ENDIF ( or other...) constructs, automatically on the fly when the program is loaded, and that no other special tools would be absolutely needed than those provided by BBQL SuperBasic + TK2.

The benefit being that everything is SuperBasic and thus remains individually small, readable and easily editable.

[ql_freak]

Finally I have found time to correct my reflection_cde toolkit :-)

Much thanks goes to Per Witte, who found and corrected a lot of bugs and provided a SuperBASIC test program. With the versions which were downloadable here until now, this program will fail (or even crash?) with out of memory.

Warning: It is under development, the only functions currently working are:

REF_GETLNLO% Returns the lowest line number of currently loaded SuperBASIC program.
REF_GETLNFREE% Returns the first "free" (lowest not yet used) line number (REF_GETLNHI%+1) of currently loaded SuperBASIC program
REF_GETLNHI% Returns highest line number of currently loaded SuperBASIC program (for Derek, I don't know why it should be useful, is the same as REF_GETLNFREE%-1)

Please note, except for merging REF_GETLNFREE% can be used to end your program with GO TO REF_GETLNFREE%

DO _N_O_T_ use the other function (REF_L%), it will not work and may (will?) crash your machine.

You also should not use the one PROCedure, albeit it does nothing, except slow down (most probably not notable) your program, it does currently nothing. I'm working on REF_L%. When I have finished, I will publish the source.

Included is also the current version of the executable rn program (it should be reentrant and if EJC documentation is correct even ROMable as it is compiled with EJC), which renumbers text files with or without line numbers (even mixed), but _N_O_T_ included GO TO and GO SUB statements(!). Look at examples from me in this thread, how you can combine this with REF_GETLNFREE% to merge any SuperBASIC (without GO TO or/and GO SUB statements!) program or command line file with your program, without the need to renumber the merged or your program. I will publish the source code of rn shortly (must refactor it before it can be published).

This may be useful for BBQLs with just Microdrive mass storage, as your stored programs must not include all the stuff needed at runtime, but can MERGE common routines when it runs (see examples from me in this thread).

tstreflect_bas is the test program from Per for reflection_cde (you should rename reflection0v1v0_cde to reflection_cde and use the original filename only for backups (so that you must not look inside the _cde file to find the version number).

rnTestFile01_bas (it is not a valid BASIC program!) is for testing the rn program with e.g.:

ex'rn';'10000 5 <WIN1_tmp_rnTestFile01_bas >WIN1_tmp_DELETE_ME'

[ql_freak]

I would prefer all S*BASIC programmes to numberless, and all programming could structured.

From what I have seen (determined) when developping reflection_cde SuperBASIC does NOT (not even in its tokenized form!) require line numbers. When I have finished reflection_cde (one PROC and one FuNc are still missing, before the 1.0 [or better 0.99] version), I will try to poke a tokenized numberless program into the BASIC-area, adjust the BASIC and System variables and try to run it.

Even if the interpreter will not run it or even the QL will crash:

It should be very easy to extend the interpreter so that it can run BASIC programs without line numbers (albeit ED would most probably not work with those programs and must also be extended, this could be a bit more complicated). The line numbers are really only required for GO TO, GO SUB, ... If you don't use it, it's absolutely not required. E.g. Python has no GO TO and more worse, it has no possibility to exit from an inner loop out of an outer loop (no problem in SuperBASIC, every loop has a name so you could use exit LOOPNAME (which is a kind of GO TO).

[ql_freak]

2025-06-15 Sun (cottage/home):

Problem (REF_L%) get parameter via a3 (NOT CA.GTSTR!)

Technical Guide says A3 points to the first parameter (my function
is using just the first parameter, all others are ignored). So I get
the first parameter with:

move.w 0(a6,a3.l),d5

into register D5 (this seems to work).

Then I make a test if parameter is preceeded by hash (#); I will perhaps
later allow an hash for an extension, so for now it's forbidden.

Now I test for if parameter is a string (type $0201 aka ntString).

Yes it is :‑)

Then there is my problem. Technical Guide says:

A3 points to the entry of the Name Table entry of the first parameter. The
Name Table entry is 8 bytes, first word is the type of the parameter. That's
ok, it is $0201 :-), second word is the pointer to the name in the Name List.
This pointer is -1 if there is no name for the parameter in the Name List,
this is also okay (it's FFFF which is -1 in decimal). Technical guide says
the last long word of the name table entry is the offset of the value in the
SuperBASIC Variables Value Area (BV.VVBAS). Offset means it's not a direct
pointer to the value, but the offset into BV.VVBAS from start of BV.VVBAS (which
you IMHO should always get with 28(a6); BTW: If not explicitly noted all values
are of course in hex.

So I think you should get the value of the parameter (a pointer to a string
in my case) with the code between:

;BEGIN Supervisor Mode
and
;END Supervisor Mode

into register a0.

(IMHO the code would run in 99.9% without the switch into SV-Mode, but if
a new job will be started, SuperBASIC (A6) may move, so I be careful.)

Unfortunately it does not work. What's my fault?

NOTE: I do NOT want to use CA.GTSTR to fetch the parameter via the RI-Stack!
In my machine code function I just need the value of the parameter (a normal
QDOS-string) to compare it with another QDOS-string. So I want to avoid
CA.GTSTR (which requires to adjust the RI-Stack and some other things). The
string is there (pointed to via A3 into the Name Table), why should I put it
on the RI-Stack (which must be reset before returning to the caller).


Here is the assembler code (not assemblable[!], the labels, definitions like
equ are missing):

Code: Select all

;Example (not working) for getting string value of a parameter which is
;NOT fetched with the vector CA.GTSTR:
        cmpa.l   a3,a5          ;Are there any parameters?
        beq      errBadParameter ;No
        move.w   0(a6,a3.l),d5  ;Load type info of parameter
        btst     #bcHash,d5     ;Parameter preceeded by hash?
        bne.s    errBadParameter ;Yes
        cmp.w    #ntString,d5   ;Parameter is string? (We mustn't
        bne.s    errBadParameter ; currently care about separator
                                 ; as hash not allowed and it's
                                 ; the first parameter)

        move.l   ntValPtr(a6,a3.l),d7 ;d7=offset of string para. in VVA
;BEGIN Supervisor Mode:
         trap    #0              ;Switch into Supervisor Mode
         move.l  BV_VVBAS(a6),a4 ;Get base of variables values area
         move.l  8(a4,d7.l),a0   ;a0 should now point (absolute!) to
                                 ;string parameter in VVA
         sub.l   a6,a0           ;make a0 ptr relative to a6

         andi.w  #endSV,sr       ;Clear Supervisor Flag
;END Supervisor Mode
         move.w  0(a6,a0.l),d5   ;d5 should now hold length of string
;
; What am I doing wrong?
; (After LRESPRing this _cde file the following statement outputs 0
; (I think it should output the length of the string, i.e. 1 for the
; example below):
;
; PRINT REF_L%('x')

;preliminary for debugging, we always return 32767 (i. e. stop prog)
        move.l   #32767,d4      ;DEBUG: Return max. allowed line no.

;Following are debugging statements only, to get value in d5:
        ;and.w   #wRmHash,d5  ;Just for testing, remove eventual hash
        move.w   d5,d4        ;Just for testing, what's in d5?

        move.w    BV_CHRIX,a0   ;We need space on RI stack
        moveq     #2,d0         ;2 bytes required for line number
        move.l    BV_RIP(a6),a1 ;Per: Only QDOS needs this move
        jsr       (a0)
;Per Witte (thank you): We must correct the stack pointer with:
        subq.l    #2,BV_RIP(a6) ;This i where the real stack top is so
                                ;here's where we need to take the space
        move.l    BV_RIP(a6),a1 ;Restore RI stack pointer
        move.w    d4,0(a6,a1.l) ;Push line no. (short int) ...
        moveq     #QINT,d4      ;... set return type (integer [short])
        moveq     #0,d0         ;No error
        rts                     ;Return to SuperBASIC

errBadParameter
        moveq   #ERR_BP,d0
        rts