Matrix Brandy BASIC VI for console and SDL1.2: V1.23.1 released

[Soruk]

I have today released version 1.23.0 of Matrix Brandy.

Changes include:

- System: Add '-tek' (or -t) option to enable Tek graphics for 'tbrandy' on compatible platforms. Equivalent to issuing SYS"Brandy_TekEnabled",1
- System: Strict mode can now be set programmatically with SYS"Brandy_Strict".
- System: Strip quotes from filenames in *LOAD and *SAVE
- System: Implemented OSWORDs 1 and 2
- System: Fix file name bug in OSFILE.
- System: Filename translation between RISC OS and Linux for OPENIN, OPENOUT and OPENUP.
- System: Added "-nofull" command line option, to disable switching into full-screen mode (for questionable hardware, e.g. Poulsbo chipsets)
- System: Do not hang on text build startup when console doesn't handle the ANSI sequence to report the cursor location (e.g. Minix3 console), instead time out after 0.5 seconds.
- MOS: *Refresh, *WinTitle and *FullScreen are now recognised on RISC OS builds, but do nothing. (Previously, they raised a "Not Found" error.) This is to allow programs written targeting other platforms a better chance to run correctly under RISC OS without further modification.
- MOS: OSBYTEs 42-44 deprecated, use 163,2-4 instead.
- BASIC: LOCAL with no parameters now does nothing (as per Acorn) instead of reporting an error. This new behaviour is in place on a DEFAULT_IGNORE build unless -strict is set, or if -ignore is set. This can also be toggled at runtime with SYS"Brandy_Strict".
- BASIC: If Strict option is set, warnings are handled as fatal errors if a program is running.
- BASIC: Limit the recursion depth of RUN.
- BASIC: Don't choke if a numeric DATA element contains a comma (e.g. multi-dimensional array member or FN call)
- BASIC: Clear variable stubs if a DIM fails, and after CLEAR HIMEM.
- BASIC: Indirection with floats containing addresses > 32 bits now work.
- BASIC: Print a warning if a conversion from int64 to float loses precision.
- BASIC: Fix bugs in Exponent format number printing. Graphics: Fixed multiple problems with VDU24, RECTANGLE FILL, MOUSE and the plot_pixel() primitive, primarily to do with the oddball MODE 22. Thanks to Michael Fairbank for identifying and assisting with fixing this.
- Graphics: Fixed a cursor placement bug for VDU31 (PRINT TAB(x,y)) in VDU 5 mode.

As of this release, the git repository master branch will track releases. Development will be found in the dev-main branch.

[scruss]

Thank you for this. I must admit that now Brandy lives as a usable version in Debian, I haven't been tracking current development. I am a little annoyed that the tbrandy/sbrandy text builds aren't included in the Debian package, but only a very little.

[Soruk]

