Matrix Brandy BASIC V for Linux with SDL: V1.21.18 released

[Richard Russell]

What were you running that on - a Geode?

No, a fast laptop (Dell XPS-13) with the CPU running flat out at 2.8 GHz. My BASICs have a reputation of being extremely slow: a ratio of 37:1 is more than I have seen in previous comparisons, but Brandy always comes out much faster. I don't know anything about its internal architecture, but I think it's not a conventional interpreter, whilst my BASICs are.

Edit: Going back to the 1980s, remember how much slower my Z80 BBC BASIC was than Sophie's 6502 BBC BASIC, when compared fairly (i.e. not using variant variables, which was my trick to make my interpreter seem faster than it actually was on standard benchmarks). All this has been discussed at length before.

Richard.

[Soruk]

What were you running that on - a Geode?

I had never heard of one of those so I had to look it up. As I was searching I was thinking "Diode, Triode, Pentode, Geode" and expecting some valve based thing from the 1950s but it seems it is much more mundane and is what has turned into the AMD version of the Atom.

Prior to that, it was Cyrix who had the Geode (and somehow it transferred to AMD). I had a small machine with a Cyrix Geode in it. It was an i586, a few hundred MHz, enough to run a home VoIP server, but you wouldn't want to tax it (it could barely cope with a couple of iLBC channels - GSM was fine though). It used very little power and didn't get too hot even with a tiny passive heatsink in a pretty much sealed metal box.

[Soruk]

What were you running that on - a Geode?

No, a fast laptop (Dell XPS-13) with the CPU running flat out at 2.8 GHz. My BASICs have a reputation of being extremely slow: a ratio of 37:1 is more than I have seen in previous comparisons, but Brandy always comes out much faster. I don't know anything about its internal architecture, but I think it's not a conventional interpreter, whilst my BASICs are.

Richard.

There's certainly no JIT compilation going on, it's definitely interpreting as it goes along.

For comparison, Brandy in my CentOS 6 VM (allocated one core of an AMD FX running at 4GHz and running my VNC desktop environemt, browser and dev environment!) gets 126 frames as the program comes, 84 frames if I bung a *refresh in after PROCdrawpic, and 7 frames if I remove the *refresh off statement. (Being VNC, no hardware acceleration of the video). I tried it in BBCSDL but it doesn't like the GCOL statement.

[Coeus]

Edit: Going back to the 1980s, remember how much slower my Z80 BBC BASIC was than Sophie's 6502 BBC BASIC, when compared fairly (i.e. not using variant variables, which was my trick to make my interpreter seem faster than it actually was on standard benchmarks). All this has been discussed at length before.

To be fair, I think it was Sophie's 6502 BASIC that was fast. When I dug into the code as a teenager I found interesting tricks like storing the variables in a number of linked lists, one for each initial letter, i.e. a kind of primitive hash table with "take the first letter" as the hash function and the linked list as the collision resolution mechanism. There are also some lower level techniques, for example Steve Wozniak's 6502 BASIC for the Apple II normalises floating point number by shifting the 3-byte mantissa left, one bit at a time, until it is in the right place. Sophie's code shifts the four-byte mantissa left by whole bytes at a time initially, and then by single bits once the distance is less than 8.

[Richard Russell]

When I dug into the code as a teenager I found interesting tricks like storing the variables in a number of linked lists, one for each initial letter

My BASICs did exactly the same thing, and perhaps significantly they still do today. Really I have only ever written one BBC BASIC interpreter: the Z80 version in the early 1980s. All my subsequent versions (16-bit 8086, 32-bit IA-32 and the recent C editions) have been semi-automated instruction-by-instruction translations of that Z80 version, not taking advantage of any 'modern' techniques like JIT.

Fortunately people judge my BASICs not by raw speed measurements but by what they can achieve in the real world. If they are 'fast enough' to create prizewinning shoot-em-up video games like 'Forces of Darkness' (100% BASIC in its BBCSDL incarnation) speed is not a major issue. In fact I'm disappointed to see small speed variations being considered important in the case of Brandy: haven't we moved on from that?

