TWIN removal from Basic

I am proposing to remove the commands TWIN and TWINO from Basic, as part of some other changes I am making to Basic (see)

My understanding is that TWIN was written by Spohie Wilson, the BBC Basic author, in the days of the BBC Master. It was announced by Acorn with the first Acorn Archimedes machines around 1988. It was a disc-based command for a two-window (hence the name!) editor for programs written in Basic, C, Fortran, Pascal and Assembler. The commands TWIN and TWINO were included in Basic so it could be invoked from the Basic command line easily.

The last trace of it I can find is from 1990, when David Holden released a program to convert the TWIN disc command into a relocatable module command. The only TWIN version I have found is certainly not 32bit compatible!

Currently these commands from within Basic give errors:

  TWIN      results in "File 'Twin' not found"
  TWINO n   results in "File 'Twin' not found"   (where n=0-15)
  TWINO     results in "Unknown or missing variable"
  TWINO n   results in "Invalid TWINO option"    (where n>16)

I also considered removing the EDIT command, which invokes the *ArmBE command to Edit Basic programs, written around the same time as TWIN. However, there is a 32bit version of the module available from ROOL, and it does have users of the facility.

It would be simple enough to change, and I doubt anyone except myself has written any software relying on it, but Basalt overloads the TWIN keyword to compare strings using Territory_Collate. Therefore it expects TWIN to be tokenised.

Inactivate it and remove the code by all means, but leave the tokenisation and syntax checking, rather like ENVELOPE. You cannot assess just what any other software may expect from BASIC, even if I would bet that you are on pretty safe ground.

A little further thought makes me question the need to do this at all: “If it is not necessary to change, it is necessary not to change”.

Martin said:

Currently these commands from within Basic give errors:

  TWIN      results in “File ‘Twin’ not found”

  TWINO n   results in “File ‘Twin’ not found”   (where n=0-15)

  TWINO     results in “Unknown or missing variable”

  TWINO n   results in “Invalid TWINO option”    (where n>16)

<panto>Oh no they don’t!</panto> Well, not on my machine, but then I still have TWIN (crikey I’ve been doing this a long time). Actually “TWINO” without a parameter is supposed to cause an error.

However, there isn’t a 32bit version of TWIN is there? And now I come to check, under RO4 the detokenisation doesn’t work anyway, rendering it useless.

Fun fact: Twin is one of the few bits of RISC OS software (actually it predates Arthur) that suffers from the Millennium Bug!

Steve suggested:

Inactivate it and remove the code by all means, but leave the tokenisation and syntax checking, rather like ENVELOPE.

Envelope isn’t deactivated, it does what it has always done in all versions of BBC BASIC.

Envelope isn’t deactivated, it does what it has always done in all versions of BBC BASIC.

It calls OS_Word 8, which has no effect in RISC OS. That’s near enough de-activated for me.

under RO4 the detokenisation doesn’t work anyway, rendering it useless.

I use the TWIN double token for the Basalt version of TWIN. It detokenises in StrongED on RO 4 and 5.

nemo wrote:

However, there isn’t a 32bit version of TWIN is there? And now I come to check, under RO4 the detokenisation doesn’t work anyway, rendering it useless.

So what I propose for TWIN & TWINO is to

• leave tokenisation unchanged.
• change help to say ‘This command is no longer available’
• change entering to result in ‘Mistake’ error, like any other non-command.
• remove code specific for the commands

Will that satisfy everybody?

Envelope isn’t deactivated, it does what it has always done in all versions of BBC BASIC.

But that is actually misleading for users, as HELP ENVELOPE says ‘ENVELOPE takes 14 numeric parameters separated by commas.’ when it should say something like ‘This keyword now does nothing’

Steve said:

[Envelope] calls OS_Word 8, which has no effect in RISC OS.

Martin added:

it should say something like ‘This keyword now does nothing’

Which is neither always true nor BASIC’s responsibility to assert.

ENVELOPE does what it has always done – calls OS_Word. Whether that has a detectable effect depends on whether there is any code responding to that OS_Word.

In the BBC Micro, there was. In the Electron, there was partial support. In Arthur and RISC OS there is no support out of the box. However, the inestimable Jeffrey Lee of this parish wrote an envelope support module some time ago.

