Bones-69 Posted December 31, 2013 Share Posted December 31, 2013 After many hours I *think* I have found where the compiled error is coming from. I felt the nature of this one was a little odd because under normal XB everything worked as expected, but when compiled things went wrong. Anyway, I am putting it out there for contemplation. Old version; 340 IF YI=0 THEN 370 350 IF YI<0 THEN GOSUB 440 :: GOTO 370 360 IF YI>0 THEN GOSUB 450 370 IF XI=0 THEN 400 380 IF XI<0 THEN GOSUB 470 :: GOTO 400 390 IF XI>0 THEN GOSUB 480 Re-written which when compiled now runs. I think the drama was due to the GOTO commands in lines 350 and 380 which appear after an IF/THEN/GOSUB command. 340 IF YI=0 THEN 390 350 IF YI<0 THEN 360 :: GOTO 370 360 GOSUB 500 :: GOTO 390 370 IF YI>0 THEN 380 :: GOTO 390 380 GOSUB 510 390 IF XI=0 THEN 440 400 IF XI<0 THEN 410 :: GOTO 420 410 GOSUB 530 :: GOTO 440 420 IF XI>0 THEN 430 :: GOTO 440 430 GOSUB 540 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted December 31, 2013 Author Share Posted December 31, 2013 Bones, you are on the right track here. You had forgotten that IF, THEN, ELSE can only work with line numbers, so for example: 350 IF YI<0 THEN GOSUB 440::GOTO 370 will not work. But you can invert the logic here: 350 IF 0>Y1 THEN 360::GOSUB 440::GOTO 370 and this should work fine in the compiled code. Don't be afraid to look at the source code created by the compiler: L340 In XB: 340 IF YI=0 THEN 370DATA CEQ,NV4,NC4,NT1DATA IF,NT1,L370L350 In XB: 350 IF YI<0 THEN GOSUB 440::GOTO 370DATA CLT,NV4,NC4,NT1DATA IF,NT1,L440DATA GOTO,L370 You can see in the code above that line 350 will simply GOTO line 440 and not GOSUB 440 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 2, 2014 Author Share Posted January 2, 2014 Robert L encountered an interesting problem with the compiler. He was trying to compile his decimal to hex and bin converter. It was getting hung up at the input line. The offending line of code was this: 440 IF X<0 OR X>65535 THEN 400 i.e. check that the number is within limits. But the integer arithmetic used sees that line as: 440 IF X<0 OR X>-1 THEN 400 meaning the program will always be sent back to 400 There are a lot of subtleties in using the compiler...... Quote Link to comment Share on other sites More sharing options...
1980gamer Posted January 2, 2014 Share Posted January 2, 2014 "There are a lot of subtleties in using the compiler......" Yes, But I LOVE IT! It has got me back to tinkering with the TI. I haven't used the TI this much since I was 12. Just for some info... What would be the max value? 32767? Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted January 2, 2014 Share Posted January 2, 2014 Robert L encountered an interesting problem with the compiler. He was trying to compile his decimal to hex and bin converter. It was getting hung up at the input line. The offending line of code was this: 440 IF X<0 OR X>65535 THEN 400 i.e. check that the number is within limits. But the integer arithmetic used sees that line as: 440 IF X<0 OR X>-1 THEN 400 meaning the program will always be sent back to 400 There are a lot of subtleties in using the compiler...... So is there a way to work around this? I've been trying to get my head around two's compliment and how that works - it seems like an understanding of that will be helpful. Indeed, getting my head around how the computer handles negative numbers will probably help, too. Just for some info... What would be the max value? 32767? I believe so... but I wouldn't take my word for it Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 2, 2014 Author Share Posted January 2, 2014 Integers are from -32768 to + 32767. Page 5 of the manual is "Differences from Extended BASIC" and this information is on that page. C'mon now, the manual is only 13 pages long so it isn't a tome like "War and Peace". Believe it or not there is useful information in there! (I'm one to talk, I still haven't watched Tursi's video on using Classic99) 1 Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted January 2, 2014 Share Posted January 2, 2014 C'mon now, the manual is only 13 pages long so it isn't a tome like "War and Peace". Believe it or not there is useful information in there! (I'm one to talk, I still haven't watched Tursi's video on using Classic99) LOL - yeah, at least myself, I like to "jump right in" on things - even though doing so can come bite you in the ass. I will read it from "cover to cover" now . Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 2, 2014 Author Share Posted January 2, 2014 (edited) So is there a way to work around this? I've been trying to get my head around two's compliment and how that works - it seems like an understanding of that will be helpful. Indeed, getting my head around how the computer handles negative numbers will probably help, too. I believe so... but I wouldn't take my word for it Here's a program to consider: 100 FOR I=1 TO 9 :: READ N :: PRINT N :: NEXT I 1000 DATA -100000,-75000,-50000,-25000,0,25000,50000,75000,100000 In XB it runs just like you'd expect. Compiled, it prints these numbers: 31072,-9464,15536,-25000,0,25000,-15536,9464,-31072 One way to think about it is that the compiler adds or subtracts 65536 until the number ends up between -32768 and 32767. As far as a work around goes, I would be tempted to ignore it. Or you could print the decimal number next to the one that was entered, which might be handy. For example, knowing that -31804 = >83C4 is useful info - at least to some of us. Edited January 2, 2014 by senior_falcon Quote Link to comment Share on other sites More sharing options...
RobertLM78 Posted January 2, 2014 Share Posted January 2, 2014 Here's a program to consider: 100 FOR I=1 TO 9 :: READ N :: PRINT N :: NEXT I 1000 DATA -100000,-75000,-50000,-25000,0,25000,50000,75000,100000 In XB it runs just like you'd expect. Compiled, it prints these numbers: 31072,-9464,15536,-25000,0,25000,-15536,9464,-31072 One way to think about it is that the compiler adds or subtracts 65536 until the number ends up between -32768 and 32767. As far as a work around goes, I would be tempted to ignore it. Or you could print the decimal number next to the one that was entered, which might be handy. For example, knowing that -31804 = >83C4 is useful info - at least to some of us. I'll have to play around with this once I'm done going over the manual. As for a work around - perhaps I'll start by just dropping the test altogether - it shouldn't be too serious if the number falls out of range - just give a null result I would think. I suppose there will still be the issue of any number being entered in that is greater-than +32767 though... Quote Link to comment Share on other sites More sharing options...
Bones-69 Posted January 5, 2014 Share Posted January 5, 2014 Bones, you are on the right track here. You had forgotten that IF, THEN, ELSE can only work with line numbers, The crazy thing was - I hadn't forgotten this at all. You know - because a GOSUB command has a line number, it just never occurred to me that I was breaking the rules. By the way Senior, thanks again for your work. I am having an amazing amount of fun with this compiler! Quote Link to comment Share on other sites More sharing options...
JamesD Posted January 5, 2014 Share Posted January 5, 2014 Bones, you are on the right track here. You had forgotten that IF, THEN, ELSE can only work with line numbers, so for example: 350 IF YI<0 THEN GOSUB 440::GOTO 370 will not work. But you can invert the logic here: 350 IF 0>Y1 THEN 360::GOSUB 440::GOTO 370 and this should work fine in the compiled code. ... That functions very different under Microsoft BASIC. I can see where there would be confusion. Quote Link to comment Share on other sites More sharing options...
1980gamer Posted March 4, 2014 Share Posted March 4, 2014 Hi Harry, I have had off and on success with INPUT commands in the compiler. In XB this works fine, It is "hidden" code for debugging. So, if you download my latest mirror maze version, if you press a key at run... you should be prompted. It works in XB.... 60 FOR KK=1 TO 5070 CALL KEY(1,K,S):: IF S<>0 THEN 10080 NEXT KK90 GOTO 200100 PRINT "DEBUG 1=Y 2=N";110 INPUT HDG120 PRINT "GHOST ATTRACT DFLT=2 -15 TO 15";130 INPUT HD140 PRINT "SCREEN (1-3)";150 INPUT MZ160 IF MZ<3 THEN 180170 MZ=1 :: RD=1180 PRINT "# GHOSTS";190 INPUT NG200 CALL CLEAR I have a few other examples that fail. Some even CRASH the system. Page 7 of the manual does not have an example, but AGAIN, I have also been successful in using similar code? At a loss????? Thanks, Gene Quote Link to comment Share on other sites More sharing options...
parsec Posted March 4, 2014 Share Posted March 4, 2014 Hi Harry, First a huge thank you for your compiler, it's a great tool and I really appreciate your work! I recently went back to working on a silly game that I started back in 2011. At the time it compiled succesfully under the older XB compiler version. I decided to update my stuff and downloaded the latest XBC V2.1 but it appears the line number bug that was discussed in another thread, or something related, is still present. During assembly I get 'UNDEFINED SYMBOL - 0182'. Looking in the assembler code, line 182 is 'DATA IF,NT1,L643' but L643 is not defined anywhere. I tried the old compiler version and there were no issues. My code is well over 200 lines so resequencing does not work. If you need more info or anything let me know. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 4, 2014 Author Share Posted March 4, 2014 Hi Harry, I have had off and on success with INPUT commands in the compiler. In XB this works fine, It is "hidden" code for debugging. So, if you download my latest mirror maze version, if you press a key at run... you should be prompted. It works in XB.... 60 FOR KK=1 TO 50 70 CALL KEY(1,K,S):: IF S<>0 THEN 100 80 NEXT KK 90 GOTO 200 100 PRINT "DEBUG 1=Y 2=N"; 110 INPUT HDG .........(deleted some lines here) 180 PRINT "# GHOSTS"; 190 INPUT NG 200 CALL CLEAR I have a few other examples that fail. Some even CRASH the system. Page 7 of the manual does not have an example, but AGAIN, I have also been successful in using similar code? At a loss????? Thanks, Gene I don't see anything in your code that the compiler won't support. The problem might be that 50 loops doesn't give you enough time to get on a key. One thing to try when you RUN is to keep holding the ENTER key down until your menu appears. Another possibility might be to start the game with a loop until no key is pressed, then follow that with another loop to scan the keyboard until a key is pressed. If the key is <Fctn 9> go to your menu, otherwise continue with the game. Report back on how that works out, and then we'll go from there. Also, could you post an example that crashes the system? Thanks! Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 4, 2014 Author Share Posted March 4, 2014 Hi Harry, First a huge thank you for your compiler, it's a great tool and I really appreciate your work! I recently went back to working on a silly game that I started back in 2011. At the time it compiled succesfully under the older XB compiler version. I decided to update my stuff and downloaded the latest XBC V2.1 but it appears the line number bug that was discussed in another thread, or something related, is still present. During assembly I get 'UNDEFINED SYMBOL - 0182'. Looking in the assembler code, line 182 is 'DATA IF,NT1,L643' but L643 is not defined anywhere. I tried the old compiler version and there were no issues. My code is well over 200 lines so resequencing does not work. If you need more info or anything let me know. Sounds like the line number bug, but that should be fixed. Can you post the line of XB code, then the assembly source code version of that line. Quote Link to comment Share on other sites More sharing options...
parsec Posted March 4, 2014 Share Posted March 4, 2014 (edited) Sounds like the line number bug, but that should be fixed. Can you post the line of XB code, then the assembly source code version of that line. Assembly (last line is 180 182) : L410 DATA KEY,NC7,NV30,NV31 DATA CEQ,NV31,NC1,NT1 DATA IF,NT1,L643 For XB, there is no line 643, closest surrounding lines are 600 and 645. Line 410: 410 CALL KEY(1,K,S):: IF S=0 THEN 645 Edited March 4, 2014 by parsec Quote Link to comment Share on other sites More sharing options...
1980gamer Posted March 4, 2014 Share Posted March 4, 2014 Hi Harry, The 20 lines of code I put in the example are the first 20 lines of Mirror Maze. Current version. Yes, you have to be quick to press a key... I hold a key on the left side of the keyboard after hitting enter on the RUN command. This will give the input prompt, it just will not let me enter any data. Also, you cannot break the execution. Only a reset will free this! Well, in emulation anyway. Win99 and Classic99 I was thinking I am killing the input buffer? But I have been lucky enough to get the input prompt with 1 quick key hit. So I am not certain about anything! I'll but up another demo I made that has the same problem. But it will have to be tonight when I get home. Thanks for your help. And on the screen blanking... I'll try the load command too. Gene Quote Link to comment Share on other sites More sharing options...
1980gamer Posted March 5, 2014 Share Posted March 5, 2014 Hi Harry, I posted everything about Mirror Maze/pacman in the other thread. Here is an other example: the input works at the beginning but the accept at does not after the game over. ( works in XB ) No response for me, I have to reset. Gene SNAKE.zip Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 6, 2014 Author Share Posted March 6, 2014 Assembly (last line is 180 182) : L410 DATA KEY,NC7,NV30,NV31 DATA CEQ,NV31,NC1,NT1 DATA IF,NT1,L643 For XB, there is no line 643, closest surrounding lines are 600 and 645. Line 410: 410 CALL KEY(1,K,S):: IF S=0 THEN 645 It looks like this is a variation of the line number bug. Some of the extras added to the XB version of the compiler led to problems, and it looks like one was missed. I will make a comprehensive check of how all the line numbers compile and see if anything else is lurking there. Fix to come soon. 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 6, 2014 Author Share Posted March 6, 2014 Parsec, there are definitely a couple of bugs involving the line number bug. It looks like you can avoid this doing a resequence so you wind up with only even numbers. A simple RES would do this as that uses an increment of ten. Or else RES 100,2 or something like that. Quote Link to comment Share on other sites More sharing options...
parsec Posted March 6, 2014 Share Posted March 6, 2014 Parsec, there are definitely a couple of bugs involving the line number bug. It looks like you can avoid this doing a resequence so you wind up with only even numbers. A simple RES would do this as that uses an increment of ten. Or else RES 100,2 or something like that. Yes sir, that worked like a charm! Thanks for your help. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 9, 2014 Author Share Posted March 9, 2014 Hi Harry, I posted everything about Mirror Maze/pacman in the other thread. Here is an other example: the input works at the beginning but the accept at does not after the game over. ( works in XB ) No response for me, I have to reset. Gene Hi Gene: SNAKE is an excellent test to show what is happening. I now know what is going on and how to fix it for you. When a program scans the keyboard, the key unit (0 to 5) is placed in >8374 and the key value is returned in >8375. It looks like XB does the keyscan, then sets >8374 back to 0. The compiler doesn't do that. Your line 170 CALL KEY(1,K,S) sets >8374 to 1 and scans the keyboard. XB resets it to 0 but the compiler leaves it at 1. The fix is simple: just before the input add CALL LOAD(-31884,0) or CALL KEY(0,K,S) and the input should then work normally for you. Quote Link to comment Share on other sites More sharing options...
1980gamer Posted March 10, 2014 Share Posted March 10, 2014 Thank You! This has been a head scratch-er for me. I cannot believe I didn't notice KEY 0 works and KEY 1 didn't. I just seemed random to me. How about the accept at? I can press the V key and it exits. But I am looking for Y or N. Thanks for checking this out for me! Gene Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 10, 2014 Author Share Posted March 10, 2014 Gene, have you tried re-compiling it? I haven't tested it, but it should work with the changes mentioned above. Quote Link to comment Share on other sites More sharing options...
1980gamer Posted March 10, 2014 Share Posted March 10, 2014 Gene, have you tried re-compiling it? I haven't tested it, but it should work with the changes mentioned above. Yes, I changed the call key to key(0,k,s) and that worked. I also changed mirror maze to not take away the power pellets on the back side of the maze, so you will not loose power pellets. Just thought of something... You can now eat the power pellet location twice, so I have to change the dot count for screen completion. Darn! It's easy, but I'll have to recompile and test all levels again. Thanks for the help and suggestions! Gene 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.