SuperBASIC buffer BV.BFBAS

Anything QL Software or Programming Related.
Post Reply
Martin_Head
Aurora
Posts: 847
Joined: Tue Dec 17, 2013 1:17 pm

SuperBASIC buffer BV.BFBAS

Post by Martin_Head »

I have seen some programs use the buffer area in SuperBASIC (bv.bfbas). They don't seem to make any tests, they just use it.

Can anyone tell me...
How big is this buffer area?
Is it a fixed size, or can it change?
If it's not big enough can you enlarge/reduce it?
And what is the point of the buffer running pointer bv.bfp


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: SuperBASIC buffer BV.BFBAS

Post by martyn_hill »

Hi again Martin

Here's my take:

. How big is this buffer area? - In QDOS, I believe it starts-off life at 128 bytes.

. Is it a fixed size, or can it change? - Not fixed - can change. In fact several of teh S*Basic commands do this internally as and when needed (like INPUT of a large string.)

. If it's not big enough can you enlarge/reduce it? - Yes, although the respective QDOS ROM routine was never formally documented (S Goodwin discussed the topic of 'hidden' SB memory management routines in SQLWorld - vectored from a word-offset from the one routine we know - BV.CHRIX). I think those routines _might_ have been formally exposed in Minerva or else SMSQ*

. And what is the point of the buffer running pointer bv.bfp - Heaven only knows. Perhaps it is just to remain consistent with the Table-type pointers (Bottom, Top and Running pointer) that are used elsewhere in the SB Variables area.


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: SuperBASIC buffer BV.BFBAS

Post by martyn_hill »

... I found the SQLWorld article from within the DIY TK documentation - it's in the first volume 'A', a Quill doc called 'sbvector_doc'...


User avatar
janbredenbeek
Super Gold Card
Posts: 629
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: SuperBASIC buffer BV.BFBAS

Post by janbredenbeek »

martyn_hill wrote:
. If it's not big enough can you enlarge/reduce it? - Yes, although the respective QDOS ROM routine was never formally documented (S Goodwin discussed the topic of 'hidden' SB memory management routines in SQLWorld - vectored from a word-offset from the one routine we know - BV.CHRIX). I think those routines _might_ have been formally exposed in Minerva or else SMSQ*
It was never formally documented or exposed. Software using it simply calls it via an offset from BV.CHRIX. If you look at the code, it has several entry points where D1 represents the number of bytes to reserve and D2 points to the running pointer, but only the BV.CHRIX entry point is vectored. Since it has been very common to call the other entry points via the BV.CHRIX vector offset, Lau had to duplicate most of the code.

Jan.


Martin_Head
Aurora
Posts: 847
Joined: Tue Dec 17, 2013 1:17 pm

Re: SuperBASIC buffer BV.BFBAS

Post by Martin_Head »

So is it reasonable to assume it's a 128 byte buffer? If another SuperBASIC command has changed it, it would not have made it smaller than 128 bytes?

I know you could work out the length (start of the token table? minus the start of BASIC). The times I have seen the buffer used, the programs just use it and don't seem to bother about checking the length.


martyn_hill
Aurora
Posts: 909
Joined: Sat Oct 25, 2014 9:53 am

Re: SuperBASIC buffer BV.BFBAS

Post by martyn_hill »

That's my understanding - it will never be reduced in size below that initial default.


User avatar
janbredenbeek
Super Gold Card
Posts: 629
Joined: Wed Jan 21, 2015 4:54 pm
Location: Hilversum, The Netherlands

Re: SuperBASIC buffer BV.BFBAS

Post by janbredenbeek »

Martin_Head wrote:So is it reasonable to assume it's a 128 byte buffer? If another SuperBASIC command has changed it, it would not have made it smaller than 128 bytes?

I know you could work out the length (start of the token table? minus the start of BASIC). The times I have seen the buffer used, the programs just use it and don't seem to bother about checking the length.
It starts off at 128 bytes after reset and might be expanded when needed (e.g. when INPUT data exceeds the buffer size) but AFAIK never gets reset.
Note that on AH and JM ROMs the INPUT command just returns a 'buffer full' error when trying to read longer strings than the buffer size. JS and later expand the buffer and retry the operation (appending the new data after the string already read).
An example of this is the GETLINE function at the end of this source file: https://github.com/janbredenbeek/QL-Bas ... bcproc.asm . It is basically the same as INPUT but returns the error status from the I/O device (but traps buffer overflows and retries with an expanded buffer).

Jan.


Post Reply