Matrix Brandy BASIC VI for console and SDL1.2: V1.22.10 released

[Richard Russell]

You can, but not within a program, resize the workspace by doing:

Code: Select all

NEW (256*1048576)

Interesting. I'm guessing that this frees the existing workspace (including the current program, hence not being allowed in code) and allocates a new one. All modern operating systems support reserving contiguous address space without actually allocating memory, which simplifies things and means it's possible to increase the workspace without having to discard an existing program.

My BASICs reserve either 256 Mbytes (BBCSDL) or 512 Mbytes (BB4W) of contiguous address space, if available (less if not), and then initially allocate the bottom 2 Mbytes of that (so HIMEM is set a little less than 2 Mbytes above PAGE). But HIMEM can subsequently be raised up to the maximum of the reserved space without anything being lost, and hence it's OK to do it within a program.

I wonder if Brandy doesn't do this for reasons of compatibility with 'ancient' operating systems like RISC OS which (perhaps) don't fully support Virtual Memory, but that's just speculation.

[Soruk]

You can, but not within a program, resize the workspace by doing:

Code: Select all

NEW (256*1048576)

Interesting. I'm guessing that this frees the existing workspace (including the current program, hence not being allowed in code) and allocates a new one. All modern operating systems support reserving contiguous address space without actually allocating memory, which simplifies things and means it's possible to increase the workspace without having to discard an existing program.

My BASICs reserve either 256 Mbytes (BBCSDL) or 512 Mbytes (BB4W) of contiguous address space, if available (less if not), and then initially allocate the bottom 2 Mbytes of that (so HIMEM is set a little less than 2 Mbytes above PAGE). But HIMEM can subsequently be raised up to the maximum of the reserved space without anything being lost, and hence it's OK to do it within a program.

I wonder if Brandy doesn't do this for reasons of compatibility with 'ancient' operating systems like RISC OS which (perhaps) don't fully support Virtual Memory, but that's just speculation.

In parallel with your message above, I have just committed a change that defaults to 64MB (and rebuilt the nightlies). This change doesn't apply to RISC OS as malloc() insists on reserving physical memory and will fail if it can't get it - so that remains defaulting to 512K.

HIMEM is always (initially) set to the limit of the allocation, Linux's allocator only actually claims memory in use.

[Richard Russell]

HIMEM is always (initially) set to the limit of the allocation, Linux's allocator only actually claims memory in use.

It wouldn't be desirable for me to do that, because it precludes using memory above HIMEM. I suppose you could lower HIMEM first, but my BASICs have always worked the other way round: initialise HIMEM relatively low but allow it to be raised. This is more compatible with memory allocators which distinguish between reserving and committing memory (which Windows does, but not Linux).

[Soruk]

Jumping back a bit (and killing time waiting for my hospital appointment!)

Running ARM BASIC v1.19 in Red Squirrel (RISC OS 4.02) it says "Starting with 29323516 bytes free" (nearly 28 Mbytes) which is plenty for the Game of Life program. Should I be surprised that Matrix Brandy provides less, by default? BBC BASIC for SDL 2.0 reserves 256 Mbytes of contiguous address space (if available), so HIMEM can be raised nearly that much above PAGE without error.

I guess you have your RISC OS environment configured to boot into BASIC, Beeb-style. When run from the Desktop, the default WimpSlot is 640K (though any application can choose to request less or more).

Upstream Brandy defaults to 512K workspace area.

Perhaps, platform-dependent, a program can increase its size with something like

Code: Select all

10 IF HIMEM-PAGE < enough% THEN OSCLI"brandy -s "+STR$(enough%)+" program.bas":END

[Richard Russell]

I guess you have your RISC OS environment configured to boot into BASIC, Beeb-style.

It's not "configured" at all:

Code: Select all

RISC OS 4.02 32MB
ARM 7500 Processor
HostFS filer
Error: File ':0.!boot' not found (Error number &D6)
*

