+Vorticon Posted March 16, 2019 Share Posted March 16, 2019 I'm going to work on it this weekend and see how it goes. Since I cannot chain compiled program, what I'll do is just compile the main program which is the most important one anyway. I'll reach out if I get stuck. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 16, 2019 Author Share Posted March 16, 2019 . Since I cannot chain compiled program, what I'll do is just compile the main program which is the most important one anyway. Yes you can. See page 10 of the compiler manual. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 17, 2019 Author Share Posted March 17, 2019 I just ran STRATINIT through the compiler. It compiled fine, but there was one error when assembling. The TI assembler reports two errors: "MULTIPLE SYMBOLS - 2837". Good luck finding the error with that information. Assm994a gives this error message: ERROR #1: Line #2[334]: "multiple definition of symbol RESTOR". Now we're getting somewhere. Looking at the compiled code we see: L2390 RESTOR DATA NV52,NA6 So now we know the error is in line 2390 of the source XB program. Looking at that line we see: 2390 SUB RESTOREB(ID,ARRY(,)) And that tells us what we need to know. The compiler takes the first 6 letters of RESTOREB which is RESTOR and this becomes the label for the start of the sub. Unfortunately RESTOR is also a label for a sub in the compiler that will RESTORE the pointer to a line number. You cannot have the same label twice. The solution is simple: change the subprogram name from RESTOREB to something like RESTRB that cannot be confused with the XB RESTORE which is shortened to RESTOR or with any other XB instruction. The runtime routines use a lot of labels and the subprogram cannot duplicate any of them. I suppose I could make an alphabetized list of all the labels and include it in an appendix so you know which ones cannot be used for subprogram names. Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 17, 2019 Share Posted March 17, 2019 Easy enough to fix. I do need to make sure all the sub names in the main program don't shorten up to similar names. My bigger issue though is going to be the IF THEN ELSE limitation as I have a lot of nested conditionals in the program. I'll have to go through it carefully. Also one of the routines uses the SQR function with float results, so I will need to find a workaround. Should be all doable though. Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 17, 2019 Share Posted March 17, 2019 And yes it would be extremely helpful to have an alphabetized list of the labels used by the compiler in order to preserve the programmers' hair Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 17, 2019 Author Share Posted March 17, 2019 (edited) Easy enough to fix. I do need to make sure all the sub names in the main program don't shorten up to similar names. My bigger issue though is going to be the IF THEN ELSE limitation as I have a lot of nested conditionals in the program. I'll have to go through it carefully. Also one of the routines uses the SQR function with float results, so I will need to find a workaround. Should be all doable though. You haven't been keeping up. The IF THEN ELSE limitation has pretty much been eliminated. From the compiler manual: IF-THEN-ELSE now can use the more versatile Extended BASIC format. The following line of code will compile and run the same as it does in XB: 100 IF X=7 THEN Y=3::Z=12::GOSUB 100::PRINT A ELSE Y=5::Z=14::GOSUB 200:: PRINT B You do have to be a bit cautious when using complicated IF-THEN-ELSE statements. If you use ELSE you should only use one IF, one THEN and one ELSE as in the example above. If you do not use ELSE the line will just run like in XB. The following two lines run properly: 100 S=S+1 :: IF S=60 THEN S=0 :: M=M+1 :: IF M=60 THEN M=0 :: H=H+1 :: IF H=13 THEN H = 1 100 IF X=3 THEN IF Y=1 THEN IF Z=4 THEN PRINT “PI” (but you cannot use ELSE) By using AND you can eliminate the multiple IF statements and then you can use an ELSE: 100 IF X=3 AND Y=1 AND Z=4 THEN PRINT "PI" ELSE PRINT "NOT PI" The line below using multiple IF-THEN-ELSE statements does not run properly if compiled: 100 IF A=1 THEN IF B=2 THEN C=3 ELSE D=4 ELSE E=5 (line is from the XB manual) SQR gives the INT of SQR so you will definitely need to work around that. (EDIT) I thought you would have to make changes to the IF THEN ELSE logic due to using multiple ELSEs in a line. From STRATINIT: 240 IF N<=2 THEN CALL HCHAR(Y,X,35)ELSE IF N>8 THEN CALL HCHAR(Y,X,36) I wasn't sure how this would behave, so I made a test program: 200 INPUT N 240 IF N<=2 THEN PRINT "N<=2" ELSE IF N>8 THEN PRINT "N>8" 250 GOTO 200 This works as expected, so there should be no problem with your line 240. Really convoluted IF THEN ELSE logic can cause trouble, so when in doubt you can do a little test program to be sure. If line 240 did had trouble you could split it up like so: 240 IF N<=2 THEN CALL HCHAR(Y,X,35)::GOTO 250 241 IF N>8 THEN CALL HCHAR(Y,X,36) Edited March 17, 2019 by senior_falcon Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 17, 2019 Share Posted March 17, 2019 I have carefully read the manual Harry. You state that if ELSE is used, then there should only be one IF, one THEN and one ELSE used. That is a limitation in my book unless I'm misunderstanding what you are trying to convey. Below is a line from my initialization program which should not work with the compiler: IF NT=1 THEN COMP(N,1)=6::NC=NC-1 ELSE IF NT=2 THEN COMP(N,1)=5::NL=NL-1 ELSE IF NT=3 THEN COMP(N,1)=3::NM=NM-1 ELSE COMP(N,1)=11::NB=NB-1 And yet you said that the program compiled normally, so before I take the time to make changes to the code I want to make sure this is needed. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 17, 2019 Author Share Posted March 17, 2019 (edited) As noted above, you can easily test the IF THEN ELSE logic to see if it will work. Your line can be changed to: 80 INPUT NT 100 IF NT=1 THEN PRINT "NT=1" ELSE IF NT=2 THEN PRINT "NT=2" ELSE IF NT=3 THEN PRINT "NT=3" ELSE PRINT "NONE OF THE ABOVE" 120 GOTO 80 According to my docs that should not work, but actually it does perfectly. You don't have to change that line. So it looks like I need to revisit the docs so as to be totally clear on what can and cannot be done. Another point: If it compiles normally, that does not necessarily mean it compiled correctly! It just means it compiled without finding any errors. (edit) 100 IF A=1 THEN IF B=2 THEN C=3 ELSE D=4 ELSE E=5 (line is from the XB manual) The logic here is IF THEN IF THEN ELSE ELSE which does not behave properly when compiled. Your logic is IF THEN ELSE IF THEN ELSE IF THEN ELSE and the compiler is happy with that. So some revisions to the docs are in order. Edited March 18, 2019 by senior_falcon Quote Link to comment Share on other sites More sharing options...
atrax27407 Posted March 17, 2019 Share Posted March 17, 2019 Compiling a program will return "00 errors" when there are no syntax errors but logic errors can certainly exist. The same is true when assembling source code. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 17, 2019 Author Share Posted March 17, 2019 I have carefully read the manual Harry. You state that if ELSE is used, then there should only be one IF, one THEN and one ELSE used. That is a limitation in my book unless I'm misunderstanding what you are trying to convey. Sorry, I thought you were referring to the earlier limitation where IF THEN ELSE could only use line numbers. Anyway, it is gratifying to see that the compiler can do more than I thought it could! 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 18, 2019 Author Share Posted March 18, 2019 (edited) I have re-uploaded the package. This is in Post #497. The only difference is in the documentation which now accurately describes how to use IF-THEN-ELSE with the compiler. Also page 12 of the compiler manual has a list of reserved names that cannot be used as subprogram names. An interesting feature of how subprograms were implemented on the compiler is that they can now be called recursively - i.e. a subprogram can call itself. But this is not particularly useful since it cannot be tested in XB, which complains when you do that. (Edit) Here is the revised description of IF-THEN-ELSE IF-THEN-ELSE now can use the more versatile Extended BASIC format. The following line of code will compile and run the same as it does in XB: 100 IF X=7 THEN Y=3::Z=12::GOSUB 100::PRINT A ELSE Y=5::Z=14::GOSUB 200:: PRINT B You can use multiple IF-THEN-ELSE in one line as long as they follow the logic: IF-THEN-ELSE-IF-THEN-ELSE-IF-THEN-ELSE. (the final ELSE is optional) You must be cautious when the IF-THEN-ELSE logic does not follow the above pattern. If you do not use ELSE any line should run like in XB. The following two lines run properly: 100 S=S+1 :: IF S=60 THEN S=0 :: M=M+1 :: IF M=60 THEN M=0 :: H=H+1 :: IF H=13 THEN H = 1 100 IF X=3 THEN IF Y=1 THEN IF Z=4 THEN PRINT “PI” (these two lines do not use ELSE) By using AND you can eliminate the multiple IF statements and then you can use an ELSE: 100 IF X=3 AND Y=1 AND Z=4 THEN PRINT "PI" ELSE PRINT "NOT PI" The XB manual shows this line of code: 100 IF A=1 THEN IF B=2 THEN C=3 ELSE D=4 ELSE E=5 The logic is IF-THEN-IF-THEN-ELSE-ELSE and this will not execute properly compiled. Edited March 18, 2019 by senior_falcon 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 18, 2019 Share Posted March 18, 2019 Excellent! This was a major limitation for complex programs, so I'm really glad this is no longer the case. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 18, 2019 Author Share Posted March 18, 2019 Also one of the routines uses the SQR function with float results, so I will need to find a workaround. Should be all doable though. I don't know what accuracy you require, but remember that if you multiply a number by 100 the SQR will be multiplied by 10 SQR(2)=1.414 SQR(200)=14.14 or with the INT it would be 14 Quote Link to comment Share on other sites More sharing options...
1980gamer Posted March 19, 2019 Share Posted March 19, 2019 An interesting feature of how subprograms were implemented on the compiler is that they can now be called recursively - i.e. a subprogram can call itself. But this is not particularly useful since it cannot be tested in XB, which complains when you do that. Hmmm, I needed this in my necco factory game. I dropped the project because I could not make it work properly. I wonder if a I can make this work now? Granted, it will take trial and error.. well everything does, but compiling. Actually, this is a great place for a demo. looking back at the code.. yuk. to many abbreviated vars. LOL had a variable in one game for Fuel Unit Consumption. Guess what the variable was? It needed a rewrite anyway. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 19, 2019 Author Share Posted March 19, 2019 The problem is, how do you test it? GOSUB can be used recursively in XB or BASIC, but not subprograms. Writing in XB and then doing the testing in the compiled program is not the easiest thing to do. But if you are clever I'm sure there is a way. Quote Link to comment Share on other sites More sharing options...
+chue Posted March 19, 2019 Share Posted March 19, 2019 Just a thought - for testing, perhaps you can have two identical subprograms, just named differently. Instead of one function recursively calling itself, it just calls the other one. Quote Link to comment Share on other sites More sharing options...
LASooner Posted March 19, 2019 Share Posted March 19, 2019 The problem is, how do you test it? GOSUB can be used recursively in XB or BASIC, but not subprograms. Writing in XB and then doing the testing in the compiled program is not the easiest thing to do. But if you are clever I'm sure there is a way. I think you underestimate how quick it is to go from XB code to E/A 5 with your package, it's not as fast as typing "run" but, the way you have it pseudo automated, it doesn't take that long to test a compiled program at all. I do it all the time, because it's better to test at the speed the game will run at. At the very least it's great to have the option to do stuff like this if it's absolutely necessary to your program. 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 20, 2019 Author Share Posted March 20, 2019 That's true. Even with my slow 10 year old computer the development process is much faster now that the compiler and loader are in assembly. If you use Asm994a or another cross assembler then things are even faster. 2 Quote Link to comment Share on other sites More sharing options...
1980gamer Posted March 20, 2019 Share Posted March 20, 2019 It is pretty quick to compile and test. But I tend to write big stuff. To the point where I have to shrink 3 letter vars to 1 or 2 so I have enough room. (then I can't figure it out when I look back on it. ) That is why I was stating a demo. Anyway, I know senior_falcon has made some great improvements. Speed, memory, speech? If-then-else etc. I am a few versions back. The funny part on the if-then's is.. when i first heard of this limit, I was bummed out. Now, I have a hard time not working around that limitation. LOL. What am I going to do without all those GOTO's? This is where I needed the recursive function: http://atariage.com/forums/topic/283290-new-game-demo-lots-of-hearts/?hl=%2Bnecco#entry4120260 Game 5. You can find the game I was ripping off... A web based game: Chocolate Factory I think. To see how the original game played. I want to complete this game. I spent a bunch of time on it. I usually FINISH games and just think they are too slow or are not very good. This one kicked my bottom! But now... maybe? 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 20, 2019 Share Posted March 20, 2019 So I tried compiling the STRATINIT file (Statego initialization file) and the compiler kept crashing the system... Classic 99 is set up per the compiler instructions and STRATINIT runs properly in straight XB. The file is attached. What am I doing wrong here? https://youtu.be/u9TupHl3rY8 STRATINIT.bin Quote Link to comment Share on other sites More sharing options...
+arcadeshopper Posted March 20, 2019 Share Posted March 20, 2019 So I tried compiling the STRATINIT file (Statego initialization file) and the compiler kept crashing the system... Classic 99 is set up per the compiler instructions and STRATINIT runs properly in straight XB. The file is attached. What am I doing wrong here? https://youtu.be/u9TupHl3rY8 are you in overdrive? try it normal speed if so Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 20, 2019 Share Posted March 20, 2019 are you in overdrive? try it normal speed if so I did. Same issue. Quote Link to comment Share on other sites More sharing options...
LASooner Posted March 20, 2019 Share Posted March 20, 2019 I did. Same issue. What happens on line 1360? Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 20, 2019 Share Posted March 20, 2019 What happens on line 1360? It chain runs the main program. I think this might be the problem. Didn't know the numbers displayed by the compiler corresponded to the actual XB program line numbers There is a fix detailed in the compiler manual. 1 Quote Link to comment Share on other sites More sharing options...
LASooner Posted March 20, 2019 Share Posted March 20, 2019 (edited) It chain runs the main program. I think this might be the problem. Didn't know the numbers displayed by the compiler corresponded to the actual XB program line numbers There is a fix detailed in the compiler manual. I believe he uses the line numbers to create unique labels in the compiled program. Edited March 20, 2019 by LASooner 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.