BBC BASIC for SDL 2.0 v0.17a released

discuss PC<>Acorn file transfer issues & the use of FDC, XFER, Omniflop/disk etc.
Richard Russell
Posts: 167
Joined: Sun Feb 27, 2011 10:35 am

BBC BASIC for SDL 2.0 v0.17a released

Postby Richard Russell » Mon May 01, 2017 11:28 am

I've updated BBCSDL, the free cross-platform BBC BASIC for Windows, Linux (86), Mac OS-X, Android and Raspberry Pi, to version 0.17a. It may be downloaded as follows:

The Android edition will also run on the Amazon Fire TV Stick. The Raspberry Pi edition requires a RPi 2 or RPi 3 running Raspbian Jessie.

Details may be found at the BBC BASIC forum here.

Richard.

User avatar
BigEd
Posts: 1438
Joined: Sun Jan 24, 2010 10:24 am
Location: West
Contact:

Re: BBC BASIC for SDL 2.0 v0.17a released

Postby BigEd » Mon May 01, 2017 1:24 pm

Oh - Raspberry Pi - hurrah! Thanks!

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: BBC BASIC for SDL 2.0 v0.17a released

Postby Elminster » Thu May 25, 2017 9:48 am

Is there a matrix that compares features between the free BB4W, full BB4W and the SDL versions?

I did have a poke around on the website and forums but couldnt spot one.

User avatar
FourthStone
Posts: 396
Joined: Thu Nov 17, 2016 2:29 am
Location: Melbourne, Australia

Re: BBC BASIC for SDL 2.0 v0.17a released

Postby FourthStone » Thu May 25, 2017 8:46 pm

BB4W is limited to 32k program size and cannot compile.

I'm interested to know what the SDL version differences are though?

EDIT: Answered my own question by downloading the SDL version which appears identical to the free BB4W.

EDIT2: Actually not identical and choice of 2 IDE's, still no compile and not sure if there is any ram limitation with SDL. Also the emulator fonts for mode 1 and 2 appear more faithful to a beeb. The speed seems slower on SDL but have not done a thorough comparison. Would also like a feature comparison between SDL and BB4W if available.

Richard Russell
Posts: 167
Joined: Sun Feb 27, 2011 10:35 am

Re: BBC BASIC for SDL 2.0 v0.17a released

Postby Richard Russell » Fri May 26, 2017 6:30 am

FourthStone wrote:BB4W is limited to 32k program size and cannot compile.

I appreciate it was just a typo, but for clarity it's only the free (trial) edition of BB4W that has those limitations!

not sure if there is any ram limitation with SDL.

256 Mbytes, if I remember rightly, so half that of BB4W (512 Mbytes max).

Would also like a feature comparison between SDL and BB4W if available.

The BBC BASIC interpreters (that is, the language itself) are identical. As you would expect, the differences arise from dependencies on the Operating Systems (SDL 2.0 in one case and Windows in the other). I haven't prepared a comprehensive list; perhaps I should.

Richard.

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: BBC BASIC for SDL 2.0 v0.17a released

Postby Elminster » Fri May 26, 2017 8:17 am

Thanks Richard.

The background is FourthStone has created quite a nice BBC BASIC paint package on the 8bit hardware/emulators and is think in branching out and making a more feature rich package on BB4W. He has been playing with it before looking to buy anything. As I am on a Mac I was interested to see how easy it was to move it between platforms and such like, and you new SDL products seemed to fit that bill. But wasnt quite sure what and wasnt avialable. e.g. compile.

User avatar
FourthStone
Posts: 396
Joined: Thu Nov 17, 2016 2:29 am
Location: Melbourne, Australia

Re: BBC BASIC for SDL 2.0 v0.17a released

Postby FourthStone » Fri May 26, 2017 9:10 am

Richard Russell wrote:I appreciate it was just a typo, but for clarity it's only the free (trial) edition of BB4W that has those limitations!

Thank you and yes I was referring to the free or trial version of BB4W as a previous post was asking about BB4W vs BB4W full

