Commander X16

Hi,

A somewhat simplified description of how BASLOAD parses a line:

- Check if the start of the line contains a label definition, i.e. possible white space, followed by a label name, ending with a colon. If so, don't copy it to the output stream

- If the previous token on the line was GOTO, GOSUB, THEN or RESTORE, check if the next char is start of label. If so store the line number to the output stream.

- If it wasn't a label after GOTO and friends, check if it is the start of token. If so look up the token ID and store it in the output stream

- If none of the above, copy the char from the input stream to the output stream

So it should have just copied the label name to the output. But as you observed, there is a bug.

I tried to fix that. It should result in a SYNTAX ERROR.

I can upload a pre-release with the fix, so you can evaluate if it is good enough. Otherwise I will look into more error checking.

Cheers,

Stefan

mortarm wrote: ↑Sat Nov 04, 2023 6:47 pm

ahenry3068 wrote: ↑Sat Oct 21, 2023 12:24 am 100 GET X$:IF X$<>"" THEN 100 : REM FLUSH ALL KEYBOARD INPUT 110 GET X$:IF X$="" THEN 110 : REM GET A KEY 120 IF MB<>0 THEN 120 :REM WAIT UNTIL MOUSE BUTTONS ARE RELEASED


Using BASLOAD this now becomes.
GET X$:IF X$<>"" THEN THIS GET X$:IF X$="" THEN THIS IF MB<>0 THEN THIS

I'm not seeing any real net benefits except for a few less characters, and even if you had several these, relative to the whole program, it wouldn't amount to much.

Some sort of "same line" syntax really is important, considering how many times I've used statements like that. I also have a BASIC parser/tokenizer, and I built the same thing into mine. iirc, I use @0, which is just a shortcut for "this line." (I use @ for labels, to make them stand out.)

I also considered using HERE to meant "this line", and it really does flow when doing things like
GET A$:IF A$="" THEN HERE
I just wanted a really clean divide between variable names, reserved words, and labels, since my variable replacement parsing doesn't care about reserved words (on purpose.)

Stefan - I've noticed this is still marked #r44. Are there any known issues that would prevent it from being used on R46?

TomXP411 wrote: ↑Wed Dec 06, 2023 9:20 pm Stefan - I've noticed this is still marked #r44. Are there any known issues that would prevent it from being used on R46?

I'm using it on R46..

TomXP411 wrote: ↑Wed Dec 06, 2023 9:18 pm

mortarm wrote: ↑Sat Nov 04, 2023 6:47 pm

ahenry3068 wrote: ↑Sat Oct 21, 2023 12:24 am 100 GET X$:IF X$<>"" THEN 100 : REM FLUSH ALL KEYBOARD INPUT 110 GET X$:IF X$="" THEN 110 : REM GET A KEY 120 IF MB<>0 THEN 120 :REM WAIT UNTIL MOUSE BUTTONS ARE RELEASED


Using BASLOAD this now becomes.
GET X$:IF X$<>"" THEN THIS GET X$:IF X$="" THEN THIS IF MB<>0 THEN THIS

I'm not seeing any real net benefits except for a few less characters, and even if you had several these, relative to the whole program, it wouldn't amount to much.

Some sort of "same line" syntax really is important, considering how many times I've used statements like that. I also have a BASIC parser/tokenizer, and I built the same thing into mine. iirc, I use @0, which is just a shortcut for "this line." (I use @ for labels, to make them stand out.)

I also considered using HERE to meant "this line", and it really does flow when doing things like
GET A$:IF A$="" THEN HERE
I just wanted a really clean divide between variable names, reserved words, and labels, since my variable replacement parsing doesn't care about reserved words (on purpose.)

Have you given this feature anymore consideration Stefan ?

I haven’t yet implemented that, but I will

Can somebody clarify - is there now a much more expanded/enhanced version of BASLOAD embedded in the ROM code?

If so, where/how might I access this, and what are the extra features it supports?

Cheers

Martin

Stefan posted a copy of his ROM.bin on the basic-dev thread on Discord.

Martin, sorry for the confusion - and yes, there will be a little bit of confusion here. So to clarify the situation for the broader community (that may not be in Discord):

BASLOAD 0.2.6 is a PRG that loads into RAM and "hooks into" BASIC (well, the System ROM). That's how it offers the "!L" syntax to load BASLOAD formatted inputs (i.e. plain text files) and doesn't interfere with the tokenized version of code that is produces when reading that input.

This "RAM BASLOAD" settles the overall "proof of concept" of being able to code on the system without line numbers - but it otherwise has all the same limitations as regular X16 BASIC V2 (mainly, two character limited variables, and that the GOTO labels are limited to 12 characters). It also removes REM statements, which in a way allows us to make even longer BASIC programs that would normally be possible (REM content otherwise does consume the code space available to BASIC). Pay attention to your "? FRE(0)" value, since when that gets to 0 or very low, you simply won't be able to make your BASIC program any larger (I think some BASIC's had "CHAINING" {?} as a way to preserve your current variable allocations, while tokenizing in a new BASIC program? but we don't have that).

I think this RAM BASLOAD is effectively frozen unless/until we find any major bug issues. Since it has no additional features, it is essentially still 1:1 equally capable and limited as regular BASIC V2 but with no line numbers (and of course the symbolic GOTO <label> capability). So all existing BASIC V2 books and examples can remain valid. But those completely new to BASIC will (I think) have to be initiated with line numbers, with examples <100 lines or so as exercises. Once they get the gist of that and get the vintage experience of those limitations (be it within 10 minutes or a few days), then they can move onto BASLOAD after that.



Once you get past a few hundred lines of BASIC: the two variable limit because a real handicap. So this ROM BASLOAD is like BASLOAD++, a super enhanced version. But it's "bleeding edge", still in alpha, and a lot of code differences than the other "RAM BASLOAD." New features are variables/labels up to *64* characters (and can contain "." symbol)! And some "#" features to adjust aspects or do special things like import other BASLOAD plain-text ASCII files (#include). Then also possibly entertaining the idea of some extended language features (not new BASIC keywords per se, but like the "GOTO THIS" to implicitly return to the same line without needing to specify a label, or being able to use sequences like {WHITE} to express certain PETSCII codes from the plain-text ASCII -- with {} chosen since that symbol isn't even normally available except in ISO mode).

All great features - but just not quite ready yet Still cooking, and certainly not documented yet.

voidstar wrote: ↑Fri Dec 22, 2023 2:02 am All great features - but just not quite ready yet Still cooking, and certainly not documented yet.

Excellent summary of the state of things!

There is a draft manual on how to use BASLOAD-ROM.

https://github.com/stefan-b-jakobsson/b ... manual.pdf