Matrix Brandy BASIC VI for Linux with SDL: V1.22.3 released

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

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.3 released

Post by Soruk » Sun Dec 15, 2019 1:26 pm

Richard Russell wrote:
Sun Dec 15, 2019 12:59 pm
Personally I'm not sure that is wise. SDL 1.2 is obsolete and not supported, going forward issues that arise aren't going to be fixed. I think this is already affecting Mac OS, so if you have ambitions of Matrix Brandy running on that platform you will probably have to abandon SDL 1.2.
What I meant is that you could build for SDL1.2 and separately build for SDL2, just as you can separately build for text and Tektronix now.

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

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.3 released

Post by Soruk » Mon Dec 16, 2019 11:37 am

Richard Russell wrote:
Sun Dec 15, 2019 12:59 pm
Soruk wrote:
Sun Dec 15, 2019 12:30 pm
In theory it should be able to, however I haven't (yet) exposed the window handle.
I think the only thing the window handle is needed for is the creation of an OpenGL context, but yes it would be necessary for you to expose it.
This is now done, extending Brandy_GetVideoDriver to return this in R5.

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

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.3 released

Post by Soruk » Thu Jan 16, 2020 2:19 pm

Latest updates:
New command line option -swsurface -- this makes SDL use a software surface instead of a hardware surface. This MAY help in some framebuffer situations.
Also - some CLI options are now recognised for BrandyApp builds (Previously none were acted upon).

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

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.3 released

Post by Soruk » Sat Jan 18, 2020 11:23 am

For reference, here's the Matrix Brandy character set (heavily based on RISC OS).

Normal (non-Teletext) mode, take in MODE 6:
Image

MODE 7 (uses a 16x20 character grid):
Image

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

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.3 released

Post by Soruk » Mon Jan 20, 2020 5:12 pm

Latest updates:
- Fixed setjmp() failing sometimes on Win64 (known MinGW issue).
- Fixed a Teletext graphics high-bit translation error.

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

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.3 released

Post by Richard Russell » Wed Jan 22, 2020 11:50 am

Soruk wrote:
Mon Jan 20, 2020 5:12 pm
- Fixed a Teletext graphics high-bit translation error.
If you are prepared to reveal, how did this error manifest itself? As far as I am aware, setting bit 7 should only have the effect of disabling the £#— character 'shuffle' (which can impact teletext graphics as well as text).

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

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.3 released

Post by Soruk » Wed Jan 22, 2020 12:40 pm

Richard Russell wrote:
Wed Jan 22, 2020 11:50 am
Soruk wrote:
Mon Jan 20, 2020 5:12 pm
- Fixed a Teletext graphics high-bit translation error.
If you are prepared to reveal, how did this error manifest itself? As far as I am aware, setting bit 7 should only have the effect of disabling the £#— character 'shuffle' (which can impact teletext graphics as well as text).
That was exactly it. Text was shuffled - but graphics weren't being. It manifested itself as glitches in the Chalksoft Pirate Adventure game. In the case of Matrix Brandy, the character map layout is as they appear at 32-126, and 255. The shuffling happens when bit 7 is set, but this was glitching the graphics.

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

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.3 released

Post by Richard Russell » Thu Jan 23, 2020 12:11 pm

Soruk wrote:
Wed Jan 22, 2020 12:40 pm
That was exactly it. Text was shuffled - but graphics weren't being.
Ah. On the BBC Micro only the SAA5050 chip knows whether a character will be rendered as alphanumeric or as graphics, so the OS couldn't do anything different in the two cases even if it wanted to (consider the case when the characters are written right-to-left, when the control character determining the mode hasn't even been seen yet)!

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

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.3 released

Post by Soruk » Thu Jan 23, 2020 12:19 pm

