Commander X16

6 minutes ago, paulscottrobson said:

Oh, that's pretty much what it does. It just detokenises the tokenised code ?



The other problem is if you store it in dual format you effectively halve the RAM, and there isn't that much of it unless you stick it in banked memory.



 

Understood about detokenizing the tokenized code. That's how v2 BASIC already handles it. Also understood about reducing the amount of RAM, just contemplating ways to give people more efficient BASIC (or some other interpreted language) that is comfortable for people who don't have the desire or mindset to go assembly. It could only work with the idea of multiple banks of RAM (or with very simple programs that don't require much space).

48 minutes ago, paulscottrobson said:

The other problem is if you store it in dual format you effectively halve the RAM, and there isn't that much of it unless you stick it in banked memory.

Though if it is stored in dual format "for editing and listing", the "for editing and listing" form can be stored on disk, since the SD card is not a bottleneck for any human-paced text mode activity along those lines.

5 hours ago, BruceMcF said:

Though if it is stored in dual format "for editing and listing", the "for editing and listing" form can be stored on disk, since the SD card is not a bottleneck for any human-paced text mode activity along those lines.

Good idea ? Mind you, I suppose that's getting close to a compiler again.

5 hours ago, Scott Robison said:

Understood about detokenizing the tokenized code. That's how v2 BASIC already handles it. Also understood about reducing the amount of RAM, just contemplating ways to give people more efficient BASIC (or some other interpreted language) that is comfortable for people who don't have the desire or mindset to go assembly. It could only work with the idea of multiple banks of RAM (or with very simple programs that don't require much space).

I know what you mean. I've been contemplating this for a while myself, and I've concluded it's not actually possible - unless you don't have very much moving.  Pacman is probably about as far as  you can go - half a dozen active screen objects that move about.

6 hours ago, paulscottrobson said:

Good idea ? Mind you, I suppose that's getting close to a compiler again.

Yes, but if the edit of a line then results in the corresponding change to the interpreted runtime, it feels like its an interpreter. All the little clock driven automatic routines, to run the ADSR or to increment the position of a sprite along its commanded trajectory or whatever, are in an $A000-$BFFF segment, since when the currently visible part of the interpreter script is sitting in the $A000-$BFFF segment being edited and then scanned to generate the changes to the interpreted runtime, at that time those little clock driven automatic routines are not in use.

And perhaps it's not just the script, perhaps there things that don't need to be tracked when an optimizing intepreted runtime is ready to go that can make the editing and then fresh run more responsive. For instance, an optimizing Basic-like interpreted runtime can have pointers to the targets of GOTO that are initialized as NUL and the keyword proceeds to read the line number or label and then scan for the target ... but it then stores the address when it finds it, and the next GOTO doesn't have to read the line number / label. Re-initializing the ones to zero that are pointing to a line number / label after the first modified location is a lot faster if you keep a list of where they are ... but that list doesn't have to be in the interpreted runtime.

And of course, if variables are just referred to in the runtime as a 16bit index to the number of unique variable references that have been made, the variable names can reside in a data structure outside of the interpreted runtime.

Going in the other direction, a couple utils I've seen here on this forum could take us in the better direction of Assembler For The Masses.

In short, Assembler with enough oomf or macro-goodness that you won't need anything else directly on the X16.

Thus, BASIC becomes the batch/boot language.

* * *

I think that may be why I was idly thinking about an AWK-like language for the X16.  Something that did things that just aren't done in a typical 3GL.  Presumably, for the purpose of file system management, but.... well is it worth bothering with on an 8 bit platform?

 

On 2/10/2021 at 8:52 AM, paulscottrobson said:

almost no program structures , no long identifier names, no local variables.

Some other significant issues: BASIC is a dead end these days. Learning it doesn't give you any skills you can use elsewhere. But most of all: BASIC doesn't have functions (the way we're used to in modern languages).

Let me give you an example. I got a mechanical keyboard with replaceable switches some time ago, and that led me to write several keyboard testing tools, such as this web-based one. (I had a hard time writing one for the Amiga because unbuffered keyboard input in standard C was hard.) I also wrote one for the X16 using the emulator: kbdtest.prg

A big problem here was setting the cursor position. There is actually a KERNAL API interface for this, so you can just do:

9010 POKE781,VE:POKE782,HO:POKE783,0:SYS65520:RETURN

And then HO=10:VE=8:GOSUB9010 as needed.

It would have been so much better if I could have just created a function for this.

My takeaway: BASIC is just too limited, and has ended up being a dead end in the evolution of programming languages. So I'd rather do something like defining a subset of Python that provides the basic BASIC functionality, but in a more modern way, where someone who learned the Python subset has a head start learning "real" Python.

1 hour ago, iljitsch said:

Some other significant issues: BASIC is a dead end these days. Learning it doesn't give you any skills you can use elsewhere. But most of all: BASIC doesn't have functions (the way we're used to in modern languages).

I believe you mean Microsoft 6502 V2 Basic doesn't have functions. QBasic had functions while the C64 was still on the market.

14 minutes ago, BruceMcF said:

I believe you mean Microsoft 6502 V2 Basic doesn't have functions. QBasic had functions while the C64 was still on the market.

Yeah, MS-based 6502 BASICs of the time were limited. Not a limitation of the CPU, BBC Basic also had procedures and function (and built-in assembler) on the 6502 BBC Micro. 

I may be in the minority, but Commodore BASIC v2 is responsible for getting me started! Sure, there are a lot of things missing WRT modern languages, but I firmly believe that learning any language is a useful exercise to get one to begin thinking in a programmer mindset. And the more languages you learn, the better off you are because you being to contemplate programming in the abstract (input, output, variables, conditionals, control structures) instead of the concrete (INPUT, PRINT, A$, IF X=Y THEN ...).

I know there are plenty of people who believe "avoid these toy languages because you'll learn bad habits" or other similar arguments. For learning the basics (pun not intended but apropos) of how to write a program to tell a computer what to do, BASIC is great.

Not every language must lead directly to a six figure income.

Then of course there is assembly / machine language. Talk about a language without modern first class features like functions! ?