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

[Soruk]

Default value for the byte is 1

The default is zero in BB4W and BBCSDL. To get rid of the gap in those versions it's necessary to change the setting explicitly:

Code: Select all

      MODE 1
      VDU 23,16,1|
      PRINT STRING$(40,"*")

The other bits of VDU 23,16 are also implemented in BB4W and BBCSDL:

Code: Select all

      MODE 1
      VDU 23,16,2|13
      PRINT "txet tfel-ot-thgir fo elpmaxe na si sihT"

There is some added complication because I also support proportional-spaced fonts, making right-to-left printing particularly tricky. Is there any support for proportional-spaced text in Matrix Brandy?

There is no facility for proportional fonts in Matrix Brandy - if I want to go down that route with SDL's TTF support (assuming it exists in 1.2) I'll most likely implement it in a way familiar to the RISC OS FontManager. Once I get my head around that!

[Soruk]

That's the rest of VDU23,16 implemented, apart from bit 3 (so making the x-axis vertical and y-axis horizontal is not supported).

[dhg2]

Is control+shift implemented? I mean, the keys that pause text scrolling. I don't remember if control+shift is the right combination. I mean, my hand knows, if you know what I mean. (I'm away from a computer and typing this on my phone)

[Soruk]

Is control+shift implemented? I mean, the keys that pause text scrolling. I don't remember if control+shift is the right combination. I mean, my hand knows, if you know what I mean. (I'm away from a computer and typing this on my phone)

I don't know about that combination... so I'll have to test that on my RPCEmu box. I do know about VDU14 (or CTRL-N) causing scrolling to stop after a screenful, with a tap of SHIFT to page the next screen. That isn't emulated - though Brandy implements an extra bit in LISTO (32) to pause scrolling a LIST after a handful of lines.

[Richard Russell]

Is control+shift implemented? I mean, the keys that pause text scrolling. I don't remember if control+shift is the right combination.

Should it be relevant, Ctrl+Shift pausing is implemented in BBC BASIC for Windows, but not in BBC BASIC for SDL 2.0. VDU 14 pausing is implemented in both.

[Soruk]

Is control+shift implemented? I mean, the keys that pause text scrolling. I don't remember if control+shift is the right combination.

Should it be relevant, Ctrl+Shift pausing is implemented in BBC BASIC for Windows, but not in BBC BASIC for SDL 2.0. VDU 14 pausing is implemented in both.

OK - we now have VDU14 paging enabled. Please note that hitting CTRL-N does not control this as the line editor uses CTRL-N as a "next line in history", similar to BASH's line editor. Though, since the arrow keys also work for the line editor, this could be changed...

Edit: OK, I changed it. By default, it's as above, but OSBYTE 44 (x=0) will disable that, so CTRL-N will send VDU14 (and CTRL-P will send VDU16 - not sure why you'd want to do a CLG like that, but it tries to match the behaviour and be consistent). Non-zero x will re-enable default behaviour.

[bakoulis]

The last changes produces some compiler warnings:

Code: Select all

src/graphsdl.c: In function ‘scroll’:
src/graphsdl.c:919:19: warning: iteration 24 invokes undefined behavior [-Waggressive-loop-optimizations]
  mode7changed[n+1]=mode7changed[n];
  ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~