Given enough time (ha!) I may look into how to build a Debian repo and add it to my nightly builds script, perhaps even for Raspberry Pi (though my carbon-dateably-old build I have running as a desktop thin-client wouldn't exactly be suitable for this...)

[nicolagiacobbe]

Thanks Soruk for all the hard work and while I do agree that an apt-updated Matrix Brandy would be a bliss at the moment is more of a lesser nuisance.
Obviously, if you want to build a Debian repo I won't be the one stopping you...
Good job.

[scruss]

Thanks Soruk for all the hard work and while I do agree that an apt-updated Matrix Brandy would be a bliss at the moment ...
Good job.

There already is one:

Code: Select all

$ apt-cache policy brandy
brandy:
  Installed: 1.22.14-1
  Candidate: 1.22.14-1
  Version table:
 *** 1.22.14-1 500
        500 http://deb.debian.org/debian bookworm/main arm64 Packages
        100 /var/lib/dpkg/status

It may not be quite the newest, but it's quite usable.

It absolutely shouldn't be up to Soruk to address the Debian maintainer's omission. I think I know the maintainer from another forum, so I'll drop a bug and see what happens.

[scruss]

Given enough time (ha!) I may look into how to build a Debian repo ...

Have you seen this?
#1038058 - brandy: Depends on SDL 1.2 - Debian Bug report logs
I don't know if you'd considered the move to SDL 2, but SDL 1.2 appears to be unmaintained. The bug report actually appears to contain some helpful information, which may be a first.

[Soruk]

I would like to but I don't understand SDL2 anything like well enough. If Debian ships sdl12-compat (as RHEL9 does), Matrix Brandy compiles and runs against that just fine. I build and test with that on Alma9 and Fedora 38/39.

[scruss]

If Debian ships sdl12-compat (as RHEL9 does), Matrix Brandy compiles and runs against that just fine. ...

It does, yes. I can try it out on Raspberry Pi OS, which is also a Wayland thing.

The bug for the missing tbrandy/sbrandy is here: #1064860 - brandy: tbrandy and sbrandy command-line interpreters are missing - Debian Bug report logs

Update: tbrandy and sbrandy will be in the next release of the Debian brandy package, as confirmed in the updated bug link. This might take a while to filter down: maybe 18 months or so. But that's the speed that Debian moves at.

[scruss]

I've confirmed that the standard Debian package runs with libsdl1.2-compat-shim (the SDL 2 wrapper that provides SDL 1.2 compatibility), and that brandy compiles and runs with libsdl1.2-compat-dev under Debian. So I don't think you need to do anything to get SDL 2 compatibility.

[Soruk]

It absolutely shouldn't be up to Soruk to address the Debian maintainer's omission. I think I know the maintainer from another forum, so I'll drop a bug and see what happens.

It's absolutely fair enough for a project like Debian to only use release versions, rather than some random point in the git checking history, and they probably stuck with 1.22.14 as that was the latest release at the time of setting in stone what the bookworm release would contain.

What I was thinking of was, like my Yum repo, is having a nightly build repo that includes the latest and (not necessarily) greatest changes. (I also have a releases Yum repo.)

I do intend to speed up the release process - maybe like in the earlier days releases contained fewer fixes but I released more often. (Even Richard Russell releases more often than me lately!) However I am not operating to a fixed schedule.

@Scruss Thanks for prodding Debian with the text builds.

[Soruk]

Highly experimentally (as part of me figuring out how to play with Docker), I've put an image together that contains the 'tbrandy' variant of the interpreter. It's on Docker Hub as soruk42/brandy. Just a note that, as it stands, you must run it interactively (docker run -it soruk42/brandy). Of course, if you modify it to make it run a program (that requires no input) then exits, it will run fine without being run interactively.

[Soruk]

I have today released version 1.23.1 of Matrix Brandy.

Changes include:

- System: Rework the threading model to use pthreads even under SDL, this allows a custom thread size to be set, so the recursion limit is now a factor of the stack and workspace size.
- Graphics: Fix VDU 19 where physical colour is 8 to 15. Thank you to Richard Russell for spotting this.
- Networking: BGET# was broken on x86-32 and x86-64 (but not ARM), returning negative numbers if bit 7 was set. Thank you to BeeBS.ddns.net for their help with tracking this down.
- BASIC: Fixed a bug importing Russell-format tokenised BASIC where tokens were incorrectly decoded. Again, thank you to Richard Russell for spotting this.
- BASIC: RUN recursion limit removed, it's now implemented with a setjmp/longjmp.
- BASIC: EVAL stops at unexpected input without error (like Acorn BASIC), unless Strict mode is set. This discrepancy was also identified by Richard Russell.
- BASIC: Implement BBCSDL's PLOT x,y syntax (assumes plot code 69).

As usual, the release downloads are available on the website, with binaries available for Windows, Linux (RHEL7-9 x86_64, Fedora 38-40 x86_64) via Yum/DNF repositories, and for RISC OS 3.1 and later.

Edit 2024-04-24: Added Fedora 40.

[Soruk]

Among some bug fixes (how did I manage to miss file pointers when upgrading the Brandy code to be able to run on 64-bit?!) I've also added a fairly significant new feature - a config file. This allows most options that can be set on the command line to be configured as user defaults, and a number of tuneables that up until now have to be enabled within the interpreter - and it's documented in docs/Config.txt.

As a reminder, the development now takes place in the dev-main branch in git, the master branch only contains releases.

[Soruk]

I've been playing with static analysis of the code, and I've noticed that putting a "return;" (or similar) after almost every call to error(), while it appears superfluous, does cause the compiler to produce better code! The call to error() only returns if it's a WARN_ message, but uses siglongjmp afer error(ERR_*) but of course the compiler doesn't know it doesn't return! As a result, not only are the binaries a fraction smaller, but they seem to be a bit faster. Indeed, the "Bubble Universe" thing that was doing the rounds last year even runs about 10% faster in RPCEmu in the UnixLib RISC OS build than it does in ARM BASIC VI (the 64-bit float version)! Of course, it lags behind ARM BASIC V, but nothing will ever beat the performance of that.

Edit: I have dropped the SharedCLibrary build, there have consistently been too many unexplained crashes, which vary depending on the compiler options used. As such I cannot reliably compile code for older Archimedes machines.

[BigEd]

wow, a 10% improvement is quite the gain!

[Soruk]

The surprise for me was that the FP stuff is now faster than ARM BBC BASIC VI, though the integer stuff is way slower.

I can't test it on real hardware for a while, but will do when I can.