"Vectoring" in modern BBC BASIC implementations?

[alex_farlie]

I recently came across an 'enhanced' Sound Module for RISC OS called RDSP ( http://www.amcog-games.co.uk/rdsp.htm ) and wondered if given the availability of the source code for BBC Basic for SDL (and various open sourced sound processing toolkits), a third party might eventually want to implement something like that, or alternatively 'compatibility' layers to provide RISC OS style voice generators in BBC BASIC on other platforms.

BBC Basic for SDL supports SOUND and ENVELOPE via internal routines.

I was unsure if modern implementations of BBC BASIC on non acorn had a way of "vectoring" calls that would otherwise be made to their internal routines (On 8-bit BBC BASIC implementations , SOUND and ENVELOPE made MOS calls which were vectored via a jump table at &200 in low memory if I recall).

Was there an agreed approach or alternative to 'vectoring' in respect of modern implementations of BBC BASIC (such as BBC Basic for SDL), that would let third party developers with appropriate expertise ( I am not) write 'extensions' for modern BBC BASIC implementations, ideally in a cross platform manner?


Another technique used on 8 bit Acorns was to intercept the ''Unknown Plot Codes vector'' to provide specific graphics or character formatting that wasn't provided in the MOS. To some extent on modern implementations this has been replaced by calling external routines via SYS commands specific to a given platform or support environment. Alternatively, the relevant functions are provided by a function library, which implements the desired behaviour, and rather than using a VDU 23 or 25 seequence directly, the relevant function is used instead.

Are there other 'enhancements' that would typically have used a 'vectored' routine on Acorn platforms, that have alternatives in writing code for modern implementations?

[Deleted User 9295]

I was unsure if modern implementations of BBC BASIC on non acorn had a way of "vectoring" calls that would otherwise be made to their internal routines

I can't speak for any others, but BBC BASIC for Windows and BBC BASIC for SDL 2.0 don't. Extensions to their functionality tend to be achieved by SYS calls (either directly or via a library) rather than by 'redirecting' existing statements. For example playing WAV or MP3 files is done that way rather than by extending SOUND.

[Soruk]

I was unsure if modern implementations of BBC BASIC on non acorn had a way of "vectoring" calls that would otherwise be made to their internal routines

I can't speak for any others, but BBC BASIC for Windows and BBC BASIC for SDL 2.0 don't. Extensions to their functionality tend to be achieved by SYS calls (either directly or via a library) rather than by 'redirecting' existing statements. For example playing WAV or MP3 files is done that way rather than by extending SOUND.

Matrix Brandy does not vector either. Like BB4W and BBCSDL any extensions would be implemented via a SYS call (but done differently!)

This module is also making use of the fact the ENVELOPE command on RISC OS, while it does nothing normally, correctly sets up the data block and calls the appropriate OSWORD (or OS_Word) call, which in RISC OS is not implemented so does nothing. By being able to intercept and thus implement this call it works from BASIC.

[jgharston]

Are there other 'enhancements' that would typically have used a 'vectored' routine on Acorn platforms, that have alternatives in writing code for modern implementations?

Z80 BBC BASIC on the CoPro environment vectors via the normal Z80 environment via the jump block at &FFC0-&FFFF.

ARM BBC BASIC on RISC OS vectors via the normal SWI vector block.

PDP11 BBC BASIC on the CoPro vectors via the normal EMT vector block.
PDP11 BBC BASIC on Unix vectors via an internal vector block that is enabled by building with VECTOR enabled.

6809 BBC BASIC vectors via the 6502-look-alike vector block at &200.

Handling and redirecting system calls is a host system thing, not a BBC BASIC thing, it's dependant on the host system. It's difficult to define a BASIC interface to such a low-level host functionality.

[alex_farlie]

Are there other 'enhancements' that would typically have used a 'vectored' routine on Acorn platforms, that have alternatives in writing code for modern implementations?

Z80 BBC BASIC on the CoPro environment vectors via the normal Z80 environment via the jump block at &FFC0-&FFFF.

ARM BBC BASIC on RISC OS vectors via the normal SWI vector block.

PDP11 BBC BASIC on the CoPro vectors via the normal EMT vector block.
PDP11 BBC BASIC on Unix vectors via an internal vector block that is enabled by building with VECTOR enabled.

6809 BBC BASIC vectors via the 6502-look-alike vector block at &200.

Handling and redirecting system calls is a host system thing, not a BBC BASIC thing, it's dependant on the host system. It's difficult to define a BASIC interface to such a low-level host functionality.

So the issue isn't of BBC BASIC vectoring, but the underlying MOS emulation/compatibility layer? Hmmm...

[jgharston]

So the issue isn't of BBC BASIC vectoring, but the underlying MOS emulation/compatibility layer? Hmmm...

Yep.

During Lockdown I've been bashing away at writing a RT11 HostIO module for PDP11 BBC BASIC, and have been testing on a Soviet UKNC/Electronica. Which has close to zero documentation on low-level I/O. I've implemented text control, I know the host supports graphics, but at this point I've decided to implement a UKVDUV in the HostIO layer as even with translating reference documents from Russian I have no idea how to do graphics. However, at this point I haven't worked out and/or decided how the foreground accesses UKVDUV, as I should do it in a way where the concept is portable into the HostIO layer of other PDP11 environments - eg somebody running Unix with a graphics-capable terminal. (tho' on Unix, doing bbcbasic | graphicsdriver is the way to do it, in the same way as colour is done with bbcbasic | ansi)

(I only got text working by disassembling Vilnius BASIC and working out what the COLOR command was doing, and single-stepping through the code. see link)

[alex_farlie]

However, at this point I haven't worked out and/or decided how the foreground accesses UKVDUV, as I should do it in a way where the concept is portable into the HostIO layer of other PDP11 environments - eg somebody running Unix with a graphics-capable terminal. (tho' on Unix, doing bbcbasic | graphicsdriver is the way to do it, in the same way as colour is done with bbcbasic | ansi)

Like for example a system with a Textronix 4010 ( or an emulation thereof). Interesting.

[Deleted User 9295]

So the issue isn't of BBC BASIC vectoring, but the underlying MOS emulation/compatibility layer? Hmmm...

I think the issue is more: what would be the point? BBC BASIC for Windows has been in existence for 20 years or so and in all that time I can't remember a single occasion on which I've thought "it would be useful if built-in statements and functions were vectored" (if I had, they would be!). Perhaps you can suggest a usage case which illustrates the benefits you think it could have.

[Soruk]

However, at this point I haven't worked out and/or decided how the foreground accesses UKVDUV, as I should do it in a way where the concept is portable into the HostIO layer of other PDP11 environments - eg somebody running Unix with a graphics-capable terminal. (tho' on Unix, doing bbcbasic | graphicsdriver is the way to do it, in the same way as colour is done with bbcbasic | ansi)

