READ, DATA & RESTORE in my TinyBasic ...

[jgharston]

BigEd wrote:

An interesting thing, that READ as a verb doesn't fit too well - I think the solution of making it a function is pretty good.

I note that BBC Basic (and probably others) can do
READ A, B, C
which is quite handy.

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$

[rudla.kudla]

drogon wrote:

rudla.kudla wrote:

In case of input, this is, i believe, very undesired 'feature'. Especially, if the expression evaluator in this case can reference variables.

For example:

Code: Select all

>LIST

10 JOHN = 30
20 INPUT A
30 PRINT A

>RUN
?JOHN
30

This renders input almost useless.

Rudla

It's a feature.

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

Code: Select all

15 PRINT "Enter your name:"
[\code]

Now all John's are out of luck.

Having an option to evaluate a string is superb feature to have, but EVAL operator would be, in my opinion, much safer option for this than INPUT. And with much wider use...

Of course, i understand, it would cost some bytes, so it may be hard to include.

Rudla

[drogon]

rudla.kudla wrote:

drogon wrote:

rudla.kudla wrote:

In case of input, this is, i believe, very undesired 'feature'. Especially, if the expression evaluator in this case can reference variables.

For example:

Code: Select all

>LIST

10 JOHN = 30
20 INPUT A
30 PRINT A

>RUN
?JOHN
30

This renders input almost useless.

Rudla

It's a feature.

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

Code: Select all

15 PRINT "Enter your name:"

Now all John's are out of luck.

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.

Quote:

Having an option to evaluate a string is superb feature to have, but EVAL operator would be, in my opinion, much safer option for this than INPUT. And with much wider use...

Of course, i understand, it would cost some bytes, so it may be hard to include.

Rudla

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

[rudla.kudla]

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

[gfoot]

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

[zu2]

teamtempest wrote:

It might be possible to allow a "feature" such as INPUT being able to evaluate expressions, but why? Doesn't PRINT already offer this same capability in a way much less likely to cause trouble?

Is there some code savings to be had this way? Possibly in the form of reduced error-checking, which would seem to be the exact opposite of what a beginning BASIC user would find useful?

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"

[teamtempest]

Quote:

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"

[drogon]

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

[barrym95838]

In VTL-2, this might be done like so, with its analog for MS BASIC's "INKEY$" (or perhaps more accurately, "GET"):

Code: Select all

10 ?="OK? (Y/N)";
20 A=$) snag and echo a keypress
30 #=A=89*50) ascii "Y"
35 #=A=78*60) ascii "N"
40 $=8) erase invalid entry
45 #=20) and try again
50 ?="ES") auto-complete the response
55 #=70
60 ?="O") auto-complete the response
70 ) proceed with 89 or 78 in A ...

Back on topic, VTL-2 offers a non-portable way of READing embedded data with comments and out-of-bounds array accesses, e.g.:

277d2a8a45b74c1dda3bcd61b6c2bb7e643dd8ac.png (6.48 KiB) Viewed 618 times