I grew up in the 60s and 70s... touched a computer for the first time at the age of 15 in 78. (HP9830A - Basic, then Apple II). I had a slight advantage over my classmates in that I could type. I don't think there were many 5 year olds with computers in the early 80's though. Teenagers - sure! (and I missed out here as I was ~20 when the C64 came out and had cut my teeth on the Apple II and BBC Micro, so from my point of view they were "rubbish" and I had "real" computers to play with at Uni... But the teenagers? They were the ones spending 24 hours a day on their Vic20's and so on... (also possibly because computers were so bloody expensive here in the UK!)

Also a tiny minority were actually programming. The vast majority were playing games.


Fortunately for me, at least I think fortunately, my teacher was an old Algol programmer so he taught me about program structure even in BASIC, and I learned more in a local university (before leaving school) with a high level language called Imp77. Since then it's been C almost all the way (although when I did go to Uni, I had to do all the "usual" others, FORTRAN, COBOL, Pascal - I did C independently, then BCPL)

Back to programming - I do think that it's better to teach programming as a concept rather than a single language. (I don't know what Raptor is) This is based on my own personal experiences though. I still like BASIC and have written my own BASIC interpreter (In C).

People tell me that Python is the new BASIC, but I was never really happy with it. it's really not my thing. Essentially I never got on with OO style programming even though I did work for a PC games company in C++ for a year.

So back to a very simple programming language (on the 6502)... It's BASIC. Give that BASIC functions and features and a hint of structure (e.g. a while loop) and you're half way there. At least I think so. For the 6502? Well, there are many many BASICs. Mostly MS based or MS derived - e.g. EhBASIC. All you need is a 6502 system that'll run a BASIC and porting EhBASIC is relatively trivial these days.

Want a bit more structure? Well, COMAL. The down-side of that is that there is only one Comal system I'm aware of and that runs on the BBC Micro. It's not that hard to make a 6502 system that looks enough like a BBC Micro to run Comal though (I did it with my Ruby 6502 system) Comal uses line numbers but only as an edit feature. You can't GOTO a line number. (Personally not convinced Comal is that good though, but it's there).

Things like turtle - well, it's visual and one thing I've noticed is that if you give young people visual feedback they're likely to stick. I've seen joy in their eyes after giving them a "program" to walk round a playground, (repeat 4, walk 3 paces, turn 1/4) then taking them through the steps of making that a real program and making a turtle draw a square on a screen. The other thing is GPIO - Light an LED, make it blink and so on. Seems almost trivial, but again, I've seen first-hand how newbies (young and old) react to this. Turtle graphics is just a tiny part of Logo, and it's a tiny part of my own BASIC too, but it provides a nice adjunct to simple point plotting and line drawing.

So keep it simple with visual feedback - the first program I had to write was to calculate compound interest. It nearly put me off for life.

Scratch makes it easy - it's almost real-live real-time Nassi Schneiderman diagram programming.

Scratch:



I'm not a fan of scratch myself, but it's there and it is being taught in UK primary schools (up to the age of about 11 - after that in secondary/high school it's more Python, but it depends on the school). There is a thing called Code Club here that sort of embraces it all that a lot of schools also embrace because it's easy for them. (Also driven by the Raspberry Pi Foundation who have a vested interest in getting kids into Python).

Neither Scratch nor Python runs on the 6502. Micro Python could be ported, but who's going to do it?

So IMO, you, we? need a modern BASIC for the 6502. Who's going to write it. Some will say that BBC Basic is already there, but it's old, almost esoteric and some dreadful quirks and foibles (again, my opinion - there are 1000's who'll defend it with their lives!) I don't think it encourages good programming although it's a great BASIC.

What do I think a good BASIC is? Well, I wrote one. It's over 30K lines of C has over 300 keywords and will never ever run on a 6502. Could I pare it down? Yes, given time (and money?) what would it need? Colour graphics, keyboard and mouse. 64KB of RAM/ROM with separate video memory. I'm almost back at the BBC Micro again.

I went back to your examples - they're almost BASIC, but one thing I did in my own BASIC was to make GOTO mandatory in an IF statement. It just reads better (to me, and it's MY BASIC for me). And CALC? Well, that's just LET with different letters to type... I've also found it easier to teach counted loops using a WHILE statement before introducing the FOR statement. Again, it reads better to me - and the young folks I've taught with it (8-14 year olds mostly) see to exhibit confusion with FOR but can read WHILE once they get the hang of variables.

