decisions re: BASIC and why?

[CapnZapp]

It really is mostly V2.0 with an extended set of keywords

Isn't every later version of BASIC exactly that?

My question is, why not start with the BASIC 3.5 of the Plus4, say, if your end goal anyway is so much bigger than what BASIC v2 offered?

Apparently, compatibility with v2 is hugely valued, but compatibility with, say, v7 is valued at zero?

I am asking since even the most brief look at the CX16 BASIC tells you this is much more than v2, and possibly more than even v10...

Is it that v2 is a known entity that is relatively easy to license, while later BASIC versions aren't practical to use as your starting point? This could explain why the wheel is re-invented?

[CapnZapp]

It seems like a chunk of graphics words got added because the decision to include the GEOS Kernal in a ROM Bank made them available

This is an excellent point, and things like this is exactly what I was curious about!

[CapnZapp]

I'm seeing a lot of assumptions in the original post, and your faulty assumptions are leading to more faulty assumptions...

Let's peel this back to its essentials:

When this project first started, Michael Steil was manging the ROM project. Michael has done some excellent work, reverse engineering and documenting the Commodore ROMS, and he worked to enhance the existing Commodore ROM to be useful on the Commander's architecture.

As far as I can tell, the additions to the ROM, aside from the essential stuff that Michael did, have been community driven. Someone in the community saw a need, pulled out an editor, and wrote some code to fill that need. For example, MorningLemur wrote a huge chunk of code to control the FM and PSG synthesizers from BASIC, making music and sound effects much easier. Other people have taken on other issues, and when it comes down to it, most of the software work has been community driven.

As to "why"... nobody came up with a working alternative, and by going with BASIC 2 as the starting point, we gain the advantage of most Commodore BASIC programs being easy to port.

As for BASIC 7... nearly everything added to BASIC for V7 would have needed re-writing, anyway, with only a very few things being actually usable or helpful. The graphics routines are all different. The sound routines are all different. About the only thing that would be relevant is the RENUMBER command. Which I'd love to see, but I'm not holding my breath for. (And I even agree with the reasons it may not make it into the ROM.)

Why retain things like "only two significant characters in variable names"... I mean if you're rewriting the BASIC ROM from scratch...

Again, most of the BASIC code is straight from the Commodore 64 interpreter. Stuff was added, but the core language remains the same. The 2-character variable names are one example - changing this would actually be a pretty big refactor, and I don't think anyone sees this change as beneficial enough to be worth the time it would take to make happen.

Thank you.

Please allow me to clarify: I didn't state it explicitly but obviously I understand that you can't use the exact same assembly code that v7 used for the C128.

What I was wondering about was:

If we are going to implement sound and graphics routines anyway...

Why not adhere to the exact syntax of an existing Commodore BASIC, and then market our product as being sort-of BASIC 7 compatible?

Obviously you would have to feed the commands different numbers given the different hardware... but there's nostalgic value in being able to write the exact same commands as before, or so I assumed.

I never assumed you could just load C128 BASIC v7 into memory and magically get shapes and sound out of VERA

I thought it would be obvious that instead of each community member suggesting their take on a given command, resulting in BASIC v2 plus a hodge-podge of more "modern" commands, it would feel more valuable if you actually chose the specific set of commands given by one version of Commodore BASIC, and then backported those commands.

Instead of saying the CX16 supports BASIC 2 plus a huge load of extra commands with no counterpart in Commodore history, you could say the CX16 supported BASIC 3.5 (say) plus a much smaller number of extra commands with no counterpart in Commodore history.

Oh well.

[BruceRMcF]

The original idea was that there would be two BASICs: one would be v2, and the reason for that being so that you could load the old stuff. The other would be v[n] with 'n' probably being something like 16.

This second BASIC would be a 'modern' BASIC, with more in common with QuickBASIC or BASIC PDS. It wouldn't need line numbers, and would have support for longer variable names and would have sophisticated flow control. It would support the ability to be 'transpiled' to v2 (and in fact would require it in order to run programs). ...

I don't know the state of the "transpiled" BASIC, but note that it can be seen as an "incremental compiler" that compiles into V2 Basic. So the two letter variables names are not an issue, since you see the variable name you gave, and the system sees a two letter variable name. Since a variable can start with any letter and the second character can be any letter or number, that is 26*36=936 different variables. Then, for example, since the transpiler assigns the variable names, it can support local variables by just never reusing the translated name anywhere else outside the local scope.

That is why the two good places for a contributor to help with the V2 Basic is expanding the Basic Keywords in a useful way (like the excellent new sound keywords), and making changes to V2 Basic that leave the V2 syntax alone but speed up operation (like the longer standing speed upgrade to floating point math). Ideas include upgrading to Basic V3.5 style garbage collection, a faster line number search process for GOTO, and/or postponing conversion from integers to floating point as long as possible (integer math operations were dropped from Microsoft 6502 Basic to save ROM space, because Commodore didn't want to buy more than 16K of ROMS for it's original PETs or the VIC-20 or C64).

