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

discuss PC<>Acorn file transfer issues & the use of FDC, XFER, Omniflop/disk etc.
Soruk
Posts: 351
Joined: Mon Jul 09, 2018 10:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Sun Mar 17, 2019 11:35 am

Richard Russell wrote:
Sat Mar 16, 2019 10:34 am
I believe I'm right in thinking that Matrix Brandy supports right-to-left printing via VDU 23,16... so presumably it has no problems with RTL languages like Hebrew (given a suitable font). But what support, if any, does it provide for complex script languages like Arabic?

In BB4W and BBCSDL I support Arabic via an FNarabic() function which performs the necessary substitution of 'contextual forms', so that the final output is properly 'cursive'. But I've recently been asked whether it would be possible to support Urdu as well, and before trying to write a similar function for that language I thought I should check whether there's something I could 'borrow' from Matrix Brandy.
RTL is supported indeed via VDU23,16,... however, there is no direct support for non-Latin alphabet languages. There is no support for loading in a TTF font file (though VDU23 character redefinition is fully supported).

Soruk
Posts: 351
Joined: Mon Jul 09, 2018 10:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Sun Mar 17, 2019 11:41 am

fordp wrote:
Sat Mar 16, 2019 6:15 pm
Has anybody tried building Matrix Brandy for RiscOS on a Pi?
Any 32-bit RISC OS build would work for the Pi - however, I haven't been able to get a toolchain from @jgharston to work in my RPCEmu serup to work, just claims it can't write to /tmp, and not sure what is handling the redirection from the Unix-type file paths to see where it's failing.

User avatar
fordp
Posts: 1016
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England
Contact:

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

Post by fordp » Sun Mar 17, 2019 12:45 pm

The reason I ask is that I would like a build for the Native Raspberry Pi CoPro with hardware VFP floating point. Are the floats in Brandy compatible with the VFP on the Pi?
Last edited by fordp on Sun Mar 17, 2019 12:46 pm, edited 1 time in total.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

User avatar
Richard Russell
Posts: 801
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

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

Post by Richard Russell » Sun Mar 17, 2019 1:38 pm

Soruk wrote:
Sun Mar 17, 2019 11:35 am
there is no direct support for non-Latin alphabet languages. There is no support for loading in a TTF font file
Based on past experience, there probably will be within 24 hours! :P

Soruk
Posts: 351
Joined: Mon Jul 09, 2018 10:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Sun Mar 17, 2019 5:53 pm

fordp wrote:
Sun Mar 17, 2019 12:45 pm
The reason I ask is that I would like a build for the Native Raspberry Pi CoPro with hardware VFP floating point. Are the floats in Brandy compatible with the VFP on the Pi?
I have to say, I don't know - I don't really know anything about the Pi's VFP instructions (last ARM programming I did was YEARS ago on an ARM2 - Acorn A310)

Soruk
Posts: 351
Joined: Mon Jul 09, 2018 10:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Sun Mar 17, 2019 5:54 pm

Richard Russell wrote:
Sun Mar 17, 2019 1:38 pm
Soruk wrote:
Sun Mar 17, 2019 11:35 am
there is no direct support for non-Latin alphabet languages. There is no support for loading in a TTF font file
Based on past experience, there probably will be within 24 hours! :P
This time, I don't think so... :( If I were able to implement the functionality of the RISC OS FontManager, whether that be with Acorn format fonts or TTFs, then this might be a possibility.

User avatar
Richard Russell
Posts: 801
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

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

Post by Richard Russell » Sun Mar 17, 2019 6:59 pm

Soruk wrote:
Sun Mar 17, 2019 5:54 pm
If I were able to implement the functionality of the RISC OS FontManager, whether that be with Acorn format fonts or TTFs, then this might be a possibility.
For TTFs you could presumably use the SDL 1.2 release of SDL_ttf.

User avatar
fordp
Posts: 1016
Joined: Sun Feb 12, 2012 9:08 pm
Location: Kent, England
Contact:

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

Post by fordp » Sun Mar 17, 2019 7:42 pm

Soruk wrote:
Sun Mar 17, 2019 5:53 pm
fordp wrote:
Sun Mar 17, 2019 12:45 pm
The reason I ask is that I would like a build for the Native Raspberry Pi CoPro with hardware VFP floating point. Are the floats in Brandy compatible with the VFP on the Pi?
I have to say, I don't know - I don't really know anything about the Pi's VFP instructions (last ARM programming I did was YEARS ago on an ARM2 - Acorn A310)
If the code is in c or c++ and just uses the float type then the compiler should take care of the rest assuming the compiler in use supports VFP and basic maths should then be massively quicker. VFP does not have trig as far as I know so that will benefit less.
FordP (Simon Ellwood)
Time is an illusion. Lunchtime, doubly so!