Anyone up for coding a 'new' simplified BASIC in e.g. C for the 6502? I ported cc65 to my Ruby 6502 board, then I ported my nano-like editor to it to. It's about 1.5K lines of C and compiles to just under 16KB of object code and it ran very well, so a tiny basic in C with some simplified structure?

Anyway, rambling on now...

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I've puttered with the idea of doing a BASIC from scratch, myself; I think the biggest challenge would be coming up with a dialect that I actually like, but which would still be suitable for use on 8-bitters. Looking at, e.g., ehBasic, I can respect the work put into it, but a lot of the enhanced features are awkward kludges intended to make more advanced hackery easier without breaking compatibility with vintage MS BASIC.

Yet if you pursue a cleaner design that lends itself to learning better programming practices, you lose compatibility, and may even make it less approachable for beginners. (I can't think of any compelling reason to support line numbers over a more structured approach, for example, except that it really does make it easier for beginners to grasp how normal program flow corresponds to "step 1, step 2, step 3..." etc.)

It feels like there must be a better way, but the challenge would be finding it.

COMAL uses line numbers, but for program editing/entry only. It's a bit like a more structured BASIC in many ways. I suspect you could write COMAL without line numbers, but then you need to write some sort of screen editor. Hm. Apparently COMAL is still in-use somewhere:

https://en.wikipedia.org/wiki/COMAL

My own BASIC can use either line numbers (and conventional GOTO/GOSUB) or no line numbers and named procedures/functions and structured looping constructs. Initially I used an external editor, but eventually wrote my own little nano-like screen editor. One challenge I had was maintaining the interactive environment especially when using an external editor. (so when loading a program without line numbers, the system gives it numbers which are visible if you LIST it)

Cramming all that into the RAM of a 6502 SBC is the challenge.

I always come back to the BBC Micro though and one big criticism of it at the time was the limited RAM (in 1981 it has 32KB in total when others had more) - the memory map is roughly: 0-$DFF system use. (Up to $18FF if you had disk, or even up to $1BFF for 'advanced' disk) there to $8000 minus video RAM for programs and data. $8000-$BFFF for the "language" (ie. the BASIC or Comal, etc. ROM) and $C000 to $FFFF for the OS ROM (minus 2K for IO). So pick a big RAM video mode, say 20KB and that leaves little for code. Or a 1KB video mode (teletext) and you get a lot left over for code. Always a compromise. (Really Acorn intended you to use a 2nd 6502 connected via a high-speed interface to write your programs in, so you had up to 60KB for code and data, but they were expensive at the time).

With paged ROMs in the Beeb, eventually a full-screen BASIC editor came about but I never used it myself.

So just how much RAM do you need for a small (tokenised?) program and data? (especially aimed at a learning environment) I'd argue "not a lot" - leaving a lot of space for interpreter and OS - more-so if you can have separate video RAM, but video is always a complication - 9KB will get you 320x240x1 but there are many other ways to get colours and simple graphics in much less - teletext mode did it in 1KB but those 2x6 pixel blocks were often challenging to use, however there is always things like "PETSCII" and systems with e.g. 1KB for 40x25 characters and 1KB for colour attributes and so on.

I often think about the Apple II too - there it as 1KB for text (or lowres graphics), or 8KB for hires graphics, but, importantly the hires graphics RAM starts at 8KB up, which really only leaves some 6KB for programs - I don't recall that being a limitation for most small programs I wrote at the time...

There is a C version of TinyBasic that comes in at under 900 lines - I suspect I could compile that with cc65 for my Ruby system and get it under my "magic" 16KB limit for an application, but I've never tried. Things that irritated me enough (in old 8-bit BASICs) to make me write my own BASIC included upper/lower case issues, spaces being significant in some places but not others and general inconsistency. These add cycles and bytes to an interpreter no matter what language it's written in. I can afford that in my BASIC as it's in C and targets Linux or 'baremetal' Raspberry Pi hosts, but it starts to become an issue in our 6502 world... And then there are the horrors of decoding PS/2 keyboards and country codes... Sometimes sticking a serial terminal on your SBC doesn't seem like a bad idea after all... (which I do for my Ruby boards)

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

My two cents is that languages like BBC BASIC - warts and all - are well-proven and you shouldn't be shy of just using them. If the quest is for a perfect teaching tool though, leading directly into modern languages, it probably won't be something you'd run on a 6502!

My kids have learned via Scratch and python, successfully I think, and my son is just starting a comp sci A level based on C. If I was teaching them I might have taken a different route, but I'm not a teacher, don't have time either, and I'm happy enough with the tuition they're getting. If I wasn't, then maybe I'd step up more!

Something else about 80s era computers is the enforced crudity of what you produce - the inherent limitations of the machines mean that there's a fairly level playing field, you can enjoy making graphical things without worrying about your art skills. I feel that modern systems provide too much fidelity and this can hamper people's learning.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Labels aren't hard to do. One way to do it would be to have a LABEL keyword followed by a name. You'd have to make some decisions - is that keyword allowed only at the start of line? That would make it easier and faster when scanning the program looking for it, and easy enough to implement if you don't allow multiple statements per line, but what if you do? Should it be allowed to use a label in the middle of a line? If not, what are you going to do to enforce that? If so, searching will take longer because you'll have to scan the entire line when searching.

Atari BASIC allows long variable names (so does COMAL). Names are added to a table when first encountered, then replaced in tokenized lines by a reference to their location in the table, saving space in the program text and still allowing proper listing. The main problem is naming a variable and then deciding later to change it or not use it at all. The old name is still in the table, taking up space for no good effect. What are you going to do about that? A secondary problem is that it's easiest to limit the number of names to 256 (at least on eight-bit machines). That's enough for most small programs, but sooner or later someone is going to want them all.

Me, I'd want local variables in BASIC subroutines. A simple scheme might be to allocate a "hidden" array every time a new depth in subroutine calls is reached (once allocated, never de-allocated until garbage collection time). Just big enough to hold all the single-letter variables A-Z and possibly A$-Z$. For Commodore BASIC's five byte floats and two byte string pointers, that would take 26*7 = 182 bytes for all of them, each at a convenient fixed offset from the start of the array for fast access.

Hmm. If the allocation was by a DIM-type statement instead of implicit by subroutine calls, and it wasn't used, then there would be only one such array, allocated at RUN time. Effectively all the single letter names would be global, just as in most BASICs.

I'm planning on making a 'new' simplified BASIC in 6502 assembly, if that counts.

I've been thinking about this for quite a while now. You all have helped me a lot in this process. I have some fantastic ideas for my own version of BASIC but I don't think I'm ready to show my whole hand yet (it has yet to be coded!). Some key points is that it will only use minimal keywords (IF...THEN, GOTO, PRINT, INPUT, LIST, RUN), all variables are treated as arrays or strings, NO special symbols required, and line numbers for editing. I'm hoping it will fit within a few KB of ROM, and use about 8KB of RAM for variables and program space.

I hope to have something to present to you soon-ish, but life is so super busy right now for me.

Thanks for the discussion here, it has been very fruitful.

Chad

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Oh, I didn't mean any of that as challenges, just as design decisions that have to be made once you decide to implement a specific feature.

From an implementation point of view I don't think it would be that hard to allow a label in the middle of a multi-statement line, but I do wonder how hard it would be to pick out of a listing. Would it add to or detract from the ease with which someone who did not write the program could figure out what was going on? My first reaction is that it would be more difficult.

Perhaps another way to do it would be something like LABEL variable=line#, ie., assign names to line numbers. Along with long variable names, you get the readability without worrying about dealing with labels in the middle of lines. The keyword would also check to make sure line# exists, of course. Handiest to use it during program intialization, but there's no real reason it couldn't be done at any time. Should it be allowed to change the value of 'variable' once it's been used in LABEL? Hmmm. I suppose a flag somewhere could prevent it, but why not? If it causes a problem that'll show up quickly enough.

The main reason I'd want local variables is so I could keep re-using 'I' as a loop index no matter how deep subroutine nesting got. I'm pretty lazy that way.

M$ BASICs do only a minimal amount of tokenization and leave a lot of error checking to run time. TINY BASICs don't tokenize at all and leave all error checking to run time.

Atari BASICs, I think, do a lot of tokenizing and syntax checking at statement entry, leaving only things like division by zero as run time errors. But they do have the problem of variable name table clutter, solved by saving the program as plain text and re-loading (re-tokenizing the program and re-building the table). This could be done in-situ by a dedicated keyword, but that would make the interpreter larger (not a real problem for a 65816).

Don't forget SAVE and LOAD, unless you're content to re-enter your programs each time you want to use them.

This list does sound very much like TINY BASIC. And implementations are tiny, often around 2K or so. The smallest don't even have string variables, just string constants.

Or you might look at ANSI Minimal BASIC (https://en.wikipedia.org/wiki/Minimal_BASIC and https://www.ecma-international.org/publications-and-standards/standards/ecma-55/).

It's something that's been on my mind for a long time - that is a "new" BASIC for the 65C02 (Not the '816 as I'm pretty much done with that - unless I write it in the BCPL that runs on my '816 system!)

But like you, other things in my life just seem to thwart me - also, I already have my "ideal" BASIC, but that's in C which now runs on a bare-bones microprocessor system (ARM/Pi and hopefully soon RISC-V) and there's the effort of creating a cut-down version for an 8-bit micro... My initial sketches are based on my existing BASIC with 32-bit floats with no explicit integer type. Many questions including arrays - as a classic N-dimension array involves multiplies to access element (P,Q,R,S,...) or you use RAM to construct index tables. (Which we're short of!)

Apple Integer BASIC has one-dimensional arrays only, so one thought (for me) is, if that was good enough to write breakout and a good "Star Trek" game in, then it's good enough for me ... strings? garbage collection? I use malloc() in my C BASIC and let that manage it - there is no explicit garbage collection other than what free() might do to to join adjacent regions - and I did get as far as writing malloc/free/merge in Sweet16 at one point and simulating some string stuff with it gave me very good results. (and many other thoughts like that - like the main thought being more on a structured approach than speed or features). Which brought me to another ponder - write it in a higher level byte-code-ey language than native 65C02 assembler? Sweet16 isn't rich enough for that, but Acheron? It's another rabbit hole to vanish down...

Anyone interested in seeing what my BASIC looks like can have a look here: https://unicorn.drogon.net/wumpus.rtb It needs a 2-D array, but actually not hard to emulate if the BASIC only supported 1-D arrays.

Not sure what I'm going to do next in the 6502 world though - my own world has changed somewhat in recent times.

Of-course, there's always VTL!

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

Early on I wrote a standalone version of PLASMA that included an editor, compiler and minimal runtime to play around in a sandbox. I hoped to someday have the editor tokenize the entered text so that the compiler had less to do before running the program (or interpret the tokenized source directly), but I doubt I'll ever get around to that. Here is a video of me showing off the sandbox at KansasFest:

https://archive.org/details/Kansasfest2 ... maLanguage

Maybe there are some ideas you can take away from that.

Just an update on things:

Attached is a picture of my simulator showing off some BASIC!

So far I have most of the keywords done: LIST, RUN, NEW, IF...THEN, GOTO, PRINT, and setting variables with math operators. I haven't yet got INPUT, still deciding on how to do that.

This features up to 254 line numbers possible, 8 variables (each acts like an array of 256 bytes), decimals from 0 to 255 (no support for negatives), and as of yet, has no support for variable strings. How awesome is that?!

BUT, it's designed for teaching my 4 yo how to program. And she wrote her first "hello world" program earlier, with my assistance of course. One keystroke at a time!

There ya have it. Might or might not update y'all on further progress. Thanks everyone!

Chad

Well done!

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I think I finished my "Acolyte BASIC". I now have all required math operators and INPUT (decimals only, no string input) as well. Fixed some bugs along the way of course. Attached is a picture of a "primes" program.

I find that doing:
PRINT "This " : PRINT X : PRINT ". That.\"

kind of annoying. I'd rather have:
PRINT "This ", X, ". That.\"

I might work on that soon, it wouldn't be the hardest thing to implement. We will see.

So, if you are reading this, can I get some suggestions? I want to have a dozen or so basic programs that do something fun. Finding prime numbers was a good example. Anything else that could show off my BASIC and still be simple overall? Wasn't there a Hammurabi game that was pretty easy to create? I'm not looking for code from you, just ideas like, "Find prime numbers!" or something.

Thanks everyone!

Chad