🪲 Fixed: ByVal and ByRef keywords not working beyond the first argument

The recently added ByVal and ByRef keywords were only working of the first argument of a function/subroutine.

This new version of BAM now allows ByVal and ByRef on arguments beyond the first one.

🆕 IDE Config Backet-Matching Options

The 2024-07-01 Release of BAM added the two following features to the editor:

• Auto insertion of closing brackets
• Highlighting of matching brackets

Today's new version of BAM provides options to turn off one or both of the features.

Via the "Tools" menu, click on the "IDE Config" menu item.  This will open the "IDE Config" window.

Expand the "Coding Editor Configuration" details, and you'll find "Bracket-Matching Options" at the bottom of the group, where you can turn on/off the features via check boxes.

🪲 IDE Editor scrolling via keyboard up/down keys: Issue fixed

Latest version of BAM

This was an issue in BAM right from the outset (i.e. since December of 2021).

When programs get so long as to not fit the height of the editor, requiring scrolling up/down, the caret in the text editor would go up/down past the border of the editor to a line above/below the editor's border, requiring some extra presses of up/down keys before (or mouse-wheel, or click on scrollbar) to bring the desired part of the program into view.

I finally figured out today the CSS override needed for the editor to properly and automatically scroll when trying to move the caret past the top/bottom visible line of text in the editor.

To compare the before and after behaviour, put the opened latest version of BAM next to any previous version (like the archived 2024-02-05 version of BAM) and see how caret navigation (up and down keys) past the top/bottom lines of a long program works.

🎉 New version of BASIC Anywhere Machine

• Full details in the Release Notes
• Try out the latest version of BASIC Anywhere Machine
• Updated Programming Reference and User Guide
• Discuss BASIC Anywhere Machine:
• BAM Discord server
• BAM Reddit

Summary of updates

• BASIC Language Updates
• FOR-NEXT: Handling zero STEP values
• LET: Bug fix
• Line Numbers: Handling leading zeroes
• New EVAL Clause for GOTO, GOSUB, RESTORE
• GOTO syntax diagram
• GOSUB syntax diagram
• RESTORE syntax diagram

🎉 New release of BASIC Anywhere Machine

• Detailed Release Notes
• Latest version of BAM
• Previous version of BAM
• Docs

Summary

BASIC Language Updates

• New KEYSTATE function
• KEYCLEAR alternative to _KEYCLEAR
• DEF FN Enhancement

Preprocessor Updates

• Overriding TW WikiText Formatting
• TEST PROGRAM
• Consecutive apostrophes
• Consecutive spaces
• Consecutive forward slashes
• Consecutive underscores
• Consecutive carets
• Consecutive commas
• Consecutive tildes
• Consecutive Backticks
• Consecutive at signs
• Consecutive dashes

🎉 New version of BASIC Anywhere Machine

• Release Notes
• Latest version of BAM

Summary

• BASIC Language Updates
• New RemoveLocalStorageItem statement
• New NVL$ function
• Program Console Window
• Mouse Click: distinguishing left vs right mouse button click
• IDE Updates
• IDE Config: New "Font for Menus/Windows/Dialogs" setting
• Reimplemented: Program "extra view windows"

🆕 ON ... RESTORE

Latest version of BAM

ON ... RESTORE sets the DATA-READ pointer to one of many specified line identifiers using a specified index.

Syntax

• indexValue
  • a value that indicates the position of the line identifier to use for branching
  • a "1" causes branching with the first line identifier
  • a "2" causes branching with the second identifier
  • etc.
• lineIdentifier
  • at least one instance, normally many
  • as many instances as there are possible index values (1 to 1)
  • each instance is one of the Line Identifier types (line number or line label)

🎉 New version of BASIC Anywhere Machine

Full details in the release notes.

• New version of BAM

• Previous release notes

• Discuss: BAM Reddit or BAM Discord

Summary of enhancements

• BASIC Language Updates
• DATA statement enhancement
• TAB behaviour change
• IDE Updates
• Program "extra view windows"

🎉 New version of BASIC Anywhere Machine

Full details in the release notes.

• New version of BAM
• Updated documentation

• Previous version of BAM
• Previous release notes

• Discuss: BAM Reddit or BAM Discord

Summary of enhancements

• BASIC Language Updates
• Statements and Functions
• New xMAX and yMAX functions
• New SCREEN_ASPECT function
• New "DONOTHING" statement
• New OPTION _EXPLICIT
• New RGB Color functions
• CIRCLE Enhancements
• CIRCLE performance improvement (Phase 1)
• CIRCLE "Thick" option
• LINE
• LINE "TO" alternative for "-"
• LINE: Syntax documentation correction
• Rgba include libraries
• READ ME: Important Rgba Notes
• New "Rgba" statements
• RgbaBox
• RgbaCircle
• RgbaLine
• Internal technical details
• Graphics coordinates: Dealing with decimal numbers
• IDE Updates
• Touch Device: Change to "overscroll" behaviour
• BAM Appearance: New "Palette Settings"
• SUGGESTION when configuring BAM

🪲 PSET: Fixed issue with "out-of-bounds" coordinates

