LASooner Posted January 31, 2019 Share Posted January 31, 2019 Just a quick glance at the 2 compiled versions, The older compile (on the left) had 1 extra line at the end of the code line 2835 is not present in the HONDARRABI compile. I do not grok Assembly code, so you'd know better than me if that makes a difference. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted January 31, 2019 Author Share Posted January 31, 2019 That makes no difference. The asterisk tell the compiler that line is a comment. If you wanted to put the runtime routines into low memory, the compiler on the left would un-comment the line. The new compiler will add AORG >2008 after ENDCC for the same result. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted February 1, 2019 Author Share Posted February 1, 2019 Found the problem. CALL LINK("IRND",A,B,C,D) was not in the list of subprograms. That didn't cause a problem before, but with the new ability to CALL your own subprograms, it assumes that IRND is your own subprogram and treats it differently. with Grechetto: L1640 DATA IRND,NC29,NV46 with Hondarrabi: L1640 DATA CALL,IRND,NC29,NV46 The fix is dead simple and I should be able to post it tonight. 2 Quote Link to comment Share on other sites More sharing options...
LASooner Posted February 1, 2019 Share Posted February 1, 2019 Good to know Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted February 1, 2019 Author Share Posted February 1, 2019 Here you go. This fixes the bug that LASooner found. I thought you might be having memory problems, but the compiler reports over 1K memory available. You only have 2 string variables, so at most they would take up 512 bytes. So that's not an issue for you. I hope there are no more bugs to find, but if there are, I hope you guys can find them! HONDARRABIBETA3.zip 3 Quote Link to comment Share on other sites More sharing options...
LASooner Posted February 1, 2019 Share Posted February 1, 2019 I'll give it a shot when I get home Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted February 1, 2019 Author Share Posted February 1, 2019 Just wanted to say, the files you sent were perfect. Exactly what was needed to diagnose what was happening. 3 Quote Link to comment Share on other sites More sharing options...
LASooner Posted February 1, 2019 Share Posted February 1, 2019 (edited) old version and new version in the same cart I feel like the player is a little more responsive, but maybe it's the placebo effect. It takes the player roughly 8 seconds to go from left to right across the top of the screen in the old version and 7 seconds in the new version. Nightstalk8.bin Edited February 1, 2019 by LASooner 3 Quote Link to comment Share on other sites More sharing options...
Opry99er Posted February 1, 2019 Share Posted February 1, 2019 Excellent!!!! Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 3, 2019 Author Share Posted March 3, 2019 After many false steps, I have finally been successful in getting the compiler to transfer an array to a subprogram. Here is the test program: 90 DIM Z(9,17) 95 PRINT "LINE 95" 100 Z(2,3)=523 110 PRINT "LINE 110" 120 CALL SUBTEST(Z(,)) 125 PRINT "BACK FROM SUBTEST" 130 PRINT Z(2,3) 150 SUB SUBTEST(Q(,)) 160 PRINT Q(2,3) 170 PRINT "LINE 170" 190 SUBEND (All the PRINT "LINE #" are there to help me determine just exactly where the compiled program was crashing..) There is more to do. I had to manually modify some of the compiler output, so the compiler needs some additional (minor) work. And of course a lot of additional testing. But it's a good start. 7 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 3, 2019 Share Posted March 3, 2019 Strong work Harry! Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 10, 2019 Author Share Posted March 10, 2019 I would like opinions on how a compiled program should behave when it comes to the end of the program. With the XB loader it is clear. When the compiled program ends it transfers control back to XB. Usually this goes back to the command line, but you can also chain compiled programs together provided they are saved in XB format. Currently, when running in EA5 format the program quits to the master title screen when it comes to the end. That can seem pretty abrupt at times. A different option would be to put the program into an endless loop. You would have to press Fctn= to break out of the loop. Any preferences? 1 Quote Link to comment Share on other sites More sharing options...
+Schmitzi Posted March 10, 2019 Share Posted March 10, 2019 yes, the endless loop, waiting for a keypress, would be fine Is it possible to add another option, like "Restart Game" (or reboot game) ? Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 10, 2019 Author Share Posted March 10, 2019 Is it possible to add another option, like "Restart Game" (or reboot game) ? The "Restart Game" option should be part of the XB program that was compiled. And that answers my question. It bothered me that some of the short test programs I wrote would print stuff on the screen and then quit before you get a chance to look at it. But in the real world that wouldn't be an issue because the XB source program would deal with where you wanted to go when the program is at an end. I will leave it as is.100 CALL KEY(0,K,S)::IF S<1 THEN 100 can be used in the last line if you want to keep from resetting the computer automatically. 1 Quote Link to comment Share on other sites More sharing options...
+OLD CS1 Posted March 11, 2019 Share Posted March 11, 2019 Generally my purpose for compiling is to make cartridges. For that I like it going back to the MTS, but I can see how other options can be useful. Are END and STOP handled differently? Maybe assign STOP to hang the program waiting for a key press and END to return to the MTS. Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 11, 2019 Author Share Posted March 11, 2019 Generally my purpose for compiling is to make cartridges. For that I like it going back to the MTS, but I can see how other options can be useful. Are END and STOP handled differently? Maybe assign STOP to hang the program waiting for a key press and END to return to the MTS. END and STOP are handled the same way. I'm going to leave it the way it is, with a return to the master title screen. If the XB programmer wants something different it can be added to the program as noted above Quote Link to comment Share on other sites More sharing options...
Tursi Posted March 11, 2019 Share Posted March 11, 2019 I like OLD CS1's suggestion, but in general, I think it should go back to the master title page. If the programmer wants a different behaviour, then they can put it in the code itself. The problem with just halting and waiting for a keypress is that it doesn't tell the user what's going on, you still rely on the programmer to tell them. So the programmer might as well put in the wait-for-key loop, too, if that's what they want. 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 13, 2019 Author Share Posted March 13, 2019 "Isabella" is a couple of days from release. You can now pass arrays to a subprogram as Vorticon does in Stratego. The XB loader that lets you use all 32K by loading the runtime routines into low memory can now save in EA5 and XB format. Before you had to use MiniMemory for that. (And you still might want to because it is a lot faster.) 5 Quote Link to comment Share on other sites More sharing options...
+Vorticon Posted March 13, 2019 Share Posted March 13, 2019 Outstanding work Harry! I hope I'll be able to compile Stratego without issues. 3 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 14, 2019 Author Share Posted March 14, 2019 (edited) Outstanding work Harry! I hope I'll be able to compile Stratego without issues. You will probably have some kind of issues if only from the integer arithmetic. But nothing that cannot be worked out. I hit a slight snag. Up to now all the programs I tested where I put the runtime in low memory worked fine. I just found one that does not work properly. It is probably simple - something like JH instead of JGT. But the trick is to find it! (edit) The problems happens in the routine that loads the lower case characters with descenders. I looked at the code and see no reason this should happen. With the help of the debugger I should be able to correct it tonight. Edited March 14, 2019 by senior_falcon 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 15, 2019 Author Share Posted March 15, 2019 Found the problem which was a super simple fix. Should be uploading "Isabella" this weekend. 2 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 16, 2019 Author Share Posted March 16, 2019 (edited) Here is "Isabella". I believe this is the final version of this package. With the exception of bug fixes this project is finished at last. Enjoy! COMPILER: The compiler actually does now fully support user defined subprograms, With Hondarrabi it could not pass an array to a subprogram such as: 10 A(2,3)=523::CALL TESTSUB(A(,)) 100 SUB TESTSUB(Z(,)) 110 PRINT Z(2,3) and 523 will be printed. The XB loader that uses the full 32K of memory (i.e. put runtime in low memory) can now save in both EA5 and XB format.You no longer have to go to MiniMemory for that (although it is quite a bit faster to do that) The usual minor tweaks to the code and docs. (Edit March 17, 2019) I have re-uploaded the package. 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. ISABELLA.zip Edited March 18, 2019 by senior_falcon 4 Quote Link to comment Share on other sites More sharing options...
LASooner Posted March 16, 2019 Share Posted March 16, 2019 With the exception of bug fixes this project is finished at last. 1 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 16, 2019 Author Share Posted March 16, 2019 Yeah but this time I really mean it! Really! 2 Quote Link to comment Share on other sites More sharing options...
senior_falcon Posted March 16, 2019 Author Share Posted March 16, 2019 (edited) Outstanding work Harry! I hope I'll be able to compile Stratego without issues. There are a couple things you should keep in mind to maximize your chances for success. *You cannot chain compiled programs (edit - that are saved) in EA5 format. Only those saved in an XB loader can be chained, and of course they must be run using the XB cartridge. Think of a compiled program as a short XB program with a big assembly subroutine. The program you compiled is the assembly subroutine. After you have compiled and saved in XB format there is a 1 line XB program that starts up the compiled code. You can LIST this program and make additions to it but don't resequence. When the compiled code comes to STOP or END it returns to XB, coming back to the instruction immediately following CALL LINK("RUN") Normally the program ends because there is no instruction there, but you can add RUN("DSK1.PART2") or any other valid XB instructions and it will behave as expected. Start small. Write a tiny program such as 10 PRINT "This program is compiled" 20 GOTO 20 Make sure your bit mapped screen loader can load and run this program. *Be alert for problems caused by integer math. (edit) Adding, subtracting, and multiplying integers always gives integers. Pay close attention to division. You may need to INT when dividing to make the XB and compiled code run the same. *Remember that disk access is DV only. Stratego used DF and so that would need to be changed. Good luck! Edited March 17, 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.