Well done!



I think it's hard to get some simple programs to engage a young person without being boring (like find prime numbers!) however times tables? Maybe see what she's currently learning at school/nursery/whatever it's called where you are?

If she's bright then some of the old 2D games from Creating computing? (PCC?)

https://bluerenga.blog/2019/03/15/befor ... nark-1973/

Or even Hunt the Wumpus if she can visualise a dodecahedron (although the classic version of that requires an array to manage the room data)

https://unicorn.drogon.net/wumpus.rtb

What about "snake" ? that may require some extras adding into your dialect - inkey (to see if a key is pressed) and text-mode character positioning...

Cheers,

-Gordon

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

Very nice! Some very random ideas:

• Hangman
• Tic-tac-toe
• Snake (always a classic)
• Arithmetic trainer
• ASCII charset explorer (useful for learning how text display works!)

Edit: I see that Gordon beat me to snake

Just out of curiosity, I see "GOTO 100" in the listing, but not a line 100. That not finding that line seems to be a termination condition, as there is no error message. Is that the default behavior when not finding a line, or does it have to be greater than any existing line?

It's your version of BASIC, of course, but wouldn't it be more intuitive to have an explicit "END" statement? I think it would be pretty easy to implement and, for what it's worth, subjectively more satisfying.

Part of learning is making mistakes, and it's nice if a beginning programming language can respond to them more or less gracefully. A message along the lines of "I can't find line (#)" (instead of "LINE NOT FOUND ERROR"), might be something to think about.

Personally, I'm OK with somewhat terse errors like that, but I grew up with them....

I did see some complaining about something like this recently on a facebook thingy - I suspect it all stems from the days of "4K BASIC", etc. when RAM was expensive, so things needed to be terse, but today in a modern 6502 system we ought to have more than enough RAM to give nicer error messages, but old habits die hard!

-Gordon

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

Advent of Code is a nice source of fairly simple programming exercises, I'm trying to get my son to try it in various languages for practice.

In the late 1970s I started with WHAT? HOW? and SORRY on the 4KB TRS-80 model one level one. The excellent paper-and-ink documentation that came with the system was quite helpful in clearing up the confusion, but couldn't help much with the disappointment.

VTL02 is incapable of producing an error message. If your program commands it do something it can't do, it quietly and politely does something else it can do.

_________________
Got a kilobyte lying fallow in your 65xx's memory map? Sprinkle some VTL02C on it and see how it grows on you!

Mike B. (about me) (learning how to github)

From what I have seen in a quick online search, ehBasic is basically, "free to use, not free to sell":

... or in effect, Creative Commons Attribution-Non-Commercial, but without all of the legal boilerplate.

Good suggestions, thank you. I like your wumpus game, but it does take visualization. The snake game is *currently* not possible because, as you said, inkey and text-positioning needs to be a thing. I had planned on putting those in, but stopped because of a few reasons.



Good ideas, thank you. I already have a 'scratchpad' program, where you can freely type any keyboard characters on the screen, wherever you wish. Is that like the charset explorer?



All very good points. Yes, the GOTO 100 basically goes to an empty line, which is ok because it will check for all 255 lines possible in it's designated code area. This makes it super slow without an END, so typically I've been using GOTO 255 to indicate the end.

I don't want to put in "END" because it uses a "D" which is a variable name. This program is very picky about letters!

And... it has no error detection at all.



Just as Mike talks about, my program does whatever it *thinks* is right. No errors at all.



Yep. Mine is nearly at the 4K mark right now. And I'm happy with that

So, another 'feature' I haven't told y'all is that keywords do not need to use all letters, so a re-coding of the previous primes example could look like:



This allows for compressed data, so you can fit more program into the little RAM available (I think I have 10K set aside for as program/variable RAM).

Thank you for the suggestions. I'll be working on this throughout the days.

Chad

Many games are going to require a source for random numbers. Have you implemented that yet?

Once you do that, a very simple game is high-low number guessing. This is what I wrote in Python:

https://talk.dallasmakerspace.org/t/pro ... /18852/161

Thanks for that, that's a simple idea that's good.

I do have random number generation. I was *highly* inspired by MINOL BASIC, a little-known variant that does a lot of what I do. It uses the ! symbol for random numbers, so that's what I used too.

Also, while I had the time, I decided to add a 'control break' by hitting Escape while running. That is good when you want to test it out with:



I'm sure I'll add another little improvement here and there, but overall it's done. Thanks everyone! I'll show source code and all that eventually, when I'm ready to present my next creation.

Chad

Hi!


Very late reply

What means "simplified"?

IMHO, my FastBasic ( https://github.com/dmsc/fastbasic ) is simple to program in, and very small (8kb for the full integer-only IDE).

It does not have line numbers, instead it uses a full-screen IDE (written in the same FastBasic), and it support many structured programming constructs:
- DO/LOOP, WHILE/WEND, REPEAT/UNTIL.
- Procedures with parameters (PROC/ENDPROC, called with EXEC or simply @).
- Arrays of floating point, integers, bytes and strings.

Also, it supports all Atari graphics commands, it has commands for sprites (Atari P/M graphics), and raster effects (DLI in Atari parlance).

I want to create a "barebones" version, but as it is written it needs support for input/output for the IDE, the porting should need:
- Support for print at given row/column, do cursor movement and insert/delete.
- Support for file load/save.
- And to allow compilation to a new binary file, it also needs the OS to support some form of binary-loaded file format.

Here is a video from one user: https://www.youtube.com/watch?v=mMRcxHKqFUU , there are also a few tutorials.

Have Fun!

Just looking at your program, line 40 should have produced an error as the target for "GOTO 100" does not exist. This could cause problems down the road.

_________________
Bill

So, as Mike Barry was saying, this program will not give an error, ever. It will do what it thinks is best, even if that was not expected.

GOTO 100 when there isn't a line 100 means that the program will be looking for line 100. When it doesn't find it, it looks for line 101, then 102, ... and eventually it stops looking at 255 because that's my max line number. So, I probably should have said "GOTO 255" in the program so that I exit much quicker than from a "GOTO 100".

*shrug* That's just how I think I guess. Thank you.

Chad

Interesting approach. It my make troubleshooting difficult for a child though.

_________________
Bill

As someone who has worked on BASIC interpreters and compilers, that is not a good idea. It is very easy to just report that the target line does not exist and easy for the programmer to understand and fix the error.

Trying to do "something reasonable" to avoid reporting an error will just end up in a mushy mess of not truly deterministic spaghetti code.

Consider this: you try to enhance the program in the future and insert a new subroutine starting at line 200...