Since all I'm interested in is BBC BASIC (I have not the slightest desire ever to run RISC OS) this suits me fine; I just type BASIC at the prompt and away it goes. But it's helpful that it gives me a respectable amount of memory.

[Soruk]

I guess you have your RISC OS environment configured to boot into BASIC, Beeb-style.

It's not "configured" at all:

Code: Select all

RISC OS 4.02 32MB
ARM 7500 Processor
HostFS filer
Error: File ':0.!boot' not found (Error number &D6)
*

Since all I'm interested in is BBC BASIC (I have not the slightest desire ever to run RISC OS) this suits me fine; I just type BASIC at the prompt and away it goes. But it's helpful that it gives me a respectable amount of memory.

You can clear that boot error with: *configure noboot

And, if you want to get it to boot into BASIC, do *modules to get the module number of BASIC, then do: *configure language <number>
The number will vary depending on RISC OS version. I don't have 4.02 but on my RPCEmu system with RISC OS 3.71 it's 16.

[Richard Russell]

And, if you want to get it to boot into BASIC, do *modules to get the module number of BASIC, then do: *configure language <number>

Thanks, that worked. Red Squirrel is of course quite a slow emulator (compared with ones you pay for!); if you have a faster system, I'd be interested to know how quickly my BASIC 5 version of Game of Life runs (I removed the code which reported the speed, but that could be put back if it gets fast enough to be interesting!). Displaying the grid is the bottleneck, but AFAIK there's nothing similar to *MDISPLAY which allows me to display it almost instantaneously in BB4W and BBCSDL.

[Soruk]

Currently away with my support bubble this weekend so away from my RPCEmu setup.

But, as I have my laptop with me I'm looking at implementing PTR(). For strings, it's self explanatory enough examining the memory from BB4C. However, reading (and writing) the array pointer, what are they pointing at? Currently my implementation (not yet pushed to git) has it pointing to a "basicarray" structure, which contains details of the array and at ](addr%%+8) is the address of the first member of the array. I'm not sure about implementing writing the address as it would need to contain a valid basicarray struct...

[Richard Russell]

Currently away with my support bubble this weekend so away from my RPCEmu setup.

I have now updated the program to use SYS "OS_SpriteOp", 52 to display the grid, which results in a considerable speed improvement.

I'm not sure about implementing writing the address as it would need to contain a valid basicarray struct...

That's true (in my BASICs too) and of the different objects that can have their pointers manipulated with PTR(), arrays are probably the least useful. But in the BBCSDL/BB4W pure-BASIC version of the Game of Life I do exactly that to good effect (I poke a valid array descriptor at the new address) so I'm pleased I included the ability to write the array pointer. Anyway in my view it would be hard to justify arrays being in the unique position of having their pointers readable but not writable.

[Soruk]

Currently away with my support bubble this weekend so away from my RPCEmu setup.

I have now updated the program to use SYS "OS_SpriteOp", 52 to display the grid, which results in a considerable speed improvement.

I'm not sure about implementing writing the address as it would need to contain a valid basicarray struct...

That's true (in my BASICs too) and of the different objects that can have their pointers manipulated with PTR(), arrays are probably the least useful. But in the BBCSDL/BB4W pure-BASIC version of the Game of Life I do exactly that to good effect (I poke a valid array descriptor at the new address) so I'm pleased I included the ability to write the array pointer. Anyway in my view it would be hard to justify arrays being in the unique position of having their pointers readable but not writable.

Thank you for that, I've committed my changed to my git tree, and rebuilt the nightlies. Possibly the useful bit is where arraystructaddr%%=PTR(array()), the array data begins at ](arraystructaddr%%+8), I've added padding on 32-bit to ensure that is valid for both 32 and 64-bit.

[Soruk]

From your mailing list (I saw the web archive) in your post

Incidentally my 'best attempt' would still be of some value if you were trying to make it work in Matrix Brandy because that does not support the OR operator in array arithmetic.

It is supported, but there was a bug breaking it for uint8 arrays (which I have now hopefully fixed).

[Richard Russell]

