PRINT TAB(X,Y) in VDU 5 mode

[Hated Moron]

Acorn's 6502 MOS 1.20 was the OS supplied with the great majority of production BBC Micros (Model A and Model B) - something like one million in all - and has therefore become the de-facto standard for the behaviour of OS features. For this reason the OS-emulation built into BBC BASIC for Windows and BBC BASIC for SDL 2.0 is largely modelled on OS 1.20.

It therefore came as a surprise to discover, quite recently, that in Acorn's MOS 3.20 (the OS fitted to the later BBC Master models) a potentially incompatible change was introduced to the behaviour of a common BBC BASIC feature: PRINT TAB(X,Y) (which maps to VDU 31). Whereas in OS 1.20 this always moves the text cursor, in OS 3.20 it moves the graphics cursor when in VDU 5 mode!

As far as I am aware this change - which could cause existing programs to fail - was not made in consultation with the BBC (which it should have been) nor was even communicated to the BBC; I certainly have no recollection of having been aware of it at the time (1985 or thereabouts). So it came as quite a shock to discover it nearly 40 years later!

Unsurprisingly this change (which reinstated a feature of OS 0.1 that had been removed in 1.20) was carried forward into future Acorn models such as the Archimedes and RISC PC, and therefore represents an unexpected and unplanned difference between their VDU emulation and mine. A program which relies on that feature won't run correctly in BB4W or BBCSDL.

So the question, of course, is does it matter? Should BB4W and/or BBCSDL be modified to match the behaviour of MOS 3.20 and later Acorn OSes (at the - small - risk of breaking some existing programs) or should it retain its compatibility with MOS 1.20? I have created a poll to sound-out opinion (if you are reading this at the Discussion Group you will need to vote at the forum, you cannot vote by email).

[nvingo]

I'd be inclined to leave it be - the number of os1.20 and compatible users must surely remain in the majority.
An elegant solution would be to have that as default behaviour, but a *fx switch be introduced to emulate os3.20 or return behaviour to os1.20.
Should any further functional differences between os1.20 and os3.20 surface and be incorporated, the switch would affect them all.
I appreciate this could be a larger change than just making the whole Russell BBC Basic behave just one way or the other.

[Hated Moron]

An elegant solution would be to have that as default behaviour, but a *fx switch be introduced to emulate os3.20 or return behaviour to os1.20.

If it's necessary to change your program to make it run (if only by the addition of a *FX command) you really might as well change it to avoid the problem in the first place! There's an elegant way of doing that in the manual: simply replace TAB(X,Y) with FNTAB(X,Y) which emulates the OS 3.20 behaviour.

[nvingo]

So there already exists a function to perform TAB like os3.20 in os1.20, which I didn't realise; meaning changing any of the interpreters isn't really necessary.

[Hated Moron]

So there already exists a function to perform TAB like os3.20 in os1.20, which I didn't realise; meaning changing any of the interpreters isn't really necessary.

It's a user-defined function which you have to include in any program that uses it! See the manual section that I linked to.

[nvingo]

Yes I get that you have to edit any (os3.20 compatible) program that uses VDU5 and Tab(x,y) to include the function and replace every Tab(x,y) with FnTab(x,y) - the difficulty being can you use an automatic search/replace - because Tab(x) is also valid, and replacing every "Tab(" with "FnTab(" could lead to an erroneous FnTab(x).
So i think the programmer would need to edit it manually - or a more complex routine written to add FN only in front of two-parameter TABs, ie. finding a comma between the outer parenthesis but ignoring any commas within embedded functions used as Tab parameters.
Whereas changing the behaviour via a switch would mean only including the switch instruction during initialisation.

Merry Christmas, from a village near King' Lynn and not many miles from Broomhill's.

[Hated Moron]

Whereas changing the behaviour via a switch would mean only including the switch instruction during initialisation.

A 'switch' isn't on the cards, once that Pandora's Box was opened people would be asking for some of the other differences between my BASICs and Sophie's BASICs to be addressed in the same way.

You could try to persuade the author of Matrix Brandy BASIC to add a switch that makes it behave like mine...

[nvingo]

The other thing is that tabs can be incorporated in strings and VDU commands; I suppose these would also need to be adjusted to make use of the added FnTab function - that probably is less trivial to automate.

[Hated Moron]

The poll showed a big majority for not changing BB4W/BBCSDL (75% compared with 13% for making the change) so that's settled.

Very few programs rely on this feature (particularly because BBC Micro OS 1.20 didn't support it) and for those that do the FNTAB() workaround is largely effective. It can be used even when the TAB(X,Y) is being done by means of a VDU string, e.g. in a sprite, for example one could change:

Code: Select all

sprite$ = "here" + CHR$31 + CHR$x% + CHR$y% + "there"

to:

Code: Select all

sprite$ = "here" + FNTAB(x%, y%) + "there"