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

discuss PC<>Acorn file transfer issues & the use of FDC, XFER, Omniflop/disk etc.
User avatar
Richard Russell
Posts: 515
Joined: Sun Feb 27, 2011 10:35 am
Location: Downham Market, Norfolk
Contact:

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

Post by Richard Russell » Wed Aug 08, 2018 12:46 pm

Soruk wrote:
Wed Aug 08, 2018 11:18 am
Brandy is single threaded
Ah, that explains a lot. It isn't really an option in an event-driven environment like Windows (GUI) or SDL 2, because events need to be handled in a timely fashion even if the interpreter is busy doing something slow (like a WAIT). All my versions run the BASIC program in its own thread, separate from the event-handling and GUI thread (it's more of an issue anyway when you have SYS and assembler code to consider). They are loosely based on the architecture of the BBC Micro + Second Processor, where a 'language processor' (e.g. ARM) runs the BASIC program and the 'I/O processor' (6502) draws the graphics and handles input/output.

Richard.

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

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

Post by dhg2 » Wed Aug 08, 2018 3:45 pm

About the Escape issue I mentioned before, I just wanted to say that I've been trying out the latest version from github and it's all working fine for me now.

While I'm at it, I'd like to share this silly program I wrote for fun last night and this afternoon: http://dusthillguy.ddns.net/folder/JimmyWales.basic
Here's some background music which I think goes well with it: https://www.youtube.com/watch?v=8GLWaI981Qo
Regards,
- Patrick

Coeus
Posts: 1029
Joined: Mon Jul 25, 2016 11:05 am
Contact:

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

Post by Coeus » Wed Aug 08, 2018 6:17 pm

Richard Russell wrote:
Tue Aug 07, 2018 10:02 pm
On BB4W and BBCSDL too. Using relative units, a 'character cell' has the following dimensions (width x height):

MODE 0: 8 x 16
MODE 3: 8 x 20
MODE 4: 16 x 16
MODE 6: 16 x 20

MODEs 0 and 4 have 32 rows, giving a total height of 512; MODEs 3 and 6 have 25 rows, giving a total height of 500. If you change the background colour, on the Beeb the extra space between the rows in MODEs 3 and 6 remains black, so you get a striped effect. I do not attempt to emulate this in BB4W or BBCSDL; the entire background changes colour.

Richard.
So, in typesetting terminology, the BBC Micro uses the CRTC to provide hardware leading but BBCB4W may be using a bastard font.

Coeus
Posts: 1029
Joined: Mon Jul 25, 2016 11:05 am
Contact:

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

Post by Coeus » Wed Aug 08, 2018 6:19 pm

Soruk wrote:
Wed Aug 08, 2018 11:52 am
In addition to the INKEY changes, I've also checked into github hopefully a fix for the MODE 3 / 6 issue.
That's looking good.

Coeus
Posts: 1029
Joined: Mon Jul 25, 2016 11:05 am
Contact:

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

Post by Coeus » Wed Aug 08, 2018 6:20 pm

dhg2 wrote:
Wed Aug 08, 2018 3:45 pm
While I'm at it, I'd like to share this silly program I wrote for fun last night and this afternoon: http://dusthillguy.ddns.net/folder/JimmyWales.basic
Here's some background music which I think goes well with it: https://www.youtube.com/watch?v=8GLWaI981Qo
Very good!

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

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

Post by Soruk » Wed Aug 08, 2018 9:35 pm

dhg2 wrote:
Wed Aug 08, 2018 3:45 pm
About the Escape issue I mentioned before, I just wanted to say that I've been trying out the latest version from github and it's all working fine for me now.

While I'm at it, I'd like to share this silly program I wrote for fun last night and this afternoon: http://dusthillguy.ddns.net/folder/JimmyWales.basic
Here's some background music which I think goes well with it: https://www.youtube.com/watch?v=8GLWaI981Qo
OK, I'm impressed. I didn't think the display routines in Matrix Brandy were fast enough to do that! (Though, I do see the judicious use of *refresh!)

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

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

Post by Richard Russell » Thu Aug 09, 2018 11:45 am

dhg2 wrote:
Wed Aug 08, 2018 3:45 pm
While I'm at it, I'd like to share this silly program I wrote for fun last night and this afternoon: http://dusthillguy.ddns.net/folder/JimmyWales.basic
In BB4W and BBCSDL I get a syntax error from line 470, which appears to be a GCOL statement with three parameters. I've never come across a variant of GCOL with three parameters, and I can't find it mentioned in any BBC BASIC manual. What does it mean?

