senior_falcon Posted March 21, 2019 Author Share Posted March 21, 2019 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. The STRATINIT that I have has: 1350 RUN "DSK1.STRATMAIN" This is not supported by the compiler, so you have to change 1350: 1350 END When the compiled program comes to END it returns to Extended BASIC. From there you can RUN "DSK1.STRATMAIN" 10 CALL INIT :: CALL LOAD(8192,255,158):: CALL LINK("RUN") 20 RUN “DSK1.STRATMAIN” Remember that the compiled program is just one large assembly subroutine. Page 10 of the compiler manual has a little more information about this. Yep, the line number being compiled is displayed on the screen, so if you look fast that tells you what line is causing the problem. I do admit to being surprised that the failure is so colorful! I will take a look to see if there is any way to make a soft landing from that error. 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 21, 2019 Share Posted March 21, 2019 OK so I managed to compile the Stratego initialization file and it runs perfectly including loading data from disk, although as expected cursor movements are far too fast and will need to be addressed, but that's a minor issue. I will add on the program chaining statements once the main program is properly compiled. Now when I tried to compile the main Stratego program, it compiled without errors, but the assembler complained about 2 instances of multiple symbols at 4272... Not sure how to proceed from there... Program attached. STRATMAIN.bin 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 21, 2019 Author Share Posted March 21, 2019 This is answered in my post #503. You have a subprogram called RESTOREB. The compiler shortens that to RESTOR and if you look at page 12 of the compiler manual you will see that RESTOR is reserved for the compiler. About all you can say about the TI assembler is that it works. If you get in the habit of using Assm994a or perhaps another cross assembler you will find them to be much faster plus you will get meaningful error messages, such as: multiple definition of symbol RESTOR Then you just have to use a text editor to find RESTOR in your XB source code and you know what needs to be fixed. Be sure you are using Display, Variable files. Stratego originally used display, fixed and that is not compatible with the compiler. 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 21, 2019 Share Posted March 21, 2019 Ah yes, totally forgot about the label length issue. That has got to be it. I'll look into it. I have already converted the data files to the DV80 format and file functions are working as they should. Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 21, 2019 Share Posted March 21, 2019 It was indeed a label issue, and the main program now compiles and assembles without errors. However, when I try to load the resulting program using XB256 in order to save it in IV254 format suitable for chaining, I get IO ERROR 07. What am I missing here? Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 21, 2019 Share Posted March 21, 2019 Is there a limit to the number of arrays or arguments passed to a subroutine for the compiler? I have reason to believe that the game is hanging on this line: CALL GENMOVE(COMP(,),I,KNOWN(),PLAY(,),MOVED(),EMOVED(),MAXSCORE,TX,TY,BFLAG,MDFLAG,PLEFT,GID,GX,GY,DGFLAG) Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 21, 2019 Author Share Posted March 21, 2019 Is there a limit to the number of arrays or arguments passed to a subroutine for the compiler? I have reason to believe that the game is hanging on this line: CALL GENMOVE(COMP(,),I,KNOWN(),PLAY(,),MOVED(),EMOVED(),MAXSCORE,TX,TY,BFLAG,MDFLAG,PLEFT,GID,GX,GY,DGFLAG) Wow! That's quite a subprogram. That line is indeed a problem for the compiler. At this point I don't know why that is so, but I will get to the bottom of it. I don't think it is because there are too many variables. I think the parentheses are somehow messing things up but will need more data to know for sure.. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 21, 2019 Author Share Posted March 21, 2019 It was indeed a label issue, and the main program now compiles and assembles without errors. However, when I try to load the resulting program using XB256 in order to save it in IV254 format suitable for chaining, I get IO ERROR 07. What am I missing here? The program is pretty long and so I am guessing it is already in IV254 format, so you probably don't need to do that. Still, it should load properly - I'm assuming you are using OLD DSK1.PROGNAME to load it. It might be a buffer space issue. You could try CALL LINK("OFF") and NEW, then try to load the program and see how that goes. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 21, 2019 Author Share Posted March 21, 2019 I don't see the problem occurring in post #531 happening in STRATINIT. You should be able to at least test STRATINI-X this way: 10 CALL INIT :: CALL LOAD(8192,255,158):: CALL LINK("RUN") (runs the compiled program) 20 RUN “DSK1.STRATMAIN” (loads and runs the XB program) Because you are not using XB256, I don't think it has to be in IV254, but it will be anyway because of the length. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 21, 2019 Author Share Posted March 21, 2019 (edited) CALL GENMOVE(COMP(,),I,KNOWN(),PLAY(,),MOVED(),EMOVED(),MAXSCORE,TX,TY,BFLAG,MDFLAG,PLEFT,GID,GX,GY,DGFLAG) This is proving to be a bit of a puzzler. When you pass multiple arrays and multiple variables, sometimes it compiles correctly (as it always did in my testing), and sometimes it does not. I have yet to find the reason for this. In the example above the compiler does not pass the array EMOVED, Instead it passes EMOVED(MAXSCORE). I have a feeling it is a simple fix, once I know what to fix. Edited March 21, 2019 by senior_falcon 1 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 21, 2019 Share Posted March 21, 2019 Thanks for looking into it Harry. We are sooo close to getting this complex program compiled and running! 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 22, 2019 Author Share Posted March 22, 2019 I am making progress. 10 CALL TEST(A(),C,B()) compiles correctly 10 CALL TEST(A(),B(),C) does not compile correctly I still don't know why but am working on it. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 23, 2019 Author Share Posted March 23, 2019 (edited) I have narrowed this down to the section of code that deals with nested arrays. When that is disabled Vorticon's line compiles properly. CALL GENMOVE(COMP(,),I,KNOWN(),PLAY(,),MOVED(),EMOVED(),MAXSCORE,TX,TY,BFLAG,MDFLAG,PLEFT,GID,GX,GY,DGFLAG) So now at least I know where to look. Edited March 23, 2019 by senior_falcon 3 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 23, 2019 Author Share Posted March 23, 2019 I have a fix that is pretty good but not perfect. All works correctly, except that you cannot send a nested array to a subprogram like so: 5 DIM A(10) 6 DIM B(10) 10 CALL TS(A(B(3))) 100 SUB TS(X) Nested arrays work properly everywhere else. 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 24, 2019 Author Share Posted March 24, 2019 (edited) I think that I now have a proper fix for this bug. Even this program compiles and runs correctly. Notice that in line 140 the entire array A() is passed and then one element of the same array is passed as a variable. Now to test thoroughly.... 105 A(=5280 130 A(3)=523 :: B(7)=3 140 CALL SP(A(),B(),A(B(7))) 150 SUB SP(Z(),Q(),T) 160 PRINT T 165 PRINT Z( 170 SUBEND Edited March 24, 2019 by senior_falcon 2 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 24, 2019 Author Share Posted March 24, 2019 This should do the trick. There are a couple of changes: 1 - If you inadvertently leave RUN in the XB source program then a STOP will be substituted (which does the same thing as END) 2 - The compiler has been modified so that now passing arrays to a subprogram is done properly The only difference in the program files is COMPILER so you only have to replace that one file; you don't have to swap out the entire package. Also the following change was made to page 7 of the compiler docs.: RUN or RUN line #.- use CALL LINK("RUN") if running the compiled program from XB. If the compiler finds RUN in the XB program it will substitute STOP. When running from XB, STOP makes the compiled program return to XB. When running in EA5, STOP returns to the master title screen. I checked STRATMAIN and all the lines seemed to compile properly. ISABELLA1.zip 3 Quote Link to comment Share on other sites More sharing options...
Tursi Posted March 24, 2019 Share Posted March 24, 2019 Dude. That's some serious compiler-fu there. 2 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 24, 2019 Share Posted March 24, 2019 There is definitely progress as I am getting past the problem statement now. Unfortunately, there are some strange issues present: - On the computer turn, it selects it piece, overlays it with a sprite, makes the galloping sound, but then the sprite does not move to its new assigned location. The game just continues from there as if the piece did move. - On the player turn, the yellow piece selection cursor appears (consists of 4 sprites), but it does not move when the cursor keys are pressed. It does get overlaid by a second targeting magenta cursor (also 4 sprites) when I press the ENTER key as it should, but again I cannot move it. I think there is something fishy going on with the VDP or the scratchpad here affecting sprites, possibly related to the program chaining process because these issues are not present with the initialization program even though I use sprite cursors there as well. I am using RUNV with the main program as the manual recommends to preserve the VDP. Another minor issue which occurs with both programs is with the SIZE option with DISPLAY AT has a bug as it seems to exceed the requested size in the statement, resulting in additional clearing of characters after the text. Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 24, 2019 Share Posted March 24, 2019 Dude. That's some serious compiler-fu there. More like wizardry... I am totally in awe. Stratego is probably one of the most complex programs you can throw at a compiler, and the fact that it actually manages to compile it is unbelievable... 2 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 25, 2019 Author Share Posted March 25, 2019 (edited) Another minor issue which occurs with both programs is with the SIZE option with DISPLAY AT has a bug as it seems to exceed the requested size in the statement, resulting in additional clearing of characters after the text. Let's do the "easy" things first. Can you make a one line program where DISPLAY AT misbehaves? Also, let's make sure STRATINIT works properly. You should be able to run the initial screen with the picture, then that program loads STRATINI-X which is the compiled program. When finished, STRATINI-X should be able to run STRATMAIN (the XB version) and with luck it should behave no differently than it does with the XB version of STRATINIT. (EDIT) I see the problem with DISPLAY AT. I removed the 3 DISPLAY AT statements from STRATINIT. When it displays STRATEGO it works properly. When it displays "READY FOR BATTLE" it clears to the end of the line. Edited March 25, 2019 by senior_falcon 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 25, 2019 Author Share Posted March 25, 2019 If you concatenate the string it works fine. 120 DISPLAY AT(23,5)SIZE(20)BEEP:"PREPARING"&CHR$(127)&"FOR"&CHR$(127)&"BATTLE" Hopefully there is a fix for the way you did it with the semicolons: "PREPARING";CHR$(127);"FOR";CHR$(127);"BATTLE" Or I might just change the manual to say not to do that. Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 25, 2019 Share Posted March 25, 2019 Concatenation is easy enough since I'm not displaying numeric variables. Otherwise the STR$() function would have to be used which is a bit clumsy. Hopefully this easily fixable for a future version. Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 25, 2019 Share Posted March 25, 2019 STRATINT works perfectly, and STRATMAIN gets chained in without issues and goes through the proper motions except for the sprite issues mentioned above. 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 25, 2019 Author Share Posted March 25, 2019 STRATINT works perfectly, and STRATMAIN gets chained in without issues and goes through the proper motions except for the sprite issues mentioned above. It is not clear to me what you have done. Let's be sure we are using the same terms. STRATINIT is the original XB source code. STRATINI-X is the compiled version embedded in an XB loader STRATMAIN is the original XB source code. STRATMAI-X is the compiled version embedded in an XB loader. Does STRATINI-X run properly? Can you use STRATINI-X to run STRATMAIN and does it run properly? (I would assume that if STRATINI-X runs right then STRATMAIN would have to run properly) Can you use STRATINI-X to run STRATMAI-X? Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 25, 2019 Author Share Posted March 25, 2019 (edited) And one other thing that would be of interest is: Can you use STRATINIT to run STRATMAI-X? Edited March 25, 2019 by senior_falcon 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.