Richard Russell wrote:
Thu Jan 23, 2020 12:11 pm
Soruk wrote:
Wed Jan 22, 2020 12:40 pm
That was exactly it. Text was shuffled - but graphics weren't being.
Ah. On the BBC Micro only the SAA5050 chip knows whether a character will be rendered as alphanumeric or as graphics, so the OS couldn't do anything different in the two cases even if it wanted to (consider the case when the characters are written right-to-left, when the control character determining the mode hasn't even been seen yet)!
Matrix does handle this one of the reasons for the earlier change from Teletext being handled as a character stream to using a 40x25 array "frame buffer", to allow a line to be recalculated - and addressed as 1000 bytes of memory at &7C00.

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

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.3 released

Post by Richard Russell » Thu Jan 23, 2020 1:04 pm

Soruk wrote:
Thu Jan 23, 2020 12:19 pm
Matrix does handle this
Indeed, any MODE 7 emulator has to be independent of the order in which the characters are written (I have tested mine with reverse-order and random-order). However, it's not necessary always to process the entire 40x25 frame at once, because the potential for a change 'propagating' to subsequent characters and rows is limited.

An approximate rule is that a change to a character can impact only on the rest of the row in which it appears, unless that character is a double-height or single-height control code. If it is, it can impact the entire row in which it appears and subsequent rows. How many subsequent rows can be affected depends in turn on whether they contain any double-height control characters.

Probably, with the speed of modern CPUs, one could 'simply' re-process the entire frame every time any character changes, but when I wrote my Videotex emulator for MS-DOS that would have been an unacceptable overhead, so it updated only the minimal amount necessary. My current emulators (as used in BB4W and BBCSDL) have inherited this behaviour.

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

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.3 released

Post by Soruk » Thu Jan 23, 2020 1:42 pm

Richard Russell wrote:
Thu Jan 23, 2020 1:04 pm
Soruk wrote:
Thu Jan 23, 2020 12:19 pm
Matrix does handle this
Indeed, any MODE 7 emulator has to be independent of the order in which the characters are written (I have tested mine with reverse-order and random-order). However, it's not necessary always to process the entire 40x25 frame at once, because the potential for a change 'propagating' to subsequent characters and rows is limited.

An approximate rule is that a change to a character can impact only on the rest of the row in which it appears, unless that character is a double-height or single-height control code. If it is, it can impact the entire row in which it appears and subsequent rows. How many subsequent rows can be affected depends in turn on whether they contain any double-height control characters.

Probably, with the speed of modern CPUs, one could 'simply' re-process the entire frame every time any character changes, but when I wrote my Videotex emulator for MS-DOS that would have been an unacceptable overhead, so it updated only the minimal amount necessary. My current emulators (as used in BB4W and BBCSDL) have inherited this behaviour.
And, that is actually what I do as well. I also track changed lines, and if a &8D character is found, I mark the next line as changed too, to ensure proper updates. The minimum size update is one complete line. Currently I don't think I'm checking for &8C - but then again, it's been a while since I touched that code :lol:

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

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.3 released

Post by Richard Russell » Thu Jan 23, 2020 2:19 pm

Soruk wrote:
Thu Jan 23, 2020 1:42 pm
Currently I don't think I'm checking for &8C
You probably don't need to; I've not looked at my code for a long time either. I don't currently support the 'black text' and 'black graphics' modes (which I believe Matrix Brandy does) because they're not available on a genuine BBC Micro. For the same reason neither do I offer any control over how the Hold Graphics mode behaves, which by common consent the SAA5050 gets slightly 'wrong'.

The one enhancement I'd ideally like to make to my MODE 7 emulation is support for the full Unicode character set (at least, all the characters present in the Bedstead font), to allow emulation of the various multilingual variants of the SAA5050 (e.g. Cyrillic and Hebrew) plus accented characters etc. Unfortunately it's not easy to retro-fit this capability without breaking compatibility so it will probably never happen.

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

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.3 released

Post by Soruk » Thu Jan 23, 2020 3:44 pm

Richard Russell wrote:
Thu Jan 23, 2020 2:19 pm
Soruk wrote:
Thu Jan 23, 2020 1:42 pm
Currently I don't think I'm checking for &8C
You probably don't need to; I've not looked at my code for a long time either. I don't currently support the 'black text' and 'black graphics' modes (which I believe Matrix Brandy does) because they're not available on a genuine BBC Micro. For the same reason neither do I offer any control over how the Hold Graphics mode behaves, which by common consent the SAA5050 gets slightly 'wrong'.

The one enhancement I'd ideally like to make to my MODE 7 emulation is support for the full Unicode character set (at least, all the characters present in the Bedstead font), to allow emulation of the various multilingual variants of the SAA5050 (e.g. Cyrillic and Hebrew) plus accented characters etc. Unfortunately it's not easy to retro-fit this capability without breaking compatibility so it will probably never happen.
Alpha and Graphics Black are available, but not enabled by default. VDU23,18,3,<0|1>| will switch it - this VDU code is from RISC OS 5. As for Hold, Matrix Brandy deliberately mimics the SAA5050's slightly errant behaviour (as does RISC OS), and there's no toggle to make it behave "correctly".

Adding other character set support to MODE 7 isn't something that's been on my radar, as it's not something the BBC or RISC OS has ever offered. It would also somewhat complicate the built-in bitmap fonts being used.

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

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.3 released

Post by dhg2 » Fri Feb 07, 2020 6:14 pm

Hello,

I've just noticed that one of my old programs is experiencing a problem when I run it in the most recent version of Matrix Brandy.
This is the program:

Code: Select all

PROCinitxrand:i=0:s=0:WHILEi<1495000:s=s EOR FNxrand(i):i=i+1:ENDWHILE:i=i AND255:PRINT i: END

DEFPROCinitxrand
 rand=0
 ranb=0
 ranc=0
ENDPROC

DEF FNxrand(in)
 SWAP rand,ranb
 rand=rand<<15 OR rand>>>16
 rand=NOTrand
 rand=rand<<1 OR rand>>>31
 rand=rand EOR ranb>>>3
 rand=rand<<8 OR rand>>>23
 ranc=(ranc<<1)OR(rand AND1)
 rand=rand EOR(ranc AND256)
IF in<>0 THEN =(rand AND 2147483647) MOD in ELSE =rand
What happens is, this message appears in the terminal window:

Code: Select all

Baditem = 0, sp = 0x345ad50, safe=0x345b018, opstop=0x345ae48
and this message appears in the Brandy window:

Code: Select all

The interpreter has gone wrong at line 1408 in evaluate at line 14 in FNxrand
PROC/FN call trace:
 FNxrand was called from line 1
- Patrick
Regards,
- Patrick

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

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.3 released

Post by Soruk » Fri Feb 07, 2020 7:24 pm

dhg2 wrote:
Fri Feb 07, 2020 6:14 pm
Hello,

I've just noticed that one of my old programs is experiencing a problem when I run it in the most recent version of Matrix Brandy.
I'll look at this from middle of next week, as I'm going away for a long weekend. Just FYI :)
Do you know which previous version(s) it worked on?

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

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.3 released

Post by dhg2 » Fri Feb 07, 2020 8:14 pm

Soruk wrote:
Fri Feb 07, 2020 7:24 pm
dhg2 wrote:
Fri Feb 07, 2020 6:14 pm
Hello,

I've just noticed that one of my old programs is experiencing a problem when I run it in the most recent version of Matrix Brandy.
I'll look at this from middle of next week, as I'm going away for a long weekend. Just FYI :)
Do you know which previous version(s) it worked on?
It seems like 1.22.0 is the latest version that I have that it worked on. Actually, that also happens to be the second latest version of Matrix Brandy that I have a binary for (with the latest being the current github version that I compiled just today). I have a number of versions earlier than that ranging from August 2019 to early/mid 2018 and it seems to work on all of those too.
By the way I hope you'll have a good weekend :)

- Patrick
Regards,
- Patrick

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

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.3 released

Post by Soruk » Wed Feb 12, 2020 9:59 am

dhg2 wrote:
Fri Feb 07, 2020 8:14 pm
Soruk wrote:
Fri Feb 07, 2020 7:24 pm
dhg2 wrote:
Fri Feb 07, 2020 6:14 pm
Hello,

I've just noticed that one of my old programs is experiencing a problem when I run it in the most recent version of Matrix Brandy.
I'll look at this from middle of next week, as I'm going away for a long weekend. Just FYI :)
Do you know which previous version(s) it worked on?
It seems like 1.22.0 is the latest version that I have that it worked on. Actually, that also happens to be the second latest version of Matrix Brandy that I have a binary for (with the latest being the current github version that I compiled just today). I have a number of versions earlier than that ranging from August 2019 to early/mid 2018 and it seems to work on all of those too.
By the way I hope you'll have a good weekend :)

- Patrick
There we go, that should be sorted. Couple of issues, one was an incorrect stack pull (which then breaks the stack alignment) so that's fixed along with some new verification added to the stack pull code. The other was shifts were made 64-bit wide, this has been partially reversed so default behaviour is shifts now are 32-bit but 64-bit shifts can be enabled with SYS "Brandy_BitShift64",1

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

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.3 released

Post by Richard Russell » Wed Feb 12, 2020 3:43 pm

Soruk wrote:
Wed Feb 12, 2020 9:59 am
default behaviour is shifts now are 32-bit but 64-bit shifts can be enabled with SYS "Brandy_BitShift64",1
Does that affect all shifts? If so it would make Matrix Brandy's behaviour different from my BASICs, in which the signed right-shift operator (>>) is not affected by the 32-bit/64-bit switch, because it doesn't need to be to guarantee compatibility with legacy programs.

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

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.3 released

Post by Soruk » Wed Feb 12, 2020 3:48 pm

Richard Russell wrote:
Wed Feb 12, 2020 3:43 pm
Soruk wrote:
Wed Feb 12, 2020 9:59 am
default behaviour is shifts now are 32-bit but 64-bit shifts can be enabled with SYS "Brandy_BitShift64",1
Does that affect all shifts? If so it would make Matrix Brandy's behaviour different from my BASICs, in which the signed right-shift operator (>>) is not affected by the 32-bit/64-bit switch, because it doesn't need to be to guarantee compatibility with legacy programs.
Right now yes, but if that is erroneous behaviour then I can put that one back to the way it was.

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

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.3 released

Post by Richard Russell » Wed Feb 12, 2020 4:49 pm

Soruk wrote:
Wed Feb 12, 2020 3:48 pm
Right now yes, but if that is erroneous behaviour then I can put that one back to the way it was.
My argument, FWIW, is that's it's useful to be able to perform 64-bit shifts even when in 32-bit mode. This is particularly the case in library functions, when you may not want to switch mode because it may break the program calling the library (a workaround would be to test the current mode on entry, by performing an 'experimental' shift, and then restore it on exit, but that's messy).

The four shift operators in BBC BASIC for Windows and BBC BASIC for SDL 2.0 behave as follows:

Code: Select all

<<  32-bit left shift in 32-bit mode, 64-bit left shift in 64-bit mode
<<< 64-bit left shift always
>>  64-bit signed right shift always
>>> 32-bit unsigned right-shift in 32-bit mode, 64-bit unsigned right-shift in 64-bit mode

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

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.3 released

Post by Soruk » Thu Feb 13, 2020 11:12 am

Richard Russell wrote:
Wed Feb 12, 2020 4:49 pm
Soruk wrote:
Wed Feb 12, 2020 3:48 pm
Right now yes, but if that is erroneous behaviour then I can put that one back to the way it was.
My argument, FWIW, is that's it's useful to be able to perform 64-bit shifts even when in 32-bit mode. This is particularly the case in library functions, when you may not want to switch mode because it may break the program calling the library (a workaround would be to test the current mode on entry, by performing an 'experimental' shift, and then restore it on exit, but that's messy).

The four shift operators in BBC BASIC for Windows and BBC BASIC for SDL 2.0 behave as follows:

Code: Select all

<<  32-bit left shift in 32-bit mode, 64-bit left shift in 64-bit mode
<<< 64-bit left shift always
>>  64-bit signed right shift always
>>> 32-bit unsigned right-shift in 32-bit mode, 64-bit unsigned right-shift in 64-bit mode
Matrix brandy is following the ARM BBC BASIC shifts as shown at http://www.riscos.com/support/developer ... bases.html - so on reflection I will keep my 32-bit/64-bit switches as they are - in 32-bit mode it'll always return something that can be shoved into a 32-bit integer variable even if the input was a float.

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

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.3 released

Post by Richard Russell » Thu Feb 13, 2020 12:07 pm

Soruk wrote:
Thu Feb 13, 2020 11:12 am
Matrix brandy is following the ARM BBC BASIC shifts... in 32-bit mode it'll always return something that can be shoved into a 32-bit integer variable even if the input was a float.
If your objective is maximum compatibility with ARM BASIC I don't think you've achieved it. If you try running this code (in the default 32-bit mode):

Code: Select all

      a% = (2.0 ^ 33) >> 3
it will report 'Number too big' in ARM BASIC, it will set a% to zero in Matrix Brandy, and it will set a% to &40000000 in my BASICs. I would argue that Matrix Brandy's result is the least 'useful'.

My approach has been that compatibility with ARM BASIC cannot extend to reporting errors in exactly the same circumstances, since that would mean you can never extend the language at all! So whilst it's true that my right-shift operator (>>) may return a valid non-zero value when ARM BASIC would report an error, it doesn't concern me, especially when being able to do 64-bit shifts in 32-bit mode has a practical value.

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

Re: Matrix Brandy BASIC VI for Linux with SDL: V1.22.3 released

Post by Soruk » Thu Feb 13, 2020 12:37 pm

Richard Russell wrote:
Thu Feb 13, 2020 12:07 pm
Soruk wrote:
Thu Feb 13, 2020 11:12 am
Matrix brandy is following the ARM BBC BASIC shifts... in 32-bit mode it'll always return something that can be shoved into a 32-bit integer variable even if the input was a float.
If your objective is maximum compatibility with ARM BASIC I don't think you've achieved it. If you try running this code (in the default 32-bit mode):

Code: Select all

      a% = (2.0 ^ 33) >> 3
it will report 'Number too big' in ARM BASIC, it will set a% to zero in Matrix Brandy, and it will set a% to &40000000 in my BASICs.

My approach has been that compatibility with ARM BASIC cannot extend to reporting errors in exactly the same circumstances, since that would mean you can never extend the language at all! So whilst it's true that my right-shift operator (>>) may return a valid value when ARM BASIC would report an error, it doesn't concern me, especially when being able to do 64-bit shifts in 32-bit mode has a practical value.
The reason mine was giving zero is in 32-bit mode, the operands are all fitted into 32-bit registers before being operated upon, so (2.0 ^ 33) AND &FFFFFFFF is zero. But I see where you're coming from. Acorn's is saying (2.0 ^ 33) is too big for a 32-bit register - and so the decision I need to make is which way do I go? Out of range (as per Acorn), clamp the inputs to 32 bits (Matrix currently), or calculate at 64-bit width and clamp the output?

Edit: I've decided to go with the third option. In 32-bit mode with some quick tests it gives the same answers as ARM BBC BASIC and BBCSDL, and in the example above it follows BBCSDL.

Post Reply