Richard.

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

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

Post by Soruk » Thu Aug 09, 2018 11:57 am

Richard Russell wrote:
Thu Aug 09, 2018 11:45 am
dhg2 wrote:
Wed Aug 08, 2018 3:45 pm
While I'm at it, I'd like to share this silly program I wrote for fun last night and this afternoon: http://dusthillguy.ddns.net/folder/JimmyWales.basic
In BB4W and BBCSDL I get a syntax error from line 470, which appears to be a GCOL statement with three parameters. I've never come across a variant of GCOL with three parameters, and I can't find it mentioned in any BBC BASIC manual. What does it mean?

Richard.
According to HELP GCOL on RISC OS 3.7, three or 4 parameters are:

Code: Select all

GCOL [<action>,]r,g,b: set colour to r, g, b.

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

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

Post by Richard Russell » Thu Aug 09, 2018 12:54 pm

Soruk wrote:
Thu Aug 09, 2018 11:57 am
According to HELP GCOL on RISC OS 3.7, three or 4 parameters are: GCOL [<action>,]r,g,b: set colour to r, g, b.
That must be a late addition. I can't see it referenced in the official BBC BASIC documentation at riscos.com. There it shows the syntax as:

Code: Select all

      GCOL [expression1,] expression2 [TINT expression3] 
What is the equivalent VDU sequence? The 'normal' GCOL becomes VDU 18,a,n so - unlike VDU 19 which had room for expansion from the beginning - there's no obvious way of extending it. I suppose the nearest equivalent is:

Code: Select all

      COLOUR n, r, g, b : GCOL [<action>], n
But I wonder what is the correct value of 'n' to use (if it matters). If I make that substitution in BBCSDL (with n set arbitrarily to 1), and choose a MODE that BBCSDL likes, then the program does run.

Richard.

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

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

Post by Soruk » Thu Aug 09, 2018 1:32 pm

Richard Russell wrote:
Thu Aug 09, 2018 12:54 pm
That must be a late addition. I can't see it referenced in the official BBC BASIC documentation at riscos.com. There it shows the syntax as:

Code: Select all

      GCOL [expression1,] expression2 [TINT expression3] 
What is the equivalent VDU sequence? The 'normal' GCOL becomes VDU 18,a,n so - unlike VDU 19 which had room for expansion from the beginning - there's no obvious way of extending it. I suppose the nearest equivalent is:

Code: Select all

      COLOUR n, r, g, b : GCOL [<action>], n
But I wonder what is the correct value of 'n' to use (if it matters). If I make that substitution in BBCSDL (with n set arbitrarily to 1), and choose a MODE that BBCSDL likes, then the program does run.

Richard.
BASIC 1.16 in RISC OS 3.71 has both GCOL r,g,b and COLOUR r,g,b - and this:

Code: Select all

  10*SPOOL Test
  20COLOUR12,34,56
  30*SPOOL
generates an empty file - no VDU codes are written to the file. Same is true testing GCOL12,34,56

I also fired up Arcem, which emulates an A440 running RISC OS 3.11 running BASIC 1.05, and these are NOT present.

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

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

Post by Richard Russell » Thu Aug 09, 2018 1:46 pm

Soruk wrote:
Thu Aug 09, 2018 1:32 pm
generates an empty file - no VDU codes are written to the file. Same is true testing GCOL12,34,56
Eek, I wonder how that is supposed to work in a Second Processor context, when graphics commands are (or should be) all piped through the VDU stream? I sometimes think Acorn lost their way after the influence of the BBC was removed, but perhaps I am prejudiced! 6502 BBC BASIC has a very clean interface to the MOS, via just a few well-documented APIs (OSWRCH, OSBYTE, OSWORD etc.). ARM BASIC seems to be much more entwined with RISC OS, and by the sound of it Brandy has inherited some of that inelegance.

Richard.

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

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

Post by Soruk » Thu Aug 09, 2018 2:04 pm