Soruk
Posts: 351
Joined: Mon Jul 09, 2018 10:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Mon Mar 18, 2019 3:03 pm

fordp wrote:
Sun Mar 17, 2019 7:42 pm
Soruk wrote:
Sun Mar 17, 2019 5:53 pm
fordp wrote:
Sun Mar 17, 2019 12:45 pm
The reason I ask is that I would like a build for the Native Raspberry Pi CoPro with hardware VFP floating point. Are the floats in Brandy compatible with the VFP on the Pi?
I have to say, I don't know - I don't really know anything about the Pi's VFP instructions (last ARM programming I did was YEARS ago on an ARM2 - Acorn A310)
If the code is in c or c++ and just uses the float type then the compiler should take care of the rest assuming the compiler in use supports VFP and basic maths should then be massively quicker. VFP does not have trig as far as I know so that will benefit less.
I'm sure it's using higher precision floats than the normal "float" type, certainly in places doubles or long doubles are being used.

User avatar
Richard Russell
Posts: 801
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

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

Post by Richard Russell » Mon Mar 18, 2019 4:04 pm

Soruk wrote:
Mon Mar 18, 2019 3:03 pm
I'm sure it's using higher precision floats than the normal "float" type, certainly in places doubles or long doubles are being used.
Brandy's floating point variables are 'doubles', so in that respect it's compatible with ARM BASIC 6. If the source code declares anything as 'long double' it won't make any difference when compiled for ARM since, as far as I'm aware, all common C compilers consider 'long double' to be synonymous with 'double' when targeting that CPU. Only when targeting x86 is 'long double' a higher precision than 'double' (and even then it's not the case with Microsoft's compiler).

It's instructive to run this code on a range of BBC BASIC interpreters:

Code: Select all

      @% = &1414
      PRINT PI