I have never heard any final word on the transpiled BASIC, but it makes sense to get the extended CBM V2.0 feature locked first before starting on it, since you wouldn't want to build a bunch of code that is then later broken by an upgrade to the underlying BASIC V2.0. So as far as I know, maybe it happens, maybe someone ports a more full featured BASIC first and the needs served by the transpiled BASIC are already taken care of by one or more BASICs loaded from "disk".

[Jestin]

Pretty much this.

As far as I can tell, the additions to the ROM, aside from the essential stuff that Michael did, have been community driven. Someone in the community saw a need, pulled out an editor, and wrote some code to fill that need. For example, MorningLemur wrote a huge chunk of code to control the FM and PSG synthesizers from BASIC, making music and sound effects much easier. Other people have taken on other issues, and when it comes down to it, most of the software work has been community driven.

Small correction: MooingLemur and ZeroByte wrote the new Audio Bank, which adds a host of useful kernal routines, pre-loaded FM patches, and even chip register memory shadows for state management. This allows for all programs, not just BASIC programs, to more easily use both the VERA's PSG and the YM2151. I then worked on top of that branch to extend BASIC with 19 new statements for calling those new kernal routines from BASIC...a much simpler task

But back to the point, yes, this is a community driven effort. The "decisions" that were made are really more the result of somebody willing to do the work rather than somebody dictating what is to be done.

[Cyber]

Instead of saying the CX16 supports BASIC 2 plus a huge load of extra commands with no counterpart in Commodore history, you could say the CX16 supported BASIC 3.5 (say) plus a much smaller number of extra commands with no counterpart in Commodore history.

I see what you mean here, and this could've been cool, I agree.
But it is also a lot of tedious work to make something 100% compatible from the scratch. I'm not saying it's impossible, I just think it's not appropriate. Because in the end saying it supports BASIC 3.5 might turn out to be a lie, because in reality it might kinda almost support it or just mimic the support. So I personally would better stick with firm CBM v2.0 extended with whatever comes ahead.

[Cyber]

I totally forgot there is a good answer in FAQ: https://commanderx16.com/faq.html

Why Commodore BASIC?
This entire computer is meant to be a close relative of the Commodore systems. While technically Commodore BASIC is actually Microsoft BASIC, David wants it to be as similar as possible to programming on a VIC-20, C64, or Plus/4. It will run BASIC v2 with some additions. We have reached agreement with the rights holder to license it for this purpose.

[BruceRMcF]

... If we are going to implement sound and graphics routines anyway...

Why not adhere to the exact syntax of an existing Commodore BASIC, and then market our product as being sort-of BASIC 7 compatible?

Who is "we" here? The design team? Community contributors?

On the question, because the exact syntax may not be the most effective syntax for the Graphics, Audio & Memory Management routines in the X16. The design team putting that additional requirement on community contributions would only discourage community contributions that went for the best design for the purpose.

Obviously you would have to feed the commands different numbers given the different hardware... but there's nostalgic value in being able to write the exact same commands as before, or so I assumed.

The nostalgic value of Basic V7.0 is really low, since given the wide gap between install base, the most common use of Basic 7.0 was to run Basic 2.0 programs over twice as fast.

... I thought it would be obvious that instead of each community member suggesting their take on a given command, resulting in BASIC v2 plus a hodge-podge of more "modern" commands, it would feel more valuable if you actually chose the specific set of commands given by one version of Commodore BASIC, and then backported those commands.

Instead of saying the CX16 supports BASIC 2 plus a huge load of extra commands with no counterpart in Commodore history, you could say the CX16 supported BASIC 3.5 (say) plus a much smaller number of extra commands with no counterpart in Commodore history.

Except it doesn't support Basic 3.5 yet. Given that it's been this many years and nobody has volunteered the upgrades offered by going from Basic 2.0 to Basic 3.5, that suggests that if the design team had made that a design goal, the result would be that the system would still be short of the design goal, even though there has been an extra two or so years to work on the system software due to various chip shortages.

If anybody steps forward and makes those contributions, they can start advertising V2.0 & 3.5 compatibility. And if nobody does, they are still feature complete on Basic wherever they get to before the main release is made.

[rje]

Along the lines of BASIC compatibility, I just tried this on the emulator.

Code: Select all

10 ? "uid: " u
20 ? "uname: " n$

u=400 : n$ = "dave" : run

The result: the variable namespace is cleared out before the BASIC program runs:

Code: Select all

UID  :   0
UNAME:

Is this correct behavior?

[TomXP411]

Along the lines of BASIC compatibility, I just tried this on the emulator.

Code: Select all

10 ? "uid: " u
20 ? "uname: " n$

u=400 : n$ = "dave" : run

The result: the variable namespace is cleared out before the BASIC program runs:

Code: Select all

UID  :   0
UNAME:

Is this correct behavior?

Here you go: https://www.c64-wiki.com/wiki/RUN_(BASIC)

tl;dr: yes, that's correct. RUN clears all variables. That's part of the BASIC standard.