Crazy TI Basic Problem

[unhuman]

This is really strange...

 

10 CALL KEY(1,K,S)

15 PRINT K

20 IF K=0 THEN 40

30 GOTO 10

40 PRINT "BYE"

 

When pressing the X key - it prints K=0, however, line 20 doesn't match.

 

However, if I switch line 20 to be

20 IF STR$(K)="0" THEN 40

Then it works

 

And, the former case works perfectly in XB

[InfernalKeith]

Without having my reference card handy, does it have anything to do with the side of the keyboard read when you specify (1,K,S) (as opposed to 0,K,S)? I've used (0,K,S) for so long, I've forgotten what the other numbers in that first spot even do, but isn't it something about only reading from part of the keyboard? Maybe it just doesn't expect to see certain values in that case? Shot in the dark here.

[unhuman]

No idea. Print K prints the correct value... Just seems like the value isn't quite right. I use 1 instead of 0 since I'm checking the joystick fire button. I want to re-use the same CALL KEY result for a different function (but still the single CALL KEY). I have not experimented with 0 in BASIC.

 

K is an integer value - and the comparison should "just work" in my mind...

 

-H

[+OLD CS1]

Were you using a real console? Mine's disassembled ATM. Tried in Classic99, same results as you. In fact, even INT(K)=0 and K*1=0 did not work. Now, if you do something like K-1=-1, that works.

 

Interesting, indeed. Kind of like the whole SQR(9)=3 being false thing (this is in the Users Guide.)

[unhuman]

Just Classic99. However, it affected my game, so I gotta do the STR$ workaround... but I'd just like to know why... Haven't tried on a real console.

 

However, for me (in Classic99)

10 IF SQR(9)=3 THEN 30

20 END

30 PRINT "MATCH"

 

Prints MATCH for me...

[+InsaneMultitasker]

I seem to recall reading about a bug in BASIC where comparing to zero doesn't always work properly? For the life of me, I do not recall where I came across it. There may have been mention of this in the forum, too.

[+InsaneMultitasker]

I remembered one place I saw a blurb about the problem: COMPUTE!'s TI COllection Volume One (referenced in the pinned forum topic) page 13:

 

"There is a slight problem in testing for zero in the TI-99/4A console. Use logic such as IF K+1<>1 rather than IF K<>0."

 

Perhaps others will shed some light or recall other references that may help to clarify?

[Tursi]

This was a documented error, though I can't remember offhand where (I think I have it in one of my BASIC manual addendums.) The problem is that there are two ways to specify 0 in the Radix notation that TI BASIC uses, and (I think it was specific to CALL KEY) returns the wrong one. But yeah, you can still do valid math on it and test that way, should be faster than the string compare? (Not tested).

[+OLD CS1]

This also works, and I would expect a similar method to be marginally faster than the string compare. In particular, if you used a ON K+1 GOTO, you only have to worry about 18 different results so you can easily null-route or even incorporate a simple quick compare. Hell, K=K+1 before making your comparison and decisions would probably work out, too.

 

10 CALL KEY(1,K,S)
20 IF S=0 THEN 10
30 PRINT "K=";K
40 IF K>-1 THEN 60
50 STOP
60 PRINT "YES!"
70 END

Edited December 17, 2010 by OLD CS1

[unhuman]

Yeah - I'm trying to find a specific key, so > check isn't quite valid... And I'm in plain old basic.... But, since it's a known issue, I'll just move on. Just amazed at how bad that is... Someone at TI should get fired for this.

[+OLD CS1]

Yeah - I'm trying to find a specific key, so > check isn't quite valid... And I'm in plain old basic.... But, since it's a known issue, I'll just move on. Just amazed at how bad that is... Someone at TI should get fired for this.

 

Yes. They should But IIRC (without scrolling up the thread,) I think Extended BASIC fixed the problem.

[unhuman]

Yes. They should But IIRC (without scrolling up the thread,) I think Extended BASIC fixed the problem.

 

Yeah - noted that in my initial post

[+OLD CS1]

Yes. They should But IIRC (without scrolling up the thread,) I think Extended BASIC fixed the problem.

 

