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