It is supported, but there was a bug breaking it for uint8 arrays (which I have now hopefully fixed).

What array arithmetic operators does Matrix Brandy support that Acorn's BASICs don't? And can you chain them like you can in my BASICs, or are they restricted to a single operator per statement like Acorn's? I'm assuming that the documentation here is still valid for BASIC 5.

[Soruk]

It is supported, but there was a bug breaking it for uint8 arrays (which I have now hopefully fixed).

What array arithmetic operators does Matrix Brandy support that Acorn's BASICs don't? And can you chain them like you can in my BASICs, or are they restricted to a single operator per statement like Acorn's? I'm assuming that the documentation here is still valid for BASIC 5.

Hopefully I have the implementation right , but I have +=, -=, AND=, OR=, EOR=, MOD= and DIV=. I've not tested matrix multiplication (which Acorn's supports), as my GCSE maths was FAR too long ago and I can't remember how matrix multiplication works!

[Richard Russell]

I have +=, -=, AND=, OR=, EOR=, MOD= and DIV=.

That's somewhat confusing because you list only the assignment operators rather than the regular binary operators! Does Matrix Brandy support both? Can you use both in the same statement? And you don't mention (scalar) multiplication or (floating-point) division, which is strange because ARM BASIC 5 supports those. Is there some online documentation that describes Matrix Brandy's array arithmetic capabilities, that I can study?

I've not tested matrix multiplication

Since that's arguably the most valuable of all the array operators, and one that I use extensively (typically for rotations), I don't find that very comforting! Presumably it's been in Brandy since the start (as it always has been in Sophie's BASIC 5 AFAIK), so if you've not had to make any changes there should be no reason to suspect it doesn't work.

[Soruk]

I have +=, -=, AND=, OR=, EOR=, MOD= and DIV=.

That's somewhat confusing because you list only the assignment operators rather than the regular binary operators! Does Matrix Brandy support both? Can you use both in the same statement? And you don't mention (scalar) multiplication or (floating-point) division, which is strange because ARM BASIC 5 supports those. Is there some online documentation that describes Matrix Brandy's array arithmetic capabilities, that I can study?

I've not tested matrix multiplication

Since that's arguably the most valuable of all the array operators, and one that I use extensively (typically for rotations), I don't find that very comforting! Presumably it's been in Brandy since the start (as it always has been in Sophie's BASIC 5 AFAIK), so if you've not had to make any changes there should be no reason to suspect it doesn't work.

It should at least work on float and int32 types, as they were in upstream Brandy. Do you have any code I could test with as it's been a few decades since I last touched matrix maths (especially the dreaded dot product!). All the scalar operations are present, including multiplication and floating point division.

[Richard Russell]

Do you have any code I could test with as it's been a few decades since I last touched matrix maths (especially the dreaded dot product!).

I don't claim that this is at all a comprehensive test (and it doesn't use either 8- or 64-bit arrays) but it can probably be adapted to Matrix Brandy quite easily. You can compare the output with what BBCSDL or BB4W produce (or BASIC 5 with the *REFRESH deleted):

Code: Select all

      MODE 0
      COLOUR 0, 0, 0, &40
      MOONPTS = 2000

      REM  Array to hold the points' positions in '3D space'
      DIM p(2, MOONPTS - 1)

      REM  Array to hold the points' positions after they've been rotated
      DIM q(2, MOONPTS - 1)

      REM  Rotation matrices
      DIM a(2,2), b(2,2), c(2,2), r(2,2)

      phi = PI * (3 - SQR(5)) : REM golden angle in radians

      REM  Define a hemisphere of points, with radius 1.0
      FOR I% = 0 TO MOONPTS - 1

        y = I% / (MOONPTS - 1)  : REM y goes from 0.0 to 1.0
        radius = SQR(1 - y * y) : REM horizontal radius at y

        theta = phi * I% : REM golden angle increment

        x = COS(theta) * radius
        z = SIN(theta) * radius

        p(0,I%) = x
        p(1,I%) = y
        p(2,I%) = z
      NEXT

      REM rotations:
      a = 0
      c = 0
      b = 0

      *REFRESH OFF
      REPEAT
        CLS

        REM  Create the rotation matrix
        a() = 1, 0, 0, 0, COS(a), -SIN(a), 0, SIN(a), COS(a)
        b() = COS(b), 0, SIN(b), 0, 1, 0, -SIN(b), 0, COS(b)
        c() = COS(c), -SIN(c), 0, SIN(c), COS(c), 0, 0, 0, 1
        r() = b() . a()
        r() = c() . r()

        REM  Rotate the 3D positions of the points
        q() = r() . p()

        REM  Plot the visible points
        FOR I%=0 TO MOONPTS-1
          IF q(2,I%) > 0  PLOT 69, 640+q(1,I%)*100, 512-q(0,I%)*100
        NEXT
        *REFRESH

        a += 0.008
        c = 0.4 * SIN(a/7) * COS(a)
      UNTIL FALSE
      END