It is useful to compare and contrast with ADVAL, which would also ‘appear’ to do nothing in RISC OS out of the box, but add an I/O Podule and it suddenly starts working.

However, TWIN is an interactive-mode only command, so there is no run-time compatibility to maintain.

If I were doing it I’d indirect both TWIN and EDIT through sysvars, delegating responsibility for the actual functionality or command to call – no sysvar defined (the default), no effect.

But that is actually misleading for users, as HELP ENVELOPE says ‘ENVELOPE takes 14 numeric parameters separated by commas.’ when it should say something like ‘This keyword now does nothing’

Would it not be possible for some clever bod to create a sound driver that intercepts OS_Word 8 thus making ENVELOPE work again? I suspect this is what Acorn had in mind until they realised that getting all the fancy Beeb sound functionality isn’t something entirely feasible to emulate on an 8MHz processor. And, well, it just never got done. But it would seem hooks are there… Might be able to pull it off on a >half-gigahertz processor!

Update: It appears that just such a clever bod has already created a module for ENVELOPE (read previous post). Does it work on, say, an ARM2/A310 or did it need something a little meatier to work nicely?

but more importantly it will free some space in the Basic workspace

In the context of your other thread, to take a copy of the line number in case CALL (etc) corrupt R12, you’d only need 16 bits of workspace. I’ve not looked, but is all this talk of messing with TWIN not needed? Surely there’s 16 bits of spare space below PAGE?

I do not want to save the line number (even though it would only be 2 bytes) because it would involve finding it from the LINE ptr in r12 before every CALL, USR, SYS and *command, which would be an unnecessary overhead. My changes just save the LINE ptr instead (4 bytes) in a single instruction. The conversion to line number is done by existing code, but only after an error. The code changes are minimal, and it all seems to work fine here.

My understanding is that TWIN is theoretically allocated all the ‘spare’ at the top of the workspace (currently 24 bytes – or 20 with VFP?), although I think in practice probably only uses the first 8 bytes. Every time something is added to the workspace, it reduces the ‘spare’ available to TWIN, and the developer has to worry about whether it will have any adverse effects or not (which is not obvious). In addition, the first byte of the TWIN workspace is actually also used as a QUIT flag, further adding to the possible confusion. So my plan was to stop TWIN using the workspace, and to identify the QUIT flag as such, helping to reduce possible future confusion. Still seems like a good plan to me.

Re: ENVELOPE. If there is a possibility of it ever working again, then obviously the code must remain. But there should be documented somewhere with Basic that it will not work unless ??? is true. Otherwise users could waste time trying to get it to work.

I do not want to save the line number (even though it would only be 2 bytes) because it would involve finding it from the LINE ptr in r12

Ah right, the pointer to the current line rather than the line number, yes that would be more speedy. 4 bytes it is then.

My understanding is that TWIN is theoretically allocated all the ‘spare’ at the top of the workspace (currently 24 bytes – or 20 with VFP?)

I got 20 when I printed it out just now. I note RECPTR isn’t being used for anything, and is 4 bytes, perhaps just grab that?

RECPTR is not referenced in the source, certainly. And it seems to be zeros.
But can anyone confirm that is is NEVER used by anything?
Or even any idea what it was used (or intended) for?

[ENVELOPE now does nothing] Which is neither always true nor BASIC’s responsibility to assert.

I really cannot believe you wrote that – it is not BASIC’s responsibility to assert what BASIC does.

ENVELOPE is not a documented keyword in BASIC V. How it remains in the source code and calls the unimplemented OS_Word 8 may be buried in the mists of time, but I would lay money that it was not intentional. OS_Word 8 was specifically tied to the sound chip on the BBC, as was OS_Word 7, implemented in BASIC II with the SOUND keyword. SOUND in BASIC V does not call OS_Word 7, but sound system SWIs. There is no means of shaping sounds in those SWIs. I would be very interested to know if FDSound is publicly available and implements OS_Word 8, making ENVELOPE work. Jeffery?

It is useful to compare and contrast with ADVAL, which would also ‘appear’ to do nothing in RISC OS out of the box, but add an I/O Podule and it suddenly starts working.

