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

for discussion of bbc basic for windows/sdl, brandy and more
User avatar
Richard Russell
Posts: 1271
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

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

Post by Richard Russell » Thu May 21, 2020 9:37 pm

Soruk wrote:
Thu May 21, 2020 11:44 am
There's probably a tidier way to do this....

Code: Select all

   10REM > SAA505Xlib
   ....
Just a heads-up that according to my editor there are lines in that library which are too long (i.e. > 251 characters after tokenization). Even if Brandy can cope with such long lines, no other version of BBC BASIC can, which makes them invalid in my opinion. I've split them up so they fit:

Code: Select all

  130 CASE code% OF
  140   WHEN 0,5050: REM SAA5050 is the default
  150   WHEN 1,5051: REM German
  160     PROCsaa505xr(&23,j%+&23,1):PROCsaa505xr(&A7,j%+&40,1):PROCsaa505xr(&C4,j%+&5B,1):PROCsaa505xr(&D6,j%+&5C,1):PROCsaa505xr(&DC,j%+&5D,1):PROCsaa505xr(&5E,j%+&5E,1)
  170     PROCsaa505xr(&5F,j%+&5F,1):PROCsaa505xr(&B0,j%+&60,1):PROCsaa505xr(&E4,j%+&7B,1):PROCsaa505xr(&F6,j%+&7C,1):PROCsaa505xr(&FC,j%+&7D,1):PROCsaa505xr(&DF,j%+&7E,1)
  180   WHEN 2,5052: REM Swedish
  190     PROCsaa505xr(&23,j%+&23,1):PROCsaa505xr(&A4,j%+&24,1):PROCsaa505xr(&C9,j%+&40,1):PROCsaa505xr(&C4,j%+&5B,1):PROCsaa505xr(&D6,j%+&5C,1):PROCsaa505xr(&C5,j%+&5D,1)
  200     PROCsaa505xr(&5F,j%+&5F,1):PROCsaa505xr(&E9,j%+&60,1):PROCsaa505xr(&E4,j%+&7B,1):PROCsaa505xr(&F6,j%+&7C,1):PROCsaa505xr(&E5,j%+&7D,1):PROCsaa505xr(&FC,j%+&7E,1)
  210   WHEN 3,5053: REM Italian
  220     PROCsaa505xr(&E9,j%+&40,1):PROCsaa505xr(&B0,j%+&5B,1):PROCsaa505xr(&E7,j%+&5C,1):PROCsaa505xr(&D9,j%+&60,1)
  230     PROCsaa505xr(&E0,j%+&7B,1):PROCsaa505xr(&D2,j%+&7C,1):PROCsaa505xr(&E8,j%+&7D,1):PROCsaa505xr(&EC,j%+&7E,1)
  240   WHEN 4,5054: REM Belgian
  250     PROCsaa505xr(&E9,j%+&23,1):PROCsaa505xr(&EF,j%+&24,1):PROCsaa505xr(&E0,j%+&40,1):PROCsaa505xr(&EB,j%+&5B,1):PROCsaa505xr(&EA,j%+&5C,1):PROCsaa505xr(&D9,j%+&5D,1)
  260     PROCsaa505xr(&EE,j%+&5E,1):PROCsaa505xr(&E8,j%+&60,1):PROCsaa505xr(&E2,j%+&7B,1):PROCsaa505xr(&F4,j%+&7C,1):PROCsaa505xr(&FB,j%+&7D,1):PROCsaa505xr(&E7,j%+&7E,1)
  270   WHEN 5,5055: REM US-ASCII
  280     PROCsaa505xr(&23,j%+&23,1):FOR loop%=&5B TO &60:PROCsaa505xr(loop%, loop%+j%,1):NEXT:PROCsaa505xr(&7B,j%+&7B,1):PROCsaa505xr(&A6,j%+&7C,1):PROCsaa505xr(&7D,j%+&7D,1):PROCsaa505xr(&7E,j%+&7E,1)
  290   WHEN 6,5056: REM Hebrew
  300     FOR loop%=0 TO 27:PROCsaa505xr(loop%,j%+loop%+&60,1):NEXT
  310   WHEN 7,5057: REM Cyrillic
  320     PROCsaa505xr(&23,j%+&23,1):PROCsaa505xr(&3F,j%+&26,2):FOR loop%=0 TO &3E:PROCsaa505xr(loop%,j%+loop%+&40,2):NEXT
  330 ENDCASE
In my library I've used DATA statements and FOR...NEXT loops to perform the equivalent operation, as you know. Whether you call that "tidier" is very much a personal thing.

My latest MODE7DEM program now runs fully in Matrix Brandy, including the Russian secondary-language text, with the libraries invoked as follows:

Code: Select all

  120 IF INKEY(-256) = 252 THEN
  130   LIBRARY "saa505xlib.bas"
  140   PROCsaa505xlibset(7,1)
  150 ELSE
  160   INSTALL @lib$ + "mode7lib"
  170   PROC_saa5057(1)
  180 ENDIF

Soruk
Posts: 631
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Thu May 21, 2020 9:59 pm

Richard Russell wrote:
Thu May 21, 2020 9:37 pm
Soruk wrote:
Thu May 21, 2020 11:44 am
There's probably a tidier way to do this....

Code: Select all

   10REM > SAA505Xlib
   ....
Just a heads-up that according to my editor there are lines in that library which are too long (i.e. > 251 characters after tokenization). Even if Brandy can cope with such long lines, no other version of BBC BASIC can, which makes them invalid in my opinion. I've split them up so they fit:
Brandy's maximum line length is 1024 characters.
Richard Russell wrote:

Code: Select all

  130 CASE code% OF
  140   WHEN 0,5050: REM SAA5050 is the default
  150   WHEN 1,5051: REM German
  160     PROCsaa505xr(&23,j%+&23,1):PROCsaa505xr(&A7,j%+&40,1):PROCsaa505xr(&C4,j%+&5B,1):PROCsaa505xr(&D6,j%+&5C,1):PROCsaa505xr(&DC,j%+&5D,1):PROCsaa505xr(&5E,j%+&5E,1)
  170     PROCsaa505xr(&5F,j%+&5F,1):PROCsaa505xr(&B0,j%+&60,1):PROCsaa505xr(&E4,j%+&7B,1):PROCsaa505xr(&F6,j%+&7C,1):PROCsaa505xr(&FC,j%+&7D,1):PROCsaa505xr(&DF,j%+&7E,1)
  180   WHEN 2,5052: REM Swedish
  190     PROCsaa505xr(&23,j%+&23,1):PROCsaa505xr(&A4,j%+&24,1):PROCsaa505xr(&C9,j%+&40,1):PROCsaa505xr(&C4,j%+&5B,1):PROCsaa505xr(&D6,j%+&5C,1):PROCsaa505xr(&C5,j%+&5D,1)
  200     PROCsaa505xr(&5F,j%+&5F,1):PROCsaa505xr(&E9,j%+&60,1):PROCsaa505xr(&E4,j%+&7B,1):PROCsaa505xr(&F6,j%+&7C,1):PROCsaa505xr(&E5,j%+&7D,1):PROCsaa505xr(&FC,j%+&7E,1)
  210   WHEN 3,5053: REM Italian
  220     PROCsaa505xr(&E9,j%+&40,1):PROCsaa505xr(&B0,j%+&5B,1):PROCsaa505xr(&E7,j%+&5C,1):PROCsaa505xr(&D9,j%+&60,1)
  230     PROCsaa505xr(&E0,j%+&7B,1):PROCsaa505xr(&D2,j%+&7C,1):PROCsaa505xr(&E8,j%+&7D,1):PROCsaa505xr(&EC,j%+&7E,1)
  240   WHEN 4,5054: REM Belgian
  250     PROCsaa505xr(&E9,j%+&23,1):PROCsaa505xr(&EF,j%+&24,1):PROCsaa505xr(&E0,j%+&40,1):PROCsaa505xr(&EB,j%+&5B,1):PROCsaa505xr(&EA,j%+&5C,1):PROCsaa505xr(&D9,j%+&5D,1)
  260     PROCsaa505xr(&EE,j%+&5E,1):PROCsaa505xr(&E8,j%+&60,1):PROCsaa505xr(&E2,j%+&7B,1):PROCsaa505xr(&F4,j%+&7C,1):PROCsaa505xr(&FB,j%+&7D,1):PROCsaa505xr(&E7,j%+&7E,1)
  270   WHEN 5,5055: REM US-ASCII
  280     PROCsaa505xr(&23,j%+&23,1):FOR loop%=&5B TO &60:PROCsaa505xr(loop%, loop%+j%,1):NEXT:PROCsaa505xr(&7B,j%+&7B,1):PROCsaa505xr(&A6,j%+&7C,1):PROCsaa505xr(&7D,j%+&7D,1):PROCsaa505xr(&7E,j%+&7E,1)
  290   WHEN 6,5056: REM Hebrew
  300     FOR loop%=0 TO 27:PROCsaa505xr(loop%,j%+loop%+&60,1):NEXT
  310   WHEN 7,5057: REM Cyrillic
  320     PROCsaa505xr(&23,j%+&23,1):PROCsaa505xr(&3F,j%+&26,2):FOR loop%=0 TO &3E:PROCsaa505xr(loop%,j%+loop%+&40,2):NEXT
  330 ENDCASE
