BASIC 2? Why not get BASIC 7?

[rje]

3 minutes ago, Michael Parson said:

I used the X-16 as an excuse to take another run at C.



The results so far?  A PETSCII game: https://github.com/mparson/gridgame (slightly older version available in the X-16 downloads section).



I started with the X-16 as the target, but now it compiles and runs on the C-64 and 128 as well.

Ah, I saw that in the downloads section.  Perfect, thank you.

 

[BruceMcF]

7 hours ago, rje said:

I'm not minding using an incremented BASIC.



Although ... well I *should* be doing my coding in C, shouldn't I?  I mean that's closer to my natural medium.



I guess all the PETSCII and cursor and color codes are still available... it's quite a paradigm shift, writing Commodore stuff with C.

I was referring to Forth, as I do not expect R to get ported to the CX16. Programming in C for me is too much like working for a living ... if the sole other alternative was C, I might give a more advanced Basic, especially one with both an interpreter and a compiler, a shot!

[Starsickle]

C IS the language of Atlantis, after all. ?

Honestly, as long as whatever we get is well documented and follows the strictures of BASIC - Whether it's C64 Basic 2.0, or C64Basic2.0++ or Basic 7, or SmileBASIC, or BubbaBASIC, Grandma Tillerson's ButteryBASIC? I'm sure a well-documented, well-cookbooked community will adapt and be able to program for the machine. The real question is: is the backwards compatibility requirement in the specification a hill really worth dying on if the machine's ACTUAL specifications can't be used by its core audience (newbs and amateurs)?

Everyone involved are very smart people, so I think it'll be worked out. ?

[Wertzui]

 

Quote

Precisely. I expect the higher productivity will be those that program it on the emulator and run it on the real iron just as a final test ... but the greater satisfaction may be those who turn off the modern world and program it old school.



Mind, I wouldn't do it in Basic.

My current development method is that I write the BASIC code in a text editor, and copy-paste the text into the emulator.

So what if you could do something similar ON the hardware itself? The X16 appears to be fast and stable enough for that.

Like, having a comfortable text editor residing in hight memory (with maybe some help with the line numbers and syntax color highlights), you can save a separate ASCII source file, and on command, it could plop the the code into the BASIC memory and you could test it, then jump back to the text editor.

It would be great ...or maybe not, but I can see myself trying to get to somewhere with that.

[x16tial]

1 hour ago, Wertzui said:

My current development method is that I write the BASIC code in a text editor, and copy-paste the text into the emulator.



So what if you could do something similar ON the hardware itself? The X16 appears to be fast and stable enough for that.



Like, having a comfortable text editor residing in hight memory (with maybe some help with the line numbers and syntax color highlights), you can save a separate ASCII source file, and on command, it could plop the the code into the BASIC memory and you could test it, then jump back to the text editor.



It would be great ...or maybe not, but I can see myself trying to get to somewhere with that.

I happen to be working on that very thing. I think I’ve got all the pieces pretty much worked out, now I just need to stitch them together.

Here’s the vision: in the editor, no line numbers, just labels. You’ll be editing the code in place, no separate file, no compilation translation or transpilation. The editor will just abstract away the line numbering, but will still leave a native V2 basic file that can be run, saved, and distributed without requiring the editor.

Also: long variable names, again, abstracting away the actual implementation that will still use the 1 or 2 character variables. What it’ll do is have a dictionary of labels and variable names in rem statements that the editor will use to map the “friendly” to the actual.

I’m a fan of “less is more” in interface design, so will have minimal interface real estate.

I’m working on the assumption that V2 basic is pretty much set for the X16. Somebody please correct me if there’s a chance that a different Basic might actually make it in.

[rje]

Michael, I think you're in the right ballpark.

[TomXP411]

5 hours ago, x16tial said:

I happen to be working on that very thing. I think I’ve got all the pieces pretty much worked out, now I just need to stitch them together.



Here’s the vision: in the editor, no line numbers, just labels. You’ll be editing the code in place, no separate file, no compilation translation or transpilation. The editor will just abstract away the line numbering, but will still leave a native V2 basic file that can be run, saved, and distributed without requiring the editor.



Also: long variable names, again, abstracting away the actual implementation that will still use the 1 or 2 character variables. What it’ll do is have a dictionary of labels and variable names in rem statements that the editor will use to map the “friendly” to the actual.



I’m a fan of “less is more” in interface design, so will have minimal interface real estate.



I’m working on the assumption that V2 basic is pretty much set for the X16. Somebody please correct me if there’s a chance that a different Basic might actually make it in.

Yeah, that sounds a lot like how my BASIC code editor works. 

I'm starting to think that all of us who are doing basically the same thing should get together and standardize our syntax, since all of ours is probably different, and it would be good to standardize it to make code sharing easier. 

 

[x16tial]

3 hours ago, TomXP411 said:

Yeah, that sounds a lot like how my BASIC code editor works. 



I'm starting to think that all of us who are doing basically the same thing should get together and standardize our syntax, since all of ours is probably different, and it would be good to standardize it to make code sharing easier. 



 

Not a bad idea, who all are working on something like this, besides me and you?

[TomXP411]

1 hour ago, x16tial said:

Not a bad idea, who all are working on something like this, besides me and you?

I think @rje  has mentioned it a couple of times. He's been calling it a "transpiler".

So far, I have planned and/or implemented:

VAR LongName=LN (done⁑)

#pc #c64 #cpm #bbc - line is only emitted on this platform (done*)

#!pc #!c64 #!cpm #!bbc - line is NOT emitted on this platform (done)

@labels  (with GOTO and GOSUB @label) (done)

@@ - same line (GET A$:IF A$="" THEN @@) (done)

DO [WHILE|UNTIL] / LOOP [WHILE|UNTIL] (in progress)

IF condition BEGIN/ENDIF - multi line IF/THEN block.  (future)

*platform filters are currently one per line. I want to change that so the line can have multiple filters, like:

#pc #cpm #c64

⁑Any word in the program that does not have an entry in the token table is treated as a variable and auto-mapped. I may change this to allow easier coding for expanded BASICs. Or I may add a user-editable syntax table. 

 

 

[BruceMcF]

15 hours ago, Starsickle said:

C IS the language of Atlantis, after all. ?



Honestly, as long as whatever we get is well documented and follows the strictures of BASIC - Whether it's C64 Basic 2.0, or C64Basic2.0++ or Basic 7, or SmileBASIC, or BubbaBASIC, Grandma Tillerson's ButteryBASIC? I'm sure a well-documented, well-cookbooked community will adapt and be able to program for the machine. The real question is: is the backwards compatibility requirement in the specification a hill really worth dying on if the machine's ACTUAL specifications can't be used by its core audience (newbs and amateurs)?

If C is the language of Atlantis, that would explain why flooding the continent was preferable to continuing to run it.

The ROM Basic is the equivalent of DOS's batch file language ... it's what is there on power up (well, boot-up on DOS).

But nobody was limited to programming on BAT files alone. Similarly, with the loading speed of the CX16, there is no need to die any any particular programming hill ... people can use whatever programming language they load onto an SD card. Indeed, if the discussed auto-exec bootup file parameter is stored on the RTC, as has long been discussed as a design goal, people can boot up into any environment they want to.