Richard Russell wrote:256 Mbytes, if I remember rightly, so half that of BB4W (512 Mbytes max).

This is quite impressive =D>

Does the SDL version allow for a compiled executable?

Is the SDL version slower than BB4W?

I've noticed that a test program that I wrote for BB4W runs noticeably slower in the SDL version although it could be just certain aspects... The graphics drawing seems about the same but reading the keyboard is slower.

User avatar
Elminster
Posts: 1632
Joined: Wed Jun 20, 2012 8:09 am
Location: Essex, UK

Re: BBC BASIC for SDL 2.0 v0.17a released

Postby Elminster » Fri May 26, 2017 9:37 am

@FourthStone

Did you notice, Just in casse Richard is busy, that there is also the Forum and Facebook Page for BBC BASIC? Might be some answers to question there. I only had a brief look when I was looking for a feature matrix.

https://www.facebook.com/bbcbasic
http://bbcbasic.conforums.com/

Richard Russell
Posts: 167
Joined: Sun Feb 27, 2011 10:35 am

Re: BBC BASIC for SDL 2.0 v0.17a released

Postby Richard Russell » Fri May 26, 2017 3:36 pm

FourthStone wrote:Does the SDL version allow for a compiled executable?

You need to specify the OS. In the case of Windows there's no particular problem with creating a standalone executable using exactly the same technique as BB4W. In Mac OS-X it's not too difficult to create a .dmg file (the usual form in which an app is distributed) but it needs to be signed to be acceptable. Similarly for Android, although I think there is probably no alternative but to install some of the native Android development tools. Linux probably poses the greatest problem in this regard, because of the different incompatible 'flavours'.

The reason why the existing IDE(s) don't yet support this capability is, of course, precisely because they are cross-platform and you can't have a 'cross platform' standalone executable.

Is the SDL version slower than BB4W?

As I stated, the BBC BASIC interpreter is identical (exactly the same code) so programs that perform no I/O will run at exactly the same speed (allowing for complications caused by OS factors such as task switching). Graphics and other I/O may run more slowly in BBCSDL, and can run much faster, all depending on how GDI and OpenGL perform. They are completely different graphics subsystems so it would be misleading to generalise.

Richard.

User avatar
FourthStone
Posts: 396
Joined: Thu Nov 17, 2016 2:29 am
Location: Melbourne, Australia

Re: BBC BASIC for SDL 2.0 v0.17a released

Postby FourthStone » Fri May 26, 2017 8:51 pm

Thanks again for taking time out to reply, Richard :D

Fantastic application and really looking forward to having a play with it, some of the programs written are amazing which goes to show how thorough and robust a platform it is =D>

Richard Russell
Posts: 167
Joined: Sun Feb 27, 2011 10:35 am

Re: BBC BASIC for SDL 2.0 v0.17a released

Postby Richard Russell » Wed May 31, 2017 9:19 pm

FourthStone wrote:I'm interested to know what the SDL version differences are though?

