VDU 5,12 inconsistency
VDU 12 (CLS) is described in the various documentation references as follows:
BBC Micro User Guide: "Clears the current text area and sets this area of the screen to the current background colour. The statement then causes the text cursor to move to the text origin (0,0) at the top left of the current text area".
RISC OS BBC BASIC Manual: "Statement to clear the text viewport to the text background colour. Note: CLS also resets COUNT to zero and moves the text cursor to its home position, which is normally the top left of the text window".
BBC BASIC for Windows manual: "A statement which clears the text viewport and sets it to the currently selected text background colour. The text cursor is moved to the 'home' position (0,0) at the top left-hand corner of the text viewport".
My versions of BBC BASIC (or more precisely the VDU emulators they contain) all work in accordance with this documentation. But, from my own tests, it seems Acorn systems (BBC Micro, RISC OS) and Brandy don't: in those VDU 5,12 acts like VDU 16 (CLG) - it clears the graphics viewport rather than the text viewport!
Nowhere can I find this documented, and I can't remember having been aware of it in the 42 years since the BBC Micro was released (although perhaps I was and have since forgotten). It seems to me far from helpful: if you have both a text viewport and a graphics viewport, you may well still want to clear the text viewport whilst in VDU 5 mode (you might simply be using CLS as a fast way of filling a rectangle).
When VDU 5 is expected to change the behaviour of another VDU code this is documented, for example in the BB4W manual VDU 30 is documented as follows: "In VDU 4 mode, VDU 30 homes the text cursor to column 0, row 0 (normally the top-left corner of the text viewport, but this can be changed using VDU 23,16). In VDU 5 mode, VDU 30 homes the graphics cursor to the 'top left' corner of the graphics viewport".
So what's going on here? How come all these systems seemingly don't work according to the documentation? Is it deliberate or accidental? As far as I am concerned my BASICs work correctly in this regard, there's no way I would change them in the interests of 'compatibility'.
BBC Micro User Guide: "Clears the current text area and sets this area of the screen to the current background colour. The statement then causes the text cursor to move to the text origin (0,0) at the top left of the current text area".
RISC OS BBC BASIC Manual: "Statement to clear the text viewport to the text background colour. Note: CLS also resets COUNT to zero and moves the text cursor to its home position, which is normally the top left of the text window".
BBC BASIC for Windows manual: "A statement which clears the text viewport and sets it to the currently selected text background colour. The text cursor is moved to the 'home' position (0,0) at the top left-hand corner of the text viewport".
My versions of BBC BASIC (or more precisely the VDU emulators they contain) all work in accordance with this documentation. But, from my own tests, it seems Acorn systems (BBC Micro, RISC OS) and Brandy don't: in those VDU 5,12 acts like VDU 16 (CLG) - it clears the graphics viewport rather than the text viewport!
Nowhere can I find this documented, and I can't remember having been aware of it in the 42 years since the BBC Micro was released (although perhaps I was and have since forgotten). It seems to me far from helpful: if you have both a text viewport and a graphics viewport, you may well still want to clear the text viewport whilst in VDU 5 mode (you might simply be using CLS as a fast way of filling a rectangle).
When VDU 5 is expected to change the behaviour of another VDU code this is documented, for example in the BB4W manual VDU 30 is documented as follows: "In VDU 4 mode, VDU 30 homes the text cursor to column 0, row 0 (normally the top-left corner of the text viewport, but this can be changed using VDU 23,16). In VDU 5 mode, VDU 30 homes the graphics cursor to the 'top left' corner of the graphics viewport".
So what's going on here? How come all these systems seemingly don't work according to the documentation? Is it deliberate or accidental? As far as I am concerned my BASICs work correctly in this regard, there's no way I would change them in the interests of 'compatibility'.
0
Comments
-
It is documented in the BBC Master reference manual part 1 - downloadable from here https://stardot.org.uk/forums/viewtopic.php?t=20466 on PDF page 175, on-page E.3-5.
It is also documented in RISC OS - https://www.4corn.co.uk/archive/docs/RISC OS 3 Programmers Reference Manual - Volume 1-opt.pdf on PDF page 572 (on-page 1-556).
0 -
Interesting, but those documents make other misleading statements, for example they say that VDU 31 behaves differently in VDU 4 and VDU 5 modes, but that was a feature of OS 0.1 which was classed as a bug and removed in OS 1.0 and later.It is documented in the BBC Master reference manual ...
It is also documented in RISC OS...
I well remember, in the very early days, that at least one of the demo programs which had been written and tested on OS 0.1 stopped working when OS 1.0/1.1/1.2 were released because it assumed that PRINT TAB(X,Y) could be used to position the graphics 'cursor' in VDU 5 mode!
So the documents you linked to only serve to muddy the waters even more, I suspect they were an attempt to retrospectively justify something clearly never intended. Because CLS is much faster than CLG it's the method of choice for clearing the screen, even when you're going to be writing VDU 5 text, so disabling it in that situation is nuts.
The BBC Micro User Guide remains the best reference we have to how things should work, because it was a joint effort by Acorn and the BBC and represents the agreed specification. Any changes to behaviour should have been proposed by Acorn and agreed (or not) by the BBC, but I certainly have no recollection of a change in VDU 12 behaviour ever being raised.
We found once before that something clearly documented in the User Guide - that STOP is not an error and shouldn't affect ERL or ERR - seems to have been disregarded by Acorn, although once again I don't remember that having been discussed.
I suppose I should accept a share of responsibility for a lack of vigilance on the part of the BBC back then. I think we possibly trusted Acorn more than we should have, which is why some of these issues slipped through the net. I'm still amazed that it took 42 years to discover it though!0 -
Richard_Russell wrote: »I well remember, in the very early days, that at least one of the demo programs which had been written and tested on OS 0.1 stopped working when OS 1.0/1.1/1.2 were released because it assumed that PRINT TAB(X,Y) could be used to position the graphics 'cursor' in VDU 5 mode!
That's odd, I just ran this on my BBC Master (OS 3.20):10 MODE 1 20 VDU31,20,20 30 PRINT "*"
Then, added 15 VDU5 and re-ran, the only obvious difference is the lack of a flashing cursor, in both cases the * is printed at (20,20). The same happens on RISC OS. It seems only OS 1.00-2.00 (at least under B-Em and Elkulator) where this doesn't happen - like a regression that got fixed in the Master MOS.0 -
I wouldn't know anything about OS 3.20, that came out after the BBC had ceased to have as close an involvement and (rightly or wrongly) we trusted Acorn even more to act responsibly!That's odd, I just ran this on my BBC Master (OS 3.20):
Indeed I think we assumed that no potentially breaking changes like that would be made, since to risk existing Model B programs not working on the Master would have been crazy. It was supposed to be 100% compatible (apart from apps calling undocumented ROM routines!).
The de-facto reference had by then become OS 1.2, because there were vastly more machines running that OS than any other - probably about a million more! That's why the VDU 12 behaviour is so surprising because it does affect OS 1.2.
I can be confident that the change from OS 0.1 to OS 1.0 affecting VDU 31 wasn't a 'regression'. The incompatibility with one or two existing programs was noticed pretty quickly and there would have been an opportunity to 'correct' it in OS 1.1 and OS 1.2 if it hadn't been deliberate.
It's also hard to imagine how removing code could ever have been 'accidental'. It's entirely possible that there was a realisation that this behaviour had never been asked for - it wasn't in the spec or the User Guide - so it could be 'safely' removed to free-up space.
Except that it wasn't entirely 'safe' after all, because somebody had managed to write a program relying on a completely undocumented behaviour. It was ever thus. :-(
0 -
Fortunately the likelihood that 'reinstating' the OS 0.1 VDU 31 behaviour in OS 3.2, if that's what happened (and however unnecessary and strange it was), would break an existing program designed to run in OS 1.2 is small. Such a program would have had to move the text cursor (caret) in VDU 5 mode, which is not a likely thing to be wanting to do.Richard_Russell wrote: »Indeed I think we assumed that no potentially breaking changes like that would be made, since to risk existing Model B programs not working on the Master would have been crazy.
I note this comment in the RISC OS BBC BASIC Reference Manual: "Even in VDU 5 mode, POS returns the position of the text cursor" - hardly consistent with the idea that TAB(X,Y) will move the graphics cursor! Because it's hard to find documentation which describes this behaviour - you succeeded but I didn't - it's unlikely that anybody will be writing code that relies on it.
Incidentally in searching the Reference Manual I came across the term 'VDU 5 magnification' which I had not previously encountered. This seems to refer to this usage to alter the size of the text characters to be different from what they normally are in the current mode:VDU 23,17,7,6,sx;sy;0;
Do you support it in Matrix Brandy? It's not dissimilar to what it's possible to achieve in my BASICs using the VDU 23,22... command instead of MODE.
0 -
I've not seen this "VDU5 magnification" thing before, indeed I never knew it existed. But it might be useful, that header line in Note Quiz is extremely slow on 8-bit kit, especially the Elk. I'll have to take a closeer look at this.
Regarding VDU5,12 possibly the best approach is simply to document the difference, I've already put a note up on BeebWiki https://beebwiki.mdfs.net/VDU_12
JGH has an annotated disassembly of MOS 1.2, and the code for VDU12 is here:
https://mdfs.net/Docs/Comp/BBC/OS1-20/C735 (go down to C759)
showing what appears to be a deliberate check to see if we're in VDU5 mode and if so calling CLG (and HOMEing the graphics cursor).
0 -
There's no realistic possibility that it could have been accidental! That's why the whole thing puzzles me: there's no mention of it in any contemporary documentation that I'm aware of (at the time, 1981, probably the only document that existed was my spec).showing what appears to be a deliberate check to see if we're in VDU5 mode and if so calling CLG
So it's almost as if whoever was coding that part of the MOS (Paul Bond?) thought it was a 'good idea' and decided to incorporate it with no consultation with the BBC and no communication with John Coll (author of the User Guide).
I hate to suggest this, but was it just a piece of 'vanity code' that the author could point to in years to come and say "I did that, and nobody noticed!".
I think it's reasonable to debate the pros and cons of VDU 31 moving the graphics cursor in VDU 5 mode, in part because VDU 8,9,10,11 & 30 have always done so. On balance I don't think it should (especially having been removed from OS 0.1) but it's arguable.
But disabling the ability to clear the text viewport just because text is being written into the graphics viewport makes no sense to me. The default is for the text and graphics viewports to be the same, and because CLS is so much faster than CLG it's useful for clearing that shared viewport - but in VDU 5 mode you can't!
Setting a text viewport so that it just covers a block of text and doing CLS would also be a quick way of deleting that block, but again in VDU 5 mode you can't; you'd be faffing around with VDU 4,12,5 all the time. All very strange.
0 -
I've created a poll to sound out opinion on this issue. If you know of anybody who might want to express a view, feel free to direct them to that poll. They would have to join to vote, but that's no bad thing!Richard_Russell wrote: »I think it's reasonable to debate the pros and cons of VDU 31 moving the graphics cursor in VDU 5 mode, in part because VDU 8,9,10,11 & 30 have always done so. On balance I don't think it should (especially having been removed from OS 0.1) but it's arguable.
(Edit by Soruk - follow your forum's host change)0 -
Thanks. I was surprised that your link didn't result in the usual 'sorry, you have been banned' message; have they quietly lifted my ban (not that it will make me want to visit the forum)?I've posted a link to your poll on the other place here.
I'd prefer not to put the VDU 5,12 issue into the mix, because it's in a very different category. It's possible to argue that VDU 31 changing behaviour in VDU 5 mode might be useful, not so VDU 12 (quite the contrary).
0