BBC BASIC: Use of VDU as a function

[Deleted User 9295]

One of the questions asked after my BBC BASIC in the 21st Century presentation was why my BASICs don't support the use of VDU as a function. I've done a little bit of investigation into this and I've concluded that doing so would not be practical or desirable. The main reasons are as follows:

• I cannot find any 'official' documentation of this usage (it doesn't seem to be mentioned in the RISC OS BASIC manual).
• It appears to be supported only in Brandy and late versions of BASIC V (it doesn't work in v1.19, which is all I have).
• Many of the 'VDU variables' (as documented in the PRM here) have no direct equivalents in my BASICs.

So I won't be supporting this feature. In BBC BASIC for Windows and BBC BASIC for SDL 2.0 VDU variables may be accessed via the @vdu{} structure.

[paintings]

This was a RISC OS 5 feature, first made available in RISC OS 5.01 (BASIC 1.34).

The RISC OS 5 version of the BBC BASIC Reference Manual mentions it in Appendix H: the information is a repeat of the PRM pages you already have. This is just as well, as the book is currently out of print (I suppose ROOL have their reasons for this decision).

[Deleted User 9295]

This is just as well, as the book is currently out of print (I suppose ROOL have their reasons for this decision).

The BASIC V (and VI) reference that I use only goes up to version 1.05. Is there anything later available online? I'd assumed that there were no significant changes in later versions, only tweaks and bug fixes, but that seems not to be entirely the case.

I only found out about the use of VDU as a function from Brandy BASIC; there is some documentation here (see 'Mode variables' near the end). But even that's confusing because the example code listed doesn't work (it prints one fewer than the true value):

Code: Select all

	width% = VDU 1
	PRINT "Screen width in characters is "; width%

[paintings]

The BASIC V (and VI) reference that I use only goes up to version 1.05. Is there anything later available online? I'd assumed that there were no significant changes in later versions, only tweaks and bug fixes, but that seems not to be entirely the case.

I don't know of any easy-to-use online reference. You could dive through the commit history in Git but that's a lot of work.

But even that's confusing because the example code listed doesn't work (it prints one fewer than the true value)

The off-by-one values are mentioned here.
The reason for them being off-by-one is that they list the maximum value for the item (e.g. VDU 2 returns the maximum row number for printing text, as you might use in a PRINT TAB command).

[Deleted User 9295]

The off-by-one values are mentioned here.

Yes, I found that interesting. The closest equivalent 'VDU variables' in my BASICs don't behave the same way (so for example the window dimensions are stored as the width and height in pixels) which is one reason why it would be messy to attempt to emulate the VDU function. In some cases it would just be a case of subtracting one, but when text dimensions are involved it would be trickier (I use pixel dimensions, even for the text viewport, because of supporting proportional-spaced fonts).

[jgharston]

When I implemented an OSBYTE &A0 layer for the MOS interface for my PDP11 emulator, there was a lot of arithmetic to translate the value available from the @vdu variables to the OSBYTE &A0 values. (See PDP11Em.bas and scroll down to WHEN 160)

But =VDU(n) is really reading very platform-specific features and you should treat it a very platform specific. For many calls it should be a rare case where a program doesn't know what it's doing and needs to read them. If you've done VDU 28,0,23,39,0 you know what size the text window is, because you've just specified it.

[Deleted User 9295]

For many calls it should be a rare case where a program doesn't know what it's doing and needs to read them.

Absolutely. One legitimate use case I can think of is if you've been doing a lot of relative plotting (MOVE BY, DRAW BY, PLOT BY) and you want to know where the graphics cursor has ended up. Annoyingly, however, the very VDU variables that you need for this (138 & 139 or 144 & 145) are not in the set supported by the VDU function in Brandy BASIC and they always return zero.

[Soruk]

For many calls it should be a rare case where a program doesn't know what it's doing and needs to read them.

Absolutely. One legitimate use case I can think of is if you've been doing a lot of relative plotting (MOVE BY, DRAW BY, PLOT BY) and you want to know where the graphics cursor has ended up. Annoyingly, however, the very VDU variables that you need for this (138 & 139 or 144 & 145) are not in the set supported by the VDU function in Brandy BASIC and they always return zero.

Added to my to-do list Implemented, and nightlies rebuilt. It's probably 138 & 139 that you need, and are provided relative to the current origin.