Described above is the issue with PSET before today's new version of BAM.

First, a little technical overview about putting text/graphics on the screen.

Any PRINT/PSET/LINE/CIRCLE/etc. does not actually do anything to the running program's screen.

Print, PSET, CIRCLE, etc.: all statements that put things on the screen, they actually put related data (the colour of affected pixels) into a one-dimensional array, each cell representing a coordinate on the screen.

The goal of doing this?  Performance.  Refreshing the screen is time-consuming.  By only updating the array, screen refresh can be delayed until it makes sense.

Description of the issue

Let's imagine a screen four pixels wide by three pixels tall:

The related array for storing the colour of each pixel:

For every PSET(x,y), the colour value will go into the array's cell number that results from the formula: x + y * screen_width = x + (y * 4).  So say we want to set the pixel colour at screen position (3,1) to (say) yellow, that value would go into array cell 3 + 1 * 4 = 7 (so cell 7 in the array).

Say our program involves an animation (a flying "dot"), and our program thinks that the dot ought to go from screen position (3,1) to (4,1).  Screen position 4,1 would mean array cell 4 + 1 * 4 = 8.  But when the screen is refreshed, the value in cell 8 will be applied to screen coordinate (0,2).

In the new version of BAM, if any coordinate (x, or y, or both) is outside of the boundaries of the screen, then the PSET is completely aborted.  So PSET (4,1), with the screen example above, will not happen.

🪲 RGBAPSET: fixed issue causing BLUE to be ignored

 All because of a typo in a variable name.  Arg!

The statement was handling the red and green components of RGB colours just fine, but was completely ignoring the BLUE component.

That is now fixed in the latest version of BASIC Anywhere Machine.

🪲 CIRCLE, LINE, PAINT: "default colour" issue fixed

Update 2023-08-28: The latest version of BASIC Anywhere Machine fixes the issue described below.

When we don't specify a colour for any of those three statements, the colour used ought to be the foreground colour specified with the COLOR statement.

If a foreground colour has not been specified with the COLOR statement, then the default foreground colour for the screen mode ought to be used.

Well until today, I never noticed that, regardless of foreground colour specified with the COLOR statement, the original wwwBASIC code always chooses the default foreground colour of the screen current screen mode when no colour is specified for any of CIRCLE, LINE, and PAINT.

In the screenshot above, the rectangle and both circles should be yellow, just like the text.

If you want to experience this first hand, try out your own tests in the current version of BAM.

I've got a fix for the problem which I'm testing.  I should have that rolled out in a new version of BAM sometime within the next couple of days.  If you want to try the fixed version: the development version of BAM.

Screenshot of the same program in the development version of BAM:

🆕 RGBAPSET and 🧼 Consecutive Commas

 Latest version of BASIC Anywhere Machine.

🆕 RGBAPSET

