BBC BASIC for SDL 2.0 version 1.09a released

[Deleted User 9295]

I've released version 1.09a of BBC BASIC for SDL 2.0 - the cross-platform programming language for Windows, MacOS, Linux, Raspbian, Android and iOS. The changes in this version are as follows:

1. BASIC Interpreter / Run Time Engine
   
   Worked around a regression in SDL 2.0.10, which caused the fern demo not to run on some platforms.
   
   Improved compatibility with GCC 4.9.
   
   
2. IDEs and Utilities
   
   SDLIDE: Added the Memory Usage Monitor (similar to the BB4W equivalent) to the Utilities menu. Now you can find out how close your program is to running out of memory (or whether you have allocated much more memory than you need!). The BASIC program must be run in Debug mode for this to work.
   
   
3. Libraries
   
   Modified dlglib.bbc to improve the responsiveness of the listbox to slow mouse button clicks.
   
   
4. Example Programs
   
   Updated Ceefax.bbc (and capitalised its name!) to include Weather, Traffic and Local News pages, and to be navigable using an Amazon Fire TV remote. With the demise of the BBC's digital ('red button') text service at the end of this month, this is my attempt to provide a substitute! This program also runs in BBC BASIC for Windows if you copy 'Bedstead-ext.otf' into BB4W's LIB directory.

This new version may be downloaded, for all the supported platforms, from the usual location. The GitHub repository has been updated (used to build the MacOS, Raspbian, iOS and 64-bit Linux editions, currently).

Please remember that if you use the Android Application Generator you should download a new APK template to ensure that any updates to the run-time engine are incorporated in your own apps.

[Deleted User 9295]

Here are some screenshots from the Ceefax simulator. It's also available as a standalone Android app which will run on an Amazon Fire TV or TV Stick:

[Soruk]

With the demise of the BBC's digital ('red button') text service at the end of this month, this is my attempt to provide a substitute!

So that's what Brexit is all about. Since "RBExit" is virtually unpronounceable without sounding like an idiot....

[Deleted User 9295]

So that's what Brexit is all about. Since "RBExit" is virtually unpronounceable without sounding like an idiot....

You could be right, it can't be a coincidence that the BBC is discontinuing its Red Button text service on 30th January and the UK is leaving the EU on 31st January! If only I could use a BBC BASIC program to fix Brexit as easily as I can to fix RBexit....

[pixelblip]

That weather map with square blobs is so much easier to comprehend than modern day stuff.

[Deleted User 9295]

That weather map with square blobs is so much easier to comprehend than modern day stuff.

It's the closest I could get to the current (but not for much longer) Red Button weather maps, which are able to show symbols for cloud etc. Using colour-coded blobs seemed the best way to utilise the limited teletext graphics capability (I can write 'FOG', as indeed do the Red Button maps, if appropriate).

I just have to hope that the BBC's news and weather RSS feeds, which of course this app relies on totally, remain available for the foreseeable future. But, sadly, there can be no certainties as far as the future of the BBC's services is concerned.

[lurkio]

I've released version 1.09a of BBC BASIC for SDL 2.0 - the cross-platform programming language for Windows, MacOS ...