I tried it in BBCSDL but it doesn't like the GCOL statement.

We discussed that recently in this very thread! You need only make the change suggested then (and select a more appropriate MODE) to make it run in BB4W and BBCSDL. I'm not sure I even consider the 'GCOL r,g,b' statement to be legitimate BBC BASIC; I'd never met it before, it's undocumented even in the 'official' RISC OS online BASIC docs, and it apparently bypasses the VDU stream (which probably makes it faster too, but that's cheating).

Richard.

[Soruk]

In fact I'm disappointed to see small speed variations being considered important in the case of Brandy: haven't we moved on from that?

In general yes. But if I do something sub-optimal in the code that unnecessarily slows it down, that's worth pointing out so it can be fixed.

I tried it in BBCSDL but it doesn't like the GCOL statement.

We discussed that recently in this very thread! You need only make the change suggested then (and select a more appropriate MODE) to make it run in BB4W and BBCSDL. I'm not sure I even consider the 'GCOL r,g,b' statement to be legitimate BBC BASIC; I'd never met it before, it's undocumented even in the 'official' RISC OS online BASIC docs, and it apparently bypasses the VDU stream (which probably makes it faster too, but that's cheating).

I haven't forgotten! I'm just not aware of the BBCSDL-compatible equivalent.

[Richard Russell]

I haven't forgotten! I'm just not aware of the BBCSDL-compatible equivalent.

The suggestion was:

Code: Select all

      COLOUR n,r,g,b : GCOL n

