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!

Last edited by Soruk on Mon Oct 08, 2018 1:27 pm, edited 1 time in total.

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)

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.

Last edited by Soruk on Wed Oct 10, 2018 5:14 pm, edited 1 time in total.

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.

Last edited by Soruk on Thu Oct 11, 2018 3:41 pm, edited 2 times in total.

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!

Last edited by Soruk on Fri Oct 12, 2018 11:03 am, edited 2 times in total.

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.

Last edited by Soruk on Fri Oct 12, 2018 6:08 pm, edited 1 time in total.

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)?!

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:

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.

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.

Last edited by Soruk on Tue Oct 16, 2018 10:49 pm, edited 3 times in total.

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.

Last edited by Soruk on Wed Oct 17, 2018 4:57 pm, edited 1 time in total.

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.

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.

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.

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).

Last edited by Soruk on Sat Oct 27, 2018 9:48 pm, edited 5 times in total.

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.

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.

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.

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: