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
SuperBASIC buffer BV.BFBAS
-
- Aurora
- Posts: 926
- Joined: Sat Oct 25, 2014 9:53 am
Re: SuperBASIC buffer BV.BFBAS
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.
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.
-
- Aurora
- Posts: 926
- Joined: Sat Oct 25, 2014 9:53 am
Re: SuperBASIC buffer BV.BFBAS
... I found the SQLWorld article from within the DIY TK documentation - it's in the first volume 'A', a Quill doc called 'sbvector_doc'...
- janbredenbeek
- Super Gold Card
- Posts: 632
- Joined: Wed Jan 21, 2015 4:54 pm
- Location: Hilversum, The Netherlands
Re: SuperBASIC buffer BV.BFBAS
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.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*
Jan.
-
- Aurora
- Posts: 852
- Joined: Tue Dec 17, 2013 1:17 pm
Re: SuperBASIC buffer BV.BFBAS
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.
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.
-
- Aurora
- Posts: 926
- Joined: Sat Oct 25, 2014 9:53 am
Re: SuperBASIC buffer BV.BFBAS
That's my understanding - it will never be reduced in size below that initial default.
- janbredenbeek
- Super Gold Card
- Posts: 632
- Joined: Wed Jan 21, 2015 4:54 pm
- Location: Hilversum, The Netherlands
Re: SuperBASIC buffer BV.BFBAS
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.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.
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.