BASIC 2? Why not get BASIC 7?

[DigitalMonk]

On 6/7/2022 at 11:13 AM, mobluse said:

Maybe ComAL is not available for licensing or the source code is not documented. Also ComAL-80 for C64 is a rather large language that came on a bank switching 64 KiB cartridge: https://www.c64-wiki.com/wiki/Commodore-64_Comal_80_rev_2.01

Purely for clarification:  COMAL is Public Domain software (at least for PET and C64).

What follows is an early morning rant/lament, and I wouldn't blame anyone at all for simply ignoring it.  But I had to get it out of my head.

As for better-than-BASIC, there are so many reasons beyond even the obvious structured loops and named subroutines.  Code entry is spectacular - as soon as you hit Enter, it does the syntax check and if it finds an error it puts the cursor at the site of the error and gives a USEFUL error message (astounding!).  It also is able to take in (at least in some cases) BASIC code and convert it to its own syntax.  When you list, you get back formatted and semantically indented code.  Pure printing-to-screen speed is about the same as BASIC 2.0.  POKEing around is roughly 3x faster than BASIC 2.0.  Internal processing logic is noticeably faster, but I haven't timed it for specifics.  Any looping construct is faster because the jump destinations are located once in a prepass immediately before running so the interpreter isn't searching through the code to find a jump target every pass through the loop.

This is sort of cross-thread to the "if you were CEO of Commodore", but I really wish that the VIC could have had COMAL instead of BASIC.  The reason for using BASIC 2.0 (as opposed to 4.0 or later) was (to my understanding) because M$ was still young in the 70s and had licensed 2.0 to Commodore for use on any number of products, whereas 4.0 would have required new licensing fees for the new machines.  So Tramiel went the cheap route, which was absolutely a winning strategy as history has shown.  As I am writing this, it's driving me insane because I can't find a release date for the first PET COMAL-80 versions, so I can't be certain that it existed in a 6502+PET Kernal compatible form prior to the VIC's release, or even the 64's release.  So maybe it's a non-starter.  But damn, if it was available, even in the PET style (no graphics, sound, or sprite commands), it would be vastly better than BASIC 2.0...

Overall, this is probably just one of those annoying what-if's for me.  The language was available early enough (1974 or '75 for bigger computers), but I don't know if the 6502+Kernal form was ready in time.  And, of course, it would have had to have been ready early enough to get integrated into the design, so that pushes back at least into '80, making almost a certainty that COMAL-80 couldn't have made it into the VIC.  Just one more year!  But "one more year" is enough to go from the VIC to the 64, or to miss your market entirely if you hold off, so you have to go with what you can use.

I know that.

I just wish that they (the Danish creators of the language) had moved COMAL from the larger computers onto microcomputers as soon as they (microcomputers) appeared, even if it meant just implemented the language as it was in 1978 (instead of defining a new version, which pushed everything back by 2 years -- a lifetime, as mentioned above).  If it could have gotten a foothold on the PET, been "good enough" for the VIC (possibly with later "patch" cartridges (or ROM chips for the brave-hearted)), and then maybe COMAL-80 (without graphics/sound/sprites) built into the C64.  I mean, the C64 0.14 version was available on disk in 1983...  So close...

I hate BASIC 2.0.  Really, I hate pretty much all BASICs that lack structured loops and named subroutines.  But I especially hate BASIC 2.0.  And that comes from it being the only language I knew how to use from '81 until I went to college in '89.  So I used it a lot, not knowing how much it sucked, and not knowing how much it was needlessly destroying my brain and ingraining horrible programming style and habits.  I remember seeing the COMAL ads back then, but then I didn't realize how badly I was being abused and didn't understand how much better life would be with COMAL.  I did get and try to use ProMAL for awhile, but as a compiled language with its own shell on a floppy-based C64, it was just too painful.

So, I guess the point of all that rambling is that if I had played with COMAL early enough and known about the Commander X16 project early enough, I would have pushed for it as the built-in language.  To correct one more flaw of history ? and also potentially to avoid having to license any ROMs from anyone.  At least, it would have avoided licensing the BASIC ROMs, and I'm kind of assuming the KERNAL ROMs had to be written more or less from scratch anyway.  But I hadn't, and I didn't, so I couldn't, and thus BASIC survives to ruin even more lives...