Yes, a useful comparison. ADVAL is a documented keyword which is a “Function reading data from an analogue port if fitted”. It has a documented error “Bad command” if one is not fitted. It does not ‘appear’ to do nothing.

I really cannot believe you wrote that – it is not BASIC’s responsibility to assert what BASIC does.

It is not BASIC’s responsibility to assert that a particular OS_Word does or doesn’t do something (unless the success of the protocol in question can be detected, arguably).

How it remains in the source code and calls the unimplemented OS_Word 8 may be buried in the mists of time, but I would lay money that it was not intentional.

Rubbish. It’s just like ADVAL and this:

A%=33:CALL&FFE3

ADVAL is a documented keyword which is a “Function reading data from an analogue port if fitted”. It has a documented error “Bad command” if one is not fitted. It does not ‘appear’ to do nothing.

Look more closely. It is not BASIC which generates that error.

As I say, it is not BASIC’s responsibility to know which bits of the OS’s API are actually implemented on the device in which it is running.

Also,

ADVAL is a documented keyword which is a “Function reading data from an analogue port if fitted”.

RISC OS and BBC Basic V were very well thought out, in order to provide the maximum backwards compatibility with the BBC Computer. Which makes me wonder if anybody has tried the 3D house demo from “Making the Most of the Micro” on the latest generation hardware, to see how many thousand times faster it runs than on the BEEB? :)

It is not BASIC’s responsibility to assert that a particular OS_Word does or doesn’t do something (unless the success of the protocol in question can be detected, arguably).

While we’re going slightly off topic, my ARM coprocessor for the BBC micro can run BASIC V. In that situation both ADVAL() and ENVELOPE will be packed up into their respectively OS_Byte and OS_Word and sent across the Tube, working as they always did in BASIC II.

Bravo. The prosecution rests, m’lud.

It is not BASIC’s responsibility to assert that a particular OS_Word does or doesn’t do something

BASIC asserts in its documentation what BASIC does, that is all.

Then ADVAL and ADVAL will come as a surprise, as will ADVAL etc.

You used the example of ADVAL and an ADC card and I confined myself to that. Now you are bringing up the mouse and buffers … ADVAL 255 anyone? ;-)

Time to stop.

In that situation both ADVAL() and ENVELOPE will be packed up into their respectively OS_Byte and OS_Word and sent across the Tube, working as they always did in BASIC II.

Interesting. It provides a reason why ENVELOPE was retained in BASIC V, because ARMs were first used as co-processors, weren’t they? That also helps me understand a little more about how BASIC V came to be how it is.

I have looked at the ARM Tube OS document, but can can only find a reference to the ADVAL 7 and 8. Do you document that ENVELOPE is available in BASIC V for this combination?

BASIC asserts in its documentation what BASIC does, that is all.

…if by “documentation” you mean this (^_^)

The written book only asserts what BASIC is supposed to do, which may or may not match reality, may or may not be complete, and may or may not be obsolete.

…if by “documentation” you mean this (^_^)

Hmm! Not really user-oriented, is it?

The written book only asserts what BASIC is supposed to do, which may or may not match reality, may or may not be complete, and may or may not be obsolete.

Indeed, and I have been attempting to record what I can of the anomalies for nigh on 15 years, now in the BASIC StrongHelp manual. You will find there an acknowledgement of the help given by nemo, among others. ;-)

It may be time for an update.

Hmm! Not really user-oriented, is it?

That’s why The Book is “good enough” for end programmers. But when it comes to deeper stuff (ERL messed up on called code failures, whether or not ENVELOPE actually does anything, etc etc) the sole reference of trust is not the book, but the code itself…

Steve asked:

I have looked at the ARM Tube OS document, but can can only find a reference to the ADVAL 7 and 8. Do you document that ENVELOPE is available in BASIC V for this combination?

It certainly is, just as OS_Word,anything_else is – it’s passed over the tube to the host and executed there. Whether that has any affect depends on what is implemented in the Host.

I have looked at the ARM Tube OS document, but can can only find a reference to the ADVAL 7 and 8.

As mentioned in the introduction, the document covers those SWIs (or sub reason codes in the case of OS_Word) that are implemented by the ARM Tube OS, the host calls are available in addition – so yes SOUND and ENVELOPE get passed verbatim to the host.