Matrix Brandy BASIC V1.22.13 released

Soruk

Hi,

Earlier this month I released version 1.22.12 of Matrix Brandy BASIC VI, with binary builds for Win32, Win64, RISC OS 26-bit and RISC OS 32-bit.

Changes in this release include:

- System: Fix some floating-point data size mismatches

- System: Fix calculations of matrix dot products (thank you mikefairbank@Github!)

- System: New RISC OS build process using GCCSDK under Linux (thank you Cameron Cawley!)

- Keyboard: Fixed keyboard from eating too much from event queue (thanks David Hawes!)

- Graphics: Implemented GCOL action codes 5-7

- Graphics: Hopefully fixed a triangle drawing bug.

- Graphics: Implement VDU23,16 (as far as already implemented) in VDU5 mode, and fixed many bugs in VDU4 mode. (Still no vertical printing though, at least not in VDU4 mode)

- Teletext: Implemented VDU23,18,4,pri,alt| to select character sets.

This is much cleaner than using SAA505Xlib in the examples, but that will remain as an example for OSWORDs &8B and &8C.

- BASIC: Fix COLOUR(r,g,b) function to return correct values in 256-colour modes.

- BASIC: Fix behaviour of RND followed by a space before parentheses to match ARM and 6502 BBC BASIC.

- BASIC: Change the behaviour of cascaded IF calls to match the behaviour of BBCSDL and friends. This is switchable and can be switched back to Acorn's (strange) behaviour via a SYS call.

- INKEY(-256) now returns ASC("M") (&4D) on ALL platforms, including RISC OS. (OS_Byte 129,0,255 and R5 from Brandy_Platform return the traditional platform value)

Source and binary downloads are available on the website, with source also at GitHub.

Soruk

Several updates since this release - in addition to the float and exponent formatting shenanigans in this thread I've made a change to loading and reading files, to make Matrix Brandy a bit more friendly for programs that were designed for Richard's BASICs. For LOAD, CHAIN, OPENIN and OPENUP, if a file isn't found, retry with a ".bbc" suffix before complaining. This isn't enabled for RISC OS as it doesn't use suffixes and it can already directly handle files from ARM BBC BASIC.

[Richard Russell]

The latest version is behaving curiously when asked to format numbers in fixed-point mode with zero decimal places, for example:

@% = &2000A
PRINT PI

There is some variability between different BASIC versions but Matrix Brandy is a definite outlier:

6502 BASIC 2:        3.
ARM BASIC V :        3.
ARM BASIC VI:        3.
BB4W v6.14a :         3
BBCSDL      :         3
MatrixBrandy:3.14159265358979312

Personally I dislike the way that Acorn BASICs print the decimal point despite having zero decimal places, it's not a style that I would ever use.

Soruk

Oh, ouch. That's a good spot. Easily fixed though, and I've rebuilt the nightlies (and RISC OS build).

And no, I'm not doing that trailing decimal point either. (The output from the C library doesn't produce it and I see no reason to artificially add it.)

Soruk

I have released version 1.22.13 of Matrix Brandy, with binary builds available for Windows (32 and 64 bit) and RISC OS (26-bit, 32 bit and ARMv6+VFP)