[Soruk]

Do you have any code I could test with as it's been a few decades since I last touched matrix maths (especially the dreaded dot product!).

I don't claim that this is at all a comprehensive test (and it doesn't use either 8- or 64-bit arrays) but it can probably be adapted to Matrix Brandy quite easily. You can compare the output with what BBCSDL or BB4W produce (or BASIC 5 with the *REFRESH deleted):

Thank you - that worked in Matrix Brandy unedited. Nice effect!

[Richard Russell]

In this thread they are discussing the best way to plot 'angled' ellipses. I was going to suggest they use the same method you do, but having tried their test program on the latest version of Matrix Brandy not only does it suffer from exactly the same fault (gaps in the ellipses which could cause a flood-fill to leak, for example) it's completely wrong in other respects!

Here's what it should be (BASIC 5 in RISC OS):

riscos_ellipse.png (20.04 KiB) Viewed 410 times

and here's what Matrix Brandy produces:

brandy_ellipse.png (5.85 KiB) Viewed 410 times

So it looks like you both have work to do! Maybe you should collaborate.

The program is:

Code: Select all

   10 MODE 1
   20 ORIGIN 640,512
   30 FOR X=-1 TO 1 STEP 2
   40 FOR Y=-1 TO 1 STEP 2
   50 MOVE 320*X,256*Y
   60 MOVE 320*X-100,256*Y
   70 PLOT 197,X*100,Y*100
   80 NEXT
   90 NEXT

[Soruk]

In this thread they are discussing the best way to plot 'angled' ellipses. I was going to suggest they use the same method you do, but having tried their test program on the latest version of Matrix Brandy not only does it suffer from exactly the same fault (gaps in the ellipses which could cause a flood-fill to leak, for example) it's completely wrong in other respects!

Here's what it should be (BASIC 5 in RISC OS):

riscos_ellipse.png

and here's what Matrix Brandy produces:

brandy_ellipse.png

So it looks like you both have work to do! Maybe you should collaborate.

Thank you for this. I've fixed the bug in my ellipse generator code (actually, where it's called that got the shear sign wrong in some cases).
Looking at hoglet's linked code, it looks like he is using near enough exactly the same algorithm that Matrix Brandy is using.

Edit: Looks like my pointer to the RISC OS code was a useful one - hoglet was able to understand and translate the ARM code, the practical upshot of which is both his and my implementations now look a hell of a lot better!

[Richard Russell]

Does Matrix Brandy (or for that matter RISC OS) provide any support for anti-aliased graphics, either built-in or via a library? I know RISC OS supports anti-aliased fonts, but I don't know about graphics more generally.

[Soruk]

Does Matrix Brandy (or for that matter RISC OS) provide any support for anti-aliased graphics, either built-in or via a library? I know RISC OS supports anti-aliased fonts, but I don't know about graphics more generally.

Matrix Brandy certainly doesn't, and as far as I have discovered, neither does RISC OS (of course, using the PLOT primitives, I'm sure there are software implementations that can do this, as if memory serves this was one of the selling points for !ArtWorks, a RISC OS desktop application.).