The RGBAPSET graphics statement sets a pixel at a specified coordinate to a specified alpha-blending of the already colour at the coordinate with a specified colour. The alpha value (0-255) determines the transparency of the specified colour (0 is completely transparent, as in no change to the already existing colour, and 255 is completely opaque, as in the already existing colour is entirely replaced.

• x%
• y%
• rgbColour&
  • A long integer
  • A value representing an rgb colour
• alpha%b
  • A "byte" integer (i.e. value between 0 and 255)
  • 0 indicates 100% transparent, meaning the new colour will be 100% the already existing colour
  • 255 indicates 100% opaque, meaning the new colour will be 100% rgbColour&
  • any in-between value will indicate the weight of rgbColour& (the weight of the already existing colour will be 255 - alpha%b)

🧼 Consecutive Commas

Previously, BAM programs would fail when a program had any consecutive commas, requiring the programmer to make sure to separate commas by one or more spaces.

Now, the pre-processor handles consecutive commas by automatically inserting a space between consecutive commas.

For example, the following statement would get mangled by the pre-processor (causing a program to fail):

CIRCLE (100,100), 25, 14,,,,F

The pre-processor would convert that statement to:

CIRCLE (100,100), 25, 14F

Bad BAM. Bad.

Today's version of BAM, during pre-processing, takes a statement like:

CIRCLE (100,100), 25, 14,,,,F

And convert it to:

CIRCLE (100,100), 25, 14, , , ,F

⚗ Testing: POLYGON macro and support library

This version of BASIC Anywhere Machine inclues the POLYGON macro (see related blog entry.) 

Please note that this is just for prototyping, and will eventually be removed from BAM once the equivalent statement is developed in an include library.

🆕 _MOUSEZONE function

Latest version of BASIC Anywhere Machine.

Test program:

• Run
• View

Description:

The _MOUSEZONE function checks whether or not the mouse pointer is in the defined "zone", the area specified by the top-left corner coordinates, the width, and the height parameters.

Syntax

• return value
  • -1 if TRUE (i.e. mouse pointer is in the defined area)
  • 0 if FALSE
• x%
  • horizontal pixel position of the area's top-left corner
• y%
  • vertical pixel position of the area's top-left corner
• width% (optional)
  • the pixel width of the area
  • if not specified, then assumed to be 1
• height% (optional)
  • the pixel width of the area
  • if not specified, then assumed to be 1
• width% and height% must
  • both be specified
  • OR: both not be specified

🆕 _AUTODISPLAY and ❇ _DISPLAY

_AUTODISPLAY

Although BASIC Anywhere Machine ignores the statement, it does recognise it when encountered as a valid QB64PE statement.  This is part of a longterm effort to get QB64PE programs running in BASIC Anywhere Machine (as much as possible) as is (without too much futzing about to get a program running.)

_DISPLAY

Modified so that when encountered, it actually causes a program to pause just long enough (a micro-fraction of a millisecond) to trigger a screen refresh.

🆕 _D2R

In the effort to make BASIC Anywhere Machine reasonably compatible with QB64pe:

The _D2R function converts a degree value into a radian value.

🆕 LPRINT

BASIC Anywhere Machine, being browser-based,  cannot implement output to hardware devices like traditional/installed BASIC implementations can.

However, can implement related BASIC statements in a way that maintains compatibility with the original intent of those statements, providing BAM with useful functionality that does work within the confines/constraints/rules of web browsers.

LPRINT has entered the building...

This first implementation of LPRINT keeps it simple by not allowing a list of expressions as normally typical in any BASIC:

LPRINT takes the string resulting from an expression and outputs that string to a text file. The string can contain a very large number of characters.

Syntax

LPRINT string_expression

• string_expression
  • this can be as simple as a string literal or a string variable, or a string expression of whatever complexity

🪲 Interface to the Web Audio API (beep, sound)

 A strange bug I noticed tonight, which started I don't know when.

In trying to figure out what recent change to BASIC Anywhere Machine caused the problem, I dug out an older version of BASIC Anywhere Machine that had no issues with audio, and I discovered the problem there, too.

The strange problem: the first sound played in a program via either BEEP or sound does not happen.

And subsequent sounds will only happen if the first failed sound played for at least half a second, the BEEP/SOUND statement immediately followed by a _DELAY of at least half a second to seemingly give Web Audio a chance to kick in.

Something like that.

This may only be an issue on my Chromebook and a recent update to either Chrome or Chrome OS.

As a workaround to the problem, I've setup the interpreter to not run any BASIC program until after a half-second delay, during which the interpreter "initialises" web audio.

Something like that.  Not easy to coherently explain what is going on when I can't make heads of tails of it.

So audio in BAM fixed for my device.  Now I have to find a way to see if other devices are fine.

🆕 POINT

 The POINT function returns the pixel COLOR attribute at a specified graphics coordinate.

Syntax

POINT (x,y)

x	the horizontal coordinate on the screen, which is an integer number, one of: a literal integer, an integer variable, or a numeric expression resulting in an integer
y	the horizontal coordinate on the screen, which is an integer number, one of: a literal integer, an integer variable, or a numeric expression resulting in an integer

BAM's implementation or POINT is partially compatible with both GW-BASIC and QB64PE.

In GW-BASIC and QB64, the POINT function has two syntax forms: the first returns the pixel color attribute at a specified graphics coordinate, and the second syntax returns the pixel color at the current graphic cursor position.

As per the GW-BASIC User's Guide:

Purpose:

To read the color or attribute value of a pixel from the screen.

Syntax:

POINT(x,y)

POINT(function)

Comments:

In the first syntax, x and y are coordinates of the point to be examined.

If the point given is out of range, the value -1 is returned.

POINT with one argument allows you to retrieve the current graphics coordinates.

POINT(function) returns the value of the current x or y graphics coordinates as follows:

Function	Returns
0	the current physical x coordinate.
1	the current physical y coordinate.
2	the current logical x coordinate if WINDOW is active; otherwise, it returns the current physical x coordinate as in 0 above.
3	the current logical y coordinate if WINDOW is active; otherwise, it returns the current physical y coordinate as in 1 above.

🆕 _DISPLAY and _LIMIT and ❇ _NEWIMAGE

_DISPLAY and _LIMIT

Although BASIC Anywhere Machine ignores these statements, it does recognise them at runtime as valid QB64PE statements.  This is part of a longterm effort to get QB64PE programs running in BASIC Anywhere Machine (as much as possible) as is (without too much futzing about to get a program running.)

I'm thinking I might never get around to fully implementing these statements in BASIC Anywhere Machine.  I do, however, allow myself to change my mind ...

_NEWIMAGE

BASIC Anywhere Machine still only has this as a parameter for the SCREEN statement.

So partial compatibility with QB64PE.  In QB64PE, _NEWIMAGE is a function, with a return value that can provided to the SCREEN statement directly or via a variable that gets set to the return value of the function.

Today's new version of BASIC Anywhere Machine allows a little bit more compatibility with QB64PE.  BAM was allowing only screen modes in _NEWIMAGE's third parameter.  Now, the third parameter also allows one of the following values:  256 or 32.

Although this helps running QB64PE programs as-is in BAM, BAM converts both of the values 256 and 32 to 21 (screen mode 21), resulting in 32 bit (16 million colors).

I might eventually get around to setting up a 256 color mode in BAM if and when it becomes a hot request.

For now, I think this is good enough.