but there was some debate over what value to use for 'n'. Often it won't matter (although zero should probably be avoided) unless it's a logical colour number used elsewhere in the program. I used '1', and selected MODE 8 (mode numbers above 7 aren't standardised between BASICs):

Code: Select all

      COLOUR 1,(c%>>10)<<3,((c%>>5)AND31)<<3,(c%AND31)<<3:GCOL 1

Of course if one wants to squeeze the best performance the 'GCOL 1' can be taken outside the loop, but I didn't bother. Also I don't think the 'AND31' is strictly necessary.

Richard.

[Soruk]

I haven't forgotten! I'm just not aware of the BBCSDL-compatible equivalent.

The suggestion was:

Code: Select all

      COLOUR n,r,g,b : GCOL n

but there was some debate over what value to use for 'n'. Often it won't matter (although zero should probably be avoided) unless it's a logical colour number used elsewhere in the program. I used '1', and selected MODE 8 (mode numbers above 7 aren't standardised between BASICs):

Code: Select all

      COLOUR 1,(c%>>10)<<3,((c%>>5)AND31)<<3,(c%AND31)<<3:GCOL 1

Of course if one wants to squeeze the best performance the 'GCOL 1' can be taken outside the loop, but I didn't bother. Also I don't think the 'AND31' is strictly necessary.

Richard.

Thank you - useful information indeed.

Concerning mode numbers, since Brandy is attempting to follow BASIC V as found in RISC OS, all the modes up to 53 are attempting to match their RISC OS equivalents (based on RISC OS 5 docs) - including reserving 54-63 (which will report an error trying to select them). 64-126 are available for user custom modes with *NewMode. Some 800x600 and 1024x576 viewport modes have been predefined but can be overwritten. Currently only 2, 4, 16 or 256 colour modes can be defined, but one thing I plan to look into is 24-bit colour.

[dhg2]

In fact I'm disappointed to see small speed variations being considered important in the case of Brandy: haven't we moved on from that?

In general yes. But if I do something sub-optimal in the code that unnecessarily slows it down, that's worth pointing out so it can be fixed.

I didn't/don't mean to complain about differences in speed - it just caught my attention that the speed of my test program running on the (at the time) latest version was roughly half (90 frames vs 170) and it made me wonder if there might potentially be a bug in the drawing routines, eg, where it does the same plotting operation twice or something.

I didn't mean to suggest that the speed difference was a serious issue. I definitely agree that adding features is more important than worrying about minor differences in speed.

[Richard Russell]

Concerning mode numbers, since Brandy is attempting to follow BASIC V as found in RISC OS, all the modes up to 53 are attempting to match their RISC OS equivalents

The BBC Micro only had MODEs 0-7 and that's the base set that I would expect to be supported, more or less, by any version of BBC BASIC (unless running on a display not capable of it, such as the Z88 or the Amstrad NC100 etc). The online RISC OS docs say "There are 33 different modes, numbered from 0 to 36 (some numbers are excluded)" but evidently, as with GCOL, there have been later additions that are not documented there. When I first created BBC BASIC for Windows I wanted to include some popular PC screen resolutions (at the time), so the RISC OS set wasn't appropriate (not that I had any inclination to slavishly follow what Acorn had done, as I have said before).

64-126 are available for user custom modes with *NewMode.

In BB4W and BBCSDL I decided to take a totally different route to defining custom modes, using VDU 23,22.... The syntax is:

Code: Select all

      VDU 23,22,width;height;charw,charh,ncols,charset

where width and height are the (client) dimensions in pixels, charw and charh are the width and height of a character cell (pixels), ncols is the number of logical colours and charset determines the character encoding (0 = ANSI, 1 = OEM, 8 = UTF-8). Setting bit7 of charset reverses the default colour scheme from the usual white-on-black to black-on-white.

Richard.

[Soruk]

In fact I'm disappointed to see small speed variations being considered important in the case of Brandy: haven't we moved on from that?

In general yes. But if I do something sub-optimal in the code that unnecessarily slows it down, that's worth pointing out so it can be fixed.

I didn't/don't mean to complain about differences in speed - it just caught my attention that the speed of my test program running on the (at the time) latest version was roughly half (90 frames vs 170) and it made me wonder if there might potentially be a bug in the drawing routines, eg, where it does the same plotting operation twice or something.

I didn't mean to suggest that the speed difference was a serious issue. I definitely agree that adding features is more important than worrying about minor differences in speed.

It was updating more than it needed to, that was fixed by making it only draw where it had to, and do a full-screen blit from the buffer when refresh called as a one-shot or re-enabled. There are extra checks going on so that would slow it down a touch.

And, the latest commits in git change the *FXes a bit, I won't make a comment about purists or anything, butif it is royally breaking the spec then it needs to change. (The docs have updated too.)

In BB4W and BBCSDL I decided to take a totally different route to defining custom modes, using VDU 23,22.... The syntax is:

Code: Select all

VDU 23,22,width;height;charw,charh,ncols,charset

where width and height are the (client) dimensions in pixels, charw and charh are the width and height of a character cell (pixels), ncols is the number of logical colours and charset determines the character encoding (0 = ANSI, 1 = OEM, 8 = UTF-8). Setting bit7 of charset reverses the default colour scheme from the usual white-on-black to black-on-white.

That shouldn't be too hard to implement. Probably not in its entirety but should be able to map the bulk of it to a *NewMode, though since a mode number isn't a parameter it'll need to hardwire a number (probably 126).
Edit: As ncols is a byte, what's the value to supply for a 256-colour mode?

[Richard Russell]

As ncols is a byte, what's the value to supply for a 256-colour mode?

I don't explicitly support 256-colour (paletted) modes because the Beeb didn't have any, and by the time I developed BB4W 'true-colour' PC displays (if only 16-bit RGB565) were becoming commonplace. Such modes would only have been of value in emulating Acorn Archimedes (and later) hardware, and as I've said that was low on my list of priorities - not least because I've never owned or used one!

So BB4W and BBCSDL only support up to 16-colour paletted modes out-of-the-box, plus of course true-colour (e.g. 24-bit RGB) via the colour look-up table that Windows provides for BB4W (and I have implemented myself in BBCSDL). Having said that there is a Wiki article that describes how to create larger palettes using Windows API calls.

Had I wanted to support a 256-colour palette via the VDU 23,22... syntax I expect I would have used the value zero in the ncols byte, because since VDU automatically evaluates its parameters MOD 256 (except when delimited by a semicolon) it would have allowed the programmer to specify 256 in his code.

Richard.

[Soruk]

64-126 are available for user custom modes with *NewMode.

In BB4W and BBCSDL I decided to take a totally different route to defining custom modes, using VDU 23,22.... The syntax is:

Code: Select all

      VDU 23,22,width;height;charw,charh,ncols,charset

where width and height are the (client) dimensions in pixels, charw and charh are the width and height of a character cell (pixels), ncols is the number of logical colours and charset determines the character encoding (0 = ANSI, 1 = OEM, 8 = UTF-8). Setting bit7 of charset reverses the default colour scheme from the usual white-on-black to black-on-white.

I have made an implementation of this, with some caveats. Colours must be one of 2, 4, 16, or 0 (256), otherwise nothing will happen. Character width and height should be a multiple of 8, and will be rounded down if not (with a minimum value of . Character encodings are not supported, so only bit 7 has any effect. It defines MODE 126 - but manually re-selecting mode 126 will NOT preserve the inverse video.
While Brandy does not as yet support 24-bit colour - I should have asked earlier, do you use '24' as the ncols value for this? After all 16777216 would slighty overflow the single byte value!

[Soruk]

In addition to the INKEY changes, I've also checked into github hopefully a fix for the MODE 3 / 6 issue.

That's looking good.

Hopefully this looks better - we now have the black bars!

[Coeus]

There's certainly no JIT compilation going on, it's definitely interpreting as it goes along.

But I did find these in comments, while looking for something else entirely:

Code: Select all

** The format of each line of Basic is:
**
**      <line number>
**      <length>
**      <tokenised source>
**      <tokenised executable line>
**      <NUL>

and

Code: Select all

** by tokens. <tokenised executable line> is a second version of the line
** with variables replaced with pointers to symbol table entries and so
** forth. This forms the executable part of each line.

Assuming the code still implements this, this is moving the table lookups for variables outside of any loops (by doing it at the start) and should give a significant boost to performance to programs with loops of many iterations. It may also be a performance hit for programs which have a significant amount of code that is never executed (error handling etc) but that isn't in a loop and that also assumes it doesn't generate the executable version of the line upon first reaching it.

[Soruk]

Assuming the code still implements this, this is moving the table lookups for variables outside of any loops (by doing it at the start) and should give a significant boost to performance to programs with loops of many iterations. It may also be a performance hit for programs which have a significant amount of code that is never executed (error handling etc) but that isn't in a loop and that also assumes it doesn't generate the executable version of the line upon first reaching it.

I haven't touched any of that in my work on Brandy, so I'd suspect it's still true. I've mainly concentrated on the display output, some keyboard handling and a little bit of the MOS layer.

[Richard Russell]

Character width and height should be a multiple of 8

So how would one specify a custom mode with the same characteristics as MODE 3 for example? In BB4W and BBCSDL it would be:

Code: Select all

      VDU 23,22,640;500;8,20,2,0

but that has a character cell height value (20) that isn't a multiple of 8.

I should have asked earlier, do you use '24' as the ncols value for this?

No, ncols is always the number of logical colours, not the number of physical colours. So with a 24-bit RGB display the number of physical colours available is 2^24 irrespective of whether ncols is 2, 4, 8 or 16.

Richard.

[Soruk]

Character width and height should be a multiple of 8

So how would one specify a custom mode with the same characteristics as MODE 3 for example? In BB4W and BBCSDL it would be:

Code: Select all

      VDU 23,22,640;500;8,20,2,0

but that has a character cell height value (20) that isn't a multiple of 8.

Which is why I said "with some caveats" - as the code has special handling for MODEs 3 and 6, the custom mode code in Brandy is only capable of creating normal graphics modes.

[Phlamethrower]

If you're after a way of using arbitrary modes, it might be worth improving Brandy's support for the extensions to the MODE statement that were introduced in RISC OS 3.5:

Code: Select all

MODE <n>

If the unsigned value of N is less than 256, it's treated as a mode number. Otherwise, it's treated as a pointer to a mode selector block - mode selector blocks are the main way of specifying screen modes in 3.5+.

Code: Select all

MODE <string>

Allows mode selection using a mode string. Internally this just gets converted to an equivalent mode selector block, but it provides a more human-friendly way of selecting modes. (Note also that mode strings don't allow you to specify the full range of attributes that selector blocks do)

Code: Select all

MODE <x>,<y>,<bpp>[,<hz>]

Causes BASIC to construct a mode selector block and use that. BPP must be 1, 2, 4, 8, 16 (selecting a 32K colour mode), or 32 (selecting a 16M colour mode). On RISC OS the true-colour modes will always be VIDC20-style, with the red channel in the low bits of the pixel. But if Brandy doesn't allow direct screen access then you can obviously ignore those concerns and just focus one the # colours.

Code: Select all

MODE <x>,<y>,<flags>,<ncol>,<l2bpp>[,<hz>]

RISC OS 5 introduced this extension to the "x,y,bpp" form, since the earlier version was a bit limited in terms of its features (e.g. no sensible way of supporting red/blue swapped modes, 4K/64K colour modes, or alpha channel modes). Flags, ncol, l2bpp directly correspond to the Mode Flags, NColour, and Log2BPP mode variables (allowing easy conversion to a mode selector block).

If a mode selector block or mode string has been used, then reading the value of MODE will return a pointer to a (kernel-managed) copy of the mode selector block (which will only be valid until the next mode change).

[Soruk]

If you're after a way of using arbitrary modes, it might be worth improving Brandy's support for the extensions to the MODE statement that were introduced in RISC OS 3.5:

Brandy actually recognises all but the last of these (and the pointer to the mode control block). However as it stands it can only select from a mode that has already been defined (either built-in or from *NewMode / VDU23,22. It shouldn't be too much of a stretch to extend it to define a new mode if the values don't match a pre-defined mode.

[Richard Russell]

the custom mode code in Brandy is only capable of creating normal graphics modes.

BB4W/BBCSDL only have "normal graphics modes" (except MODE 7 of course). MODEs 3 and 6 aren't special at all, because the 'black gaps' between the rows aren't emulated; you can draw graphics in them just like the rest.

Richard.

[Soruk]

the custom mode code in Brandy is only capable of creating normal graphics modes.

BB4W/BBCSDL only have "normal graphics modes" (except MODE 7 of course). MODEs 3 and 6 aren't special at all, because the 'black gaps' between the rows aren't emulated; you can draw graphics in them just like the rest.

Ah, right. 3 and 6 are emulated in Brandy, and like the BBC/Arc, don't support graphics.

[Soruk]

If you're after a way of using arbitrary modes, it might be worth improving Brandy's support for the extensions to the MODE statement that were introduced in RISC OS 3.5:

Brandy actually recognises all but the last of these (and the pointer to the mode control block). However as it stands it can only select from a mode that has already been defined (either built-in or from *NewMode / VDU23,22. It shouldn't be too much of a stretch to extend it to define a new mode if the values don't match a pre-defined mode.

And - implemented. I've also extended *NewMode to allow the eigen factors to be set. One difference between this and RISC OS 3.71 (which is what I have running in RPCEmu) is that in RISC OS, setting the eigen value to values other than 1 alter the drawing coordinates but the mouse coordinates are NOT changed. In Brandy, both are changed keeping the mouse in step with the drawing. I don't intend to "fix" this, as I would actually class the RISC OS behaviour as a bug. RPCEmu bug with follow mouse enabled; ignore that - Brandy's implementation is OK.

[Phlamethrower]

One difference between this and RISC OS 3.71 (which is what I have running in RPCEmu) is that in RISC OS, setting the eigen value to values other than 1 alter the drawing coordinates but the mouse coordinates are NOT changed. In Brandy, both are changed keeping the mouse in step with the drawing. I don't intend to "fix" this, as I would actually class the RISC OS behaviour as a bug.

That's almost certainly an RPCEmu bug, not a RISC OS bug. Try disabling the mouse hack (aka "Follow host mouse"); it causes the emulator to intercept various mouse-related SWI calls, injecting its own values instead of allowing the call to be handled by the RISC OS kernel. And it looks like it just guesses what the eigen values are for the mode, instead of attempting to extract the values from the OS.

[Soruk]

One difference between this and RISC OS 3.71 (which is what I have running in RPCEmu) is that in RISC OS, setting the eigen value to values other than 1 alter the drawing coordinates but the mouse coordinates are NOT changed. In Brandy, both are changed keeping the mouse in step with the drawing. I don't intend to "fix" this, as I would actually class the RISC OS behaviour as a bug.

That's almost certainly an RPCEmu bug, not a RISC OS bug. Try disabling the mouse hack (aka "Follow host mouse"); it causes the emulator to intercept various mouse-related SWI calls, injecting its own values instead of allowing the call to be handled by the RISC OS kernel. And it looks like it just guesses what the eigen values are for the mode, instead of attempting to extract the values from the OS.

Yep, that fixes it. Mouse position and graphics cursor now agree with each other. So - no bug to fix in Brandy or RISC OS - and in RPCEmu I don't normally ever play with the eigen values, I just added support in Brandy for the extended MODE options. As I run RPCEmu fullscreen on an old netbook (and it performs surprisingly well on that), I'll just leave follow host mouse off.

[Soruk]

SWI support is here - well, the beginnings of it.

Enough that some of the demos from http://www.proggies.uk/riscosstuff/index.html work unmodified. Only the ones available as Text work, and then only the ones which don't use any assembly language. But, the Raspberry Pi logo, the Risc OS Open logo (without the starfield) and the Pseudo 3D starfield all work unmodified now. (The ones that purport to be in BASIC (FFB) don't load in either Brandy or ARM BBC BASIC on RISC OS 3.71.)

There's no facility for it to use external modules, what SWIs are available are all implemented within the MOS code of Brandy.

Edit: This, along with locally-defined OSBYTE 43 (write character to controlling Linux terminal), has allowed me to amend the old Tek examples library (examples/teklib) so they once more can run from Brandy, as they used to prior to SDL graphics being implemented.

[Soruk]

Hi,

I've just released version 1.21.10. Changes since 1.21.9 include:
* *REFRESH now follows BB4W/BBCSDL behaviour, with extension *REFRESH ONERROR to re-enable on an error condition.
* Some local OSBYTEs defined, including reading *REFRESH setting, and sending characters to controlling terminal
* VDU23,22 from BB4W/BBCSDL implemented (to a degree).
* Extended MODE commands as defined in RISC OS 3.5 now supported, and will define a new mode if the requested mode doesn't already exist.
* Initial SWI support - only a few SWIs currently supported, and are all implemented within Brandy, they don't call external libraries.
* The old Tek demos once again work, as they did in Brandy 1.19.
* Bug fixes include COLOUR r,g,b and GCOL r,g,b now doing the right thing with values > 255.

[dhg2]

I've noticed some keyboard/input related bugs. If you run this:

Code: Select all

REPEAT:PRINT GET:UNTIL0

then press any of the arrow keys, page up/page down, Insert, End, or F1 through F12, it seems like two keypresses are recorded into the keyboard buffer. So a 0 appears, and then a number representing the key that you pressed.

Also, if the Capslock is off, pressing the Capslock key seems to put a 0 on the keyboard buffer. This causes another problem where if you switch the capslock on and then start typing at the prompt, the next letter you type after turning on the capslock won't appear. So if you type "one (capslock)two", "one WO" will appear on the screen.

[Soruk]

I've noticed some keyboard/input related bugs. If you run this:

Code: Select all

REPEAT:PRINT GET:UNTIL0

then press any of the arrow keys, page up/page down, Insert, End, or F1 through F12, it seems like two keypresses are recorded into the keyboard buffer. So a 0 appears, and then a number representing the key that you pressed.

Good spot. I'll take a look at that.

However...

Also, if the Capslock is off, pressing the Capslock key seems to put a 0 on the keyboard buffer. This causes another problem where if you switch the capslock on and then start typing at the prompt, the next letter you type after turning on the capslock won't appear. So if you type "one (capslock)two", "one WO" will appear on the screen.

I can't replicate this one. But, I'll keep trying.

[dhg2]

I can't replicate this one.

Hmm, it happens very reliably for me. Is it possible that different window managers or different distros could affect it somehow? I'm using XFCE on Debian stable.