[Richard Russell]

Matrix Brandy certainly doesn't, and as far as I have discovered, neither does RISC OS

Oh well, that's a shame. I don't make heavy use of anti-aliasing (it's inevitably quite slow) but in my opinion it's an important component of the 'toolbox' that makes BBC BASIC a general-purpose programming language.

[Soruk]

Matrix Brandy certainly doesn't, and as far as I have discovered, neither does RISC OS

Oh well, that's a shame. I don't make heavy use of anti-aliasing (it's inevitably quite slow) but in my opinion it's an important component of the 'toolbox' that makes BBC BASIC a general-purpose programming language.

I've just checked !Draw on RISC OS 5.28 (the latest stable version from ROOL), and sadly that doesn't appear to support it either, as if it did it would mean the support module in the OS had the capability.

In other news, on a branch I'm experimenting with separating the graphics and the interpreter to separate threads. It's looking quite promising, and my MODE 7 implementation now runs like a startled cat! (Though, threads and SDL can be a right royal pain in the backside at times too)

[Richard Russell]

threads and SDL can be a right royal pain in the backside at times too

SDL 2 is supposed to be thread-safe but that's not what I found when implementing the in-browser edition of BBCSDL. On querying this at the forum they claim it's probably a configuration mistake arising from when Emscripten was only single-threaded, but without knowing how to fix it I've had to add my own mutex.

[Soruk]

threads and SDL can be a right royal pain in the backside at times too

SDL 2 is supposed to be thread-safe but that's not what I found when implementing the in-browser edition of BBCSDL. On querying this at the forum they claim it's probably a configuration mistake arising from when Emscripten was only single-threaded, but without knowing how to fix it I've had to add my own mutex.

The only thing in SDL 1.2 that is thread-safe (that I've discovered) is SDL_PeepEvents, thankfully it was trivial to convert the SDL_PollEvent call to an SDL_PeepEvents call, and display writes (from the interpreter) are not done using SDL calls, they write directly to the pixel buffer, usually via a modescreen (where one pixel location is one pixel on screen, and is thus scaled to the displayed surface). That said, Linux and MinGW didn't object to SDL_PollEvent but my MacOS X build took an extremely dim view of it. Indeed, where I need to change video mode MacOS X is proving to be really annoying. Part of me doesn't want to dump MacOS support but then again x86-64 is a dead end there.

Edit: Fixed, MacOS X is working again.

[Richard Russell]

The only thing in SDL 1.2 that is thread-safe (that I've discovered) is SDL_PeepEvents, thankfully it was trivial to convert the SDL_PollEvent call to an SDL_PeepEvents call

I don't know about SDL 1.2, but in SDL 2.0 SDL_PollEvent calls SDL_PeepEvents internally (as do SDL_AddEvent, SDL_WaitEvent etc.) so that change wouldn't achieve anything.

[Soruk]

The only thing in SDL 1.2 that is thread-safe (that I've discovered) is SDL_PeepEvents, thankfully it was trivial to convert the SDL_PollEvent call to an SDL_PeepEvents call

I don't know about SDL 1.2, but in SDL 2.0 SDL_PollEvent calls SDL_PeepEvents internally (as do SDL_AddEvent, SDL_WaitEvent etc.) so that change wouldn't achieve anything.

That must be one of the points where SDL 2 and 1.2 differ because this was one of the things that was royally messing up MacOSX. I've got it to the point where it builds and runs correctly in my VM.

[Richard Russell]

That must be one of the points where SDL 2 and 1.2 differ

So switch to SDL2 perhaps?

[Soruk]

In addition to a significant reworking of the way the graphics display is handled on SDL builds, I've attempted a 26/32bit neutral RISC OS build. It works in RPCEmu (so far, if I've got it to build, it runs on this), and it also runs on ArcEm running RISC OS 3.11. (I haven''t been able to test it in RISC OS 2 but I wouldn't be surprised if it didn't work.)

[Richard Russell]

I've reported this in the other thread, but for completeness: