BASIC 2? Why not get BASIC 7?

paulscottrobson · Post by **paulscottrobson** » Wed Mar 10, 2021 2:51 pm

On 3/9/2021 at 9:29 PM, x16tial said:

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

My current syntax is at https://github.com/paulscottrobson/6502-basic/blob/main/documents/Reference.pdf

That stuff is implemented as opposed to planned, though it's still pretty fragile obviously, it hasn't been bashed much. You can run programs from text source and type stuff in at the keyboard but you can't edit programs through the keyboard yet. Not that there's any point as the token tables are not set in stone(ish) yet.

There's no X16 specific stuff except some basic text I/O commands, VPOKE VPEEK() and 16 bit versions VDOKE and VDEEK(). No assembler yet. Still single index arrays (the array code needs rewriting). All the hooks are in there for floats, but no actual code yet.

Also for a consistent syntax, anything real text is in quoted strings, hence REM "this is a comment" and likewise with DATA.

rje · Post by **rje** » Fri Mar 12, 2021 4:47 am

On 3/9/2021 at 5:17 PM, TomXP411 said:

VAR LongName=LN

#pc #c64 #cpm #bbc - line is only 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)

These are nice.

I could handle the 'var' keyword instead of my current 'longvar'.

I used to allow an explicit mapping to a two letter var, but now I just gen them up, starting with A0-A9, then B0-B9, and on up. I figure 260 unique long variables is enough.

Similarly, I could easily handle the shell-inspired octothorpe for platform-only comments.

And I could recognize @my.label. It's easier than writing {:my.label}, which I think I borrowed from C64LIST.

Do you allow periods in your labels? I find it handy.

@@ is clever.

I don't have loops or code blocks.

Ed Minchau · Post by **Ed Minchau** » Fri Mar 12, 2021 6:52 am

This all started out as David Murray's dream 8-bit computer. I think the specs and emulator are pretty close to what he outlined a year and a half ago.

So, who says a dream 8-bit computer has to be stuck with 40 year old code? What would be the dream language?

We're using the 65c02, so we have a stack. One stack, always at 0100-01FF. That's a hard limit on anything that can be done in a language for the X16.

If we're not using BASIC, then the whole of zero page is open except 0000 and 0001 should be off-limits as those are going to be the ROM bank pointer and RAM bank pointer in the new version of the board. There's also a number of zero page locations being used by the Kernal (i.e. 82 and 83 are overwritten by JSRFAR). A number of the API subroutines use the zero page locations from 02-21, the lower addresses in particular. We'd want to keep using the Kernal and API so, in practical terms, the zero page values from 22-7F are available for the dream language.

RAM bank 00 should also be off-limits as that is used by the Kernal and API.

Any computer language has to consider paradigm - which is really just a set of limitations imposed upon the programmer. For instance, having local-scope variables makes those variables inaccessible to code outside the scope, and if a programmer wants access to that variable outside the scope must have some kind of PUT and GET subroutines within the scope. It's a limitation imposed on the programmer, but it's done with the purpose of preventing the accidental use of a variable outside its scope.

And every feature that is part of the language is a trade-off. Longer variable names or double-precision floating point numbers have advantages, but they come at a cost of increased storage for more characters in a name or more bytes used to represent the variable.

So, what sort of paradigm would people like for the Dream Language? (that's actually a pretty good name, come to think of it) What sort of features? Longer variable names, label identifiers, extended variable types? Local and global variables? File handling using something like iostream?

And heck while I'm at it, why not a dream OS? GeckOS looks interesting

TomXP411 · Post by **TomXP411** » Fri Mar 12, 2021 8:38 am

3 hours ago, rje said:

Do you allow periods in your labels? I find it handy.

@@ is clever.

I don't see why not. My parser looks for a letter first, then either a letter, number, or underscore. I could easily add periods to that check.

rje · Post by **rje** » Fri Mar 12, 2021 3:12 pm

My "transpiler" isn't even that. It's a two-pass thing that looks for patterns and does some simple substitutions. It doesn't care about syntax at all.

paulscottrobson · Post by **paulscottrobson** » Sat Mar 13, 2021 6:45 am

I think it looks neater with indents and everything lower case (except quoted strings). I have a workflow and an actual working game ? albeit not the most complicated one in the world, but it's all done with text commands .... inkey$() has been added since I wrote this test game (I forgot ...). Code size is about 10k, but it's chopped up into about a dozen modules which are designed to be paged, and the largest module "main", the core, is under 6k and that's not likely to grow much, as the assembler has its own module (though that's not written yet), and anything system specific goes in another module.