src/graphsdl.c:917:7: note: within this loop
       for(n=0; n<=24; n++) {
       ^~~
src/graphsdl.c:878:32: warning: iteration 23 invokes undefined behavior [-Waggressive-loop-optimizations]
  mode7changed[n-1]=mode7changed[n];
                    ~~~~~~~~~~~~^~~
src/graphsdl.c:876:7: note: within this loop
       for(n=2; n<=25; n++) {
       ^~~

[Soruk]

Hi,

I've just put together version 1.21.15, it's on the website and Github as usual.

This release includes a handful of bug fixes (one of which I inadvertently introduced back in 1.21.8 ) and enhancements, some of which are:
- Bug fix: Setting *KEY15 scribbled outside array bounds.
- Bug fix: Erroneously trimming a string introduced in V1.21.8.
- Improvement: In networking code, move WSAStartup (MinGW) to init, if this fails, disable networking.
- Enabled VDU14/15 scroll paging. Note, by default Brandy uses CTRL-N for accessing the next line in the command line history (along with CTRL-P for previous line). OSBYTE 44 with x=0 disables this, so CTRL-N will send the VDU14 code, CTRL-P will send the VDU16 (CLG) code. (CTRL-O will always send the VDU15 code.)
- Enabled VDU23,16; currently bits other than 3 are observed. This sets the scroll protect mode, X and Y cursor movement and whether the screen is overprinted or scrolled when the Y limit is reached, and whether VDU5 mode linewraps. (Bit 3, making Y horizontal and X vertical is NOT supported.)
Default value is 1 (*CONFIGURE NOSCROLL on RISC OS or BBC Master) and the VDU mode when RISC OS Desktop is running (or in a single tasking state from F12 or Exit) regardless of Scroll/NoScroll configuration setting.
- Fix compiler warnings for MinGW - and allow DOS-type commands to return their output to the SDL window (so *dir works for example).
- Flush SDL queue on INKEY and MOUSE reads, otherwise events start to get missed (bonus point: Close window icon is more responsive.)
- LISTing a program now stops on ESCAPE.
- Code cleanups: Remove functions that aren't used anywhere.
- Updated some of the documentation to reflect the changes introduced in Matrix Brandy.
- Improved the Mode 7 appearance, using a font based on Risc OS 5's 16x20 font (with small tweaks) - see docs/Mode7.txt - and speed up Mode 7 screen updates.

Have fun with it, if you find any breakage please shout!

[Soruk]

The last changes produces some compiler warnings:

Code: Select all

src/graphsdl.c: In function ‘scroll’:
src/graphsdl.c:919:19: warning: iteration 24 invokes undefined behavior [-Waggressive-loop-optimizations]
  mode7changed[n+1]=mode7changed[n];
  ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~
src/graphsdl.c:917:7: note: within this loop
       for(n=0; n<=24; n++) {
       ^~~
src/graphsdl.c:878:32: warning: iteration 23 invokes undefined behavior [-Waggressive-loop-optimizations]
  mode7changed[n-1]=mode7changed[n];
                    ~~~~~~~~~~~~^~~
src/graphsdl.c:876:7: note: within this loop
       for(n=2; n<=25; n++) {
       ^~~

Argh, I have this track record of something like this happening just after I've put together a release!

I've just checked in a change that should sort this (and moved the label).

[bakoulis]

Fixed! The warnings have gone.

[Soruk]

I came across this ( https://groups.io/g/bb4w/topic/25390331 ) earlier today.

Richard, I'm sorry you sometimes feel Matrix Brandy is a "threat". That is not, and has never been my intention.

BB4W is a mature, stable and highly acclaimed product which you should be rightly proud of.
BBCSDL, while much newer, is grounded in your BB4W work, thus immediately giving it a prestigious background and undoubtedly it'll be more stable than Matrix Brandy.
Whereas, Matrix Brandy is based on development code, no doubt has serious bugs ( that I haven't found yet ) and doesn't (and probably never will ) have an assembler, and no direct access to host OS features is offered. Where I have implemented BB4W features it was by user request and seemed pretty straightforward to implement. I am not attempting to align Matrix Brandy with BB4W or BBCSDL, it is a conscious decision to align more closely with RISC OS.

The Windows build of Matrix Brandy is not, and never will be, a focus for development, Linux is where I am concentrating.

Also, as an aside, the reference to Brandy in MagPi magazine is to the one in the repos, version 1.20.1, which is where I forked from.

[Richard Russell]

Richard, I'm sorry you sometimes feel Matrix Brandy is a "threat". That is not, and has never been my intention.

Please don't feel bad about Matrix Brandy being so good! Ever since I encountered Brandy (long before you were involved) I realised that it was a potential 'threat' for the simple reason of being so much faster than my BASICs.

Matrix Brandy is based on development code, no doubt has serious bugs ( that I haven't found yet ) and doesn't (and probably never will ) have an assembler, and no direct access to host OS features is offered.

You are too modest. Whenever any 'missing' feature has been mentioned here you have managed to implement it within days (sometimes within hours). Some of the editions of BBCSDL don't have an assembler either, and didn't you only today announce that Matrix Brandy can now access the Windows command line (e.g. *dir)?!

[Soruk]

and didn't you only today announce that Matrix Brandy can now access the Windows command line (e.g. *dir)?!

It has always been able to, what I fixed was the output being returned to the SDL window which was previously broken.

There is no capability of SYS to access arbitrary host (or even SDL) functionality, what gets enabled are specific operations that are cross-platform, typically emulating a RISC OS SWI call.

[Richard Russell]

There is no capability of SYS to access arbitrary host (or even SDL) functionality

Yet!

[Soruk]

On a branch (rpigpio), I'm experimenting with adding GPIO support for the Raspberry Pi, while not breaking anything for any other platform. In keeping with the BBC Micro style of I/O ports being memory-mapped, if Brandy is able to open /dev/gpiomem for read-write, then it'll mmap() it, and the following code can be used to test whether it's available, and if so, where:

Code: Select all

SYS "RaspberryPi_GPIOInfo" TO present%,gpiomem%

If /dev/gpiomem is available and usable, present% will be set to 1, and gpiomem% set to the base of memory as addressed within Brandy. Otherwise, present% will be set to 0, and gpiomem% to &FFFFFFFF. This will happen every time Matrix Brandy is started.

Edit: That's a bunch of SYS calls added - and documented (docs/raspi-gpio.txt).

In addition to the SYS calls, it should work with a modified version of Richard Russell's gpiolib.bbc - with a small change. The DEF FN_gpio_setup needs to be changed to:

Code: Select all

DEF FN_gpio_setup
LOCAL present%
SYS "RaspberryPi_GPIOInfo" TO present%,G%
IF present%=0 THEN ERROR 0, "GPIO not present or usable"
= G%

I don't actually have any interface attached to my RaspberryPi to test whether any of this actually works, so this is all a real stab in the dark. If there's anyone who is in a position to test it, that would be most welcome.

[Soruk]

On the mainline branch, I've fixed a bug in LIST where I hadn't protected the ESCAPE check (which calls INKEY(-113)) to only being called if built with SDL, thus LIST crashed with an Unsupported feature error after one line on text mode builds.

Oops.

[dhg2]

I'm planning on putting the console/text only version of brandy to some serious use.
I have a headless raspberry pi next to my bed that drives a speaker system. It has a bunch of bash scripts and C programs that I wrote years ago that make it work as a white noise machine or a music player, controlled by a USB joypad.

The scripts I wrote aren't very good and are hard to maintain. I never liked bash. Now with textmode brandy available, I think it'd be the perfect language to rewrite my scripts in. It'll probably be a lot more reliable and definitely a lot easier to maintain.

I'll probably start working on it in november since this month has been pretty busy for me.

[Soruk]

I'm planning on putting the console/text only version of brandy to some serious use.
I have a headless raspberry pi next to my bed that drives a speaker system. It has a bunch of bash scripts and C programs that I wrote years ago that make it work as a white noise machine or a music player, controlled by a USB joypad.

The scripts I wrote aren't very good and are hard to maintain. I never liked bash. Now with textmode brandy available, I think it'd be the perfect language to rewrite my scripts in. It'll probably be a lot more reliable and definitely a lot easier to maintain.

I'll probably start working on it in november since this month has been pretty busy for me.

Sounds interesting! If you find issues, or something you want to do and find you can't, please do shout.

[Soruk]

I've merged my Rasperry Pi GPIO stuff to mainline - it seems to follow the spec, but I don't have an attachment for my RPi to test whether GPIO lines are being asserted.

[scruss]

I'd be very happy to get you a PiStop, which is about the simplest and cheapest GPIO thingy

[Soruk]

I'd be very happy to get you a PiStop, which is about the simplest and cheapest GPIO thingy

I hadn't seen that before - looks good. I've just ordered myself one. Might have to get myself a new RPi as well, the one I develop on is my sort-of thin client desktop which is also an NFS server for my Kodi boxes (and my wife will kill me if I crash it!) so a new one for tinkering wouln't be a bad idea.

[Soruk]

My PiStop and new RasPi 3+ arrived, and I decided to give it a go.

And, much to my surprise, plugged in the PiStop in one of the recommended locations, set the associated GPIOs to output and started wiggling values and the lights lit up on the very first attempt.

So, YAY. It works, for GPIO pins set as output. Reading inputs might be a touch trickier if I don't want to blow my Pi up... but if I'm reading the blurb correctly, I can join Pin 1 (3V3) or pin 9 (GND) to a GPIO pin set as input should be safe. Cross fingers.

Edit: That worked too on a couple of randomly chosen GPIO pins. And my RasPi lives.

One thing that will change, the code refers to GPIO Pin numbers, they will be renamed to GPIO Port, as the pins don't map to GPIO port numbers.
(Edit: That change has been pushed into Github)

These tests were run using the SYS calls, documented in docs/raspi-gpio.txt. I haven't yet checked with Richard's gpiolib library (with the above modification).

[scruss]

My PiStop and new RasPi 3+ arrived, and I decided to give it a go.

And, much to my surprise, plugged in the PiStop in one of the recommended locations, set the associated GPIOs to output and started wiggling values and the lights lit up on the very first attempt.

Yay! Without resorting to using sudo, I hope?

One thing that will change, the code refers to GPIO Pin numbers, they will be renamed to GPIO Port, as the pins don't map to GPIO port numbers.

Pin numbering is … a little confusing on the Raspberry Pi. There are at least three different systems. The RPF-recommended way of referring to them is by BCM number rather than physical pin, eg BCM 2 is on physical pin 3. These are the labels produced by the pinout command and described on the pinout.xyz site.

[Soruk]

My PiStop and new RasPi 3+ arrived, and I decided to give it a go.

And, much to my surprise, plugged in the PiStop in one of the recommended locations, set the associated GPIOs to output and started wiggling values and the lights lit up on the very first attempt.

Yay! Without resorting to using sudo, I hope?

Yep - provided your user is a member of the gpio group. New Raspbian distros have this out of the box.

One thing that will change, the code refers to GPIO Pin numbers, they will be renamed to GPIO Port, as the pins don't map to GPIO port numbers.

Pin numbering is … a little confusing on the Raspberry Pi. There are at least three different systems. The RPF-recommended way of referring to them is by BCM number rather than physical pin, eg BCM 2 is on physical pin 3. These are the labels produced by the pinout command and described on the pinout.xyz site.

Yep, it's using the BCM numbers, the SYS calls were erroneously using the term "pin", which I've renamed to "port".

Also, just been testing a tweak of Richard's gpiolib.bbc - it doesn't work as written as Brandy doesn't support things like M% AND=127. So, I've written a replacement library, using the same call names as Richard's gpiolib, but using my SYS calls instead under the lid, to allow a degree of BASIC-code compatibility. This is also checked in as of a few minutes ago.

Edit: That M% AND= 127 construction is not valid in BBC BASIC on RISC OS 3.71 either.

[Richard Russell]

Edit: That M% AND= 127 construction is not valid in BBC BASIC on RISC OS 3.71 either.

My recollection (and it was more than 17 years ago!) is that when adding the compound assignment operators I decided to include a more complete set than ARM BASIC does. So BB4W and BBCSDL support += -= *= /= AND= OR= EOR= DIV= and MOD=.

I think this extension came effectively for free; I don't know why Sophie didn't do the same. Compound assignment is particularly valuable in an interpreted language because it saves a variable lookup.

[jgharston]

Edit: That M% AND= 127 construction is not valid in BBC BASIC on RISC OS 3.71 either.

Integer compound assignments are supported in ARM BBC BASIC 1.37-Plus.

[Soruk]

Edit: That M% AND= 127 construction is not valid in BBC BASIC on RISC OS 3.71 either.

Integer compound assignments are supported in ARM BBC BASIC 1.37-Plus.

Interesting, not seen that before.

Anyway, I've got AND=, OR=, EOR=, MOD= and DIV= implemented for integer variables (+= and -= already exist). Not quite sure how I would implement bitwise operations on floats...

[Coeus]

Anyway, I've got AND=, OR=, EOR=, MOD= and DIV= implemented for integer variables (+= and -= already exist). Not quite sure how I would implement bitwise operations on floats...

Presumably,

Code: Select all

A AND= B

should do the same as

Code: Select all

A=A AND B

? The latter seems to treat them as booleans.

[Richard Russell]

Not quite sure how I would implement bitwise operations on floats...

What makes a compound assignment different from a conventional bitwise operator (which presumably does work with floats)? I'm pretty sure that in BB4W and BBCSDL the two work identically, except for the variable only needing to be looked up once in the former case:

Code: Select all

>a = 59.5
>a AND= &55
>PRINT a
        17
>
>DIM a(10)
>a() = 59.5
>a() AND= &55
>PRINT a(0), a(10)
        17        17

[Soruk]

Anyway, I've got AND=, OR=, EOR=, MOD= and DIV= implemented for integer variables (+= and -= already exist). Not quite sure how I would implement bitwise operations on floats...

Presumably,

Code: Select all

A AND= B

should do the same as

Code: Select all

A=A AND B

? The latter seems to treat them as booleans.

Apart from the fact I haven't implemented them on floating point variables (separate handlers required), here's what I'm getting for A AND B

Code: Select all

>A=160
>B=127
>PRINT A AND B
        32
>
>A=A AND B
>PRINT A
        32
>

Looks right to me. If using A% and B% instead, I can also do A% AND=B%

Code: Select all

>A%=160
>B%=127
>A% AND= B%
>PRINT A%
        32
>

Edit: Looking at the float behaviour, it appears to be doing an INT on both arguments:

Code: Select all

>PRINT 12.34 AND 56.78
         8
>PRINT 12 AND 56
         8
>

This behaviour is the same on RISC OS 3.71. So that would be a way forward to implementing these bitwise operations on floats.