Why does this not error out (XB)

[jrhodes]

Not really sure if this should go here or ti development. I am not really developing anything, just noticed some really strange behavior and would like to know why it does it.

I have seen @,[,] and even _ used as variables, so i decided to try using some other characters as variable names.

While i did not receive any errors when giving them a value, i am unable to do anything with them.

Please look at the attached picture.

any attempt to use them, like PRINT {, gives a unrecognized character error. Why did i not get that error upon trying to name the variable?

In the above listing, the program has to execute through the lines containing these "variables", but it never errors.

 

Entering them as a line in a program seems just fine (I.E.: 1 ~=1) but trying to enter ~=1 outside of a program, errors of course, like i would expect it too.

 

Is there anything interesting this could possibly be used for, other then taking up program space?

I know variables have to be stored in memory, so perhaps it would be possible to assign one of the variables a value, and then find it in memory and do something like adding it to some other variable?

Say for instance we have a "variable" named ~, and we give it the value 65. Then we find where "~" is in memory, and do something like "PRINT CHR$(PEEK(where ever the ~ variable is at in memory))" to get the program to print an A character.

[Casey]

While I don't have an answer to your question, it is interesting what has this behavior and what doesn't. TI BASIC returns a * BAD NAME error with any of lines 1-4. Extended BASIC V100 won't let you type these characters at all so you can't create lines 1-4. Extended BASIC V110 and RXB both behave the way you showed above. You can enter the lines and they'll RUN but not do anything. Entering them without a line number produces an error. Extended BASIC V200 (in the 99/8) returns a * Unrecognized character error with any of lines 1-4 also, so it appears TI fixed this when they were working on the 99/8. I didn't try any of the other Extended BASICs but I presume they'd all work like V110.

[+Schmitzi]

Maybe they "can" be used as variables (just setting them),

but cannot be re-used further because of the basic´s syntax (error) ?

Something like this ?

[RXB]

This is like you using you TV remote as a hammer, yea you can do it but why?

 

Valid Variable labels are not listed in the XB Manual at all, oddly this is a real oversight.

 

I do think they are listed somewhere but do not remember where or by who.

 

Keep in mind the XB version 100 was for the TI99 and XB version 110 was for the TI99/4A

 

Just to explain this may have been the problem taken from GPL Extended Basic Source Code:

TOPLEV CLR  V@>0370           Initialize temp area
       MOVE 77,V@>0370,V@>0371
       ST   5,@KEYBD          Select full keyboard 
       SCAN
       CZ   @KEYBD            99 Console?
       BR   G6388             99/4A Console?
       ST   >01,V@CONFLG      Select 99/4A console
G6388  CLR  @KEYBD            Reset to default
       DST  NLNADD,V@BUFSRT   Initialize edit-buffer start
       DST  NLNADD,V@BUFEND   Initialize edit-buffer end
       MOVE 2,G@ATNZZ,@INTRIN Get address of ATNZZ
       AND  >1F,@INTRIN       Throw away the BR opcode
       DADD >5B,@INTRIN       Address of polynomial constants

The TI99/4A has key scan from 0 to 5 and the TI99 only had key scan from 0 to 4

 

I think a proposed Extended Basic version 120 would have added repairs to this problem and only worked on TI99/4A or the TI99/8

 

Just look at this keyboard: https://en.wikipedia.org/wiki/File:TI-99-4_homecomputer_(adjusted_version).jpg

 

You can see this explains exactly why you ran into this problem in the first place!

Edited April 14, 2018 by RXB

[Casey]

Interesting:

 

1 {=1

2 {={+1

3 {=A

 

Extended BASIC 110 will accept lines 1 and 3 but reject line 2. Has to be a bug in the syntax parser.

[RXB]

Interesting:

 

1 {=1

2 {={+1

3 {=A

 

Extended BASIC 110 will accept lines 1 and 3 but reject line 2. Has to be a bug in the syntax parser.

Hmm I just explained the issue above, but maybe you replied before I had edited my reply,.

[senior_falcon]

 

Valid Variable labels are not listed in the XB Manual at all, oddly this is a real oversight.

 

 

Page 39 at the bottom:

"The first character of a variable must be a letter of the alphabet, the at symbol or an underline. Subsequent characters may be those symbols plus any of the digits..."

[+OLD CS1]

Hmm I just explained the issue above, but maybe you replied before I had edited my reply,.

 

To expand, the problem Rich demonstrated is those characters, with the exception of the "pipe" character, I believe, are not defined on the 99/4 (like the braces, "{" and "}", in particular.)

 

What is interesting, though, is the assignment lines are accepted but any manipulation or use is rejected. I do not care so much about those mechanics as I am more interested as to whether a variable table entry is made for them during assignment.

[+OLD CS1]

I tried to be sneaky:

 

1 FOR {=1 TO 10

 

Which returned

 

* UNRECOGNIZED CHARACTER

[+OLD CS1]

I just determined that, yes, Extended BASIC does indeed create a variable table entry for these invalid characters on the stack.

 

 

1 {=1
2 }=25
3 GOTO 3

 

In VDP RAM when run:

 

 

37C8: 37 CF 37 CE FF B7 7D 00 7.7...}.
37D0: 01 00 00 37 D7 FF BF 7B ...7...{
37D8: AA 3F FF 11 03 00 00 00 .?......

[RXB]

 

I just determined that, yes, Extended BASIC does indeed create a variable table entry for these invalid characters on the stack.

1 {=1
2 }=25
3 GOTO 3

In VDP RAM when run:

37C8: 37 CF 37 CE FF B7 7D 00 7.7...}.
37D0: 01 00 00 37 D7 FF BF 7B ...7...{
37D8: AA 3F FF 11 03 00 00 00 .?......

 

This picture alone explains why these characters can get past the interpreter as they did not exist

in original TI99 till even after the TI99/4

 

https://en.wikipedia.org/wiki/File:TI-99-4_homecomputer_(adjusted_version).jpg

[+OLD CS1]

I got that, I just wanted to see if there were more firewalls and if assumptions were made about the validity of data. You know, a little reverse-engineering

[+Schmitzi]

Though, maybe there is a trick to use them as variables (and not only to set them) ?

 

If you manipulate or compare !%strings%! in DOS/Batch, there are also some restrictions on special characters,

and in some cases there is a way around by using i.e. ^ or ^\ , setting them in front of the restricted character....

[+OLD CS1]

Maybe. So far as I know, the only character escaping is the extra double-quote in a quoted string to print a double-quote. Rich can probably answer to that as he has the XB source code burned into his brain.

 

That is,

 

PRINT """HELLO"""

 

prints

 

"HELLO"

[+Schmitzi]

The ^ is needed for the pipe | in a batch -> ^| and there were some more.

I would have to check all my batches, but this would not help here.

 

like

FOR /f "tokens=3 delims= " %%G IN ('%_ping_cmd% ^|find "ytes"') DO SET %IPprefix%%suffix%=%%G

[RXB]

Maybe. So far as I know, the only character escaping is the extra double-quote in a quoted string to print a double-quote. Rich can probably answer to that as he has the XB source code burned into his brain.

 

That is,

 

PRINT """HELLO"""

 

prints

 

"HELLO"

Well not to get complicated with showing all the GPL code this is the result of GPL looks for another " (quote mark)

to match the first one found.

Example: PRINT """"

Will print 1 " (quote mark)...??? I count 4 of them but it prints 1?

Example: PRINT """"""

Will print 2 " (quote mark)....??? I count 6 of them but it prints 2?

Example: PRINT """"""""

Will print 3 " (quote mark)...??? I count 8 of them but it prints 3?

 

And so on. A very strange form of logic here.

[+Schmitzi]

I think it´s just because of the syntax from the interpreter (like I ""know"" from DOS batch commands)

like the nature of things. " is a special character, specially to be handled.

[apersson850]

The logic isn't strange. A pair of " delimits the string. Like "Anders".

To put a " inside a string, you have to used it as a pair, "", or it will terminate the string instead. To understand why eight " will print three, it's easier if you add some more characters. Like this: PRINT "(""+""+"")". This will print ("+"+"). Now remove parentheseis and the plus characters, and you have the printed result """, entered as """""""".

[+mizapf]

Number_of_shown_quotes = (number_of_quotes - 2)/2

 

(minus 2 for the outer quotes, all inner quotes are doubled)

[jrhodes]

Longest i could get XB to accept

[+Schmitzi]

[apersson850]

Longest i could get XB to accept

Screenshot.png

 

Do you mind if I quote you?

[jrhodes]

 

Do you mind if I quote you?

Don't mind at all :-)