In my library I've used DATA statements and FOR...NEXT loops to perform the equivalent operation, as you know. Whether you call that "tidier" is very much a personal thing.

My latest MODE7DEM program now runs fully in Matrix Brandy, including the Russian secondary-language text, with the libraries invoked as follows:

Code: Select all

  120 IF INKEY(-256) = 252 THEN
  130   LIBRARY "saa505xlib.bas"
  140   PROCsaa505xlibset(7,1)
  150 ELSE
  160   INSTALL @lib$ + "mode7lib"
  170   PROC_saa5057(1)
  180 ENDIF
Nice one! However, 252 is only under Windows. Linux uses 249, and anything between 243 and 254 is used depending on the hardware Brandy is running on. I haven't changed these from upstream Brandy, it would be nice to have a value (or range) that identifies Matrix Brandy, but I'm not sure how these get allocated (and those values are already documented in BeebWiki to refer to what hardware the platform is running on).

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

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

Post by Richard Russell » Fri May 22, 2020 12:06 am

Soruk wrote:
Thu May 21, 2020 9:59 pm
it would be nice to have a value (or range) that identifies Matrix Brandy, but I'm not sure how these get allocated (and those values are already documented in BeebWiki to refer to what hardware the platform is running on).
I don't think they get "allocated" as such, in my case I simply chose one that hadn't already been claimed ('W' for BB4W and 'S' for BBCSDL, for obvious reasons). 'M' (0x4D) hasn't been used so perhaps you could nab that for Matrix Brandy.

INKEY(-256) values are a precious resource so I wouldn't advocate trying to claim a 'range'. Once you know which interpreter you're dealing with you can then use commands specific to it to get further information. For example once the interpreter haa been identified as BBC BASIC for SDL 2.0 you can safely use the @platform% variable to discover the platform and version of SDL.

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

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

Post by Richard Russell » Fri May 22, 2020 7:46 am

Hopefully easy-to-fix bug: the 'dual character set' functionality seems not to be dependent on the VDU 23,18,3... flag. It must be, because ESC characters may be present in ordinary MODE 7 pages and you defnitely don't want them to switch to the secondary character set by default (they should be ignored, just as the alpha and graphics black codes are)!

Soruk
Posts: 631
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Fri May 22, 2020 9:27 am

Richard Russell wrote:
Fri May 22, 2020 7:46 am
Hopefully easy-to-fix bug: the 'dual character set' functionality seems not to be dependent on the VDU 23,18,3... flag. It must be, because ESC characters may be present in ordinary MODE 7 pages and you defnitely don't want them to switch to the secondary character set by default (they should be ignored, just as the alpha and graphics black codes are)!
Yup, just wrapped the call to toggle the flag in a test for MODE7_BLACK enabled. Thank you for pointing this out!

It is a good point, your online docs for your teletext emulation in BB4W suggest REVEAL be implemented by replacing CONCEAL codes with &9B, and this would have a rather curious side-effect!

I've taken a different approach for Conceal, taking an extension from RISC OS 5, VDU23,18,2,x| where if bit 0 of x is set, the CONCEAL code becomes a no-op and text is displayed, clear the bit and Conceal behaves as normal.

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

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

Post by Richard Russell » Fri May 22, 2020 9:48 am

Soruk wrote:
Fri May 22, 2020 9:27 am
It is a good point, your online docs for your teletext emulation in BB4W suggest REVEAL be implemented by replacing CONCEAL codes with &9B, and this would have a rather curious side-effect!
That's how I noticed it!
I've taken a different approach for Conceal, taking an extension from RISC OS 5, VDU23,18,2,x|
I quite genuinely knew nothing about RISC OS when I developed BBC BASIC for Windows 20 years ago (OK I could have researched it I suppose, but my prejudices against that OS meant that it never entered my mind to do so). My recent implementation of VDU 23,18,3... is one of very few RISC OS-specific features I've incorporated in one of my BASICs. It still makes me feel queasy... :lol:

Although Matrix Brandy and my BASICs are converging to a degree, and will probably continue to do so, they will always remain distinct in that yours is principally an emulator of ARM BASIC running under RISC OS whereas mine have been designed from the outset to be native implementations of the BBC BASIC language for the relevant platforms. Emulation has always taken second place in my versions, and when it conflicts with the 'general purpose' nature of the language (which I promote as competitive with Python, for example) it has been sacrificed.

Soruk
Posts: 631
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Fri May 22, 2020 9:58 am

