BASIC_INDEX%() and SBASIC/MultiBASIC

[dilwyn]

Unfortunately, I have no sources for TurboFix to be able to tell.

The original notes for the original version from Rich Mellor which are included with TurboFix 2 state:

BASIC_NAME$, BASIC_INDEX%, BASIC_TYPE%, BASIC_F, BASIC_L, BASIC_W% and
BASIC_B%
All of these will now either access SuperBasic's variables or those of a
MultiBasic (see above).

But refer to Minerva MultiBasic only (probably written before SBASIC came about).
The Turbo Fix 2 notes in the same package refer to another version modified by Simon Goodwin.

The notes from Davide Santachiara (Ergon Development) with TurboFix 2 state that:

A new version of TURBOFIX has been prepared. This allows to use
the following Turbo Toolkit keywords on Minerva MultiBasic or
SMSQ S-BASIC:
BASIC_POINTER / BASIC_B% / BASIC_W% / BASIC_F / BASIC_L / BASIC_NAME$
The previous version of Turbofix worked on Minerva but not on SMSQ.
This release is OK on both o/s.

And looking in the extensions file, it includes BASIC_INDEX% too.

Without the sources, we probably can't tell other than just trying it. If you have already tried the turbofix and it didn't work for you, the next step is probably to try to ask Davide if he can look at this if he still has the sources.
For anyone sufficiently familiar with the internal workings of SBASIC and Turbo, the Turbo Toolkit sources are available.

[dilwyn]

I forgot to include that I've tried this on my system, which has Turbo Toolkit v3.44 and the result agrees with your findings, that PRINT BASIC_INDEX%("x_%") in an SBASIC job returns error -12, error code for "Invalid name."

[ql_freak]

I have now tested it with TurboFix_bin. Also doesn't work in additional SBASIC jobs.

[pjw]

I have now tested it with TurboFix_bin. Also doesn't work in additional SBASIC jobs.

I tested BASIC_INDEX% with Turbo_SMS_CODE just now and it seems to work fine, both in Job #0 and in SBASIC daughter jobs! Im talking Turbo toolkit V3.44. I also tried Turbo_Fix (V2.10, which seems to be the latest) and this does NOT work. So I think it may just be a question of getting the right version of Turbo Tk installed, and to NOT load Turbo_Fix over it.

There is still one compatibility problem with Turbo_SMS_CODE: It overwrites SMSQ/E's better PEEK_F and POKE_F functions. But the source code is configured for a particular toolchain with which Im not familiar, and thats just too much trouble, so Ive just patched V3.44's version of PEEK_F and POKE_F to PEEK_X and POKE_X. This again has caused another compatibility problem: The Turbo parser uses a particular quirk of Turbo TK's version of PEEK_F, which has been eliminated from SMSQ/E's version, so to make this work, I had to patch the Parser too. You can find these patched versions in the Turbo section of Dilwyn's site as Turbo 510.

I wrote to George Gwilt a little while ago asking if he'd be prepared to make a new official version of Turbo. While I had an initial positive response from him (and John Southern) it has been quiet since then.

PS: The patched software is only needed for SMSQ/E, so Remainers should continue to use the standard EU versions.

[dilwyn]

I wonder if there's an element of misunderstanding how BASIC_INDEX% works here?

Although the same variable name can have different values in Job 0 and a daughter job, BASIC_INDEX% will return the same value for both (1050 on my system). In that sense, you can't use BASIC_INDEX% to differentiate between the same name in two jobs - it can be set in Job 0 (so in the name table) but might be undefined locally in the daughter job and BASIC_INDEX% would be none the wiser. (I don't know enough about how daughter jobs handle the name table entries)

Maybe I misunderstood originally that this was at the heart of Peter's problems? Being unable to differentiate between x_% and y_% being defined in Job 0, but not in the other SBASIC jobs?

[pjw]

I wonder if there's an element of misunderstanding how BASIC_INDEX% works here?
<>

You could be right. BASIC_INDEX% only reads job #0's name table and it can do that whether called from job #0, a daughter SBASIC, or (I presume) a compiled task. But it cant read the daughter job's private name table.
My FINDNAME% function can optionally read either the global name table, the private name table, or both, but it only cares about machine code functions and procedures, although that could quite easily be changed. Therefore, I suspect, it shouldnt be too hard to do the same for TurboFix. The source code is available to the intrepid Tinkerer..