Spot the bug ?

TomXP411 · Post by **TomXP411** » Sat Mar 13, 2021 10:02 am

18 hours ago, rje said:

My "transpiler" isn't even that. It's a two-pass thing that looks for patterns and does some simple substitutions. It doesn't care about syntax at all.

Yeah, that's largely how this one works, but since I wanted the short variable naming to be automatic, I needed to know the text of all the reserved words. That way I didn't try to shorten "FOR" or "THEN".

I've also got some additional syntax rules, compared to BASIC 2. Among other things, a space between keywords and variable names is required. So no FORT=1TO100. That would cause the parser to think FORT is a word, and it would try to shorten it to FO. I plan to include packing in a fourth pass, so the final output might indeed look like that, but the input definitely cannot. ?

rje · Post by **rje** » Sat Mar 13, 2021 6:35 pm

11 hours ago, paulscottrobson said:

I think it looks neater with indents ...

Quoted For Metaphysical Truth. I indent the for-blocks in my transpiled fake-BASIC thing, and it's refreshing.

I've thought about adding inkey$ as a cipher for


get a$: if a$="" <then_try_again_until_there's_something_there_to_worry_about>

P.S. I like the defproc syntax.

The overall result looks sorta like Pascal with C-style assignment.

Sean · Post by **Sean** » Sun Mar 14, 2021 3:46 am

9 hours ago, rje said:
Quoted For Metaphysical Truth. I indent the for-blocks in my transpiled fake-BASIC thing, and it's refreshing.

I've thought about adding inkey$ as a cipher for
get a$: if a$="" <then_try_again_until_there's_something_there_to_worry_about>
P.S. I like the defproc syntax.

The overall result looks sorta like Pascal with C-style assignment.

I think it looks a good bit like Algol, from which C and Pascal descend, but with fewer parentheses.

BruceMcF · Post by **BruceMcF** » Sun Mar 14, 2021 4:29 am

18 hours ago, TomXP411 said:

Yeah, that's largely how this one works, but since I wanted the short variable naming to be automatic, I needed to know the text of all the reserved words. That way I didn't try to shorten "FOR" or "THEN".

I've also got some additional syntax rules, compared to BASIC 2. Among other things, a space between keywords and variable names is required. So no FORT=1TO100. That would cause the parser to think FORT is a word, and it would try to shorten it to FO. I plan to include packing in a fourth pass, so the final output might indeed look like that, but the input definitely cannot. ?

Oh my goodness yes ... even in a hosted Basic transpiler, 80 columns and 30ish rows is enough that there is no reason to have crunched source.

Also, on indents, while eight column tabstops is the traditional 80s standard for programming and five column tabstops the standard for text editing, to my eye either three or four column tabstops work fine. When working on BMW, my pure text character line editor for & in Forth, I had a first line tabstop define, where if the first line was a comment line:

\ -+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+

or

\ --+---+---+---+---+---+---+---+---+---+---+---+---+---+---+

... would give three or four column tabstopping, respectively. The test for a tabstop line was "Does it start with the string Comment character, space, - character? If so, skip any additional - characters, is the next character a +? If so, this is a tabstop comment, store it in the tabstop definition buffer". The indent out and indent back routines are the only ones that have to read the tabstop definition buffer, since they set the current tab indent column and that value is what the line display routine uses. There was no need for a tabstop setting command, since, eg, loading file consisting of nothing but a tabstop comment with 8 column tabstops would "set" the tabstop to 8 columns. Loading it into the copy and paste buffer rather than the main file buffer could set it after the file was loaded.

A similar thing can be done in the editor for any language that has a single character, single character plus space, or double character comment symbol, to support arbitrary regular column tabstops from 3 columns on up.