Commander X16

Hi,

Who are making decisions regarding the BASIC that is planned for the X16, and which rationales are offered?

I mean, I see the obvious attraction in just saying "we'll support Commodore BASIC v2 because that's what the C64 had!" and that's the end of discussion.

Except it isn't. Somehow, someone is capable of extending this BASIC with a load of new commands BIN$, BOOT, CLS, COLOR, DOS, FRAME, GEOS, and so on and so on...

* Who is writing this new BASIC and how is the promised 100% compatibility ensured?
* Who chose what new commands to support? By which criteria? What decides which commands are in and what are left out?
* are new commands included because... because they were supported on [enter fave nostalgic system here]? the team just likes them? the programmer responsible is the only one with decision power? or what?

The project is clearly not going with BASIC v2... why wasn't another version of official Commodore BASIC considered? Like v7 used by the Commodore 128?

Wouldn't that achieve much of the same goals (re: v2 is lacking in functionality) but with authentic nostalgia?

Why go with the unaltered Commodore BASIC at all - it basically sucks, and is extremely slow! Why not pick a more competent alternative from the era? (That still looks and feels like Commodore BASIC I mean, I'm not suggesting a completely different dialect of BASIC here just because it runs faster)

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

At this point, I'm pointing no fingers and making no accusations. Consider this initial curiosity only. Getting insight into how the project leadership thinks and what I presume are many good reasons for going with this "BASIC v2... but not really" approach, would be much appreciated!

Thanks

Every new feature, every new keyword, is added 'on top' of the existing code.

CBM BASIC 2.0 is still present in full and unaltered, and if you happen to have one of those rare programs that doesn't use any specific hardware features, from a VIC-20, or a 64, or for that matter from a PET 2001-N, then you can load it up and run it on an X16. You can even write a quick little machine code stub to grab the screen size using the KERNAL routine "SCREEN" at $FFED and adjust your screen to the 64's 40x25, VIC-20's 22x23, or X16's 40x30, 80x30, 80x60, and other formats, and have a program that will run on any of those platforms with full use of the screen. (Said stub should probably check first to see if it's running on a PET, which doesn't have the "SCREEN" function.)

And if you do happen to have one of those v2 programs that uses the hardware, well, at least you know you can load it on your X16 in order to make the necessary changes to it.

Thanks but that just details what the chosen solution will use.

I was asking why these choices were made.

Why advertise the system's BASIC as "v2 plus more" when in reality this version of BASIC appears to be more capable than v3.5 or even v7... (mouse input was only added with the unreleased V10).

Why not go with an existing (old school) version (Commodore's or one of the more popular BASIC expansions)?

Why not address the lack of structure in Commodore BASIC (line numbers, structures like WHILE loops, ...)? Or choose an era-appropriate BASIC implementation that isn't horrendously slow? (Apparently garbage collection was improved in v4 used for Commodore 600/700 series)

Starting with a very limited v2 and then adding lots of functionality on top of that, essentially creating your own BASIC that, compared to Commodore's version numbering would merit a v9 or v11 or something seems like a... curious... choice, and I was intrigued to learn more about each step along the way!

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).

A lot of the reason why so many commands have been 'tacked onto' v2 in the current state of affairs is to support more sophisticated operations for v16 without needing to include a massive runtime that would have to be tacked on to every transpiled program... and as the latter has fallen farther and farther down the priority list, those added features have become more primary to the 'extended' version of v2 that we have. (Call it v2.16 if you like.)

We do have some starting points for what would essentially be a community-based v16. BASLOAD is one such point. CX-BASIC is another.

And if I'm wrong about any of the above, someone will correct me. It's the internet; Cunningham's Law applies.

kelli217 wrote: ↑Mon Feb 13, 2023 6:25 pm VIC-20's 22x23

Commander X16 doesn't have this screen mode. The closest is 20x30 text, but it also has 20x15 text.

mobluse wrote: ↑Mon Feb 13, 2023 8:46 pm

kelli217 wrote: ↑Mon Feb 13, 2023 6:25 pm VIC-20's 22x23

Commander X16 doesn't have this screen mode. The closest is 20x30 text, but it also has 20x15 text.

Right, and that's why it says VIC-20's 22x23.

And why the X16 is mentioned with other screen sizes, later on in the post.

And this is why you'd want to check with SCREEN before doing any of this, anyway.

Commander X16 BASIC core must fit in a certain memory space if it is to be kept simple and not become buggy. Since CBM BASIC v2 was written by Microsoft it seems sensible to extend it in line with the latest line oriented MS BASIC i.e. GW-BASIC (which is a translation to 8086/8088 of MBASIC for Z80). One reason to expand BASIC v2 in the direction of GW-BASIC is that a lot of code exist for GW-BASIC that would then be possible to run on Commander X16. Another popular BASIC was AppleSoft BASIC for Apple II and I think one should add one command from that, if it isn't too much trouble, in order to be able to easily convert those BASIC programs: POP.

One could be inspired by later Microsoft BASICs e.g. QBasic, VBA, and Visual Basic (.NET). One could also be inspired by Python since it is rather similar to BASIC. Bugs in the original BASIC v2 can be fixed and optimizations can be done, but one should be careful not to introduce new bugs. Anyone can suggest improvements in this forum or on GitHub.

CapnZapp wrote: ↑Mon Feb 13, 2023 5:40 pm ... I mean, I see the obvious attraction in just saying "we'll support Commodore BASIC v2 because that's what the C64 had!" and that's the end of discussion.

Except it isn't. Somehow, someone is capable of extending this BASIC with a load of new commands BIN$, BOOT, CLS, COLOR, DOS, FRAME, GEOS, and so on and so on...

* Who is writing this new BASIC and how is the promised 100% compatibility ensured?

There is a difference between adding a new keyword and changing the interpreter itself. None of the keywords you mentioned changed the execution of the interpreter code ... they all are just additions to the keyword names, keyword symbols and the ROM code that is called to execute the command.

If they implement a keyword with code that doesn't touch any memory that original CBM V2.0 keywords use, the upward compatibility should be easy to confirm. If it does, then that would require more careful unit testing for interference. But there's a lot of vanilla CBM V2.0 programs they can use to confirm that there isn't any interference.

* Who chose what new commands to support? By which criteria? What decides which commands are in and what are left out?

I expect some member of the design team would have proposed it, and the design team would have agreed on an approach. Often the proposal would have started in the community, since many of the extensions / changes have been provided by the community.

* are new commands included because... because they were supported on [enter fave nostalgic system here]? the team just likes them? the programmer responsible is the only one with decision power? or what?

Those who are not on the design team wouldn't be privy to all of the details -- obviously those involved in a specific contribution likely know more about their own contribution -- but I haven't seen any apparent "fave nostalgic system" approach. 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 without dedicating a lot of the BASIC ROM to it ... that is the original CBM V2.0 that they started with is ~9KB in size, and they have just shy of 16KB to work with, so they had room for expansion, but not unlimited room, so keywords that are a wrapper for a call to a routine in another ROM Bank are often a "bang/buck" win.

It seems like some were added because Micheal Steil knew they could be added that way fairly efficiently and they are useful capabilities. A couple, like BOOT, seem like they were added because the capability was added to the Kernel that made also offering it in BASIC straightforward. VLOAD would be similar ... when loading direct to the Vera RAM was added to the Kernel, the hardest part of adding a VLOAD keyword to BASIC has already been done.

The project is clearly not going with BASIC v2... why wasn't another version of official Commodore BASIC considered? Like v7 used by the Commodore 128?

It really is mostly V2.0 with an extended set of keywords. More efficient floating point and the ability to use "$" for hex integer literals are the main changes I know of, as opposed to keyword additions, and the more efficient floating point is more along the lines of changing existing keyword code rather than changing the interpreter. Checking that upgraded routines give the same results as the original routines, just faster, would be fairly straightforward.

Wouldn't that achieve much of the same goals (re: v2 is lacking in functionality) but with authentic nostalgia?

v7 wouldn't have worked as it stood, as it is too closely tied to the Commodore 128 hardware. It's sound keywords assume a SID, its BANK keyword assume the C128 MMU, and so on. Starting from V7 would have meant a whole lot of work.

Why go with the unaltered Commodore BASIC at all - it basically sucks, and is extremely slow! Why not pick a more competent alternative from the era? (That still looks and feels like Commodore BASIC I mean, I'm not suggesting a completely different dialect of BASIC here just because it runs faster)

It's Dave's dream, not mine. But nobody is stuck with using the ROM Basic if someone implements a better Basic. And nobody is prevented from coming up with an upwardly compatible improvement and offering it as a upgrade on the Github.

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

They absolutely, positively didn't rewrite it from scratch ... the original interpreter keeps the floating point operations that are used to implement the floating point math separate from the interpreter routines themselves, and in that interpreter routines themselves, easily over 95% of the original interpreter code is still in use.

At this point, I'm pointing no fingers and making no accusations. Consider this initial curiosity only. Getting insight into how the project leadership thinks and what I presume are many good reasons for going with this "BASIC v2... but not really" approach, would be much appreciated!

As far as getting insight as to how the project leadership thinks, I dunno, but so far I haven't seen any changes that seem to be total clunkers, and I can't really complain about them starting with an existing working 65C02 code base that their most productive Kernel assembler was extremely familiar with and building on it, since I certainly haven't had the time to write a 6502 Basic interpreter from scratch (given that my port of Camel Forth has been stalled for over a year now).

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).

A lot of the reason why so many commands have been 'tacked onto' v2 in the current state of affairs is to support more sophisticated operations for v16 without needing to include a massive runtime that would have to be tacked on to every transpiled program... and as the latter has fallen farther and farther down the priority list, those added features have become more primary to the 'extended' version of v2 that we have. (Call it v2.16 if you like.)

We do have some starting points for what would essentially be a community-based v16. BASLOAD is one such point. CX-BASIC is another.

And if I'm wrong about any of the above, someone will correct me. It's the internet; Cunningham's Law applies.

Thank you Kelli. This sort of stuff is exactly what I was curious about.