Giving these results (I haven't got BASIC 6 to try):

Code: Select all

6502 BASIC:    3.141592653
ARM BASIC 5:   3.141592653
Matrix Brandy: 3.1415926535897931
BB4W v6.xx:    3.141592653589793238
BBCSDL (x86):  3.1415926535897932385
BBCSDL (ARM):  3.141592653589793116
BBCSDL (ARM) is displaying a misleading precision because the data type is declared as 'long double' but PI is being returned only with 'double' precision.

User avatar
BigEd
Posts: 2517
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

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

Post by BigEd » Mon Mar 18, 2019 5:08 pm

With Basic VI (1989) from RISC OS Pico on a Pi:

Code: Select all

BasicVI: 3.1415926535897931

User avatar
dhg2
Posts: 122
Joined: Tue Oct 25, 2016 7:37 pm
Contact:

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

Post by dhg2 » Mon Apr 01, 2019 2:51 pm

I don't have anything important to say, but I just wanted to say again, big thanks for all your work on Matrix Brandy. I use it a lot and I'm really glad that it's being maintained.
Regards,
- Patrick

Soruk
Posts: 351
Joined: Mon Jul 09, 2018 10:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Tue Apr 02, 2019 12:10 pm

dhg2 wrote:
Mon Apr 01, 2019 2:51 pm
I don't have anything important to say, but I just wanted to say again, big thanks for all your work on Matrix Brandy. I use it a lot and I'm really glad that it's being maintained.
I'm glad to hear that.

Development has slowed a lot, as much of what I wanted to add is now there (and shortly, I'll be out of the country for a few weeks - it'll be interesting to see if Hong Kong Free Press via Teletext over Viewdata works over the Great Firewall of China ... yes, I like doing daft stuff!) but there are a few things to look at (e.g. SDL2) when I get back.

Soruk
Posts: 351
Joined: Mon Jul 09, 2018 10:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Sat May 11, 2019 5:30 pm

I've arrived back from my travels - and as a little bonus I've updated the repo with a little teletext editor (examples/Mode7/ttxtedit) that I wrote on the plane home!

Soruk
Posts: 351
Joined: Mon Jul 09, 2018 10:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Thu May 30, 2019 7:21 pm

After trying the demo posted here viewtopic.php?f=2&t=17215 it transpired the graphics window clipping just didn't work. More weirdly, while graphics could be plotted outside of the graphics window, text couldn't be! The way points are plotted meant graphics completely bypassed the limits set by SDL_SetClipRect, yet text painting honoured it!

I've removed the SDL_SetClipRect stuff, in its place the point plotting code checks the bounds, and if it's outside the window, it does nothing. I've also separately added handling so VDU5 can't paint outside of the graphics window.

Soruk
Posts: 351
Joined: Mon Jul 09, 2018 10:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Tue Jun 04, 2019 11:57 am

New SWI call "Brandy_GetVideoDriver", as a wrapper to SDL_VideoDriverName. Additionally, it will return "no_sdl" for a non-SDL build.
Usage: SYS "Brandy_GetVideoDriver" TO driver$, string_length%

Additionally, "Brandy_Version" extended.
Usage: SYS "Brandy_Version" TO major%, minor%, patchlevel%, git_tag%, platform$, is_sdl%
Last edited by Soruk on Fri Jun 07, 2019 10:01 am, edited 1 time in total.

Soruk
Posts: 351
Joined: Mon Jul 09, 2018 10:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Wed Jun 12, 2019 9:12 am

Hi,

I've just put together version 1.21.20. A number of updates and bug fixes have been wrapped up in this, including:
- Improved CIRCLE FILL and ELLIPSE FILL routines.
- Added -v CLI option - thanks TheBrokenRail @ Github.
- Reworked graphics window clipping via VDU24, as it was completely broken.
- Fixed string return values from SWI calls, hopefully they will not break on 64-bit systems
- Added SWI "Brandy_GetVideoDriver" as a wrapper for SDL_VideoDriverName, additionally returns "no_sdl" for non-SDL builds
- Extended SWI "Brandy_Version" to also return host OS and whether or not it's an SDL build.

Soruk
Posts: 351
Joined: Mon Jul 09, 2018 10:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Mon Jun 17, 2019 11:11 am

Richard Russell wrote:
Mon Jun 17, 2019 8:15 am
Soruk wrote:
Mon Jun 17, 2019 5:15 am
ESCAPE checking is done by internally calling INKEY(-113)
I would not expect ESCape to be checked asynchronously (i.e. polled) like that: it's expensive, on some platforms it might detect the key being pressed even if BASIC doesn't have keyboard focus (for example using GetAsyncKeyState in Windows) and it might miss the key being pressed for only a very short time. There are also potential accessibility issues if used with alternative 'non keyboard' input devices.

In all my implementations of BBC BASIC, ESCape detection has always used the conventional synchronous keypress mechanism, and as that is (usually) conveyed to the application by an event or callback, not by polling, there should be little or no overhead. In the case of BBCSDL the keypress event handler sets a flag in memory which is polled by the interpreter, which is very fast.
Taking this over here rather than hijacking the other thread....
It seems quite an expensive call was the gettimeofday() being used to rate-limit the keyboard polling. Moving that to a sub-thread, and having it just read a variable instead, the result on my FX8350 has gone from 11 to 5 - approximately twice as fast, without disabling Escape.

User avatar
Richard Russell
Posts: 801
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

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

Post by Richard Russell » Mon Jun 17, 2019 12:45 pm

Soruk wrote:
Mon Jun 17, 2019 11:11 am
It seems quite an expensive call was the gettimeofday() being used to rate-limit the keyboard polling. Moving that to a sub-thread, and having it just read a variable instead, the result on my FX8350 has gone from 11 to 5 - approximately twice as fast, without disabling Escape.
An empty FOR loop is about as far as you can get from typical BBC BASIC code, and I said that it was a poor benchmark, but I suppose I should have expected that it would trigger a 'mine is faster than yours' race. I am fully aware that my BASICs are not as fast as some others; there are multiple reasons for that, some of which I listed in the other thread. I have always put functionality before speed.

In any case I would not expect the impact of ESCape testing on speed to be as great with more typical code, when the statement being executed will take proportionally more time than a NEXT (probably one of the fastest statements). My concerns remain much more about using an asynchronous (rather than synchronous) test fot ESCape, with the potential disadvantages I listed, than the effect on speed.

Soruk
Posts: 351
Joined: Mon Jul 09, 2018 10:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Mon Jun 17, 2019 1:05 pm

Richard Russell wrote:
Mon Jun 17, 2019 12:45 pm
Soruk wrote:
Mon Jun 17, 2019 11:11 am
It seems quite an expensive call was the gettimeofday() being used to rate-limit the keyboard polling. Moving that to a sub-thread, and having it just read a variable instead, the result on my FX8350 has gone from 11 to 5 - approximately twice as fast, without disabling Escape.
An empty FOR loop is about as far as you can get from typical BBC BASIC code, and I said that it was a poor benchmark, but I suppose I should have expected that it would trigger a 'mine is faster than yours' race. I am fully aware that my BASICs are not as fast as some others; there are multiple reasons for that, some of which I listed in the other thread. I have always put functionality before speed.

In any case I would not expect the impact of ESCape testing on speed to be as great with more typical code, when the statement being executed will take proportionally more time than a NEXT (probably one of the fastest statements). My concerns remain much more about using an asynchronous (rather than synchronous) test fot ESCape, with the potential disadvantages I listed, than the effect on speed.
I'm not trying to get into a "who's is fastest" race - the code I've inherited isn't as fast as Sophie's ARM BASIC on a RasPi - about half the speed, and when someone built a RISC OS build it was very noticeably slow. For me, this thing highlighted a definiency in the way I had implemented ESCAPE checking and spurred me on to look to improve it.

In the original Brandy 1.20.1 code there is no testing for ESCAPE in the SDL window within a running program at all (it only responded to CTRL-C on the controlling terminal!), the ability to recognise ESCAPE was something I shoehorned in. During a WAIT statement, or otherwise in the statement dispatcher, I call checkforescape() before each command is dipatched. if escape_enabled is TRUE. In checkforescape() there's a timer to rate-limit the checks to once every centisecond, and this is the thing I've optimised earlier today. I did look at putting the ESCAPE checker into a separate thread, but SDL (and X!) took a rather dim view of that.
Last edited by Soruk on Mon Jun 17, 2019 1:06 pm, edited 1 time in total.

User avatar
Richard Russell
Posts: 801
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

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

Post by Richard Russell » Mon Jun 17, 2019 2:50 pm

Soruk wrote:
Mon Jun 17, 2019 1:05 pm
I did look at putting the ESCAPE checker into a separate thread, but SDL (and X!) took a rather dim view of that.
I know very little about SDL 1.2 (I don't want to!) but of course SDL2 is more than happy with multi-threaded apps and indeed BBCSDL could not work otherwise (the interpreter runs in one thread, the UI in another). Since the keyboard event handler runs in the UI thread, handling the ESCape key (or indeed any other key) doesn't directly impact the interpreter, unless the CPU is too busy to allocate them to separate cores.

Soruk
Posts: 351
Joined: Mon Jul 09, 2018 10:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Mon Jun 17, 2019 7:59 pm

Richard Russell wrote:
Mon Jun 17, 2019 2:50 pm
Soruk wrote:
Mon Jun 17, 2019 1:05 pm
I did look at putting the ESCAPE checker into a separate thread, but SDL (and X!) took a rather dim view of that.
I know very little about SDL 1.2 (I don't want to!) but of course SDL2 is more than happy with multi-threaded apps and indeed BBCSDL could not work otherwise (the interpreter runs in one thread, the UI in another). Since the keyboard event handler runs in the UI thread, handling the ESCape key (or indeed any other key) doesn't directly impact the interpreter, unless the CPU is too busy to allocate them to separate cores.
That is certainly something I can do, as SDL 1.2 is happy to be multithreaded, but keyboard (and other events) have to be in the same thread as the thread that ran SDL_Init. Probably something for 1.22.x as it'll mean a bit of a reworking of how things hang together internally, and I'll need to see how to send things like VDU calls from one thread to another. (Multithreaded programming is new to me, it was simple enough making a thread to run the centisecond timer, but it's a whole other kettle of fish passing things back and forth.)

User avatar
Richard Russell
Posts: 801
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

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

Post by Richard Russell » Mon Jun 17, 2019 8:59 pm

Soruk wrote:
Mon Jun 17, 2019 7:59 pm
I'll need to see how to send things like VDU calls from one thread to another.
I don't know how similar SDL 1.2 is to SDL 2 in that respect. SDL 2 has a sophisticated event system, so in my case the interpreter uses SDL_PushEvent to send the VDU call (for efficiency reasons it packages the entire command, with its parameters, into a single event rather than sending it one byte at a time) and then the UI thread retrieves that event using SDL_PeepEvents and actions the command. Lots of other things. e.g. some star commands, work in a similar way.

Soruk
Posts: 351
Joined: Mon Jul 09, 2018 10:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Tue Jun 18, 2019 10:39 am

Richard Russell wrote:
Mon Jun 17, 2019 8:59 pm
Soruk wrote:
Mon Jun 17, 2019 7:59 pm
I'll need to see how to send things like VDU calls from one thread to another.
I don't know how similar SDL 1.2 is to SDL 2 in that respect. SDL 2 has a sophisticated event system, so in my case the interpreter uses SDL_PushEvent to send the VDU call (for efficiency reasons it packages the entire command, with its parameters, into a single event rather than sending it one byte at a time) and then the UI thread retrieves that event using SDL_PeepEvents and actions the command. Lots of other things. e.g. some star commands, work in a similar way.
SDL 1.2 certainly has these, indeed yesterday I've fixed a bug with the INKEY polling where a keypress was lost if INKEY happened to be called but it wasn't the key being searched for - by pushing the event back to the queue. This was quite noticeable in the Telstar client where keypresses were sometimes being lost, due to the internal ESC checking.

User avatar
dhg2
Posts: 122
Joined: Tue Oct 25, 2016 7:37 pm
Contact:

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

Post by dhg2 » Thu Jun 20, 2019 6:16 pm

I just compiled the latest version of brandy and unlike previous versions (and unlike the original brandy) it immediately closes after the program ends if you run it with a program file as a command line argument. Previously it only did that if you specified -quit.
Is this intentional? If it is intentional, would you mind changing it back or adding a makefile option or something that restores the original behaviour?
Thanks.
Regards,
- Patrick

Soruk
Posts: 351
Joined: Mon Jul 09, 2018 10:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Thu Jun 20, 2019 6:30 pm

dhg2 wrote:
Thu Jun 20, 2019 6:16 pm
I just compiled the latest version of brandy and unlike previous versions (and unlike the original brandy) it immediately closes after the program ends if you run it with a program file as a command line argument. Previously it only did that if you specified -quit.
Is this intentional? If it is intentional, would you mind changing it back or adding a makefile option or something that restores the original behaviour?
Thanks.
Yes, I did change it, several months back, default behaviour used to be -chain. brandy -ch <filename> restores old behaviour. This way is more in keeping with the way scripts are run on Linux, in bash, tcl, wish, perl, python etc.
Last edited by Soruk on Thu Jun 20, 2019 6:33 pm, edited 2 times in total.

Soruk
Posts: 351
Joined: Mon Jul 09, 2018 10:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Mon Jun 24, 2019 12:22 pm

Just a wee aside, SYS "GPIO_GetBoard" has been updated to know about the new RasPi 4 (at least the 4MB version).

Soruk
Posts: 351
Joined: Mon Jul 09, 2018 10:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Wed Jun 26, 2019 4:39 pm

A few more SYS calls are now implemented, enough that the "Snow" demo that ships with RISC OS Pico now runs unmodified. Next trick is to see if I can make the other demos that do things like flash LEDs run unmodified too...

scruss
Posts: 131
Joined: Sun Jul 01, 2018 3:12 pm
Location: Toronto
Contact:

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

Post by scruss » Mon Jul 08, 2019 1:41 am

Soruk wrote:
Fri Sep 07, 2018 5:41 pm
New feature added: *ScreenSave <filename.bmp> - saves the screen as a Windows BMP file.
Hey - bit of a BBC BASIC thicko here. How do you pass a string variable value to *ScreenSave, please? It seems to only take a static string

User avatar
Richard Russell
Posts: 801
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

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

Post by Richard Russell » Mon Jul 08, 2019 8:12 am

scruss wrote:
Mon Jul 08, 2019 1:41 am
Soruk wrote:
Fri Sep 07, 2018 5:41 pm
New feature added: *ScreenSave <filename.bmp> - saves the screen as a Windows BMP file.
Hey - bit of a BBC BASIC thicko here. How do you pass a string variable value to *ScreenSave, please? It seems to only take a static string
OSCLI is the way to pass variables to 'star' commands::

Code: Select all

      OSCLI "ScreenSave " + bmpfile$
If the path/file name includes spaces or other punctuation you may need to enclose it in quotes (this is certainly true in BB4W and BBCSDL, I'm not certain about Brandy but Soruk will no doubt confirm):

Code: Select all

      OSCLI "ScreenSave " + CHR$(34) + bmpfile$ + CHR$(34)
or:

Code: Select all

      OSCLI "ScreenSave """ + bmpfile$ + """"

Post Reply