XB Game Developers Package

[+Schmitzi]

I made a DSK for me, so here it is:

 

BXLOADER-TiBasic.dsk

 

hope this is OK. thanks.

[senior_falcon]

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.

[senior_falcon]

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

[Bones-69]

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!

[+Lee Stewart]

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:

 

 

...lee

[Bones-69]

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?

[+Lee Stewart]

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

[senior_falcon]

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 November 22, 2017 by senior_falcon

[Bones-69]

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?

[senior_falcon]

Either way is fine. I'm just glad to see people using my programs!

[senior_falcon]

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

[senior_falcon]

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.

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 January 23, 2018 by senior_falcon

[Opry99er]

Amontillado!!! LOVE the name!

[senior_falcon]

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.

 

XBGDPamontillado.zip

Edited January 26, 2018 by senior_falcon

[Opry99er]

Wow... that'll cut the "code/compile/test" interval down SIGNIFICANTLY! Excellent stuff!

[Airshack]

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!

[senior_falcon]

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

[Opry99er]

..... mother of God .....

[senior_falcon]

..... mother of God .....

I think you have me confused with someone else.

[Sinphaltimus]

How did I miss this thread until just now I will never know. But holycow - this looks amazing.

Edited February 12, 2018 by Sinphaltimus

[RXB]

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

[senior_falcon]

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 February 13, 2018 by senior_falcon

[RXB]

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 February 13, 2018 by RXB

[Bones-69]

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!

[unhuman]

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