[ql_freak]

First try (in SuperBASIC) for a BASIC replacement (ssems to work).

I even have a batch (SB without line numbers) for that, but this needs testing).

Code: Select all

100 REMark Preparation of a oneliner (for a batch file) to search the
110 REMark BASIC namelist for a name
140 :
180 :
1000 REMark Start of main() program
1040 :
1080 CLEAR
1090 xyz_nam$='n6'
1120 PRINT sbNameExists(xyz_nam$)
14840 :
14880 STOP
15820 :
15920 :
15960 :
16000 :
16040 REMark PROCedures and FuNctions
16080 :
17020 DEFine FuNction sbNameExists(sbnam$)
17030   LOCal idx,addr,namlen,name$
17060   idx=-1
18000     REPeat loop
18040       idx=idx+1
18080       addr=sbGetAddrOfName(idx):REMark PRINT'Address=';addr;' '
18120       IF addr=-1:RETurn 0
18160       namlen=PEEK(\$20\addr)
18170       name$=PEEK$(\$20\addr+1,namlen):REMark PRINT'Name: ';name$
18180       IF name$==sbnam$:RETurn 1
18200     END REPeat loop
18230     RETurn 0:PRINT#0,'Oops after END REPeat loop':REMark For safety, should never be reached
18240 END DEFine
19880 :
20000 DEFine FuNction sbGetAddrOfName(index):REMark Eventually an integer is enough?
20010   LOCal last,ntentry
20040   last=PEEK_L(\\$1C):REMark PRINT'last=';last;' ';
20080   ntentry=PEEK_W(\$18\2+index*8):REMark PRINT'ntentry=';ntentry
20160   IF ABS(ntentry)>=ABS(last):RETurn -1
20200   RETurn ntentry
20240 END DEFine

[RWAP]

TurboFix was my code - I should have the sources here somewhere

[pjw]

First try (in SuperBASIC) for a BASIC replacement (ssems to work).<>

Nice one! It does what BASIC_INDEX% doesnt do, namely search the current name table, which is not necessarily the same as the main name table.

However, it does overshoot the name table a bit, which means it does some unnecessary comparisons. How about a slightly simpler arrangement:

Code: Select all

100 DEFine FuNction FindName(nm$)
110 LOCal n, o, t%, l%
120 REMark If found returns name number..
130 REMark ..in this SBASIC only
140 :
150 REMark Size of Name Table, 8 byte entries
160 FOR n = 0 TO PEEK_L(\\ $1C) - PEEK_L(\\ $18) STEP 8
170  REMark Get type of name
180  t% = PEEK_W(\ $18\ n)
190  REMark This nonsense must be past the end
200  IF t% < 0 OR t% > $900: EXIT n
210  REMark Get offset in Name List
220  o = PEEK_W(\ $18\ n + 2)
230  REMark Skip no names and end of names
240  IF o < 0: EXIT n: REMark Not documented! May not always work?
250  REMark Get Name length
260  l% = PEEK(\ $20\ o)
270  REMark Compare name. (Could use INSTR)
280  IF nm$ == PEEK$(\ $20\ o + 1, l%): RETurn 1 + n DIV 8
290 END FOR n
300 RETurn 0
310 END DEFine FindName
320 :
330 :

If you make the following changes, you can see that it doesnt overshoot the name table but stops at the end:

Code: Select all

275  PRINT PEEK$(\ $20\ o + 1, l%)
280  REMark IF nm$ == PEEK$(\ $20\ o + 1, l%): RETurn n DIV 8

(Search for something you know isnt there, eg print FindName("findnamex") to see what I mean. Then do something similar with your code.)
This code is a basic template for scanning the name table from SBASIC. You could filter out the kind of name you want (eg 200 IF t% <> $900: NEXT n: EXIT n would filter out all names that were not m/c functions, etc..)
Its possible to do something similar for SuperBASIC.
One thing to bear in mind is that the whole S*BASIC area may move while youre scanning it, so results could come out wrong in certain cases!

[ql_freak]

TurboFix was my code - I should have the sources here somewhere

That's Good!

Than it should be easy to port BASIC_INDEX% to S/MultBASIC. I think the main problem is to get the name table. I have did it always via asking the System Variables for the start of the name table. But this seems not to be necessary (am I right?). Instead it seems you can address the BV variables simply by A(6).BV... which is also working in S/MultiBASICs. But I'm not sure(!).