Richard Russell's BBC BASIC

Hello,

I didn’t know whether this should go in aldershot or the general forum, since it’s not really related to RISC OS.

The past couple of weeks I’ve been experimenting with Richard Russell’s variant of BBC BASIC. After getting used to some of the differences, I quite like it. There are some extra features that are really handy, like LOCAL arrays for example.

What do you all think about Richard Russell’s version of BBC BASIC?
Is there any chance of the useful extra features coming to the RISC OS/ARM version of BASIC?

Patrick

I’ve used it quite a bit. But only the free version because I’m cheap.

It works very well. Richard’s a top bloke. Some behaviour is slightly different – COLOUR for example. I wrote a module that made RISC OS work the same way as BBfW as it happens (I can’t remember why I thought that was worthwhile).

BBC Basic has had local arrays for quite a while though. Is that what you meant?

I think he meant volatile local arrays that evaporate when you leave the function/procedure in which they were defined.

REM Main prog
DIM a%(50):REM global
...
DEFPROCfred
LOCAL a%()
DIM a%(900):REM Local array on stack (BB4W) global values stored on stack (RISC OS BB)
...
ENDPROC:REM Local array has gone

And, yes, you are right – you can do that in RISC OS BBC BASIC as well as BB4W.

BBfW has structures, which may or may not have been influenced by the design discussion Steve and I had a long time ago. I implemented structures in BBC Basic, but being limited by the lack of memory management I did not release it. Steve added a slightly different syntax to Basalt, which I think can do memory management.

BBfW has EXIT for jumping out of loops (but no CONTINUE), PRIVATE variables (which are persistent LOCAL vars), 16bit string lengths, some event handling in lieu of the Wimp, a variable address operator (instead of little bit of assembly), tautological byte variables (DIMb%0:?b%=255 works fine), non-syntactic line breaks, PROC/FN references and selectable numeric precision.

PROC/FN references are very good, eliminating one of the two reasons for using EVAL (the other being the inability to evaluate a hexadecimal number, d’oh!).

Richard’s a top bloke.

He is, indeed. Can I take this opportunity to point out that he has just released versions of BBC BASIC for Android and iOS, after his earlier version for Linux on the Pi: http://www.bbcbasic.co.uk/bbcsdl/index.html. He asked me for help with an ARM assembler for use in these, but that was a bit beyond me. However, he has solved that, except that Apple restricts the used of such things.

BBfW has structures

I do not think Richard was influenced by us, but it was about that time he included them.

Steve added a slightly different syntax to Basalt, which I think can do memory management.

It does. Structures in Basalt and BB4W achieve largely the same ends, but differ signifcantly in syntax.

Just to note, from your list, Basalt has forms of EXIT and PRIVATE, long strings of any length, event handling in Wimp and Toolbox applications, PTR for variable addresses, line breaks (not as flexible as BB4W) and PROC/FN references. The PROC/FN references are only as efficient as calling a routine by variable name (not using EVAL) which Basalt can do.

The PROC/FN references are only as efficient as calling a routine by variable name (not using EVAL) which Basalt can do.

ORLY? Shame. I’d have thought that F%=^PROCfoo...PROC(F%) would be speedy (see what I did there?).

I wrote a module that made RISC OS work the same way as BBfW

BBfW treats ‘logical colours’ as pens, in effect, so whereas VDU19,7,16,128,128,128 on RISC OS puts mid grey into the display palette, in BBfW it makes ‘pen 7’ grey (IIRC).

I wrote a module that made RISC OS work the same way in deep colour modes (that can’t sensibly have a programmable palette). I honestly have no recollection why I thought that was worth the time.

I’d have thought that F%=^PROCfoo…PROC would be speedy

Working outside BASIC itself make things tricky, and calling a PROC by name is not made easy because the ‘Synergistic Cache’ (SC) is not cleared of its references and there is a problem of error handling. It is done, but is not pretty or very fast. ;-)

Calling a FN by name in assembler is just using the branch routine EXPR, also used by EVAL, and the SC is cleared and errors handled. Using FN as a statement is also easy, and then calling it by name is a convenient substitute for PROC.

When it comes to pointers, only a duplication of chunks of BASIC would may this work directly. Instead, Basalt stores a pointer to the cached data in the list, which includes the name, and then uses the name code.

So you can indeed have:

F%=PTR(PROCfoo)
PROC(F%,<parameters>)

It is not quite as fast as I would like, so this is a better option, using ENDFN in the definition.

F%=PTR(FNfoo)
FN(F%,<parameters>)

I forget the constraints under which Basalt works. I was thinking of hacking Basic itself, where it would seem to be straightforward.

I so want to make a version of Basic with an IDE and single-stepping/breakpoints… but I’m massively overstretched as it is. These kind of discussions always pique my interest though. Stop, Steve!

Rant deleted.

Richard Russell’s website is one of the best resources for using BBC BASIC on RO, even though it’s not even quite the same product. While a version with IDE (I keep thinking like Complete BASIC on Apple IIgs) would be nice, an easily available source of documentation for the underlying language would make it far better.

