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

[Soruk]

Hello,

I've noticed a bug in Brandy related to the behaviour of graphics drawing commands when the coordinates are outside of the visible screen area.
This program demonstrates it:

Code: Select all

MODE 0
FOR i =-1280 TO 1280 STEP 8
 MOVE i,0: DRAW i+1024,1024
NEXT

On the BBC Micro it produces a consistent smooth full screen checkerboard pixel pattern, whereas on Brandy a line appears in the middle of the screen.

screenshot_Fri09Sep2022__13_03_22.png
screenshot_Fri09Sep2022__13_02_42.png

This program produces a similar result but the pattern of the discrepancy is a bit different:

Code: Select all

MODE 0
FOR i =-1024 TO 1024 STEP 8
 MOVE 0,i: DRAW 1280,i+1024
NEXT

Apologies if this issue has already been fixed upstream, I'm testing this using the version of Matrix Brandy supplied by Debian Bookworm as my main desktop system is currently broken in such a way that I can't install the SDL1.2 dev packages...

The issue is still there in my latest version, so it is definitely something I need to address. Possibly a rounding error, this shows it too:

Code: Select all

MODE 1: DRAW 1024,1024

Indeed, it shows up in every graphics mode other than 2 and 5.

[Soruk]

The issue is still there in my latest version, so it is definitely something I need to address. Possibly a rounding error, this shows it too:

Code: Select all

MODE 1: DRAW 1024,1024

Indeed, it shows up in every graphics mode other than 2 and 5.

It was a rounding error, as in the conversion between Acorn coordinates and SDL addressing, the top of the screen is 0 so an error crept in if the end-point was off the top of the screen as division with integers rounds towards zero rather than rounds down. One dirtyish hack later, this bug is fixed and checked into git.

[dhr2]

-

[Soruk]

Perhaps the basis of this idea (replacing the division with a shift right) is a good one, if it's assured that ds.xgupp and ds.ygupp are only ever powers of 2.

Built-in modes all use powers of 2, however it is possible to create screen modes that don't, for example

Code: Select all

*NEWMODE 96 640 256 16 2 3
MODE 96

[dhr2]

-

[Soruk]

Perhaps the basis of this idea (replacing the division with a shift right) is a good one, if it's assured that ds.xgupp and ds.ygupp are only ever powers of 2.

Built-in modes all use powers of 2, however it is possible to create screen modes that don't, for example

Code: Select all

*NEWMODE 96 640 256 16 2 3
MODE 96

Ahh cool, is this a feature that RISC OS supported?

No, it's a feature I added to Matrix Brandy. However, in newer versions of RISC OS you could do MODE <width>,<height>,<bpp> and this is indeed supported under Matrix Brandy too. Matrix Brandy doesn't support the RISC OS 15bpp and 16bpp modes, it will select a 24bpp mode instead, and will generate a square-pixel mode with pixels the same size as MODEs 20 and 27 (in the case of Matrix Brandy, if the parameters match a predefined mode this will be used instead of generating one, e.g. MODE 640,256,1 will select MODE 0)

Unrelated but I also wonder, is it possible to make MODEs that allow you to resize the window freely, or modes that allow you to use the full 24bit set of colours? Something I remember from when I used to code with Brandy a lot is that it always seemed limited to 256 colours.

