BBC BASIC for SDL 2.0 version 1.32a released

[Deleted User 9295]

Ctrl+Cmd+Left bongs and prints 128, and Ctrl+Cmd+Right bongs and prints 129 (no matter which of the two Cmd keys I use).

The actual codes are unimportant, what matters is that a keypress event is generated. Knowing that, I can modify BBC BASIC to generate whatever code seems to be most appropriate. Since Cmd+left is equivalent to Home and Cmd+right to End on a PC keyboard, my intention would be that Ctrl+Cmd+left will generate the same code as Ctrl+Home and Ctrl+Cmd+right the same as Ctrl+End.

Would you be kind enough to repeat the test with the Fn key. Do Fn+left, Fn+right, Fn+up and Fn+down generate any codes in BBC BASIC at all?

[lurkio]

Would you be kind enough to repeat the test with the Fn key. Do Fn+left, Fn+right, Fn+up and Fn+down generate any codes in BBC BASIC at all?

Yes: 130, 131, 132 and 133 respectively.

Incidentally, I can't seem to get the IDE to run programs that use keyword abbreviations, such as your example: REP.P.GET:U..

The program window just says "Mistake" (or "Mistake at line 10"). What am I doing wrong?

[Deleted User 9295]

What am I doing wrong?

You're not doing anything wrong. BBC BASIC for Windows has a configuration option to allow or disallow keyword abbreviations in the editor, but realistically you must always disable them otherwise they clash with the syntax for structure members (if you put R.a meaning 'member a' of 'structure R' it's not at all helpful if the R. is expanded to RETURN!). So when it came to writing SDLIDE I simply decided not to support keyword abbreviations at all.

You can still use abbreviations in immediate mode, because of course that's a function of the interpreter's parser/tokeniser and completely independent of the editor. The possibility of a reference to a structure member being mistaken for a keyword abbreviation still arises, but you're pretty unlikely to be wanting to do that in immediate mode.

[BigEd]

Oops, I do apologise - I had of course downloaded the correct version and then opened a previous download. Even though I'd tried to be careful.

I can confirm lurkio's observations above, including the presence or absence of bongs: 128,129, and 130, 131, 132, 133.

[Deleted User 9295]

Yes: 130, 131, 132 and 133 respectively.