[BruceMcF]

On 7/27/2022 at 10:39 AM, DigitalMonk said:

I hate BASIC 2.0.  Really, I hate pretty much all BASICs that lack structured loops and named subroutines.  But I especially hate BASIC 2.0.  And that comes from it being the only language I knew how to use from '81 until I went to college in '89.  ...

Yes, this is a key difference. Within a year of getting my C64, I had a C64 port of fig-Forth on disk, so I was in the "the only language I have" situation for months, rather than years. From that point on, I basically used Basic when typing in Basic programs from magazines, and that was about it.

[rje]

On 7/27/2022 at 9:39 AM, DigitalMonk said:

I hate BASIC 2.0.  Really, I hate pretty much all BASICs that lack structured loops and named subroutines.  But I especially hate BASIC 2.0.  And that comes from it being the only language I knew how to use from '81 until I went to college in '89. 

Same experience for me, except I started college in '87, but yeah from 81 to 87 BASIC 2 is what I knew.  (Well, BASIC 4 in 1981 but same difference).

I'll never go back, and I think things like COMAL are the bees' knees; however, BASIC 2++ is perfectly fine as a "shell command language" for the purposes of the X16.

[rje]

The Apple ][, PET, and TRS-80 all inherited the ecosystem of the kit computers and mainframes that predated them.  And even on the mainframes, BASIC was common.  And on the kit computers, maybe you had 2K for your interpreter?  Practically, that meant BASIC.

 

Unlike those, on the other hand, the 8 Bit Guy chose what he wanted the X16 to inherit, and we've talked that topic to death, but we can talk about it again.  Maybe it needs an accessible summary somewhere on this forum; I don't know.

 

[EvilSnack]

I started learning Commodore BASIC in 1980 (on the PET), and got 6502 programming docs the moment I could lay my hands on them. Remembering back to those days, I now have the idea of developing a transpiler (or whatever you want to call it) which:

* Looks and runs like CBASIC, or, should I say, how CBASIC would have run had it originally been made for the X-16;

* Minimizing its inefficiencies (by tokenizing the code for faster execution, better string support, more efficient program flow, supporting integer arithmetic where desired, etc.);

* Maybe have extra commands for the graphics and sound, support for text labels in addition to line numbers, and accessing the X-16's banked memory;

* Generates assembler listings (which can be optimized and assembled).

I'm a bit rusty on 6502 (I last used it to write a C64 word processor back in 1987-88), and I'd have to give up some of my other hobbies...

 

[BruceMcF]

On 9/24/2022 at 6:48 PM, EvilSnack said:

I started learning Commodore BASIC in 1980 (on the PET), and got 6502 programming docs the moment I could lay my hands on them. Remembering back to those days, I now have the idea of developing a transpiler (or whatever you want to call it) which:



* Looks and runs like CBASIC, or, should I say, how CBASIC would have run had it originally been made for the X-16;



* Minimizing its inefficiencies (by tokenizing the code for faster execution, better string support, more efficient program flow, supporting integer arithmetic where desired, etc.);



* Maybe have extra commands for the graphics and sound, support for text labels in addition to line numbers, and accessing the X-16's banked memory;



* Generates assembler listings (which can be optimized and assembled).



I'm a bit rusty on 6502 (I last used it to write a C64 word processor back in 1987-88), and I'd have to give up some of my other hobbies...

A fully compatible transpiler is the approach likely to get the most widespread use. That reduces the optimizations that can be done, but it gets the optimizations that can be done to the widest possible audience.

Note that supporting integer arithmetic can be done without being incompatible, since a transpiler can analyze whether an expression has all-integer inputs and has an integer output, and in the case where it has both can keep things in integer operations, and in the case where it is all-integer inputs can perform the operation in integers and only do one integer-float conversing at the end.

Then even better, you can be upward compatible by having integer longs (with the Microsoft QBasic symbol), so that if there is something outside the range of a 16bit integer which will still benefit from 32bit integer operations over floating point, the code can be upgraded to gain even more efficiency.

There's already a limited access to X16 Banked memory in the Basic, but a transpiler could analyze the size of arrays and place larger arrays in HIgh RAM rather than the Variable / String pool above program memory.