Rant deleted.

Oh, go on. ;-)

easily available source of documentation for the underlying language

Is the BBC BASIC Reference Manual just published by ROOL not sufficient?

There is also my StrongHelp manual, although it could do with an update in light of recent developments.

a version of Basic with an IDE

Both DrWimp and especially AppBasic have attempted that. And who remembers Archway?

These kind of discussions always pique my interest

My own take on an IDE is StrongED and ResEd, with Basalt of course. ;-)

If ResEd could use named events that would almost complete the the requirement.

a version of Basic with an IDE

Both DrWimp and especially AppBasic have attempted that. And who remembers Archway?

An IDE on any other system is something that resembles Visual Studio, or something that at least uses a splitter window to display different information such as files, properties, objects.

Nothing remotely close to that on RISC OS at all. If only there was.

Sourcery come to mind take look the really small software company might only work with c though

or something that at least uses a splitter window to display different information such as files, properties, objects.

Moreso than that (as multiple Zap|StrongEd windows can almost fake the same sort of thing) is that IDEs on other systems tend to be capable of single-stepping through the code allowing real-time evaluation of variables as you go. DDT can do this, but it’s not the most pleasant thing to use…I tend to rely upon DADebug and try to avoid DDT entirely.

While I’m here, a rant of my own. DDT’s crashiness and the fact that when it crashes, you cannot use it again without a full system reset. Makes it somewhat of a non-starter for many debugging jobs.

Really, it would be good if DDT had an “emergency” option to permit it to be either killed (and reloaded) or used again.
I DO NOT CARE if this leaves orphaned dynamic areas or bits of RMA or whatever/however it does its thing. On a system with plentiful memory, throwing away some in order to get DDT running again is a lot more useful than having to shut everything down, restart, reload everything, and then try to remember what your chain of concentration was, while actutely aware that stepping through the same code again may well give cause for DDT to top itself…again.

capable of single-stepping through the code allowing real-time evaluation of variables as you go.

I completely forgot to include the wonderful Reporter in my IDE. You can step through a program and report selected variable values. There are other very useful facilities.

The removal of debugging lines from a program for a published version is discussed in the Help, but if you use Basalt you can access Reporter with keywords and remove debugging lines very simply.

Alan said

An IDE on any other system is something that resembles Visual Studio

Indeed, that is my preferred model. Unlike DDT, I envisage something that fools the BASIC program, rather than fooling the rest of the system. ie the BASIC program thinks it is doing Wimp_Poll, Wimp_Redraw etc, but it ain’t. CALL would have to be atomic, but there’s NO reason why BASIC can’t be single-stepped by a managed BASIC environment.

Naturally its workspace would look like vanilla BASIC, but there’d be a Dynamic Area with the IDE-specific stuff.

The IDE doesn’t have to be part of the BASIC interpreter of course, that can be delegated. We’ve all written things that spy into a BASIC program’s workspace so you can view variables live as the program runs, I presume? So it’s only really the breakpoints, single-stepping and SYS spoofing that would be new.

things that spy into a BASIC program

Interesting – is ‘Basic Spy’ available for download?

For the 26bit world there is !BasDT by Dick Alstein.

available for download?

Not at the moment. It dates back to 1993 would you believe it, though I last updated it… (checks)… yesterday. :-/

Steve and I are discussing a better method (whether he knows it or not).

Oh Steve…

What if *BASIC -debug ... creates a new instantiation of BASIC with RMA workspace, then when BASIC starts it looks up the workspace of the preferred instantiation and hence finds its RMA workspace. This is then stored in RECPTR which to the best of my knowledge has never been used.

Actually, I have a much better location in mind. FNTEMPLOC has never been used for anything much because LVAR blats those 16 bytes in the name of saving an instruction or two in interactive mode. However, when running, only the first 8 bytes are used – by the temporary stack during PROC/FN, so -&18C and -&188 would be free for BASIC to use if one made a tiny change to LVAR. I’m thinking LVAR sticks 1<<31 in FNTEMPLOC and hence trivially steps over those 16 bytes. 8 bytes gained.

The RMA workspace can then be shared between the debuggee BASIC instance and the debugger, being the trampoline for breakpoint lists (of all types), execution mode, execution count, BASIC’s state (LINE, stack etc), BASIC’s task handle, wimp buffer and queues.

Obviously the interpreter in debugging mode can look for breakpoints on statements (LINE), Lvalues, memory locations… it might be useful to log DIMs for identification purposes.

Sound flakey? It would be more robust than DDT.

Significantly, even if the program was halted or went into an infinite loop, it could still be quit from the Task Manager because BASIC would be the Task, not the program.

Colin teased

!BasDT by Dick Alstein

I have never heard of that, and it doesn’t seem to exist now. Is this something you have access to?

Sound flakey? It would be more robust than DDT.

<mumbles under breath>Most things are more robust than DDT</mumbles>

I have never heard of [BasDT]

I have a copy of version 1.10 if you cannot find it. It is ‘CareWare’, which permits distribution but limits use, and I never felt the need to use it myself.