I don't know if this has been mentioned before, but it's worth noting that on macOS you have to copy the BBCBasic app from the disk-image and then paste it into a new location (in the Applications folder, say) before launching the app from the new location. I don't think you can just move the app -- i.e. click once and hold on the app-icon and drag it -- to the new location; if you try to move the app in this way it won't run properly (or at least that's been my experience): it won't be able to "find" some of its files. I believe the reason for the faff is something to do with a "feature" of macOS called "AppTranslocation" (which I don't really understand). EDIT: Actually, scratch that. My problem with trying to run the app from a macOS folder on my hard disk might have been due to the fact that the name of the folder contains a comma, which seems to confuse the SDL BBCBasic app on macOS.

Btw, out of curiosity I tried pasting the listing for Nellan Is Thirsty into the SDL BBCBasic editor on macOS and running the program. It worked, but the MODE7 Teletext graphics were all messed up. Not a big deal, but any idea why?

[Deleted User 9295]

It worked, but the MODE7 Teletext graphics were all messed up. Not a big deal, but any idea why?

I'm not certain, but this comment in the code concerns me:

Code: Select all

 1320 FORj=1TO9:w3$(j)="ˇˇˇ":NEXT
      REM  the "funny" characters are all CHR$255

I copied-and-pasted the code from the forum page you linked to, and the "funny" characters that ended up in my clipboard definitely aren't CHR$255, not least because my browser and SDL's clipboard are both assuming UTF-8 encoding and CHR$255 isn't valid in UTF-8! Although CHR$255 is valid in ANSI, it corresponds to a ÿ, not the caron character ˇ shown above.

Is it available somewhere as a tokenised BASIC file (other than in a disc image)?

[lurkio]

Is it available somewhere as a tokenised BASIC file (other than in a disc image)?

Here you go:

• NELLAN.$.zip

  (8.31 KiB) Downloaded 159 times

EDIT: Ah, yes, having opened that tokenised BASIC file in your editor and run it, I can see that the graphics look right now.

EDIT2: This looks a bit weird though:

EDIT3: When I used your SDL BBCBasic editor to save the program out to disk again as a text file and then opened the resultant text file in my usual macOS text editor, the "funny" chars appeared as carons again, as in the original listing I linked to above.

[Deleted User 9295]

EDIT2: This looks a bit weird though:

Look in the Options menu and check whether you have Unicode enabled. Since that program has literal strings containing ANSI characters (notably the CHR$255) it won't display correctly if those strings are interpreted as though they are UTF-8. That same section of program displays correctly for me (in Windows) with Unicode deselected:

[lurkio]

When I used your SDL BBCBasic editor to save the program out to disk again as a text file and then opened the resultant text file in my usual macOS text editor, the "funny" chars appeared as carons again, as in the original listing I linked to above.

But did you save it with Unicode enabled or disabled?

Both. Regardless of whether I've enabled or disabled Unicode in your SDL editor, when I save the tokenised program to disk as a text file and then open the text file in a native macOS text editor (I tried TextEdit and BBEdit), the CHR$255 chars all appear as carons. In BBEdit at least it doesn't seem to be possible to select ANSI as an encoding. (In fact, no matter which encoding I select in BBEdit, the chars (and the rest of the text) look the same!)

I'm not saying any of this is a problem, btw.

[Soruk]

Is it available somewhere as a tokenised BASIC file (other than in a disc image)?

Here you go:

• NELLAN.$.zip

EDIT: Ah, yes, having opened that tokenised BASIC file in your editor and run it, I can see that the graphics look right now.

EDIT2: This looks a bit weird though:


Screenshot 2020-01-17 at 14.47.04-.png


EDIT3: When I used your SDL BBCBasic editor to save the program out to disk again as a text file and then opened the resultant text file in my usual macOS text editor, the "funny" chars appeared as carons again, as in the original listing I linked to above.

I had similar problems in Matrix Brandy (sorry, not trying to hijack the thread), but again this tokenised version runs fine, and a Brandy-saved (text form) file shows the correct characters, no carons.

[Deleted User 9295]

when I save the tokenised program to disk as a text file and then open the text file in a native macOS text editor (I tried TextEdit and BBEdit), the CHR$255 chars all appear as carons.

What would you expect it to display as?! UTF-8 encoding is virtually universal these days, it's the standard multilingual encoding for the web and most other 'online' applications, and for Linux-based Operating Systems (which I'm guessing includes Mac OS). So if you have a 'text' file containing CHR$255, which is not a valid UTF-8 character, it's inevitably going to be misinterpreted. Of the mainstream OSes only Windows retains significant support for ANSI, in which CHR$255 is valid and displays as the ÿ character.

[Deleted User 9295]

a Brandy-saved (text form) file shows the correct characters, no carons.

What do you consider to be the the "correct" character? If you mean the ÿ character, that's what you get if the literal strings are interpreted as ANSI but not when interpreted as UTF-8. To what extent does Matrix Brandy support Unicode anyway?

[lurkio]

when I save the tokenised program to disk as a text file and then open the text file in a native macOS text editor (I tried TextEdit and BBEdit), the CHR$255 chars all appear as carons.

What would you expect it to display as?!

I didn't necessarily "expect" anything. I was merely reporting my observations. As I said above, I'm not saying that any of this is a problem.

[Soruk]

a Brandy-saved (text form) file shows the correct characters, no carons.

What do you consider to be the the "correct" character? If you mean the ÿ character, that's what you get if the literal strings are interpreted as ANSI but not when interpreted as UTF-8. To what extent does Matrix Brandy support Unicode anyway?

Right now, it doesn't support it at all. All characters are 8-bit entities, like on the Beeb and ARM BBC BASIC on RISC OS. For a typeable program, you would probably be better off refactoring those bits of code with literal CHR$(255) characters with CHR$(255) function calls, though not sure how you'd refactor the DATA statements as BBC BASIC allows DATA to have string entities without quote marks.

[Deleted User 9295]

Right now, it doesn't support it at all. All characters are 8-bit entities, like on the Beeb and ARM BBC BASIC on RISC OS.

I don't think the BBC Micro had any pre-defined character 'shapes' for the codes 128-255, they were reserved solely for being user-defined (with VDU 23) as I recall. Therefore the issue didn't really arise, effectively it used a 7-bit character encoding, not 8-bit (something not quite ASCII and not quite ISO-7-UK I think).

As usual, I know nothing about RISC OS. Did that extend the character set to 8-bits, and if so what encoding is used for codes 128-255? A standard encoding like ANSI or something unique to Acorn?

not sure how you'd refactor the DATA statements as BBC BASIC allows DATA to have string entities without quote marks.

It's probably safer to avoid characters outside the 7-bit ASCII range when omitting the quotes.

[Soruk]

Right now, it doesn't support it at all. All characters are 8-bit entities, like on the Beeb and ARM BBC BASIC on RISC OS.

I don't think the BBC Micro had any pre-defined character 'shapes' for the codes 128-255, they were reserved solely for being user-defined (with VDU 23) as I recall. Therefore the issue didn't really arise, effectively it used a 7-bit character encoding, not 8-bit (something not quite ASCII and not quite ISO-7-UK I think).

As usual, I know nothing about RISC OS. Did that extend the character set to 8-bits, and if so what encoding is used for codes 128-255? A standard encoding like ANSI or something unique to Acorn?

The Master certainly had all characters 128-255 defined, though 255 was a full square block. RISC OS is similar to Latin-1 but with some characters used as symbols for the windowing system - certainly RISC OS 2 made use of them. In this encoding, 255 is y-umlaut, and even the BBC could store high-bit values in strings, which were useful in MODE 7 storing control codes at &80-&9F and the square block at &FF - which is the character used here.

[Deleted User 9295]

The Master certainly had all characters 128-255 defined

OK, but I'm pretty sure the Model B didn't. Finding somewhere to put the pound sign whilst keeping the hash at its normal ASCII code was something that preoccupied the BBC in the very early days, and the MODE 7 musical chairs of £, # and — was interesting!

even the BBC could store high-bit values in strings

Only to a limited extent: it could break things. Try this on a BBC Micro (or compliant emulator):

Code: Select all

   10 IF FALSE PRINT "‹" ELSE PRINT "OK"

where the character in the first string is CHR$(139). Ideally it would run and print "OK" but in fact it fails with 'Syntax error at line 10'. I'm not sure when this particular 'feature' was fixed, but it meant one had to be careful when putting high-bit-set characters in strings.

[Soruk]

The Master certainly had all characters 128-255 defined

OK, but I'm pretty sure the Model B didn't. Finding somewhere to put the pound sign whilst keeping the hash at its normal ASCII code was something that preoccupied the BBC in the very early days, and the MODE 7 musical chairs of £, # and — was interesting!

even the BBC could store high-bit values in strings

Only to a limited extent: it could break things. Try this on a BBC Micro (or compliant emulator):

Code: Select all

   10 IF FALSE PRINT "‹" ELSE PRINT "OK"

where the character in the first string is CHR$(139). Ideally it would run and print "OK" but in fact it fails with 'Syntax error at line 10'. I'm not sure when this particular 'feature' was fixed, but it meant one had to be careful when putting high-bit-set characters in strings.

Interesting... it breaks on BeebEm in both Model B and Master mode - and on RISC OS BASIC V (1.16 - RISC OS 3.71 ROM) and VI (1.75 - Softloaded)! Perhaps it was never fixed.

(The "bug" is not implemented in Brandy, nor do I intend to do so!)

And yes, that MODE 7 musical chairs, I remember spotting that oddity to ensure my emulation was (reasonably) faithful to the BBC and RISC OS implementations!

[Deleted User 9295]

it breaks on BeebEm in both Model B and Master mode - and on RISC OS BASIC V (1.16 - RISC OS 3.71 ROM) and VI (1.75 - Softloaded)!

That's surprising. Really it should have been fixed before the character set was extended to 8-bits, when the presence of CHR$(139) in a literal string became more likely.

[Deleted User 9295]

For the record there are two 'built-in' bitmapped character sets in BBC BASIC for SDL 2.0: there's an 8x8 character set used normally in MODEs 0 to 6 and there's a 16x16 character set used in MODE 7 (if one isn't using a 'proper' teletext font like Bedstead) and user-defined modes specifying characters of this size or bigger:

[lurkio]

For the record there are two 'built-in' bitmapped character sets in BBC BASIC for SDL 2.0: there's an 8x8 character set used normally in MODEs 0 to 6 and there's a 16x16 character set used in MODE 7 (if one isn't using a 'proper' teletext font like Bedstead) and user-defined modes specifying characters of this size or bigger

In BBCSDL on Mac I opened the app package and found the OTF Bedstead fonts in the lib folder, but they weren't selectable in the Set Font dialog box in the BBCSDL IDE. So I converted the OTF Bedstead fonts to TTF and dropped the TTFs into the lib folder: now, the Bedstead TTF fonts can be selected from Set Font, but they only seem to apply to the text in the IDE editor window and not to any text printed in MODE7 by the running BASIC program in the program window. Is there any way to get the program window to use the Bedstead TTF fonts?

[Soruk]

For the record there are two 'built-in' bitmapped character sets in BBC BASIC for SDL 2.0: there's an 8x8 character set used normally in MODEs 0 to 6 and there's a 16x16 character set used in MODE 7 (if one isn't using a 'proper' teletext font like Bedstead) and user-defined modes specifying characters of this size or bigger:

Comparing the Matrix Brandy set (see my thread), the non-Teletext set is the same (character for character - font is a bit different in places!), excluding &80-&9F where RISC OS did something different. For MODE 7, Matrix Brandy follows RISC OS and the BBC. There are no character definitions for the control code areas.

[Soruk]

For the record there are two 'built-in' bitmapped character sets in BBC BASIC for SDL 2.0: there's an 8x8 character set used normally in MODEs 0 to 6 and there's a 16x16 character set used in MODE 7 (if one isn't using a 'proper' teletext font like Bedstead) and user-defined modes specifying characters of this size or bigger

In BBCSDL on Mac I opened the app package and found the OTF Bedstead fonts in the lib folder, but they weren't selectable in the Set Font dialog box in the BBCSDL IDE. So I converted the OTF Bedstead fonts to TTF and dropped the TTFs into the lib folder: now, the Bedstead TTF fonts can be selected from Set Font, but they only seem to apply to the text in the IDE editor window and not to any text printed in MODE7 by the running BASIC program in the program window. Is there any way to get the program window to use the Bedstead TTF fonts?

Take a look at the ceefax.bbc and telstar.bbc examples.

[lurkio]

Is there any way to get the program window to use the Bedstead TTF fonts?

Take a look at the ceefax.bbc and telstar.bbc examples.

Thanks!

[Deleted User 9295]

For MODE 7, Matrix Brandy follows RISC OS and the BBC.

So how does that differ from mine? I presume that Matrix Brandy has the same restriction as BBC BASIC for SDL 2.0, i.e. that pixels have to be 'square', so it's not possible to reproduce the MODE 7 font without using anti-aliasing (MODE 7 uses a 12 MHz 'pixel' clock compared with 8 MHz for MODEs 1 & 6 or 16 MHz for MODEs 0 & 3)? I chose the 16x16 font as being as close as I could reasonably get within that square-pixel restriction.

[Deleted User 9295]

found the OTF Bedstead fonts in the lib folder, but they weren't selectable in the Set Font dialog box in the BBCSDL IDE.

True. I didn't anticipate that anybody would want to use a teletext-style font for the editing pane of the IDE, so it lists only the TTF fonts.

Is there any way to get the program window to use the Bedstead TTF fonts?

I see that Soruk has provided the answer. BB4W and BBCSDL support TTF and OTF fonts (even proportional-spaced) via the *FONT command; Ceefax.bbc and telstar.bbc are complicated to some degree because they are designed to work in both dialects, and font-loading with the native Win32 API used by BB4W is somewhat different from that with the SDL2_ttf library used by BBCSDL.

[lurkio]

BB4W and BBCSDL support TTF and OTF fonts (even proportional-spaced) via the *FONT command; Ceefax.bbc and telstar.bbc are complicated to some degree because they are designed to work in both dialects, and font-loading with the native Win32 API used by BB4W is somewhat different from that with the SDL2_ttf library used by BBCSDL.

I found that if you make the following changes to my listing it will still work in BBCSDL and can also be pasted into BeebEm as a valid program (if you ignore the errors thrown by the unnumbered lines in immediate mode):

Code: Select all

   1 MODE7

     PROCbbc

  10 FORI%=0TO1:PRINTTAB(10,3+I%)CHR$141"NELLAN IS THIRSTY":NEXT:PRINT''TAB(5)CHR$134"Written by Dr Furman H Smith"'TAB(2)CHR$134"Published in Recreational Computing"'TAB(11)CHR$134"magazine in 1980"
   
     [...]
   
9350 NEXT:w2$(I%)=a$:NEXT:ENDPROC

     DEFPROCbbc
      REM!Embed @lib$ + "fnusing", @lib$ + "sortlib", @lib$ + "Bedstead-ext.otf"

      INSTALL @lib$+"fnusing"
      INSTALL @lib$+"sortlib"

      REM Test the OS platform and set the font:
      IF INKEY$(-256) = "W" THEN
       OS$ = "Windows"
       SYS "AddFontResource", @lib$ + "Bedstead-ext.otf"
       @vdu%!220 = -20
       IF INKEY$(-256) = "W" THEN *FONT Bedstead
       SYS "SetWindowText", @hwnd%, "Nellan Is Thirsty"
      ELSE
       OS$ = "SDL 2.0"
       OSCLI "FONT """ + @lib$ + "Bedstead-ext.otf"",16"
       @vdu%!220 = 20
       SYS "SDL_SetWindowTitle", @hwnd%, "Nellan Is Thirsty"
      ENDIF
     ENDPROC

[Deleted User 9295]

I found that if you make the following changes to my listing it will still work in BBCSDL and can also be pasted into BeebEm as a valid program

I don't suppose you need the sortlib or fnusing libraries, or the associated REM!Embed directives, to make it work. They have nothing to do with fonts.