6502.org

In my PDP11 implementation of BBC BASIC, READ and INPUT are both slightly different entries to the same code that falls through into assignment (LET).

I've occasionally needed READ as a function, and have done it with eg: DEFFNread:LOCAL A$:READ A$:=A$

Not really. Let's add this line to my original example:

Not really, however I'm not sure you quite understand - but I'll keep banging the drum - this is TinyBasic. Variables are one character only. There is virtually no string handling. It was designed to fit into as small a memory footprint as possible, (c1975) so things have to compromise. At one point, I was desperately trying to save just one byte in the EEPROM - It's just 4KB and at that point in time I had all the serial IO routines as well as the TinyBasic interpreter. I spent weeks "code golfing" to save enough bytes to add new commands into it to control the GPIO pins, and so on. The original would run in under 3KB of RAM on an 8080, leaving just 1KB free for your program. You would happily put up with features like this just to be able to sit back at your own computer and run a BASIC program.

So the side-effect of calling the evaluator on an input string is just that - a side-effect. It would add a few more bytes to the code if I were to call the number parser, then push that into the arithmetic evaluation stack, then pop if off into a variable when there is one routine that can do all that and more. This is code re-use at quite an intense level.
Maybe you need to think about the time when this was written - 1975. We had virtually no memory in the systems then - 4K was a luxury for a home user and compromises were made and understood.

Sure, today with GB of RAM, you might well say why bother, but sometimes it's nice to remember history as it was.

I do have another BASIC interpreter which I wrote from scratch, but it's in C, needs Linux and a good system to run. It solves all these issues, but there is no-way it's ever going to run on a 6502. Not even a 65816 with 16MB of RAM. The alternative today? Well, MS Basic is out there, as is the infinitely superior BBC Basic, also the Paul Robson Basic(s) for the 6502 and '816. go for it.

-Gordon

I understand memory constraints very well. We are all on the same forum, after all

I just could not understand how that 'input evaluator' could be a feature. Now, compromise on the side of code size, that I can understand very well:-)

Rudla

At some point, a feature is anything that could be useful for something

An old trick was simulating character input through expression evaluation:

10 Y=1
20 N=0
30 PRINT "OK? (Y/N)";
40 INPUT A
50 IF A=Y THEN PRINT "YES"
60 IF A=N THEN PRINT "NO"

This isn't quite what I was thinking of. In this example 'A' is simply a numeric variable; there is no expression evaluation going on in line 40 as there is in lines 50 and 60. I was thinking more of something like:

10 Y=1
20 N=0
30 PRINT "OK? (Y/N)";
40 INPUT A+1
50 IF A=Y THEN PRINT "YES"
60 IF A=N THEN PRINT "NO"

I have to say; The above 2 posts are actually very creative ways to do something. So even in a limited/restricted environment things can be made easier.

Cheers,

-Gordon

In VTL-2, this might be done like so, with its analog for MS BASIC's "INKEY$" (or perhaps more accurately, "GET"):Back on topic, VTL-2 offers a non-portable way of READing embedded data with comments and out-of-bounds array accesses, e.g.: