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: 513
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: 513
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: 513
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: 513
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: 513
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: 1053
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: 513
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: 1053
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: 513
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: 1053
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: 513
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: 1053
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: 513
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.

Post Reply