Jump to content
senior_falcon

XB Game Developers Package

Recommended Posts

I forgot to mention two things:

1 - If you want to save the program so that it loads as an XB program, then you have to use the standard (slow) compiler loader. I hope to add to the new loader so it will save in XB format, but time is limited

2 - I believe that object code saved in compressed format will load faster. You'd want to choose the options RC with the TI Assembler.

  • Like 1

Share this post


Link to post
Share on other sites

BXLOADER has been adjusted so it can load both uncompressed and compressed object files. Compressed object files will load twice as fast as uncompressed object filed. However, saving in XB format is not supported by BXLOADER. You have to use the original XB loader in the compiler and you cannot use a compressed object file.

 

(BXLOADER is a TI BASIC program that lets you load a compiled XB program about 20x faster. Instructions are in a PDF in the folder. Editor/Assembler cartridge is required.)

BXLOADER.zip

  • Like 1

Share this post


Link to post
Share on other sites

Hi Harry - Not sure if I have found a bug or missing something plain obvious. The following gives the correct result when run in XB or XB256;

100 CALL CLEAR
110 ACCEPT AT(10,1)VALIDATE("123")SIZE(1):A
120 PRINT A
However, when compiled, A always returns a value of zero.
I did some experimenting and once I removed the VALIDATE option I started to get the correct outcome when compiled. I was using the result in the following manner and wondering why I was finding no data! :)
530 A$="DSK"&STR$(A)&".GSDAT" :: PRINT "LOADING ";A$;
540 OPEN #1:A$,DISPLAY ,VARIABLE
550 INPUT #1:A$

Is this a little glitch or have I misunderstood the way to use ACCEPT AT with the compiler?

 

Thank you!

Share this post


Link to post
Share on other sites

Hi Harry - Not sure if I have found a bug or missing something plain obvious. The following gives the correct result when run in XB or XB256;

100 CALL CLEAR
110 ACCEPT AT(10,1)VALIDATE("123")SIZE(1):A
120 PRINT A
However, when compiled, A always returns a value of zero.
I did some experimenting and once I removed the VALIDATE option I started to get the correct outcome when compiled. I was using the result in the following manner and wondering why I was finding no data! :)
530 A$="DSK"&STR$(A)&".GSDAT" :: PRINT "LOADING ";A$;
540 OPEN #1:A$,DISPLAY ,VARIABLE
550 INPUT #1:A$

Is this a little glitch or have I misunderstood the way to use ACCEPT AT with the compiler?

 

Thank you!

 

This from page 7 of the manual:

 

post-29677-0-74404400-1511355230_thumb.gif

 

...lee

Share this post


Link to post
Share on other sites

Hi Lee. I did read this.

 

I get the same result even if I do something like;

 

A$="123"

ACCEPT AT(10,1)VALIDATE(A$)SIZE(1):A

 

Again, have I missed something obvious here?

Share this post


Link to post
Share on other sites

Hi Lee. I did read this.

 

I get the same result even if I do something like;

 

A$="123"

ACCEPT AT(10,1)VALIDATE(A$)SIZE(1):A

 

Again, have I missed something obvious here?

 

Sorry about that. :) I missed something obvious myself in my too quick read.

 

...lee

Share this post


Link to post
Share on other sites

Hi Harry - Not sure if I have found a bug or missing something plain obvious. The following gives the correct result when run in XB or XB256;

100 CALL CLEAR
110 ACCEPT AT(10,1)VALIDATE("123")SIZE(1):A
120 PRINT A
However, when compiled, A always returns a value of zero.
I did some experimenting and once I removed the VALIDATE option I started to get the correct outcome when compiled. I was using the result in the following manner and wondering why I was finding no data! :)
530 A$="DSK"&STR$(A)&".GSDAT" :: PRINT "LOADING ";A$;
540 OPEN #1:A$,DISPLAY ,VARIABLE
550 INPUT #1:A$

Is this a little glitch or have I misunderstood the way to use ACCEPT AT with the compiler?

 

Thank you!

Definitely a glitch. This was discussed in Majestyx's "Grail of the Gods" thread. This issue has been fixed and I sent it to Majestyx for testing. I will post the two files RUNTIME1 and RUNTIME3 tonight and that should make it work for you. (One limitatation is that VALIDATE must be used with ACCEPT AT, not just ACCEPT.)

Edited by senior_falcon

Share this post


Link to post
Share on other sites

Sorry - I had not read the Grail thread. Thank you.

 

What is the correct etiquette here? Should I post as I did, or would you prefer a PM in the event of something similar in the future?

Share this post


Link to post
Share on other sites

The attached Runtime files should fix the bug with validate. This was thoroughly tested and worked fine, but I then wrote a custom BLWP @VMBW routine that unrolls the loop for more speed and there was a register conflict. This is one of the rare cases where an error in an assembly program doesn't lead to a total crash with colorful graphics displayed on the screen!

 

You only need to update RUNTIME1 and RUNTIME3. All these files are in windows format (.TXT) to be used with Classic99. I would post a more complete version, but soon there will be a new, greatly improved version that much easier to use. With the new one, after saving the XB program you just press "Enter" a bunch of times for it to be compiled, assembled, loaded, saved and test run.

 

 

RUNTIME fixed validate.zip

  • Like 3

Share this post


Link to post
Share on other sites

Teaser video for the new XB Game Developer's Package "Amontillado" to be released in a couple of days. With auto complete you just press Enter at each prompt.

gallery_34177_1071_256878.gif

From the manual:

If you have never used the compiler it can be a bit intimidating. - 6 different files are used!
--a list of the file types used--
Wow, that sure is a lot to keep track of, but don't let it scare you off. Before going into the details, let's give the game developer's package a test drive. HELLO is a simple XB demo program that is on DSK1 as part of the package. Let's see how easy it is to compile it.
----then a description of how to compile HELLO and test run the compiled program---
What just happened? Without having to know anything about assembly language you have just:
Loaded an XB program, tested it, saved it, saved it in merge format, compiled the merge format XB program into assembly source code, assembled the source code into assembly object code, loaded the object code, saved the compiled program in EA5 format, saved the compiled program in an XB loader, and run the compiled program! Sounds complicated, but you can see that it really isn't!
Edited by senior_falcon
  • Like 6

Share this post


Link to post
Share on other sites

This is the latest version of the XB Game Developers Package "Amontillado". It all goes onto DSK1. Use XBGDPTXT for classic99 and XBGDPDV80 for Win994a and a real TI99. Start by reading XBGDPDOCS to be sure you set it up right. There is a new assembly subroutine in XB256. CALL LINK("RUN",A$) which can run a file name that is a string variable. This should be useful for menu programs.

 

The video below shows a BASIC program called HELLO. After compiling it and assembling using Asm994a the compiled program is test run. Then I go back and modify the program, save it, compile, assemble, load and test run. The second time through you just push "Start Assembly" on Asm994a - it is already set up from the first time through. This is not meant as a tutorial; it is an example of how fast the compilation process can be.

 

The TI Assembler is now a stand alone program loading from XB. Now there is no need to get there via Funnelweb. Regardless of whether you use the TI assembler or Asm994a, this should really speed up the work flow.

 

gallery_34177_1071_167531.gif

XBGDPamontillado.zip

Edited by senior_falcon
  • Like 8

Share this post


Link to post
Share on other sites

I was recently wondering if you were going to update the documentation for the changes youve made to the improved workflow. Wow! This looks great! Many thanks to the Senior Falconator for introducing me to the thrill of watching BASIC code run swiftly on a TI-99/4A. Cant wait to download and review this update!

Share this post


Link to post
Share on other sites

Here's some news you're gonna like. I have been updating the compiler so it can use the more complicated XB style IF/THEN/ELSE statements. It all appears to work, but I want to take a few more days to be sure nothing is amiss.

The only difference is that there are some minor restrictions on nesting IF/THEN/ELSE statements. A single IF, THEN, ELSE is OK in a line, but you cannot have: 100 IF A=1 THEN IF B=2 THEN C=3 ELSE D=4 ELSE E=5

  • Like 7

Share this post


Link to post
Share on other sites

Very cool!

Just for fun try this in Classic99 using RXB:

100 CALL CLEAR
110 T$="HELLO WORLD"
120 B$=" "
130 CALL BIAS(1,T$,1,B$)
140 FOR X=757 TO 0 STEP-1
150 CALL MOVES("$V",11,T$,X,"$V",1,B$,X+10)
170 NEXT X
180 GOTO 140

Share this post


Link to post
Share on other sites
100 CALL CLEAR
110 T$="HELLO WORLD"
120 B$=" "
130 CALL BIAS(1,T$,1,B$)
140 FOR X=757 TO 0 STEP-1
150 CALL MOVES("$V",11,T$,X,"$V",1,B$,X+10)
170 NEXT X
180 GOTO 140

 

What is this code supposed to show?

Edited by senior_falcon

Share this post


Link to post
Share on other sites

It does the same demo as yours but starts at bottom and twice as fast as XB, also faster then your demo.

 

(But I assume your demo in Assembly has delays in it to slow it.)

 

Also as suggested you can cut and paste it into Classic99 in RXB 2015 and see for yourself.

 

To explain the lines:

 

130 CALL BIAS(1,T$,1,B$) ! This adds the Screen Bias value of 96 to the characters in strings T$ and B$

 

150 CALL MOVES("$V",11,T$,X,"$V",1,B$,X+10) ! Moves String T$ to screen location X, and moves string B$ to screen location X+10

Edited by RXB

Share this post


Link to post
Share on other sites

Here's some news you're gonna like. I have been updating the compiler so it can use the more complicated XB style IF/THEN/ELSE statements. It all appears to work, but I want to take a few more days to be sure nothing is amiss.

The only difference is that there are some minor restrictions on nesting IF/THEN/ELSE statements. A single IF, THEN, ELSE is OK in a line, but you cannot have: 100 IF A=1 THEN IF B=2 THEN C=3 ELSE D=4 ELSE E=5

 

Will this equate to faster execution times when compiled, or is it more about trying to better emulate something more faithful to the standard XB syntax?

 

I have now gotten used to writing the way the compiler demands! :)

Share this post


Link to post
Share on other sites

I have an idea for an ambitious game.... Is it known what the maximum size of program can be compiled? I have, honestly, no idea if what I want to do will fit, but... I think it may be worthwhile to attempt....

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