6502.org

So looking to implement READ, DATA and RESTORE in my TinyBasic (Now that I have a little more space after freeing up over 250 bytes by using the "monitor" IO routines)

DATA is easy - it's the same as REM - you skip over the line at run time, no parsing, nothing. Prefer putting the DATA at the end to help improve GOTO speeds, etc. as was the case in other Basics so it's never executed anyway.

RESTORE is just as easy (set the data pointer to the start of the program text - need to do on RUN and CLEAR too)

But then READ.

(Note for the following: There are no real arrays in my TinyBasic; the ? operator is poke byte - so ?(A+4) = 42 means poke 42 into the address represented by the value of A plus 4)

Classic Basic has it looking like:
to copy the next item of data into variable V. (Let's quietly ignore the linear searches for DATA, comma, etc. for now).

However in (my) TinyBasic world it would be just as easy to use
In the same way I use V = LED or V = TOP, or V = BTN and so on.

Filling an array the "classic" way:
vs. my (potential) TinyBasic way
It won't be easily possible to use
which would be like a classic Basics
statement - because that looks like a fetch to TinyBasic rather than a store.

Any thoughts or opinions?

Cheers,

-Gordon

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.

Been mulling it over this afternoon... Yes, most BASICs can handle multiple variables.

Also, looking (as ever) to re-use code, I did realise that there is an existing instruction that would work like READ A and that's INPUT A ... And most Basics can INPUT A,B,C, ... however there was a minor issue I found way back with this, so I omitted it - single variable input only.

But maybe it's time to fix that now as input and read might well use a lot of the same code....

it's just a minor inconvenience to fill an array from DATA doing it the "classic" way, although weirdly, I can, if I want to do it both ways; A=READ and READ A in the same way I can do LED=V and V=LED ... What's a few more bytes of code amongst friends ...

-Gordon

The READ and INPUT keywords in (at least) Microsoft BASICs do share a lot of the same code. Which is reasonable since they are both requests for data. The main difference is that the INPUT source can be interactive from the user or from a file on mass storage , but READ will only take its input from a DATA statement.

Yes, the simple way to implement RESTORE would be to set the READ pointer to the start of the program text. However if it takes a line number as an argument (like GOTO or GOSUB) and sets the pointer to that line, READ acts like a kind of poor man's random data access. The BASICs on TRS computers were able to do this, and I've seen it used it to avoid having to copy all DATA items to variables in memory (so effectively they are stored twice, once in the program text and once in memory). Some text adventure games, for instance, or ELIZA-type programs, to enable the program to give long answers to user input.

ZX Spectrum Basic allowed using of expressions in DATA statements, which was sometimes quite handy.
Depending on how your code is organized, it can be even simpler, than allowing just constants.

Classic VTL-2 doesn't have any direct analog for READ or RESTORE, but its analog for INPUT does allow one unsigned number or numeric expression per invocation. Comments are fine for storing all forms of DATA but READ and RESTORE require carnal knowledge of out-of-bounds array accesses and manual translation of the ASCII comment to whatever the final format of the data will be ... although it wouldn't be super difficult to maintain a separate data pointer and temporarily usurp the program text pointer for each "READ", which is similar to what "INPUT" does already. One issue that comes to mind is that the comma character is a valid variable name and operator in VTL-2, so reusing the "INPUT" code verbatim would limit us to one data element per comment, with the associated overhead.

I've not looked at VTL in detail, but my TinyBasic does similar - mostly due to re-use of code, and (I suspect) some slop from an earlier incarnation of the IL (Intermediate Language) that TinyBasics are written in... So:
And yes, there is an issue with commas here too, but it's not to do with variable names (@-Z only)

-Gordon

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

For example:
This renders input almost useless.

Rudla

It's a feature.
I could, relatively easy remove this feature, it it makes for a very easy calculator...

-Gordon

Absolutely. Sometimes the difference between a defect and a feature is just a matter of proper documentation.

Also, it's TinyBasic. Squeezing a recognisable BASIC into - well originally, under 2K on the 8080 and I can get mine to about 3K on the 6502 if I drop a few features - it's currently 3.75K or 4K including the serial IO routines.
Maybe I'll see if I can squeeze VTL into the monitor ROM I have on it... I do recall the last time I tried to get it going that its zero page usage was somewhat creative though...

Cheers,

-Gordon

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?

Lots of code saving. This is TinyBasic, after all.

Welcome to Nightmare #6. You have 4000 bytes. Your move:

-Gordon

I would like to do a deep dive into Tiny BASIC (and someday create my own 24-bit float version), but I'm too distracted with real life at this point of my development into an old man. But I can tell you why VTL-2 does it -- code reuse.

All VTL-2 statements (with three exceptions: null statement, comment and print literal string) are of the form variable=expression. An expression is either a term or two-or-more terms separated by binary operators, evaluated strictly left to right. A term is a numeric constant, a variable (simple or array), or a parenthesized sub-expression. By doing this consistently, the input term naturally falls into the same category with all other terms in the evaluator.

It has been years since I studied it in detail, but I think the original 6800 VTL-2 only had one exception: print literal string. Null statements and full-line comments were "evaluated" just like any other assignment statement, and the "result" was placed in the NULL or right parenthesis variable respectively. Trailing comments were "evaluated", and the "result" was discarded. That's one of the main reasons why the entire editor and interpreter fit into 768 bytes. That, and a 16-bit X register and 16-bits worth of accumulators. I knew that I wasn't clever enough to shoehorn the 6502 version into 768 bytes, so I set my sights on <1KB and added several "bells and whistles", including a proper cold start program initialization, the analogs of PEEK/POKE, and five new operators, along with a few performance enhancements. Oh, and accidental divide-by-zero "errors" won't paralyze my 6502 version, which is quite a nice performance boost ... it just keeps calm and carries on (A/0 returns 65535 and sets the remainder to A).