Richard Russell wrote:
Fri May 22, 2020 9:48 am
I've taken a different approach for Conceal, taking an extension from RISC OS 5, VDU23,18,2,x|
I quite genuinely knew nothing about RISC OS when I developed BBC BASIC for Windows 20 years ago (OK I could have researched it I suppose, but my prejudices against that OS meant that it never entered my mind to do so). My recent implementation of VDU 23,18,3... is one of very few RISC OS-specific features I've incorporated in one of my BASICs. It still makes me feel queasy... :lol:
RISC OS 5 is pretty new, it's the one made available for Raspberry Pi, none of the VDU23,18 calls are available in the Archimedes or RISC PC series machines.
Richard Russell wrote: Although Matrix Brandy and my BASICs are converging to a degree, and will probably continue to do so, they will always remain distinct in that yours is principally an emulator of ARM BASIC running under RISC OS whereas mine have been designed from the outset to be native implementations of the BBC BASIC language for the relevant platforms. Emulation has always taken second place in my versions, and when it conflicts with the 'general purpose' nature of the language (which I promote as competitive with Python, for example) it has been sacrificed.
I agree to an extent, yes, the GUI layer is emulating the BBC and RISC OS to a degree (pattern drawing isn't implemented for starters!) and some of the SYS calls are deliberately aligned with RISC OS ones (e.g. OS_Byte, OS_Word, ColourTrans_SetGCOL) as they seemed to be genuinely useful for Brandy functionality, but other calls are Brandy-specific (e.g. Brandy_GetVideoDriver) though styled after RISC OS. I guess this just reflects my history with BBC BASIC.

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

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

Post by Richard Russell » Fri May 22, 2020 10:32 am

Soruk wrote:
Fri May 22, 2020 9:58 am
none of the VDU23,18 calls are available in the Archimedes or RISC PC series machines.
Oh! In that case I couldn't have used them in BB4W anyway. :wink:
I guess this just reflects my history with BBC BASIC.
Same here! Once the formal association between Acorn and the BBC ended (shortly after Sophie developed the BASIC V extensions to the language, to which I contributed) my "history with BBC BASIC" means with my BBC BASICs. :lol:

Soruk
Posts: 631
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Fri May 22, 2020 11:07 am

Richard Russell wrote:
Fri May 22, 2020 12:06 am
Soruk wrote:
Thu May 21, 2020 9:59 pm
it would be nice to have a value (or range) that identifies Matrix Brandy, but I'm not sure how these get allocated (and those values are already documented in BeebWiki to refer to what hardware the platform is running on).
I don't think they get "allocated" as such, in my case I simply chose one that hadn't already been claimed ('W' for BB4W and 'S' for BBCSDL, for obvious reasons). 'M' (0x4D) hasn't been used so perhaps you could nab that for Matrix Brandy.

INKEY(-256) values are a precious resource so I wouldn't advocate trying to claim a 'range'. Once you know which interpreter you're dealing with you can then use commands specific to it to get further information. For example once the interpreter haa been identified as BBC BASIC for SDL 2.0 you can safely use the @platform% variable to discover the platform and version of SDL.
Once again you raise an excellent point, which I have chosen to implement. INKEY(-256) now returns &4D, and new SYS call "Brandy_Platform" which returns host OS (e.g. Linux, MinGW), CPU family (x86, x86-64, ARM - though this is compile time so 32-bit build running on 64-bit OS will return x86), whether 64-bit build, whether it's an SDL build and the machine type (as per OSBYTE 0).

Edit: Nightlies rebuilt with this and the above Teletext fix, and BeebWiki updated to claim and register machine type &4D.

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

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

Post by Richard Russell » Fri May 22, 2020 12:47 pm

Soruk wrote:
Fri May 22, 2020 11:07 am
INKEY(-256) now returns &4D, and new SYS call "Brandy_Platform" which returns host OS (e.g. Linux, MinGW), CPU family (x86, x86-64, ARM - though this is compile time so 32-bit build running on 64-bit OS will return x86), whether 64-bit build, whether it's an SDL build and the machine type (as per OSBYTE 0).
All good stuff. Jonathan will probably complain that it's not how INKEY(-256) was originally intended to be used, and of course it isn't, but the world has changed and it's the only test that every implementation of BBC BASIC is supposed to recognise. As such it has to be the way to detect which interpreter it is, after which it's OK to start using implementation-specific code.

Soruk
Posts: 631
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Fri May 22, 2020 1:11 pm

Richard Russell wrote:
Fri May 22, 2020 12:47 pm
Soruk wrote:
Fri May 22, 2020 11:07 am
INKEY(-256) now returns &4D, and new SYS call "Brandy_Platform" which returns host OS (e.g. Linux, MinGW), CPU family (x86, x86-64, ARM - though this is compile time so 32-bit build running on 64-bit OS will return x86), whether 64-bit build, whether it's an SDL build and the machine type (as per OSBYTE 0).
All good stuff. Jonathan will probably complain that it's not how INKEY(-256) was originally intended to be used, and of course it isn't, but the world has changed and it's the only test that every implementation of BBC BASIC is supposed to recognise. As such it has to be the way to detect which interpreter it is, after which it's OK to start using implementation-specific code.
It's also a bit like the IPv4 situation, when these numbers were first allocated, 256 possible values seemed like a bottomless pit. As my rather less than sensible suggestion of wanting a range for Matrix Brandy shows, it will get exhausted fast. Thus your idea of taking just one value (&4D), specifically identifying Matrix Brandy (of any build flavour) which I then extended by creating the "Brandy_Platform" sys-call to get detailed information makes far more sense! And, for legacy programs, I've added another return parameter to Brandy_Platform that returns the old-school INKEY-256 value so modifying a program that used to check for, say INKEY-256 = 252, can be modified fairly easily:

Code: Select all

hwtype%=INKEY(-256)
matrix%=FALSE: IF hwtype% = &4D THEN matrix%=TRUE: SYS"Brandy_Platform" TO ,,,,,hwtype%: REM get legacy INKEY-256 value
Up until now there was no way to distinguish between Matrix Brandy and its predecessor programmatically, or even other BBC BASIC variants that might exist on Linux and Windows (aside from yours which use &53, &57 or &73). For a while I've been scratching my head looking for a way to do this which doesn't break on existing platforms.
Last edited by Soruk on Mon May 25, 2020 10:09 am, edited 1 time in total.

Soruk
Posts: 631
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Sat May 23, 2020 7:11 pm

Soruk wrote:
Sun May 17, 2020 5:27 pm
Richard Russell wrote:
Sun May 17, 2020 5:01 pm
I am inclined to agree with the comment here that VDU 23,18,3,1| should 'fix' the SAA5050 Hold Graphics bug. It's a reasonable expectation since it's switching from a strict MODE 7 emulation to something more compliant with later devices and the standard. I intend to implement that in the next release of BBCSDL:


vdu2318.gif
That seems eminently sensible, I will look to doing that too. And, thank you for the GIF, helps a lot to describe the fix! (I added ,128,42 to my VDU string to show alpha black being enabled.)

Edit: Checked in a commit that does just that. It'll be in tonight's nightly builds.
Aaaand, just checked in a fix for another change that COMPLETELY broke this. Sigh.

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

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

Post by Richard Russell » Sun May 24, 2020 11:55 am

Soruk wrote:
Sat May 23, 2020 7:11 pm
Aaaand, just checked in a fix for another change that COMPLETELY broke this. Sigh.
Do you (or does anybody) have an example of a page that looks right with accurate SAA5050 emulation but wrong with the 'hold fix' applied? It would be helpful to have such a thing for test purposes.

Soruk
Posts: 631
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Sun May 24, 2020 4:26 pm

Richard Russell wrote:
Sun May 24, 2020 11:55 am
Soruk wrote:
Sat May 23, 2020 7:11 pm
Aaaand, just checked in a fix for another change that COMPLETELY broke this. Sigh.
Do you (or does anybody) have an example of a page that looks right with accurate SAA5050 emulation but wrong with the 'hold fix' applied? It would be helpful to have such a thing for test purposes.
Sadly not, I spotted this because my change broke Hold completely, which I spotted in the tongue of CCl4's logout screen!

Soruk
Posts: 631
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Mon May 25, 2020 8:04 am

Richard Russell wrote:
Fri May 22, 2020 12:47 pm
Soruk wrote:
Fri May 22, 2020 11:07 am
INKEY(-256) now returns &4D, and new SYS call "Brandy_Platform" which returns host OS (e.g. Linux, MinGW), CPU family (x86, x86-64, ARM - though this is compile time so 32-bit build running on 64-bit OS will return x86), whether 64-bit build, whether it's an SDL build and the machine type (as per OSBYTE 0).
All good stuff. Jonathan will probably complain that it's not how INKEY(-256) was originally intended to be used, and of course it isn't, but the world has changed and it's the only test that every implementation of BBC BASIC is supposed to recognise. As such it has to be the way to detect which interpreter it is, after which it's OK to start using implementation-specific code.
Guess what? You were right, he has complained. Raised a ticket on my GitHub project and struck out the entries on BeebWiki. He suggested I used the methods on his Wiki page http://beebwiki.mdfs.net/What_BASIC_is_running but most of those require an assembler. I've also cited your versions :D I'm surprised he hasn't said anything about it here.

User avatar
richardtoohey
Posts: 3807
Joined: Thu Dec 29, 2011 5:13 am
Location: Tauranga, New Zealand
Contact:

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

Post by richardtoohey » Mon May 25, 2020 10:13 am

Well, can see what you are getting at, and can see what Jonathan is getting at, but not sure what the middle path is that makes everyone happy. :-k

Got 1.22.5 building on OpenBSD 6.7 and had a brief play (just curious!)... :D Thank you for your efforts. =D>

Soruk
Posts: 631
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Mon May 25, 2020 10:17 am

richardtoohey wrote:
Mon May 25, 2020 10:13 am
Well, can see what you are getting at, and can see what Jonathan is getting at, but not sure what the middle path is that makes everyone happy. :-k

Got 1.22.5 building on OpenBSD 6.7 and had a brief play (just curious!)... :D Thank you for your efforts. =D>
I'm glad it is working! If you are running the latest from git then you will also have the above changes, including the new SYS "Brandy_Platform" call and the multilingual Teletext support.

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

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

Post by Richard Russell » Mon May 25, 2020 10:18 am

Soruk wrote:
Mon May 25, 2020 8:04 am
Guess what? You were right, he has complained. Raised a ticket on my GitHub project and struck out the entries on BeebWiki.
My opinion remains that pragmatism and practicality must win over the original intention for INKEY(-256), which couldn't have anticipated how things would develop. Essentially there has to be a 'universal' way (something that will run on pretty much every version of BBC BASIC that has ever existed, or will ever exist) of determining what subset or superset of the language the interpreter accepts. Once that determination has been made it's OK to use dialect-dependent features, or issue an error if the program is unsuitable for that dialect. Really only INKEY(-256) fits the bill: it's simple and reliable.
He suggested I used the methods on his Wiki page http://beebwiki.mdfs.net/What_BASIC_is_running but most of those require an assembler
At least Brandy is no longer alone in not supporting assembler code: the iOS edition of BBCSDL is also in that position because Apple forbids 'arbitrary code execution' on that platform and any attempt to do so will cause the app to abort.
I'm surprised he hasn't said anything about it here.
Indeed. As you say, irrespective of any inherent merit (which I believe it has) the precedent has been set by my BASICs and Jonathan incorporated those IDs in his table without argument - probably knowing that anything he said wouldn't have made any difference anyway! I suggest you stick to your guns and continue to use 0x4D (I've altready modified some of my programs to test for it).

