Commander X16

BruceRMcF wrote: ↑Mon Feb 13, 2023 10:31 pm It really is mostly V2.0 with an extended set of keywords

BruceRMcF wrote: ↑Mon Feb 13, 2023 10:31 pm 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

TomXP411 wrote: ↑Tue Feb 14, 2023 10:50 am 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.

kelli217 wrote: ↑Mon Feb 13, 2023 8:38 pm 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). ...

TomXP411 wrote: ↑Tue Feb 14, 2023 10:50 am 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.

CapnZapp wrote: ↑Tue Feb 14, 2023 2:33 pm 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.

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.

CapnZapp wrote: ↑Tue Feb 14, 2023 2:33 pm ... 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 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.

rje wrote: ↑Tue Feb 21, 2023 6:27 pm 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?