Resizing the window - no.
24-bit colours? Use 16777216 colours in *NEWMODE or specify 24bpp in the above extended MODE command. (24bpp wasn't supported in upstream Brandy at all.)

[dhr2]

-

[Soruk]

In the latest github version of brandy, running this program:

Code: Select all

REPEAT
 I+=1
 PRINT I
UNTIL0

and then clicking the window manager close button causes brandy to crash with segmentation fault on my system.

That should be fixed. Totally my fault for splitting the program execution and GUI display to separate threads. Trying to shut the GUI down while the program execution is drawing to the framebuffer isn't going to be pretty, as you discovered.
So, a very simple fix, which seems to have sorted it, is to check if the shutdown flag is set for the program execution thread to enter an infinite loop of sleeps, the shutdown will terminate the thread.

(Edit: My typing is atrocious.)

[dhr2]

-

[Soruk]

Thank you

- Sound: Notes are now queued by default if no delay parameter is used.

I noticed this line in the changelog. I went to test and I noticed that the queuing behaviour seems different from BASIC on the BBC Micro - it doesn't block/pause if you try to add notes to the queue when it's full and instead just seems to cut short or overwrite what's already there, and ADVAL with values of -8 to -5 doesn't give information about how many free spaces there are in the queues for sound channels 0 to 3, instead it just returns 0.

Do you plan on changing the implementation of SOUND in future releases so it behaves more like BASIC on the BBC Micro, or are you planning on implementing similar features but in a Matrix Brandy specific way?

This came about as a result of this thread over at the Distillery. Prior to this change a new note would immediately cancel the old one, now they queue up. However, this being donated code I don't really understand how it works so not sure yet how to extract the queue length. But, based on a few tests (and an old Beeb game that now plays its tune correctly!) the queue length is rather longer than that of the BBC, if indeed there is a limit at all.

[Soruk]

Thank you

- Sound: Notes are now queued by default if no delay parameter is used.

I noticed this line in the changelog. I went to test and I noticed that the queuing behaviour seems different from BASIC on the BBC Micro - it doesn't block/pause if you try to add notes to the queue when it's full and instead just seems to cut short or overwrite what's already there, and ADVAL with values of -8 to -5 doesn't give information about how many free spaces there are in the queues for sound channels 0 to 3, instead it just returns 0.

Do you plan on changing the implementation of SOUND in future releases so it behaves more like BASIC on the BBC Micro, or are you planning on implementing similar features but in a Matrix Brandy specific way?

Update: A few days ago I heard from David H, the author of the sound feature, as he saw your post and my earlier reply, he gae me a patch that causes new notes to block rather than be discarded if the queue is full. Additionally, he told me the queue length is 64 notes (it's in the SNDTABWIDTH define near the top of soundsdl.c, which must be a power of 2 to work properly), and when I experimentally reduced it to 8 it correctly showed Scruss's example on the Distillery blocking until a note had been cleared from the queue. This is with the d832dc5 commit from 19th September when new notes were by default queued rather than obliterating the previously played note.

[scruss]

Yay! It works now. Thanks to all who contributed

[dhr2]

-

[Soruk]

Hi,

I have released version 1.22.14 of Matrix Brandy. Changes include:
- System: Workaround for sdl12-compat library bug affecting keyboard input.
- System: RISC OS SharedCLibrary build now supports networking.
- System: Now compiles on Solaris 11 (tested x86_64). Use "gmake".
- System: Now compiles on illumos (an OpenSolaris fork). Use makefiles in build directory.
- System: Text mode build available for Minix 3 (no networking yet). Use gmake -f build/makefile.minix
- System: Fixed a bug that caused Brandy to throw an Xlib error in some cases when exiting.
- Graphics: Fixed GCOL action codes 5-7 for filled rectangles (this function does not use the plot_pixel prototype).
- Graphics: Fixed an error where VDU variables 138 and 139 were erroneously clamping to pixel boundaries based on the current screen mode scaling.
- Graphics: Fixed an integer division rounding error that crept in when drawing went partially off screen.
- Graphics: Can now plot arcs RISC OS-style (thank you Michael Fairbank)
- Graphics: Much faster full-screen blit for 1:1 pixel modes.
- Sound: Notes are now queued by default if no delay parameter is used.
- Sound: Block instead of discarding notes if the buffer is full.
- BASIC: Fix LVAR so it doesn't choke on stupidly long variable names.
- BASIC: Tidied up an earlier cheat - when interpreting @%, if the top byte is non-zero then STR$ obeys @% so we were masking against &FF - but we were setting all the top bits when using "+". This is fixed now the top byte is set to 1 instead. (We still check the byte is non-zero.)
- BASIC: Raising to the power has better bounds checking.
- BASIC: Fixed a bug in the parser where a variable could be erroneously combined with an indirection operator.
- BASIC: Fixed a bug where ENDPROC in a function or =expr in a procedure would cause a crash.
- BASIC: Be a bit more graceful if loading a program bigger than the workspace.
- Examples: Telstar client: Removed unnecessary code, TEEFAX server change, added new Teletext services and a custom address option.

Downloads are available as usual from the Matrix Brandy website, also from git.

[Soruk]

Relatively hot on the heels of the New Year's Eve release, I've reworked ESCAPE polling on the SDL build, so the polling is done in its own thread rather than checking for it each time a command is dispatched to the interpreter. This has netted a 15-25% speed-up!

[Soruk]

Sadly SDL isn't responding to the PAUSE/BREAK key, so had to use the PrtSc / SysRq key instead - so if BREAKONCTRLPRTSC is defined at build time, then pressing CTRL+PrtSc will force the SDL build to immediately exit. This may be useful in situations where the program you're running has hung and you're in fullscreen mode. There is no noticeable performance penalty for having this option enabled.

If people like this functionality, I could make it the default.

[Soruk]

The above CTRL+PrtSc forcing an immediate exit is now the default behaviour.
I've implemented the atan2() C function as an extension to ATN, while ensuring there is no ambiguity so any previous code will still run.
And, a change to the way exit codes are handled, if run with a program from the command line and the program exits with an error condition, the exit code is now ERR+1 instead of 1. (I've added 1 because the untrappable value of ERR is 0, and on modern systems 0 indicates no error, or success!)

[Soruk]

About a year ago I added some (very tentative) support for passing floats via SYS for the dlcall feature. Unfortunately this created a regression that a value passed by a float variable was put in the wrong place for all other SYS calls, even if the float variable contained an integer. This has now been fixed, so float variables and values are only handled specially for dlcall and dlcalladdr, for all other calls they're handled in the old way as integers.

[Soruk]

I have released version 1.22.15 of Matrix Brandy. Changes include:

- System: For SDL builds, move ESCAPE polling to its own thread.
- System: Added CTRL+PrtSc to force immediate exit in SDL build. Unfortunately the Pause/Break key doesn't register in SDL. This functionality can be disabled with build-time option BRANDY_NOBREAKONCTRLPRTSC.
- System: Added some fixes to handle issues with the sdl12-compat library.
- System: Implemented an internal *./*CAT handler, loosely styled on BBC Micro ADFS output.
- System: Exit code is now ERR MOD 256 (or 255 if that would result in 0), or 0 if exited with no error. A program can still set its own exit code as a parameter to QUIT.
- System: Fixed a regression in the way floats were handled by SYS.
- System: Corrected a flawed usage of fcntl().
- MOS: Implemented OSBYTE 210
- BASIC: Extended ATN to take two parameters in parentheses, this calls atan2().

Downloads are available from the Matrix Brandy website, also from git.

[mike12f]

Great work Soruk. Much appreciated.

Nearly all my old BASIC Archimedes programs run perfectly now under Matrix Brandy. The only ones that don't generally have some assembler code in there somewhere. I partly regret now the hours I spent in the 80s/90s writing that assembler code, thinking it was making the programs better. In hindsight, it seems that using as high-level languages as possible is the way to future-proof your code. For example, rather than writing your own sorting algorithm, you should choose a built in "Sort" function, if the language supports such a thing. Similarly for things like SQRT and division routines in assembler - it just makes emulation slow and reverse engineering difficult.

[Grasshopper]

Hi Soruk,

Do you think it would be feasible to decouple the basic interpreter's code from the code that emulates the Acorn MOS commands?

If it is, then it occurs to me that the MOS emulation could be handled by an entirely separate application. It could behave in a similar way to a Linux terminal, except that instead of emulating a VT102, or some other old UNIX terminal, it would emulate the BBC Micro's VDU commands.

This arrangement would enable any Linux application to generate BBC Micro style graphics simply by being run within the Acorn MOS compatible terminal, and then sending appropriate VDU codes to STDOUT.

There would still be the problem of how to access the MOS commands that are not accessible through VDU codes (e.g. sound). Maybe these commands could be accessed through the ioctl() system call. Or maybe additional VDU commands could be created for this purpose. I don't know enough about Linux system programming to know what the best approach would be, but I don't see this as being an insurmountable problem.

If you created a separate application to handle the Acorn MOS emulation, then you wouldn't necessarily need to maintain separate console versions of the BASIC interpreter. You could simply run the console versions in an Acorn MOS terminal to gain access to all the MOS commands.

[scruss]

This arrangement would enable any Linux application to generate BBC Micro style graphics simply by being run within the Acorn MOS compatible terminal, and then sending appropriate VDU codes to STDOUT.

This might be a huge amount of work for a step change down in graphics capability

[Soruk]

This arrangement would enable any Linux application to generate BBC Micro style graphics simply by being run within the Acorn MOS compatible terminal, and then sending appropriate VDU codes to STDOUT.

This might be a huge amount of work for a step change down in graphics capability

The desired effect could be done with no changes to the Brandy code, just a small BASIC program that opens a named pipe, sending all bytes to VDU, and another program generating VDU codes writing to the same named pipe.

Code: Select all

   10REM > PipePlayer
   20ON ERROR CLOSE#P%:OSCLI"rm /tmp/pipe":END
   30*mknod /tmp/pipe p
   40P%=OPENIN"/tmp/pipe"
   50REPEAT: VDU BGET#P%
   60UNTIL FALSE

I tried something like

Code: Select all

*/cat pipe

however, while it is good for showing text, it also translates inbound &0A to &0D,&0A which can definitely will mess up the graphics.

Edit: Program creates and removes the pipe.

[Soruk]

I've checked in a new bit of functionality, that allows filenames to be translated between ADFS-style (with DFS at a pinch) and Linux. Currently this is implemented for OPENIN, OPENOUT and OPENUP, but not SAVE, LOAD, LIBRARY and INSTALL. This might need some fine tuning...

[Soruk]

As of 3 days ago, Debian Bookworm was released as the latest stable release, and includes Matrix Brandy 1.22.14. While not the latest and greatest, it's an improvement of what was previously present. As such I would expect future releases of Raspberry Pi OS (edit: and Ubuntu) that are descended from Bookworm to also include this. Debian "sid" (the unstable build) includes V1.22.15, but only seems to track release builds and not the git repo.

[mike12f]

As of 3 days ago, Debian Bookworm was released as the latest stable release, and includes Matrix Brandy 1.22.14. While not the latest and greatest, it's an improvement of what was previously present. As such I would expect future releases of Raspberry Pi OS that are descended from Bookworm to also include this. Debian "sid" (the unstable build) includes V1.22.15, but only seems to track release builds and not the git repo.

Great news!

[EdwardianDuck]

In episode 11 of the Next Without For podcast, Earl Evans and Randy Kindig discuss Matrix Brandy Basic amongst many others, including Richard Russell's BBC Basic.

Jeremy

[Soruk]

In episode 11 of the Next Without For podcast, Earl Evans and Randy Kindig discuss Matrix Brandy Basic amongst many others, including Richard Russell's BBC Basic.

Jeremy

Thank you for the heads-up - I'll give this a listen! - Edit: Matrix Brandy is mentioned from 1:04:45 (approx), and Richard's BBC BASICs were mentioned for iDevices at 29:08 in a very positive light, also for MacOS at 44:06, again very positively, and again in passing at 48:17 for Android. Both were mentioned again in the closing comments from about 1:16:00

[Soruk]

It's been a while since I updated here, but things have been trundling along slowly, with a number of bugs fixed.

I have also created a Yum repo for nightly builds, currently targeting Fedora 38 & 39, and Red Hat Enterprise Linux 7-9 (including derivatives such as CentOS, AlmaLinux, Rocky Linux and Oracle). Currently, only x86_64 is offered. Through this repo, the package name is "brandy".

[Soruk]

I've been busy in the shadows.

Some new fixes since my last post include
- PRINT now handles exponent format better, with padding akin to Acorn BASICs
- Subtraction now works in "long double" space (80 bits on x86), although the result is returned in 64-bit space (float or int as appropriate).
- Indirections using floats to contain the address were utterly broken if outside of 32-bit address space.
- Fix text-mode interpreter to not hang if no response is received from the VT/ANSI code to enquire the screen domensions.
- Clean up variable stubs behind if a DIM array allocation fails, or after CLEAR HIMEM.
- Display fixes including PRINT TAB in VDU5 mode, misbehaviour of VDU23;8202;0;0;0;
- Makefile updated to build on Fedora 39 (without breaking existing systems)

I hope these are working correctly now - I'd hate to once again push a new release then discover a bug a day later....!