Like for example a system with a Textronix 4010 ( or an emulation thereof). Interesting.

Matrix Brandy can do this - http://scruss.com/blog/2019/11/25/schot ... -tek-4010/

[alex_farlie]

So the issue isn't of BBC BASIC vectoring, but the underlying MOS emulation/compatibility layer? Hmmm...

I think the issue is more: what would be the point? BBC BASIC for Windows has been in existence for 20 years or so and in all that time I can't remember a single occasion on which I've thought "it would be useful if built-in statements and functions were vectored" (if I had, they would be!). Perhaps you can suggest a usage case which illustrates the benefits you think it could have.

Other than the two examples I gave which relate to SOUND and PLOT (and are easily replaced by a procedure) I cannot think of any examples, so will defer to your technical expertise and experience. If I think of any I'll note them.

The issue of 'cross-platform' sound-handling for doing sound that's more advanced than that provided by the internal sound system is a different issue.

(Aside: I've also had an idea in relation to your 'dispaly-list sprites' idea , which I will raise in the relevant thread, once I have had some further thought on it.)

[jgharston]

Pondering this while wandering around Morrisons, the "normal" way to catch a vector from BASIC would be to assemble the destination code, then call it, eg:
[OPT p
blah blah...
.startup
LD HL,(wrchv)
LD (oldwrchv),HL
LD HL,newwrch
LD (wrchv),HL
RET
]:NEXT
CALL startup

or *RUN some code which does the same.
*RUN vduextend
(Other than those cases where the program does !old=vector:?vector=new:vector?1=new DIV 256)

So leave it to platform-specific functionality, don't try to build something into BASIC.

[jgharston]

So the issue isn't of BBC BASIC vectoring, but the underlying MOS emulation/compatibility layer? Hmmm...

I think the issue is more: what would be the point? BBC BASIC for Windows has been in existence for 20 years or so and in all that time I can't remember a single occasion on which I've thought "it would be useful if built-in statements and functions were vectored" (if I had, they would be!). Perhaps you can suggest a usage case which illustrates the benefits you think it could have.

Yes, that's why I ended up making the default build for PDP BASIC to be 'no vectors'. Certainly at the VDU level anything can be done on Unix builds via the standard Unix pipe system. I only started pondering recently when writing a RT11 Host IO layer, and that doesn't have the stream redirection sort of functionality that Unix has. Even then it only became something to think about when I discovered the UKNC that runs RT11 and has graphics capabilities.