Soruk
Posts: 631
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Mon May 25, 2020 10:29 am

Richard Russell wrote:
Mon May 25, 2020 10:18 am
I suggest you stick to your guns and continue to use 0x4D (I've altready modified some of my programs to test for it).
I intend to :) First time I've used the "wontfix" tag on GitHub :lol:

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

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

Post by Richard Russell » Mon May 25, 2020 1:55 pm

Soruk wrote:
Mon May 25, 2020 10:29 am
First time I've used the "wontfix" tag on GitHub :lol:
There's a first time for everything! Jonathan would like INKEY(-256) to return information about the 'host' but what is the host in a situation like this:

host_squares.png

It seems to me that the 'host' a BASIC program is most likely to be interested in is the MOS emulation and its capabilities (OSBYTE, OSCLI, OSWORD, VDU etc.) which is consistent with the way INKEY(-256) behaves in 'our' BASICs. As one moves further out it becomes less likely that a BASIC program will need to know about it (so for example it is relatively unlikely that a program written for Matrix Brandy or BBCSDL will need to be aware of whether it is running on Linux or Windows) although that information should be available by implementation-specific means.

Soruk
Posts: 631
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Mon May 25, 2020 3:08 pm

👆👆👆 This! =D>

Soruk
Posts: 631
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Mon Jun 01, 2020 12:25 pm