Richard Russell wrote:
Thu Aug 09, 2018 1:46 pm
Soruk wrote:
Thu Aug 09, 2018 1:32 pm
generates an empty file - no VDU codes are written to the file. Same is true testing GCOL12,34,56
Eek, I wonder how that is supposed to work in a Second Processor context, when graphics commands are (or should be) all piped through the VDU stream? I sometimes think Acorn lost their way after the influence of the BBC was removed, but perhaps I am prejudiced! 6502 BBC BASIC has a very clean interface to the MOS, via just a few well-documented APIs (OSWRCH, OSBYTE, OSWORD etc.). ARM BASIC seems to be much more entwined with RISC OS, and by the sound of it Brandy has inherited some of that inelegance.
While reading ARM assembly is, to me, almost as opaque as trying to read Chinese, I'm not going to try to pick my way though the RISC OS Open source from RiscOS5. However, I'm wondering if it might be via a SWI call to ColourTrans. (Only because someone on the Raspberry Pi forum found calling ColourTrans_SetGCOL was faster than BASIC's GCOL)

User avatar
jgharston
Posts: 3212
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

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

Post by jgharston » Thu Aug 09, 2018 2:54 pm

BASIC 1.16 in RISC OS 3.71 has both GCOL r,g,b and COLOUR r,g,b - and this:

Code: Select all

  10*SPOOL Test
  20COLOUR12,34,56
  30*SPOOL
generates an empty file - no VDU codes are written to the file. Same is true testing GCOL12,34,56
What's the functionality of COLOUR a,b,c ? If it is COLOUR r,g,b what does it set to that r/g/b triplet?
COLOUR l,r,g,b issues VDU 19,l,16,r,g,b to set logical colour L to physical colour R/G/B, but COLOUR r,g,b ? Set what? to R/G/B?

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

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

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

Post by Soruk » Thu Aug 09, 2018 2:59 pm

jgharston wrote:
Thu Aug 09, 2018 2:54 pm
BASIC 1.16 in RISC OS 3.71 has both GCOL r,g,b and COLOUR r,g,b - and this:

Code: Select all

  10*SPOOL Test
  20COLOUR12,34,56
  30*SPOOL
generates an empty file - no VDU codes are written to the file. Same is true testing GCOL12,34,56
What's the functionality of COLOUR a,b,c ? If it is COLOUR r,g,b what does it set to that r/g/b triplet?
COLOUR l,r,g,b issues VDU 19,l,16,r,g,b to set logical colour L to physical colour R/G/B, but COLOUR r,g,b ? Set what? to R/G/B?
In a 256-colour mode (e.g.13, 21) typing "COLOUR 255,160,160" gives me pink text. It is indeed r,g,b - as shown by "HELP COLOUR" in BASIC in RISC OS 3.71.

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

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

Post by Richard Russell » Thu Aug 09, 2018 3:54 pm

jgharston wrote:
Thu Aug 09, 2018 2:54 pm
COLOUR l,r,g,b issues VDU 19,l,16,r,g,b to set logical colour L to physical colour R/G/B, but COLOUR r,g,b ? Set what? to R/G/B?
Sounds to me as though it's somehow bypassing the palette and setting an RGB colour without also setting one of the palette entries. That's 'impossible' in all my versions of BBC BASIC because there's always a palette: if it's a paletted display (which is unlikely these days) then it sets the hardware palette entry; if (as is usual) it's a 'full colour' display it sets a software colour look-up table. This all happens for free in Windows GUI, which has the same concept of hardware/software palette (it makes it easier to code in a display-independent way).

I wonder if Acorn went down the different road of using a palette only when the display is itself paletted, and using RGB values if not. If so it was a poor decision in my opinion, making it more difficult to write a program that will run on both kinds of display. I'm pleased that I was 'out of the loop' for so many years after the BBC and Acorn parted company, and all my BBC BASICs stick very much to the spirit of the original. Where I've added back features from ARM BASIC, I've done so in a way that is in keeping with the philosophy of the original Beeb, and not slavishly followed what Acorn did.

I commonly store VDU sequences in string variables, and use them as a kind of graphics metafile. For example in my SDLIDE program the icons for a program file and a folder, which are displayed in the file selector window, are handled that way:

Code: Select all

      OSCLI "spool """ + @tmp$ + "bbfile.vdu"""
      GCOL 14+128
      PLOT 0,C%,0 : PLOT 99,C%*0.75,-C%*0.75 : PLOT 0,C%/4,C%/4 : PLOT 0,-C%*0.75,0
      PLOT 115,-C%/2,-C%/2 : PLOT 0,C%/4,C%/4 : PLOT 98,C%*0.75,C%*0.75 : PLOT 0,0,-C%/2
      PLOT 1,C%/4,0 : PLOT 1,-C%/2,-C%/2 : PLOT 1,-C%*0.75,0 : PLOT 1,C%/4,C%/4
      PLOT 0,C%*1.25,C%*0.75 : PLOT 0,0,0
      OSCLI "spool """ + @tmp$ + "folder.vdu"""
      GCOL 14+128
      PLOT 0,C%,0 : PLOT 0,C%*0.75,0 : PLOT 99,-C%*0.75,-C%
      PLOT 0,C%/2,-C%/4 : PLOT 0,0,C% : PLOT 115,-C%/2,C%/4
      PLOT 1,0,-C% : PLOT 1,C%/2,-C%/4 : PLOT 1,0,C% : PLOT 1,-C%/2,C%/4
      PLOT 1,C%*0.75,0 : PLOT 1,0,-C% : PLOT 1,-C%*0.25,0 : PLOT 0,C%*0.75,C%
      *spool
      F% = OPENIN(@tmp$ + "bbfile.vdu")
      BBfile$ = GET$#F% BY EXT#F%
      CLOSE #F%
      F% = OPENIN(@tmp$ + "folder.vdu")
      Folder$ = GET$#F% BY EXT#F%
      CLOSE #F%
The whole idea of a graphics operation which has no VDU-stream equivalent is simply wrong!

Richard.

User avatar
jgharston
Posts: 3212
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

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

Post by jgharston » Thu Aug 09, 2018 4:33 pm

I've done some digging through the source for 1.50, and ignoring the TINT subcalls there is:

Code: Select all

COLOUR L            -> VDU 17,L
  Select logical text colour L
COLOUR L,P          -> VDU 19,P,P<<8,P<<16,P<<24
  Set logical colour L to physical colour P, allowing COLOUR L,&RRGGBBxx
COLOUR R,G,B        -> ColourTrans_SetTextColour,&00RRGGBB,??,0
  Set text colour to logical colour closest to R/G/B.
  Equivalent COLOUR (ColourTrans_ReturnColourNumber,&00RRGGBB)
COLOUR L,R,G,B      -> VDU 19,L,16,R,G,B
  Set logical colour L to physical colour R/G/B
COLOUR L,R,G,B,S    -> PaletteV,L,16,&RRGGBBSS,2
  Set logical colour L to physical colour R/G/B and supremacy S
  Equivalent to COLOUR L,R,G,B as all documentation says S should be 0.
Seems so "wrong" that they should bypass the VDU vector, especially when most could be done through the VDU vector.
(Another Edit: especially as other OS calls that call the VDU system directly explicitly ensure that the equivalent VDU sequence is used, eg OS_Plot issues VDU 25,a,x;y;, OS_SetColour issues a VDU 16 or VDU 18 sequence.)

Edit: and GCOL R,G,B sets the current graphics colour to the logical colour closest to R/G/B via a ColourTrans call, which could also be done with a ColourTrans lookup followed by a VDU sequence.
Last edited by jgharston on Thu Aug 09, 2018 4:39 pm, edited 3 times in total.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

Phlamethrower
Posts: 84
Joined: Fri Nov 24, 2017 1:35 pm
Contact:

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

Post by Phlamethrower » Thu Aug 09, 2018 6:17 pm

Richard Russell wrote:
Thu Aug 09, 2018 3:54 pm
I wonder if Acorn went down the different road of using a palette only when the display is itself paletted, and using RGB values if not.
Pretty much, yeah.

In true colour modes, the memory used by the palette is used for defining the gamma table instead - which means that COLOUR L,R,G,B will actually change the gamma table (I suspect they didn't think things through that much when they made that change).

In paletted modes, COLOUR R,G,B and GCOL R,G,B will still work; ColourTrans will pick the nearest palette entry (and for GCOL, it'll use an ECF pattern if there isn't an exact match). So if it wasn't for the fact that COLOUR L,R,G,B changes the gamma table in true colour modes, you could have mode-independent code by using COLOUR L,R,G,B to define your colours and then COLOUR R,G,B to select them (with the obvious performance penalties of the OS having to search for the nearest colour). But since COLOUR L,R,G,B does change the gamma table, you're basically going to have to have two different code paths.
Last edited by Phlamethrower on Thu Aug 09, 2018 6:18 pm, edited 2 times in total.

Coeus
Posts: 1029
Joined: Mon Jul 25, 2016 11:05 am
Contact:

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

Post by Coeus » Thu Aug 09, 2018 10:22 pm

Richard Russell wrote:
Thu Aug 09, 2018 1:46 pm
Eek, I wonder how that is supposed to work in a Second Processor context, when graphics commands are (or should be) all piped through the VDU stream? I sometimes think Acorn lost their way after the influence of the BBC was removed, but perhaps I am prejudiced! 6502 BBC BASIC has a very clean interface to the MOS, via just a few well-documented APIs (OSWRCH, OSBYTE, OSWORD etc.). ARM BASIC seems to be much more entwined with RISC OS, and by the sound of it Brandy has inherited some of that inelegance.
Are you saying that VDU interface was a BBC idea?

Back in the day when I first got a BBC micro and found it worked that way it was a bit of a surprise but at that stage I had not used a terminal attached to a remote computer. Had I have done it would probably have seen more natural, i.e. the BBC micro was acting like a computer and a terminal in the same box, maintaining that interface even though both components were running on the same processor. It also worked very naturally when the two separated out again when one added a tube processor. That was not the only way of doing things - a kind of remote procedure call could have been used for communication between the processors, but the VDU interface did lend itself to parallelism and it did mean CP/M packages could be customised to the BBC by putting the BBC VDU codes in the patch area used for adapting to various other terminals. It is also useful to have a data stream that can simply be captured and replayed.

But if Acorn started to move away from this idea once the ARM was in its own machine, the Archimedes, rather than a language processor for the BBC micro, then they were hardly breaking new ground given that the IBM PC didn't implement anything similar. In fact the IBM seemed particularly poor in that it neither carried the emulated terminal idea forward nor implemented a viable alternative behind a similar INT interface to the ones used for OS/BIOS services. What was on offer was too few operations and too slow such that DOS programmers were essentially forced to write to the screen memory directly and that only changed with the introduction of Windows.

In the Unix world there was X11, another protocol to allow graphics operations to be generated in once place and actually drawn somewhere else and that seemed very advanced by comparison with the likes of VNC but that is out of favour now.
Last edited by Coeus on Thu Aug 09, 2018 10:24 pm, edited 1 time in total.

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

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

Post by Richard Russell » Thu Aug 09, 2018 11:30 pm

Coeus wrote:
Thu Aug 09, 2018 10:22 pm
But if Acorn started to move away from this idea once the ARM was in its own machine, the Archimedes, rather than a language processor for the BBC micro, then they were hardly breaking new ground
If they had abandoned the VDU stream idea altogether, and moved to something closer to what, say, the IBM PC did (ugh!) then I suppose that would at least have been consistent. But keeping the VDU mechanism substantially intact whilst bolting on a few graphics commands that bypassed it altogether is indefensible in my opinion.

Richard.

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

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

Post by Soruk » Fri Aug 10, 2018 2:08 pm

Dragging this thread back on topic...

I've released Matrix Brandy V1.21.9.

Significant changes include:
* ESCAPE now works when pressed within the SDL window.
* *REFRESH implemented (user request, based on BB4W/BBCSDL). Possible divergence: An error condition will re-enable Refresh.
* INKEY implementation improved - and now picks up mouse buttons.
* Rendering of screen modes 3 and 6 improved.
* MODE 7 flash now locked to the centisecond timer, so flashing remains consistent irrespective of what else is going on.

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

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

Post by Richard Russell » Fri Aug 10, 2018 4:11 pm

Soruk wrote:
Fri Aug 10, 2018 2:08 pm
Possible divergence: An error condition will re-enable Refresh.
Not in the case of an error trapped with ON ERROR, I presume? One wouldn't want Refresh to be enabled as a side effect of an 'expected' error, for example a 'Division by zero' or 'Number too big' in an ATAN2 function.

Richard.

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

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

Post by Soruk » Fri Aug 10, 2018 4:17 pm

Richard Russell wrote:
Fri Aug 10, 2018 4:11 pm
Soruk wrote:
Fri Aug 10, 2018 2:08 pm
Possible divergence: An error condition will re-enable Refresh.
Not in the case of an error trapped with ON ERROR, I presume? One wouldn't want Refresh to be enabled as a side effect of an 'expected' error, for example a 'Division by zero' or 'Number too big' in an ATAN2 function.
At the moment, yes it would. But that's easily changed. Simplest would be to auto-reenable only on Escape or where ERR=0, or extend with a third option: *Refresh onerror, which would disable until an error condition is raised. I made it auto-enable because when hitting Escape when disabled, nothing seems to happen (except perhaps a noticeable drop in host CPU usage), requiring a blind *refresh on to fully regain control.

I might also make "END" re-enable Refresh. As it drops the user to Immediate mode, it's rather pointless leaving refresh off.
Last edited by Soruk on Fri Aug 10, 2018 4:19 pm, edited 1 time in total.

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

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

Post by Richard Russell » Fri Aug 10, 2018 4:45 pm

Soruk wrote:
Fri Aug 10, 2018 4:17 pm
when hitting Escape when disabled, nothing seems to happen (except perhaps a noticeable drop in host CPU usage), requiring a blind *refresh on to fully regain control.
The same is true of my BASICs, but in every program that uses *REFRESH OFF I make sure to include an ON ERROR handler which enables it again.

I've got nothing against automatically re-enabling it on an untrapped error or END, except that it breaks the internal 'demarcation' between what belongs to the 'language' (which would have been in the language ROM on a BBC Micro) and what belongs to the 'OS emulation' (which would have been in the OS ROM). Although everything gets compiled into a common executable, that distinction is fairly strictly observed internally, so the BASIC error handler can't 'see' the *REFRESH mechanism in order to enable it.

What about other situations when the interpreter's output becomes 'invisible', for example if the foreground and background colours are the same, or the output is disabled with VDU 21 etc. Does Brandy take special measures to 'restore control' if an untrapped error occurs in those circumstances, as well?

Richard.

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

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

Post by dhg2 » Fri Aug 10, 2018 8:49 pm

I've noticed another difference between Brandy and RISC OS 3/ARM BASIC, they behave differently when there's a GCOL with values outside the normal 0 to 255 range.
Here's an example:

Code: Select all

   10MODE 13
   20R%=255<<8 OR 128
   30G%=255<<8 OR 64
   40B%=255<<8 OR 32
   50GCOL R%,G%,B%
   60CIRCLE FILL 640,512,320
which produces this result:
2018-08-10-214537_640x512_scrot.png
2018-08-10-214536_640x512_scrot.png
Regards,
- Patrick

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

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

Post by Soruk » Sat Aug 11, 2018 8:09 am

dhg2 wrote:
Fri Aug 10, 2018 8:49 pm
I've noticed another difference between Brandy and RISC OS 3/ARM BASIC, they behave differently when there's a GCOL with values outside the normal 0 to 255 range.
That should be sorted, and uploaded to Github. Filtering the input to only pass the low 8 bits now makes it match RISC OS.

EDIT: Same problem existed for COLOUR r,g,b - also fixed.
Last edited by Soruk on Sat Aug 11, 2018 3:57 pm, edited 2 times in total.

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

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

Post by Soruk » Sat Aug 11, 2018 9:34 am

Richard Russell wrote:
Fri Aug 10, 2018 4:45 pm
Soruk wrote:
Fri Aug 10, 2018 4:17 pm
when hitting Escape when disabled, nothing seems to happen (except perhaps a noticeable drop in host CPU usage), requiring a blind *refresh on to fully regain control.
The same is true of my BASICs, but in every program that uses *REFRESH OFF I make sure to include an ON ERROR handler which enables it again.

I've got nothing against automatically re-enabling it on an untrapped error or END, except that it breaks the internal 'demarcation' between what belongs to the 'language' (which would have been in the language ROM on a BBC Micro) and what belongs to the 'OS emulation' (which would have been in the OS ROM). Although everything gets compiled into a common executable, that distinction is fairly strictly observed internally, so the BASIC error handler can't 'see' the *REFRESH mechanism in order to enable it.

What about other situations when the interpreter's output becomes 'invisible', for example if the foreground and background colours are the same, or the output is disabled with VDU 21 etc. Does Brandy take special measures to 'restore control' if an untrapped error occurs in those circumstances, as well?

Richard.
Fair points. (Though to "fix" VDU21, the immediate mode prompt could change from VDU62 to VDU6,62 - and wouldn't break the separation).

Edit: I've made the BB4W/BBCSDL options (on /off) behave as BB4W/BBCSDL, but added *Refresh OnError. I've made the separation by using a function call to read the state - as on the BBC Micro a language can read OS state using, for example, an OSBYTE call. Perhaps a "valid" extension would be to take an unused OSBYTE code (e.g. 42) and that could be used to read the state, so available to both the language and to program - and perhaps even allow it to set the state too (e.g. *MOTOR is a front-end to *FX137, and the OSBYTE call can also read the state)

Edit 2: To enable communication of states across the boundary while maintaning a logical separation, I've gone ahead and implemented OSBYTE 42, currently only X=1 is supported to get or set the *Refresh state. I'm planning on just using A=42 and different X values if I want or need to pass other information across in future that's not covered by pre-existing OSBYTE values.
Last edited by Soruk on Sat Aug 11, 2018 9:26 pm, edited 4 times in total.

User avatar
jgharston
Posts: 3212
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

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

Post by jgharston » Sat Aug 11, 2018 11:50 pm

In the BBC environment, when the foreground application (eg BASIC) detects an Escape state it issues an EscapeAcknowledge OSBYTE &7E, and then it's down the the MOS to process whatever Escape Effects are in effect - flush sound queues, clear all buffers, turn EXEC off, cancel scroll pending, clear the Escape state - and that is where a *REFRESH ON equivalent would occur. OSBYTE 230 enables/disables Escape Effects, so you could extend that to, eg, implement a bitmap of Escape efects.

As a note, in BASIC I, REPORT does PRINT CHR$6'error$; whereas all future Acorn BASICs REPORT does PRINT 'error$;
Last edited by jgharston on Sat Aug 11, 2018 11:52 pm, edited 1 time in total.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
jgharston
Posts: 3212
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

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

Post by jgharston » Sun Aug 12, 2018 12:05 am

Soruk wrote:
Sat Aug 11, 2018 9:34 am
Edit 2: To enable communication of states across the boundary while maintaning a logical separation, I've gone ahead and implemented OSBYTE 42, currently only X=1 is supported to get or set the *Refresh state. I'm planning on just using A=42 and different X values if I want or need to pass other information across in future that's not covered by pre-existing OSBYTE values.
You really should use a high numbered OSBYTE so you can read and write the variable using the standard new=(old AND Y) EOR X;return old process. As OSBYTE 230 is the Escape Effects Enabled/Disabled OSBYTE, it would be best to use it as the Escape Effects Enabled/Disables OSBYTE.

Current programs set OSBYTE 230 to either:
* 0 to enable all normal Escape Effects
* 1 or 255 to disable all normal Escape Effects

If we say that not doing *REFRESH ON in acknowledgement of Escape is the normal Escape effect, then I'd recommend:
* b0=disable flushing buffers/cancel SOUND/close EXEC on Escape acknowledgement
* b1=*REFRESH ON on Escape acknowledgement

That preserves the current implementation where
* 0 - flush buffers/cancel SOUND/close EXEC, addition of don't *REFRESH ON
* 1 - flush buffers/cancel SOUND/close EXEC, addition of don't *REFRESH ON
* 255 - don't flush/cancel SOUND/close EXEC, addition of *REFRESH ON

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

Phlamethrower
Posts: 84
Joined: Fri Nov 24, 2017 1:35 pm
Contact:

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

Post by Phlamethrower » Sun Aug 12, 2018 12:55 am

Don't forget that RISC OS has OS_Byte 112/113 for controlling screen banking. It's not quite the same functionality as *REFRESH, but if the intention is to keep Matrix Brandy programs compatible with RISC OS BASIC (and vice-versa) then supporting those calls would be useful.

Richard Russell's BASICs could theoretically support them as well, at least write-only via *FX.
Last edited by Phlamethrower on Sun Aug 12, 2018 1:05 am, edited 1 time in total.

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

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

Post by Richard Russell » Sun Aug 12, 2018 9:16 am

jgharston wrote:
Sat Aug 11, 2018 11:50 pm
In the BBC environment, when the foreground application (eg BASIC) detects an Escape state it issues an EscapeAcknowledge OSBYTE &7E
On Escape, yes, but unless it also happens on all untrapped errors it doesn't resolve this issue. When developing a program, especially, an error such as 'Mistake' or 'No Such Variable' or 'Syntax Error', if it occurs during *REFRESH OFF (or other circumstances when the output is 'invisible'), will result in an (apparent) loss of control.

This is not so much of an issue when an IDE is in use (which will usually be the case with my BASICs, on desktop platforms at least) because the usual user action in that event is to close the 'output window'. It doesn't matter that the interpreter's output has been disabled, or is invisible, because the IDE is unaffected and the location of the error (also the error message in the case of BB4W) is likely to be shown there.

Richard.

Post Reply