Yeah - noted that in my initial post

 

+2 to me for laziness.

[Tursi]

Yeah - I'm trying to find a specific key, so > check isn't quite valid... And I'm in plain old basic.... But, since it's a known issue, I'll just move on. Just amazed at how bad that is... Someone at TI should get fired for this.

 

If it's any consolation, they probably don't work there anymore. But since Microsoft wrote it, maybe someone at Microsoft should be fired. (Actually, if I read the history right Microsoft hired a contractor to do it.)

[unhuman]

Yeah - I'm trying to find a specific key, so > check isn't quite valid... And I'm in plain old basic.... But, since it's a known issue, I'll just move on. Just amazed at how bad that is... Someone at TI should get fired for this.

 

If it's any consolation, they probably don't work there anymore. But since Microsoft wrote it, maybe someone at Microsoft should be fired. (Actually, if I read the history right Microsoft hired a contractor to do it.)

 

Oh - I don't think the developer should be fired. The tester and/or the management that permitted such a bug through...

 

Anyhow, it is interesting that X+0 doesn't affect the "badness" but X+1 does. Guess I'll be using that instead of STR$

[unhuman]

One interesting note:

IF K+1=1 uses up one more byte than if STR$(K)="0"

[+OLD CS1]

One interesting note:

IF K+1=1 uses up one more byte than if STR$(K)="0"

 

True, but the numeric-to-string conversion and subsequent string comparison I believe takes more time than the math and compare. Any thoughts on this hypothesis?

[Opry99er]

Throw it in a loop and see how long a hundred passes of each takes.

[+OLD CS1]

Throw it in a loop and see how long a hundred passes of each takes.

 

Thanks. I was hoping for something more technical, like, "well, the source for BASIC shows that the string conversion should take 45ms, and the comparison takes 5ms, but the straight numeric comparison takes 15ms, so it is all-around quicker to use the numeric comparison."*

 

* These are not real values

[Opry99er]

I'm not your guy then. I can come up with ways to make stuff "work," but couldn't tell you precisely WHY it works. .

[unhuman]

I'm not your guy then. I can come up with ways to make stuff "work," but couldn't tell you precisely WHY it works. .

 

me either.

[Tursi]

It's more accurate to measure it than to try and figure it out from the source, in all cases, all systems, all codes. It may be /possible/ to calculate what it SHOULD take, but if you fail to factor in any variable, you'll be wrong. Only measuring the code is accurate.

 

That said, you just build a loop that runs 1000 times (or for very slow things, 100 times).

 

10 FOR A=1 TO 1000
50 NEXT A

 

Run that, and time how long it takes from start to finish (add some CALL SOUNDs outside the loop if you would rather have sound than display as the trigger - remember to use negative durations though!)

 

The time this takes is your baseline - it shows how long the for loop takes to execute. The nice side of using 1000 iterations is that the number of seconds it takes, you divide by 1000 and get milliseconds, a nice convenient unit. In TI BASIC this is usually 3.

 

Now add the function you want to test into the FOR loop and run it again. For instance:

 

10 FOR A=1 TO 1000
20 K=K+1
50 NEXT A

 

Run it again, and subtract '3' from the time you get. That gives you the average number of milliseconds it takes to execute "K=K+1".

[Opry99er]

That's kind of what I had in mind, Tursi--- but you (as usual) have the ability to make a general concept into a very easily understandable set of instructions.

 

Listen to the Lion here, OLD CS1.... That'll give you the "stuff" you need.

[+OLD CS1]

Listen to the Lion here, OLD CS1.... That'll give you the "stuff" you need.

 

No doubt, I just enjoy my habit of over-thinking and over-engineering, I suppose. I sometimes dig through my 6502 code bumming instructions here and there to reduce the amount of time spent in IRQs, etc. Sometimes for practical purposes, but mostly just for fun. It is something I picked up a few years ago when I took Computer Organization and learned MIPS.

 

Great class, actually. We had a project in which you had to take a program description and write the program to make full use of the pipeline. If you stalled the pipeline even once, you failed. If you have not played with MIPS before and you like that kind of hacking, you should grab a book on it and the free "spim" MIPS emulator.