Having followed a guide to installing MacOS Catalina in VirtualBox, I now have a working(?) Mac-ish environment - but one without working 3D acceleration (as the host is a rack-mount server without an accelerated 3D graphics card) which could be the cause of some problems I'm having.

I've checked in some updates which allow Matrix Brandy to build (with SDL 1.2.15 installed using the scripts from https://brew.sh/ but should be agnostic to other ways of installing libSDL, it just needs sdl-config to be in the path ), though with quite the handful of warnings. Edit: Fixed, along with some subtle bugs.

The text-mode builds run, and seem to do what they are supposed to do, which is good.

The SDL build, on the other hand, opens a window. I get a warning about "Unable to create basic Accelerated OpenGL renderer" but unfortunately Google is being rather unhelpful in this regard for me - I am suspecting that it's because I'm running a virtual Hackintosh type setup, but the software renderer is doing absolutely nothing, I'd much prefer to have something even if painfully slow. It responds to commands that are typed in the window (Q. <ENTER> exits, for example, and changing MODE can change the window size) and it can run programs, but I can't see a damn thing in it.

Would someone with a real Mac be able to pull the latest git and try to build it? It would be very helpful to be able to prove (or disprove) the problem I'm having is to do with my machine not being a real Mac.
Last edited by Soruk on Tue Jun 02, 2020 12:35 am, edited 2 times in total.

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

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

Post by Richard Russell » Mon Jun 01, 2020 1:43 pm

Soruk wrote:
Mon Jun 01, 2020 12:25 pm
I've checked in some updates which allow Matrix Brandy to build (with SDL 1.2.15...
I know very little about SDL 1.2, but judging by some comments at the SDL forum there are compatibility issues with recent versions of MacOS which, given the emphasis being put on SDL 2.0, are unlikely to be addressed. I've not dared update my Mac OS High Sierra to a later version (Mojave or Catalina) because even SDL 2.0 applications built on them can have issues; however if built on High Sierra they run fine on the later versions in my experience.

Soruk
Posts: 631
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Mon Jun 01, 2020 3:30 pm

Richard Russell wrote:
Mon Jun 01, 2020 1:43 pm
Soruk wrote:
Mon Jun 01, 2020 12:25 pm
I've checked in some updates which allow Matrix Brandy to build (with SDL 1.2.15...
I know very little about SDL 1.2, but judging by some comments at the SDL forum there are compatibility issues with recent versions of MacOS which, given the emphasis being put on SDL 2.0, are unlikely to be addressed. I've not dared update my Mac OS High Sierra to a later version (Mojave or Catalina) because even SDL 2.0 applications built on them can have issues; however if built on High Sierra they run fine on the later versions in my experience.
I'll see if I can build myself a High Sierra virtual Mac.

In other news, having built libSDL from source, it works to a degree. But, the display is rather garbled as the SDL framebuffer has the opposite endianness to Linux or Windows. It's a bit awkward as I'm also using the unused 4th channel in the 32bpp framebuffer to hold the 8-bit palette value as that's used for keeping things sane when I do VDU19...

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

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

Post by Richard Russell » Mon Jun 01, 2020 4:55 pm

Soruk wrote:
Mon Jun 01, 2020 3:30 pm
the SDL framebuffer has the opposite endianness to Linux or Windows.
Interesting. Here is what I get (as reported by SDL_GetRendererInfo):

Windows 10 laptop (integrated graphics):

Code: Select all

 Supported pixel formats:
         0: &16362004 (ARGB8888)
         1: &16762004 (ABGR8888)
         2: &16161804 (RGB888)
         3: &16561804 (BGR888)
         4: &32315659 (YV12)
         5: &56555949 (IYUV)
         6: &3231564E (NV12)
         7: &3132564E (NV21)
Ubuntu 18.04 LTS (nVidia):

Code: Select all

 Supported pixel formats:
         0: &16362004 (ARGB8888)
         1: &32315659 (YV12)
         2: &56555949 (IYUV)
         3: &3231564E (NV12)
         4: &3132564E (NV21)
Mac OS High Sierra (Mac Mini):

Code: Select all

 Supported pixel formats:
         0: &16362004 (ARGB8888)
         1: &16762004 (ABGR8888)
         2: &16161804 (RGB888)
         3: &16561804 (BGR888)
         4: &32315659 (YV12)
         5: &56555949 (IYUV)
         6: &3231564E (NV12)
         7: &3132564E (NV21)
         8: &59565955 (UYVY)
Admittedly this is SDL 2.0 (which will do on-the-fly format conversion if necessary) but it looks as though ARGB8888 should be a common format, so I wonder if your ''endianness' issue is another feature of your non-standard hardware.

Soruk
Posts: 631
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Mon Jun 01, 2020 7:48 pm

Richard Russell wrote:
Mon Jun 01, 2020 4:55 pm
Soruk wrote:
Mon Jun 01, 2020 3:30 pm
the SDL framebuffer has the opposite endianness to Linux or Windows.
Interesting. Here is what I get (as reported by SDL_GetRendererInfo):
Looks like SDL2 supports multiple pixel formats, the display layer on SDL1.2 has its format that is readable, other surfaces can be made with other formats but would require manual blitting.
Linux and Windows give me the pixel format of &00RRGGBB (or &AARRGGBB if I use an alpha channel) for 32bpp. MacOS Catalina is giving me &BBGGRR00.

