Tony Firshman wrote:
>>QA.RESRI.
>>> I haven't tried QDOS/Minerva on this yet, I hope they do the
>>> same.
>Ask Laurence Reeves ([EMAIL PROTECTED])
In the usual tradition of asking first before RTFM I found Minerva manual page
ASM.6 details how BV.CHxxx is dealt with. If enough memory can not be reserved
then address held at BV_SSSAV is called.
Per wrote:
>Superbasic returns straight back to the parser on an OM error in sb.resri.
This concurs.
SMSQ
I did a little trace of QA.RESRI but (due to stack manipulations which screwed
up tracing) it went awry. But I do recall seeing BV_SSSAV referenced before
I got an address error exception call (so I assumed it was incorrect reference).
Marcel, does this mean D0 will not return ERR_IMEM but simply stop SBASIC with
error? Which basically (sic) is the required result anyway. eg just call
BV.CHRIX/QA.RESRI and if it returns all is well.
Per wrote:
>I also notice that the value pointers in the name table have all gone
>absolute, ie even SB variable values are stored in some user heap outside the
>SB. Havent got round to arrays yet, but all my array-handling toolkits still
>seem to work, so perhaps no change there?
Now that rings a bell. In early coding days I wrote some array handling SBASIC
commands (which, given a channel, filled arrays directly from a MIDI data dump).
They worked well under SMSQ but failed when I qliberated the program. I just put
it down to different data structures in Qlib'd programs, perhaps it wasn't.
Qlib'ing the final program was doomed to fail anyway since by then I had
extensively used SMSQ SBASIC features/constructs that Qlib rejected :-(
O/T Qliberator
I wonder what the status of Qlib sources are, wasn't it going to be updated to
deal with SMSQ some time ago? Although SBASIC is as quick as compiled, you can't
circulate EasyPtr extensions separately to your programs. Writing a new program
using TPTR and Turbo would be OK but I wouldn't like to completely rewrite my
old EasyPtr programs to use it :-(
Regards,
Dave.
