unhuman Posted December 16, 2010 Share Posted December 16, 2010 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 Quote Link to comment Share on other sites More sharing options...
InfernalKeith Posted December 16, 2010 Share Posted December 16, 2010 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. Quote Link to comment Share on other sites More sharing options...
unhuman Posted December 16, 2010 Author Share Posted December 16, 2010 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 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted December 17, 2010 Share Posted December 17, 2010 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.) Quote Link to comment Share on other sites More sharing options...
unhuman Posted December 17, 2010 Author Share Posted December 17, 2010 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... Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted December 17, 2010 Share Posted December 17, 2010 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. Quote Link to comment Share on other sites More sharing options...
+InsaneMultitasker Posted December 17, 2010 Share Posted December 17, 2010 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? Quote Link to comment Share on other sites More sharing options...
Tursi Posted December 17, 2010 Share Posted December 17, 2010 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). Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted December 17, 2010 Share Posted December 17, 2010 (edited) 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 Quote Link to comment Share on other sites More sharing options...
unhuman Posted December 17, 2010 Author Share Posted December 17, 2010 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. Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted December 18, 2010 Share Posted December 18, 2010 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. Quote Link to comment Share on other sites More sharing options...
unhuman Posted December 18, 2010 Author Share Posted December 18, 2010 Yes. They should But IIRC (without scrolling up the thread,) I think Extended BASIC fixed the problem. Yeah - noted that in my initial post Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted December 18, 2010 Share Posted December 18, 2010 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. Quote Link to comment Share on other sites More sharing options...
Tursi Posted December 18, 2010 Share Posted December 18, 2010 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.) Quote Link to comment Share on other sites More sharing options...
unhuman Posted December 18, 2010 Author Share Posted December 18, 2010 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$ Quote Link to comment Share on other sites More sharing options...
unhuman Posted December 18, 2010 Author Share Posted December 18, 2010 One interesting note: IF K+1=1 uses up one more byte than if STR$(K)="0" Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted December 18, 2010 Share Posted December 18, 2010 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? Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 11, 2011 Share Posted January 11, 2011 Throw it in a loop and see how long a hundred passes of each takes. Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted January 11, 2011 Share Posted January 11, 2011 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 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 11, 2011 Share Posted January 11, 2011 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. . Quote Link to comment Share on other sites More sharing options...
unhuman Posted January 11, 2011 Author Share Posted January 11, 2011 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. Quote Link to comment Share on other sites More sharing options...
Tursi Posted January 12, 2011 Share Posted January 12, 2011 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". Quote Link to comment Share on other sites More sharing options...
Opry99er Posted January 12, 2011 Share Posted January 12, 2011 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. Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted January 14, 2011 Share Posted January 14, 2011 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. Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.