Here is a comparison between BBC BASIC for Windows (BB4W) and BBC BASIC for SDL 2.0 (BBCSDL). It is far from exhaustive, but hopefully will be useful:

  1. The BBC BASIC interpreters, i.e. the language itself, are identical (literally the same x86 assembly language code). Of course the ARM editions, i.e. Android (ARM) and Raspberry Pi, use different code but are designed to be functionally compatible - apart from the assembler (and CALL statement) that is! ARM sadly does not support 80-bit extended-precision floats so normal numeric variables (with no suffix) are 64-bit 'doubles'.

  2. The differences between BB4W and BBCSDL arise from dependencies on the Operating Systems (Windows in one case and SDL 2.0 in the other) and primarily affect features such as input/output, graphics (e.g. PLOT), OS commands (e.g. OSCLI) and the SYS statement.

  3. Graphics use entirely different subsystems: GDI (Graphics Device Interface) in the case of BB4W and OpenGL (OpenGL ES in the Android edition) in the case of BBCSDL. This affects the capabilitities and performance. For example BBCSDL does not currently support plotting filled segments (PLOT 168-175) or block swap (PLOT 249/253). Graphics may differ at the individual-pixel level since the algorithms for drawing lines, curves etc. are not identical.

  4. OpenGL (ES) is not architecturally suited to reading data 'back' from the screen, and this operation can be very slow as a result. As far as possible, programs should avoid using the POINT() and TINT() functions, or using RECTANGLE...TO, or performing scrolls, if they are not to suffer a significant performance hit when running in BBCSDL.

  5. BBCSDL currently provides no support for hardcopy (printer) output, e.g. VDU 1,2 & 3 are not implemented. This is because SDL 2.0 itself provides no abstraction layer for printing.

  6. BBCSDL does not support changing the system date/time using 'TIME$ =' nor setting the length of a file using 'EXT#file =' (even in BB4W these features are not guaranteed to work).

  7. The following built-in BB4W 'star' (OSCLI) commands are not available in BBCSDL: *HARDCOPY, *INPUT, *OUTPUT (*OPT), *PRINTER, *PRINTERFONT.

  8. BBCSDL provides the following additional 'star' (OSCLI) commands: *STEREO, *VOICE.

  9. The following 'star' (OSCLI) commands behave differently in BBCSDL: *FONT (the full path to the OTF or TTF file must be specified rather than just the name of the typeface), *RUN (the commands available depend on the underlying OS) and *SYS (*SYS 1 is not implemented,
    *SYS 4 enables SDL_MULTIGESTURE messages). *CD should be avoided in Android because it does not have the concept of 'current' directory.

  10. The multi-threading requirements of OpenGL mean that some 'system variables' (e.g. the VDU variables) can only be reliably read after performing a 'thread synchronisation', which can for example be achieved using GET(0,0).

  11. Although not directly related to differences between BB4W and BBCSDL, be aware of other Operating System dependencies such as file paths and names being case-sensitive in Linux and Android. Use only the forward slash (/) as a directory delimiter to ensure compatibility.

  12. The BB4W and BBCSDL IDEs are different in their interfaces and capabilities, but crucially the three IDEs supplied with BBCSDL (BBCEdit.bbc, SDLIDE.bbc and touchide.bbc) are themselves written in BBC BASIC so are amenable to development and enhancement by
    third parties without my involvement.

  13. Whilst BB4W will remain a proprietary closed-source product (with free-trial and paid-for versions) BBCSDL will always be absolutely free and I may well release the source code in due course.
Richard.

User avatar
FourthStone
Posts: 396
Joined: Thu Nov 17, 2016 2:29 am
Location: Melbourne, Australia

Re: BBC BASIC for SDL 2.0 v0.17a released

Postby FourthStone » Sun Jun 25, 2017 1:28 am

Hi Richard,

I have a question regarding how graphics are drawn in BB4W if you have time to answer?

I am trying to wrap my head around how rectangles and filled rectangles operate, I've noticed that a rectangle fill using the same coords as a rectangle doesn't completely fill in the same area. This does not seem to be an issue with the SDL version but I am having other issues getting my drawing program to work in SDL so I am sticking with BB4W at this time.

I have a small demo program which highlights the issue, if you have to examine and set me straight I would be very thankful and relived as it is driving me a bit bonkers with working out my drawing interface.

EDIT: The xcoord I mentioned in the code below is not right either, I could understand the box not filling all the way up and all the way out but it doesn't make sense that the bottom row is not being filled as that is the first line/y coord, anyway if I can make it work by understanding how it functions then it should be fine for what I am trying to do with it.

Code: Select all

      MODE 22


      REM fill doesn't appear to fill the same region as a same sized rectangle
      GCOL 3

      REM Large outline
      RECTANGLE 8,8,1280,1024

      REM small outline
      RECTANGLE 8,1100,64,64


      GCOL 1

      REM Large fill
      RECTANGLE FILL 8,8,1280,1024

      REM small fill
      RECTANGLE FILL 8,1100,64,64


      a=GET

      REM coords for fill have to be stretched out to appear to work?
      REM y has to start 2 pixels lower and finish 2 pixels higher
      REM x has to finish 2 pixels wider

      GCOL 3
      REM Large outline
      RECTANGLE 8,8,1280,1024

      REM small outline
      RECTANGLE 8,1100,64,64


      GCOL 1
      REM Large file
      RECTANGLE FILL 8,6,1282,1026

      REM small fill
      RECTANGLE FILL 8,1098,66,66


Richard Russell
Posts: 167
Joined: Sun Feb 27, 2011 10:35 am

Re: BBC BASIC for SDL 2.0 v0.17a released

Postby Richard Russell » Sun Jun 25, 2017 10:10 am

FourthStone wrote:I am trying to wrap my head around how rectangles and filled rectangles operate, I've noticed that a rectangle fill using the same coords as a rectangle doesn't completely fill in the same area.

Does this answer your question? In particular: "Solid shapes, such as filled triangles, rectangles and parallelograms, are drawn using the Windows™ Polygon function. This function treats the supplied vertices in a special way: vertices to the left and top of the polygon are inclusive of the plotted shape whereas vertices to the right and bottom are exclusive ".

Going right back to the BBC Micro there have been ambiguities about precisely what plot commands should do, even things as fundamental as whether the supplied parameters are true coordinates or pixel 'indices'. For example a graphics viewport filling the entire screen might need to be specified as 0;0;1276;1020; rather than 0;0;1280;1024;

As it says in the BB4W docs, I decided to sidestep the entire issue by converting the BBC BASIC coordinates into Windows coordinates in the most straightforward and 'obvious' way, thus leaving it up to the Windows GDI subsystem to determine precisely what happens. You can argue that it was a bit of a cop-out, and it does result in differences between platforms at the individual pixel level, but it makes it easier to mix PLOT and VDU commands with native Windows graphics. Similarly in the SDL version the graphics are drawn using the SDL_gfx subsystem and again one cannot expect that the pixels plotted will be precisely the same as they are on other platforms.

In a perfect world graphics coordinates should be floating-point values rather than integers, and all graphics should be plotted anti-aliased in order to achieve sub-pixel sizes and positions. This ideal is approached by the Windows GDI+ subsystem (GDIPLUS.DLL) and I would have liked to use this in BB4W had it not been for one serious problem: GDI+ does not support the 'logical' (OR, AND, XOR) plotting modes that are required by BBC BASIC.

One compensation is that screen resolutions are increasing all the time, with 'retina' displays with 300 DPI or better native resolution becoming commonplace. This means that 'off by one pixel' errors are far less important than they once were, and indeed the whole idea of drawing a line or curve which is one-pixel thick is a nonsense because it is likely to be invisible.

Richard.

User avatar
FourthStone
Posts: 396
Joined: Thu Nov 17, 2016 2:29 am
Location: Melbourne, Australia

Re: BBC BASIC for SDL 2.0 v0.17a released

Postby FourthStone » Mon Jun 26, 2017 1:37 am

Thanks Richard,

I've had a read through (again) of the details on the link provided, I'm sure I've skimmed through it all before but now I'm using it directly it's starting to sink in.

I'll do some tests with various sized fills and rectangles along with some pixel plotting to ensure I am getting precisely the amount of pixels I am requiring.

Only Microsoft could come up with a coordinate system where a height of 200 pixels actually equals 199 :evil:

EDIT: Or reading it again, could it be that the filled rectangles are correct and that the rectangles are 1 pixel wider...

Note in particular that although the RECTANGLE statement specifies the width and height of the rectangle, since the end-points of the lines forming the edges are inclusive, the actual dimensions (measured to the outer edges of the lit pixels) will be one pixel greater than those specified.

:-?

Richard Russell
Posts: 167
Joined: Sun Feb 27, 2011 10:35 am

Re: BBC BASIC for SDL 2.0 v0.17a released

Postby Richard Russell » Mon Jun 26, 2017 8:58 am

FourthStone wrote:Only Microsoft could come up with a coordinate system where a height of 200 pixels actually equals 199

No, Microsoft think a height of 200 equals 200 pixels whereas Acorn think a height of 200 means 201 pixels! Now which do you think is strange? :?

Consider the statement 'RECTANGLE FILL 200,200,200,200' - what would you expect the width of the resulting rectangle to be? In BB4W it will be exactly 100 pixels but try it on an Acorn machine and you will find that the rectangle is wider than that, in MODE 0 it will be 101 pixels wide.

Since straight lines are (by default) drawn with the end-points inclusive, the statement 'RECTANGLE 200,200,200,200' draws an outline rectangle whose bounding box is 101 pixels wide. Acorn seem to have felt that a filled rectangle should extend to the same external dimensions as an outline rectangle with the same parameters, so that is also 101 pixels wide.

This would have been tricky to emulate accurately in BB4W, not least because the extent to which the rectangle ends up being wider than you might expect depends on the MODE. For example on an Acorn machine the width of the resulting rectangle will be 202 graphics units in MODE 0, 204 graphics units in MODE 1 and 208 graphics units in MODE 2!

I am happy for you to 'blame' Microsoft for the vertical position of the resulting rectangle not being what you might expect, but in my opinion the dimensions of the rectangle are more 'correct' in BB4W than they are in Acorn versions.

Richard.

User avatar
FourthStone
Posts: 396
Joined: Thu Nov 17, 2016 2:29 am
Location: Melbourne, Australia

Re: BBC BASIC for SDL 2.0 v0.17a released

Postby FourthStone » Mon Jun 26, 2017 10:12 am

Richard Russell wrote:I am happy for you to 'blame' Microsoft for the vertical position of the resulting rectangle not being what you might expect, but in my opinion the dimensions of the rectangle are more 'correct' in BB4W than they are in Acorn versions.


Actually I've got a lot more blame I could throw at MS for atrocities committed against users and admins alike, but I will reserve that for another day :wink:

It's important for me to understand how things work (today) (on a basic level) so that I may progress my little application so thank you again for taking time out to reply, much appreciated! And it's good to know there's a logical and programmatic reason for how the rectangle fills work so I can make my programs to work the same way.

User avatar
FourthStone
Posts: 396
Joined: Thu Nov 17, 2016 2:29 am
Location: Melbourne, Australia

Re: BBC BASIC for SDL 2.0 v0.17a released

Postby FourthStone » Wed Jun 28, 2017 12:31 am

Just to reply to my own post and confirm what I found... hope this is helpful to anyone that may need the same information.

Rectangle Fill was the initial source of my confusion as I had assumed Rectangle was working as expected and something was not right with Fill... it turns out that both statements have a little getting used to.

NOTE: Each pixel is 2 graphic units so 32 graphic units is 16 pixels

RECTANGLE draws a box with dimensions one extra pixel high and to the right.

e.g. RECTANGLE 64,64,32,32

Box starts at 64,64 and finishes at 96,96 which is 17 pixels wide and 17 pixels high, not 16 as we might expect, so to get the box to draw with the expected dimensions subtract 2 from the width and height as follows:

RECTANGLE 64,64,30,30


RECTANGLE FILL creates the correct dimensions for a filled box but due to the way BB4W handles the plotting the box gets plotted 1 pixel higher (2 graphic units) probably because it calculates the start coordinate (top left) by adding the height to the starting point without subtracting 1 pixel to make the height match what is specified.

e.g. RECTANGLE FILL 64,64,32,32

Draws a filled box starting at 64,66 and finishes at 94,96 which is 16 pixels wide and 16 pixels high... just not where we specified.

To get the box to plot where we expect just subtract 2 from the y start position as follows:

RECTANGLE FILL 64,62,32,32

Now the box will draw at 64,64 and extends 16 pixels in width and height..

Simple! :lol:

Richard Russell
Posts: 167
Joined: Sun Feb 27, 2011 10:35 am

Re: BBC BASIC for SDL 2.0 v0.17a released

Postby Richard Russell » Wed Jun 28, 2017 8:34 am

FourthStone wrote:Box starts at 64,64 and finishes at 96,96 which is 17 pixels wide and 17 pixels high, not 16 as we might expect

Why are you "expecting" RECTANGLE to work differently from the way it works on Acorn products? That seems a surprising attitude on StarDot! I wrote the following simple test program:

Code: Select all

   10 MODE 1
   20 RECTANGLE 64,64,32,32
   30 FOR X% = 64 TO 96 STEP 4
   40   IF POINT(X%,64)<>3 OR POINT(X%,96)<>3 STOP
   50 NEXT
   60 FOR Y% = 64 TO 96 STEP 4
   70   IF POINT(64,Y%)<>3 OR POINT(96,Y%)<>3 STOP
   80 NEXT

This runs to completion on BBC BASIC for Windows, BBC BASIC for SDL 2.0 and Red Squirrel (emulating a Risc PC 700). I haven't had the opportunity to run it on genuine Acorn hardware but I have every expectation that it will work the same way.

Richard.

User avatar
FourthStone
Posts: 396
Joined: Thu Nov 17, 2016 2:29 am
Location: Melbourne, Australia

Re: BBC BASIC for SDL 2.0 v0.17a released

Postby FourthStone » Wed Jun 28, 2017 11:38 am

Richard Russell wrote:
FourthStone wrote:Box starts at 64,64 and finishes at 96,96 which is 17 pixels wide and 17 pixels high, not 16 as we might expect

Why are you "expecting" RECTANGLE to work differently from the way it works on Acorn products? That seems a surprising attitude on StarDot! I wrote the following simple test program:

Code: Select all

   10 MODE 1
   20 RECTANGLE 64,64,32,32
   30 FOR X% = 64 TO 96 STEP 4
   40   IF POINT(X%,64)<>3 OR POINT(X%,96)<>3 STOP
   50 NEXT
   60 FOR Y% = 64 TO 96 STEP 4
   70   IF POINT(64,Y%)<>3 OR POINT(96,Y%)<>3 STOP
   80 NEXT

This runs to completion on BBC BASIC for Windows, BBC BASIC for SDL 2.0 and Red Squirrel (emulating a Risc PC 700). I haven't had the opportunity to run it on genuine Acorn hardware but I have every expectation that it will work the same way.

Richard.


Happy to post my test program, I've found I need to compensate to enable my program to operate correctly as described.

Just trying to find a way to make my program behave as expected and definitely not pretending to know how things should behave.

Richard Russell
Posts: 167
Joined: Sun Feb 27, 2011 10:35 am

Re: BBC BASIC for SDL 2.0 v0.17a released

Postby Richard Russell » Wed Jun 28, 2017 12:47 pm

There is only so much I can do in terms of providing explanations and evidence. I will not waste my, or your, time by posting again.

Richard.

User avatar
FourthStone
Posts: 396
Joined: Thu Nov 17, 2016 2:29 am
Location: Melbourne, Australia

Re: BBC BASIC for SDL 2.0 v0.17a released

Postby FourthStone » Wed Jun 28, 2017 8:39 pm

Apologies for posting again, I do understand why it operates this way and I thank you for help, I was just trying to find out why so I could use it effectively.

If I take your example one step further I get the answer I was looking for:

Code: Select all

   10 MODE 1
   20 xcount=0
   30 ycount=0
   40 RECTANGLE 64,64,32,32
   50 FOR X% = 64 TO 96 STEP 2
   60   IF POINT(X%,64)<>3 OR POINT(X%,96)<>3 STOP
   70   xcount=xcount+1
   80 NEXT
   90 FOR Y% = 64 TO 96 STEP 2
  100   IF POINT(64,Y%)<>3 OR POINT(96,Y%)<>3 STOP
  110   ycount=ycount+1
  120 NEXT
  130 PRINT "X: ";STR$(xcount)
  140 PRINT "Y: ";STR$(ycount)


Return to “software & utilities for the pc, mac or unix”

Who is online

Users browsing this forum: No registered users and 1 guest