Jump to content
senior_falcon

XB Game Developers Package

Recommended Posts

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

 

Tqae7MF.png

 

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.

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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.

  • Like 2

Share this post


Link to post
Share on other sites

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

  • Like 3

Share this post


Link to post
Share on other sites

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 by LASooner
  • Like 3

Share this post


Link to post
Share on other sites

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.

  • Like 7

Share this post


Link to post
Share on other sites

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?

  • Like 1

Share this post


Link to post
Share on other sites

yes, the endless loop, waiting for a keypress, would be fine

 

Is it possible to add another option, like "Restart Game" (or reboot game) ?

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

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.

  • Like 1

Share this post


Link to post
Share on other sites

"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.)

  • Like 5

Share this post


Link to post
Share on other sites

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 by senior_falcon
  • Like 1

Share this post


Link to post
Share on other sites
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 by senior_falcon
  • Like 4

Share this post


Link to post
Share on other sites

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 by senior_falcon

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...