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: 139
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: 1247
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: 1383
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: 276
Joined: Thu Nov 17, 2016 2:29 am

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: 139
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: 1383
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: 276
Joined: Thu Nov 17, 2016 2:29 am

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: 1383
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: 139
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: 276
Joined: Thu Nov 17, 2016 2:29 am

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: 139
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: 276
Joined: Thu Nov 17, 2016 2:29 am

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: 139
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: 276
Joined: Thu Nov 17, 2016 2:29 am

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:


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

Who is online

Users browsing this forum: No registered users and 1 guest