Soruk
Posts: 631
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Mon Jun 01, 2020 9:38 pm

Soruk wrote:
Mon Jun 01, 2020 7:48 pm
Richard Russell wrote:
Mon Jun 01, 2020 4:55 pm
Soruk wrote:
Mon Jun 01, 2020 3:30 pm
the SDL framebuffer has the opposite endianness to Linux or Windows.
Interesting. Here is what I get (as reported by SDL_GetRendererInfo):
Looks like SDL2 supports multiple pixel formats, the display layer on SDL1.2 has its format that is readable, other surfaces can be made with other formats but would require manual blitting.
Linux and Windows give me the pixel format of &00RRGGBB (or &AARRGGBB if I use an alpha channel) for 32bpp. MacOS Catalina is giving me &BBGGRR00.
Edit: I created a SDL_PixelFormat structure with exactly what my Linux machines have in it, and made all my working surfaces use that instead of trying to copy the structure from the displayed surface. Much to my surprise, everything just worked from that point, without having to do any endianness-swapping when plotting into the actual displayed surface, so something in SDL is a bit amiss on the MacOS driver - but it means I now have a working SDL Matrix Brandy build on MacOS Catalina. (Different issue on High Sierra, but again, with the latest Mercurial snapshot of SDL 1.2, it's working, if really very slow screen updates.)
macos-brandy.png
Edit 2: OK, SDL 1.2 is actually slightly smarter than I was giving it credit. When it blits from one surface with one pixel format to another with a different one, it's translating the content.

Soruk
Posts: 631
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Thu Jun 04, 2020 12:31 am

I've just committed a check-in addressing the relatively slow text scrolling. It uses several bits of blitting to a temporary space then back to move the screen up or down, and this successfully handles all scenarios including text window scrolling.

However, it is slow.

I've put in an alternative code path, that is only used when there is no text window in use and not in MODE 7 and scrolling up (the most common situation), just using a couple of memcpy() calls to shift the screen up then a couple of for loops to paint a single text row of background colour, operating directly in the surface pixel buffers.

The scrolling on my RasPi2 is now as fast as the old routines were on my Xeon 2.6GHz server CPU, and on the Xeon, it runs like a startled cat - very unscientifically measured, it's about a 500% speed increase in LISTing a longish program (tested using the Telstar client BASIC source)

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

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

Post by Richard Russell » Fri Jun 05, 2020 10:30 am

Soruk wrote:
Thu Jun 04, 2020 12:31 am
I've put in an alternative code path, that is only used when there is no text window in use and not in MODE 7 and scrolling up
Good stuff. Just for clarification, when you say "when there is no text window in use" can I assume that the 'fast' scroll will be used when there is a text viewport defined but you are explicitly ignoring it by using VDU 23,7,1,3| (scroll entire window up)? Similarly, will the fast scroll be used when a text viewport is defined but happens to fill the window?

I must say that I rarely use conventional VDU 23,7... text scrolling these days because the 'modern' expectation seem to be for smooth scrolling, i.e. scrolling by a minimum of one 'pixel' rather than one row of text. This is particularly the case when 'drag' scrolling using the mouse or a touchscreen, but I also tend to do it when using a scrollbar. Only yesterday I modified my List Box code to scroll continuously rather than one row at a time.

Soruk
Posts: 631
Joined: Mon Jul 09, 2018 11:31 am
Location: Basingstoke, Hampshire
Contact:

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

Post by Soruk » Fri Jun 05, 2020 11:18 am

Richard Russell wrote:
Fri Jun 05, 2020 10:30 am
Soruk wrote:
Thu Jun 04, 2020 12:31 am
I've put in an alternative code path, that is only used when there is no text window in use and not in MODE 7 and scrolling up
Good stuff. Just for clarification, when you say "when there is no text window in use" can I assume that the 'fast' scroll will be used when there is a text viewport defined but you are explicitly ignoring it by using VDU 23,7,1,3| (scroll entire window up)? Similarly, will the fast scroll be used when a text viewport is defined but happens to fill the window?

I must say that I rarely use conventional VDU 23,7... text scrolling these days because the 'modern' expectation seem to be for smooth scrolling, i.e. scrolling by a minimum of one 'pixel' rather than one row of text. This is particularly the case when 'drag' scrolling using the mouse or a touchscreen, but I also tend to do it when using a scrollbar. Only yesterday I modified my List Box code to scroll continuously rather than one row at a time.
VDU23,7 is currently not implemented.

For a defined text window, there is code that recognises the defined window as being full screen so acts as if no window is in place.

Post Reply

Return to “classic languages (e.g. BASIC) on non-acorn platforms”