That leaves me rather confused again (an almost continuous state, I'm afraid). In an earlier reply you wrote "Then there's Cmd+left_arrow, which should move the cursor to the beginning of the current line. And Cmd+right_arrow to move to the end thereof" which I understood to mean that they are equivalent to the Home and End keys on a standard PC keyboard (because that's what those keys generally do).

But Home and End generate codes 130 and 131 in Windows which would make me think that Fn+left and Fn+right are the Mac equivalents, not Cmd+left and Cmd+right! So what are the most common functions of those four keyboard shortcuts on Macs? Two of them are seemingly move to the beginning and end of the current line (which two?) but what do the others do?

Edit: This is perhaps relevant.

[Deleted User 9295]

Edit: This is perhaps relevant.

From that linked page: “Well, we only added those keys to keep PC users happy. Let’s really mess with them. We don’t need to make them happy, we’ve got truckloads of brain-washed fanboy to keep our User satisfaction numbers up”.

[lurkio]

Yes: 130, 131, 132 and 133 respectively.

That leaves me rather confused again (an almost continuous state, I'm afraid). In an earlier reply you wrote "Then there's Cmd+left_arrow, which should move the cursor to the beginning of the current line. And Cmd+right_arrow to move to the end thereof" which I understood to mean that they are equivalent to the Home and End keys on a standard PC keyboard (because that's what those keys generally do).

But Home and End generate codes 130 and 131 in Windows which would make me think that Fn+left and Fn+right are the Mac equivalents, not Cmd+left and Cmd+right! So what are the most common functions of those four keyboard shortcuts on Macs? Two of them are seemingly move to the beginning and end of the current line (which two?) but what do the others do?

I never use Fn+Left, Fn+Right, Fn+Up or Fn+Down. In TextEdit (the native "built-in" macOs text editor), they don't perform any function: they don't move the cursor, and nor do they bong. In the BBCSDL IDE, they seem to move the cursor to the beginning of the line, to the end of the line, to the beginning of the document, and to the end of the document, respectively. When typed into the BBCSDL BASIC program REP.P.GET:U.. in immediate mode, they print key codes 130, 131, 132 and 133 respectively.

I frequently use Cmd+Left and Cmd+Right to move to the beginning and end of the current line in multiple macOS apps. I less frequently use Cmd+Up and Cmd+Down to move to the beginning and end of a document. When typed into the BBCSDL BASIC program REP.P.GET:U.. in immediate mode, Cmd+Left, Cmd+Right, Cmd+Up and Cmd+Down print the key codes 136, 137, 139 and 138 respectively.



EDIT: Ah, and now we have a problem! When typed into the BBCSDL BASIC program REP.P.GET:U.. in immediate mode, Alt+Left, Alt+Right, Alt+Up and Alt+Down also print key codes 136, 137, 139 and 138 respectively! The same as the Cmd+ equivalents! But in "standard" macOS apps, the Cmd+direction keys perform different functions from the Alt+direction keys! (Alt+Left/Right=back/forward one word. Alt+Up/Down=Go to beginning/end of line.) Oh dear...

[BigEd]

(I just plugged in a USB keyboard and can confirm that TextEdit doesn't respond to Home, End, PgUp and PgDn either. So, that's a native Apple application, and it doesn't use those keys. But Terminal uses them to scroll... so they are known to at least on native application. But not as synonyms for ctrl-Cmd-Left, etc.)

[lurkio]

EDIT: Ah, and now we have a problem! ...

Or maybe not...

The actual codes are unimportant, what matters is that a keypress event is generated. Knowing that, I can modify BBC BASIC to generate whatever code seems to be most appropriate.

[Deleted User 9295]

I never use Fn+Left, Fn+Right, Fn+Up or Fn+Down. In TextEdit (the native "built-in" macOs text editor), they don't perform any function.

OK, but I think that probably makes TextEdit an 'outlier'. It's pretty clear from the codes they generate that Fn+Left, Fn+Right, Fn+Up and Fn+Down are intended to be direct equivalents of the Home, End, PgUp, and PgDn keys on a standard PC keyboard (and in the case of the first two this is confirmed by Apple themselves here). You would expect a text editor to respond to those, and my SDLIDE editor does.

Where the complication arises appears to be that Macs and PCs define Home and End differently, by default. On PCs Home and End are 'move to the beginning or end of the line' but on Macs they are 'move to the beginning or end of the document' (again that is confirmed here).

So (short of a configuration option, which I really don't like) I'm not going to be able to please everybody, because I want Home and End to work consistently in SDLIDE across all platforms. In practice that means I want them to work as they do in Windows (beginning and end of line) and from the page I linked to it's pretty clear that people who have moved from a PC to a Mac want that too.

So that determines what FN+left and FN+right will (and indeed already) do in SDLIDE: move to the beginning and end of the line. But that leaves some unanswered questions: principally what should Cmd+left and Cmd+right do, and what keyboard shortcuts on a Mac should move to the beginning and end of the document?

For maximum compatibility and minimum irritation one option would be to make Cmd+left and Cmd+right do the same as Fn+left and Fn+right (even though that feels like a wasteful duplication) and Cmd+up and Cmd+down move to the beginning and end of the document.

[lurkio]

I never use Fn+Left, Fn+Right, Fn+Up or Fn+Down. In TextEdit (the native "built-in" macOs text editor), they don't perform any function.

OK, but I think that probably makes TextEdit an 'outlier'.

Not really. I'm pretty sure that most "native" Mac apps that allow you to edit text behave in the same way in this respect. Certainly BBEdit does, and that's a very popular code editor on the Mac (if not the most popular).

So (short of a configuration option, which I really don't like) I'm not going to be able to please everybody, because I want Home and End to work consistently in SDLIDE across all platforms. In practice that means I want them to work as they do in Windows (beginning and end of line) and from the page I linked to it's pretty clear that people who have moved from a PC to a Mac want that too.

Fair enough.

For maximum compatibility and minimum irritation one option would be to make Cmd+left and Cmd+right do the same as Fn+left and Fn+right

I think that's the right thing to do. Cmd+Left and Cmd+Right are very commonly used to move the cursor to the beginning and the end of the current line -- certainly by me!

Cmd+up and Cmd+down move to the beginning and end of the document.

Seems fine.

Also, hopefully Alt+Left and Alt+Right can be made to move the cursor back and forward by one word in the BBCSDL IDE?

[Deleted User 9295]

Not really. I'm pretty sure that most "native" Mac apps that allow you to edit text behave in the same way in this respect.

I still think that anything that calls itself a 'text editor' should respond to keys labelled Home and End (e.g. when using a standard PC keyboard with a Mac Mini) and Apple themselves acknowledge that Fn+left and Fn+right are the direct equivalents of those on a Mac keyboard. Perhaps some of the apps you refer to are so old that they existed before the first Mac Mini, and therefore never encountered those keys.

Also, hopefully Alt+Left and Alt+Right can be made to move the cursor back and forward by one word in the BBCSDL IDE?

As I mentioned before, that's an entirely separate issue. I can safely modify how the Cmd+ key combinations work on a Mac because you can't use the equivalent ('Windows') key that way on a PC anyway, so there is no compatibility issue. However I cannot modify how the Alt+ key combinations behave because that would affect every platform and introduce an incompatibility.

So making Alt+left and Alt+right do word-left and word-right is something that will need to be achieved within the confines of SDLIDE (indeed I have already made that change in my copy) rather than in the 'interpreter'.

[lurkio]

So making Alt+left and Alt+right do word-left and word-right is something that will need to be achieved within the confines of SDLIDE (indeed I have already made that change in my copy) rather than in the 'interpreter'.

Great! I look forward to trying it out.

[lurkio]

I never use Fn+Left, Fn+Right, Fn+Up or Fn+Down. In TextEdit (the native "built-in" macOs text editor), they don't perform any function: they don't move the cursor, and nor do they bong.

Correction! In both TextEdit and BBEdit, Fn+Up performs a Page Up (but doesn't move the cursor), Fn+Down performs a Page Down (but doesn't move the cursor), Fn+Left moves the scrollbar to the beginning of the document (but doesn't move the cursor), and Fn+Right moves the scrollbar to the end of the document (but doesn't move the cursor).

Nevertheless, I still agree with you when you say this:

So that determines what FN+left and FN+right will (and indeed already) do in SDLIDE: move to the beginning and end of the line.

[Deleted User 9295]

Correction! In both TextEdit and BBEdit, Fn+Up performs a Page Up (but doesn't move the cursor), Fn+Down performs a Page Down (but doesn't move the cursor), Fn+Left moves the scrollbar to the beginning of the document, and Fn+Right moves the scrollbar to the end of the document.

That's much more what I expected, and is consistent with Apple's own documentation (and that Home and End by default have different actions in Windows and MacOS). So there may be a few BBC BASIC users who are irritated that those two keys (or equivalently Fn+left and Fn+right) behave differently from what they are used to on a Mac, but cross-platform applications have to confront that sort of issue, and there are evidently plenty of users who have switched from a PC to a Mac who prefer them to work the Windows way anyway.

[Deleted User 9295]

For maximum compatibility and minimum irritation one option would be to make Cmd+left and Cmd+right do the same as Fn+left and Fn+right (even though that feels like a wasteful duplication) and Cmd+up and Cmd+down move to the beginning and end of the document.

OK, change made and will be in the next release. Also perhaps worth mentioning that you can in addition hold down the Shift key to do select to start of line, select to end of line, select to start of document and select to end of document (bearing in mind that 'vertical' selections are whole lines only). Similarly you can hold down Shift with Alt+left and Alt+right to select words.

[Soruk]

BTW, according to my observation, without dumping events, Fn left and right are Home and End, whereas Fn up and down are Prev and Next Page. I use these often.

The Fn key is not recognised by SDL 2.0 so its existence is entirely hidden from me and I can't take any action on a key combination which uses it. I can try asking at the SDL forum whether there's a workaround, but otherwise it's out of my hands.

In my experience (Linux laptop, x86-64 and x86-32), the Fn key sends no signal on its own, but is used in conjunction with other keys to send the keycodes of the key being simulated. For example,. on my netbook, FN-Up is Page Up and FN-Down is Page Down. They send the same X scancodes as a normal desktop PgUp and PgDn respectively and thus indistinguishable. (My miniature USB wireless keyboard even has Fn+Enter send CTRL+Alt+Del.) It also goes without saying that FN+key combinations tend to be very manufacturer - and even keyboard - specific.

[Deleted User 9295]

the Fn key sends no signal on its own, but is used in conjunction with other keys to send the keycodes of the key being simulated.

That's my understanding too, but as I don't have a 'proper' Mac with a Fn key I can't put it to the test. Therefore making Cmd+left and Cmd+right (which I can test) have the same effect as Fn+left and Fn+right I can eliminate any uncertainty.

[Deleted User 9295]

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

1. BASIC Interpreter / Run Time Engine
   
   Cmd+left, Cmd+right, Cmd+up and Cmd+down are mapped to Home, End, Ctrl+Home and Ctrl+End, respectively, for improved compatibility with Apple Macs.
   
   In the in-browser edition *RUN now runs JavaScript code (previously it did nothing useful) e.g.

   Code: Select all

    OSCLI "window.open(""http://www.rtrussell.co.uk"")"

   The QUIT n statement can now accept a parameter of zero (ARM and 64-bit editions only, 32-bit x86 editions always could).
   
   A few performance optimisations have been carried out (e.g. fixing memory alignment issues).
   
   
2. IDEs and Utilities
   
   In SDLIDE.bbc Alt+left and Alt+right are mapped to Word Left and Word Right, respectively, for improved compatibility with Apple Macs.
   
   Added a -P command-line switch to SDLIDE.bbc to activate the profiler.
   
   The Android and iOS editions report if a later version is available.
   
   
3. Libraries
   
   Changed gleslib.bbc and ogllib.bbc to call glLightfv by address rather than name.
   
   
4. Example Programs
   
   Added Newton's Cradle simulation (cradle.bbc in examples/physics).
   
   Bundled the set of instructive Box2D demos in examples/physics/samples (these all use Debug Draw graphics).
   
   Updated sudoku.bbc to add Tidy and New Game options (the difficulty of the generated game is very variable!).

This 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, Android, iOS, 64-bit Linux and in-browser editions, currently).

[lurkio]

Cmd+left, Cmd+right, Cmd+up and Cmd+down are mapped to Home, End, Ctrl+Home and Ctrl+End, respectively, for improved compatibility with Apple Macs.

Thank you! Amazing how much of a difference it makes to be able to rely on Mac-like muscle-memory rather than tripping up every time and having to consciously switch context from macOS edit-keys to Windows ones whenever I launch the BBCSDL IDE!

In SDLIDE.bbc Alt+left and Alt+right are mapped to Word Left and Word Right, respectively, for improved compatibility with Apple Macs.

That's great too! You don't realise how much you take these affordances for granted, and how jarring it is when they don't work (regardless of which OS behaviours you're switching from and to). Speaking of which...

Please don't hate me for mentioning this (!) but is there any chance you could make Alt+Backspace delete the word to the left of the cursor and Alt+Delete delete the word to the right? Sorry for not mentioning these key-combos earlier, but I was completely unaware that I used them! It's only when I started using the BBCSDL IDE more "naturally" ("Maccily"), just now, that I discovered (a) that I do in fact use those key-combos, and (b) that they don't work in BBCSDL! No rush or urgency, obviously. And no worries if you ultimately decide not to recognise these key-combos at all.

[Deleted User 9295]

is there any chance you could make Alt+Backspace delete the word to the left of the cursor and Alt+Delete delete the word to the right?

Currently it's not just that those shortcuts don't work, there are no existing delete-word-left and delete-word-right operations in SDLIDE to map those shortcuts to! So they would have to be coded from scratch, not necessarily difficult but more work than just adding a new shortcut.

However I notice, somewhat to my surprise (since I never use them myself), that BBC BASIC for Windows does implement Ctrl+Backspace and Ctrl+Delete for those operations so there is indeed an argument that they should be implemented in SDLIDE too.

[Deleted User 9295]

Please don't hate me for mentioning this (!) but is there any chance you could make Alt+Backspace delete the word to the left of the cursor and Alt+Delete delete the word to the right?

Can I just check that these are definitely Alt+Backspace and Alt+Delete not Cmd+Backspace and Cmd+Delete. I ask because Google finds more references to the latter than the former. Although I could implement the Alt+ shortcuts you've asked for, I don't know how to implement the Cmd+ equivalents because that has to be done at a different place (in the interpreter rather than in SDLIDE) and there are literally no spare keycodes available for them.

[lurkio]

Please don't hate me for mentioning this (!) but is there any chance you could make Alt+Backspace delete the word to the left of the cursor and Alt+Delete delete the word to the right?

Can I just check that these are definitely Alt+Backspace and Alt+Delete not Cmd+Backspace and Cmd+Delete. I ask because Google finds more references to the latter than the former. Although I could implement the Alt+ shortcuts you've asked for, I don't know how to implement the Cmd+ equivalents because that has to be done at a different place (in the interpreter rather than in SDLIDE) and there are literally no spare keycodes available for them.

Alt+Backspace/Delete deletes the word to the left/right, whereas Cmd+Backspace/Delete deletes everything from the cursor to the beginning/end of the current line.

If it's a choice between implementing Alt+Backspace/Delete or Cmd+Backspace/Delete, I'd probably vote for the former because I think I delete by the word more often than I delete to the start/end of a line. (Although, as I've demonstrated, I'm not exactly the most reliable witness to my own behaviour here..!)



EDIT: Cmd+Delete doesn't seem to be universally accepted by all Mac apps: it doesn't seem to do anything (but "bong") in TextEdit and in Pages, for example, but it works in BBEdit (to delete everything from the current position of the cursor to the end of the current line).

[Deleted User 9295]

Alt+Backspace/Delete deletes the word to the left/right, whereas Cmd+Backspace/Delete deletes everything from the cursor to the beginning/end of the current line.

OK. One of the references I found was this for Quark, but perhaps it's non-standard.

[Deleted User 9295]

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

1. BASIC Interpreter / Run Time Engine
   
   An experimental build for the 64-bit Raspberry Pi OS has been added (with many thanks to Simon Willcocks who wrote the AArch64 assembler which made it possible). This runs more than twice as fast as the 32-bit Pi OS edition!
   
   On a MODE change, the window will be centered only if it would otherwise extend beyond the edge of the desktop.
   
   If SDL's message system is unavailable (which it currently is on 64-bit Pi OS), fatal errors will be reported in a MODE 7 window.
   
   
2. IDEs and Utilities
   
   Extended SDLIDE.bbc so Ctrl+Backspace is delete word left and Ctrl+Delete is delete word right. Alt (Option) may be used instead of Ctrl, for compatibility with Apple Macs.
   
   Extended the Cross Reference utility to report mismatched quotes, parentheses and braces.
   
   Fixed a couple of minor bugs in the Cruncher, one of which could cause the output file to be larger than it needed to be.
   
   Updated BBCEdit to version 0.38.1, with thanks to Andy Parkes.
   
   
3. Libraries
   
   Added msgbox.bbc which provides support for Message Boxes, similar to those available in Windows.
   
   Updated filedlg to save and restore the VDU state (e.g. colours, viewports).
   
   Updated the Box2D libraries to be compatible with the 64-bit Raspberry Pi OS.
   
   Extended sdldebug.bbc and timerlib.bbc to include a 64-bit ARM (AArch64) version of the assembler code.
   
   
4. Example Programs
   
   Extended hello.bbc to include a 64-bit ARM (AArch64) version of the assembler code.
   
   Simplified telstar.bbc by using the built-in MODE 7 font in BBCSDL (and MODE7LIB in BB4W).
   
   Updated several examples to replace SDL's message boxes with BBC BASIC-created ones.

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

[Deleted User 9295]

I've ported David Williams's little SubZapII game to BBC BASIC for SDL 2.0, it looks and behaves virtually identically to the original. Here's a video of David playing it himself:



https://www.youtube.com/watch?v=lPrqBjzfmfA

It will run on any supported desktop platform (a keyboard is required) or in a suitable browser here.

[Deleted User 9295]

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

1. BASIC Interpreter / Run Time Engine
   
   Implemented GCOL modes 5-7 (in the web edition these are approximated by the closest available blend modes).
   
   Relative plot commands (e.g. DRAW BY x,y) no longer discard the LS bit of the offsets.
   
   Fixed a memory leak which could occur if you incompletely initialise a string array from a list of literals.
   
   Added macros to support CPUs having strict alignment requirements (e.g. the ARM Cortex-M0+).
   
   Updated Emscripten to version 2.0.5 (still old, but recent versions won't run BBC BASIC owing to an SDL threading deadlock).
   
   
2. IDEs and Utilities
   
   SDLIDE now captures the mouse while dragging, to avoid an anomaly that could result if the drag continued beyond the edge of the window. Also fixed another bug affecting dragging.
   
   Fixed Alt+F X (keyboard shortcut for Exit) not working in SDLIDE (oops!).
   
   
3. Libraries
   
   Updated ellipse.bbc to support GCOL modes 5-7.
   
   
4. Example Programs
   
   There are no changes to the example programs in this release.

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

[Soruk]

Interesting, until now I didn't know GCOL numbers went above 4!

Looking at http://www.riscos.com/support/developer ... phics.html I see the definitions, but is my reading of GCOL 5,c right that it makes graphic operations that plot pixels a no-op?

[Deleted User 9295]

Interesting, until now I didn't know GCOL numbers went above 4!

Nor did I until fairly recently, I'm not sure when they were introduced.

but is my reading of GCOL 5,c right that it makes graphic operations that plot pixels a no-op?

My understanding is based on what Jonathan wrote here which is indeed that GCOL 5 is a no-op. This is presumably useful if you are passing the GCOL mode as a parameter to some multi-purpose plotting code which you sometimes want to do nothing. This is the mapping I use from GCOL number to OpenGL LogicOp:

Code: Select all

        GCOL 0 - GL_COPY
        GCOL 1 - GL_OR
        GCOL 2 - GL_AND
        GCOL 3 - GL_XOR
        GCOL 4 - GL_INVERT
        GCOL 5 - GL_NOOP
        GCOL 6 - GL_AND_INVERTED
        GCOL 7 - GL_OR_INVERTED

[Soruk]

Interesting, until now I didn't know GCOL numbers went above 4!

Nor did I until fairly recently, I'm not sure when they were introduced.

but is my reading of GCOL 5,c right that it makes graphic operations that plot pixels a no-op?

My understanding is based on what Jonathan wrote here which is indeed that GCOL 5 is a no-op. This is presumably useful if you are passing the GCOL mode as a parameter to some multi-purpose plotting code which you sometimes want to do nothing.

Thank you for this. It's at times like this I'm rather glad I reworked much of the graphics to use a single plot_pixel function (back when I implemented action codes 1-4) as it turned out quite simple to implement with a couple of new CASE entries and a fast-return at the top if action = 5.