Changes include:
- System: Stricter handling of oversize variable and PROC/FN names.
- System: Improved handling of ESCAPE under RISC OS (notably, it no longer crashes the interpreter).
- System: Improve behaviour on Linux console framebuffer, particulary Raspberry Pi. Experience may vary across other hardware.
- System: Remove the old keyboard code, JGH's NEWKBD code is now the only version present.
- System: On non-RISC OS platforms, when using LOAD, CHAIN, OPENIN and OPENUP, if file isn't found, retry with a .bbc suffix before complaining. SAVE and OPENOUT will not use a .bbc suffix unless explicitly provided in the filename.
- System: Permit system memory to be up to 4194303K (4GB less 1K)
- System: Programs saved under RISC OS now get file type &FD1 (allocated by Acorn as BASIC stored as text). The file type is associated with Matrix Brandy for loading and running by double-clicking on the desktop.
- System: RISC OS: MODE in form xres,yres,depth was broken. Fixed.
- Graphics: Reworked line drawing, the earlier adaption of upstream was not right. This new version is based on PiTubeDirect's implementation.
- Graphics: Dot patterns, VDU23,6 and OSBYTE 163,242 now implemented
- Graphics: Fixed a crash bug due to SDL not being particularly thread-safe.
- BASIC: PRINT and STR$ now support displaying a decimal comma instead of a point.
- BASIC: PRINT and STR$ now show exponents in the style used by the BBC and RISC OS, rather than the C standard.
- BASIC: @% with precision 0 now uses &11 (except in fixed-precision mode), same as ARM BBC BASIC VI.
- BASIC: @% with width set to 0 now left-justifies, as per Acorn BASICs, RTR's assembly-language builds and (as of V0.40) BB4C.
- BASIC: @% precisions greater than &11xx are now capped at &11xx.
- BASIC: LVAR now includes @% in its output, displaying both in hex and its string form.
- BASIC: Extended TRACE with TRACE VDU [OFF], this redirects TRACE output to Brandy's controlling terminal, specifying OFF puts it back to normal.

Source and binary downloads (Windows, RISC OS) are available on the website, with source also available at GitHub.

[Richard Russell]

System: Stricter handling of oversize variable and PROC/FN names

Can you go into some more detail? What does "oversize" mean in this context?

Soruk

Richard_Russell wrote: »

System: Stricter handling of oversize variable and PROC/FN names

Can you go into some more detail? What does "oversize" mean in this context?

There's a fixed buffer of 256 bytes used in places to hold a variable or PROC/FN name - including the zero byte terminator. However, when it was being populated there was no bounds checking to ensure the name would fit, causing corruption and a crash. Thus, this change was to report an error for a variable or PROC/FN name in excess of 255 characters. (Matrix Brandy lines are not limited to 255 characters (the text client has a limit of 943, SDL version is limited to 1022), unlike Acorn's BASICs (or is it the OS readline code?) which are actually limited to inputting no more than 238 characters).

[Richard Russell]

Matrix Brandy lines are not limited to 255 characters

Ah. As far as I know, in every other version of BBC BASIC variable names are limited to 250 characters anyway (and FN/PROC names to even fewer). Logical line lengths are not limited in my current BASICs, but names still are.

[Richard Russell]

Soruk wrote: »

- Graphics: Implemented GCOL action codes 5-7

Am I doing something silly, or is this indicating that GCOL action code 5 isn't working properly:

MODE 27
GCOL 0,129
CLG
GCOL 5,0
MOVE 0,868
PLOT 101,1248,884

This ought to plot nothing (GCOL 5 is 'nop') but here I see a black bar.

Soruk

That's a good spot. As it happens, the handler for filled rectangles has its own GCOL action handler as it writes directly to the frame buffer for performance instead of using the plot_pixel primitive used by practically everything else. This has now been fixed, in addition to adding the code for action codes 6 and 7.

I've also rebuilt the "nightly" Windows binaries.

Soruk

Very much an aside and an observation - Debian Bookworm (the next release, currently in development and pencilled in with a mid 2023 release) has made the switch from upstream to Matrix Brandy. This should eventually filter down to Ubuntu and Raspberry OS. Hopefully they will be tracking releases as they have taken the January 2022 release and none of the updates since then.

Soruk

Earlier today I've checked in an important bug fix / workaround for the sdl12-compat library. Some distros (notably RHEL 9 and its derivatives) ship with this instead of the real SDL-1.2.15 library. sdl12-compat is a binary and source compatibility library that an SDL 1.2 app can link against, but under the lid it's using SDL 2.
I spotted an issue with that when tinkering with AlmaLinux 9 where the keysym.unicode value isn't correctly populated when the CTRL key is used. I have raised an issue on their github, but in the meantime I've added a workaround as this situation is detectable (keysym.unicode is zero), to use the keysym.sym value to work out what should be returned and use that instead. If it's supposed to be zero for a particular key sequence, the workaround can return this and all is good. Once it's fixed in the library and it's trickled down to the distros, I'll remove the workaround.