Jump to content

Photo

XB Game Developers Package


85 replies to this topic

#76 Schmitzi OFFLINE  

Schmitzi

    River Patroller

  • 3,912 posts
  • ToXiC
  • Location:Germany

Posted Fri Apr 28, 2017 3:25 AM

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

 

Attached File  BXLOADER-TiBasic.dsk   90KB   7 downloads

 

hope this is OK. thanks.



#77 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • Topic Starter
  • 960 posts
  • Location:Lansing, NY, USA

Posted Fri Apr 28, 2017 7:06 AM

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.



#78 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • Topic Starter
  • 960 posts
  • Location:Lansing, NY, USA

Posted Fri Apr 28, 2017 7:51 PM

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

Attached Files



#79 Bones-69 OFFLINE  

Bones-69

    Chopper Commander

  • 176 posts
  • Location:Australia

Posted Wed Nov 22, 2017 6:11 AM

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!



#80 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,434 posts
  • Location:Silver Run, Maryland

Posted Wed Nov 22, 2017 6:54 AM

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:

 

Attached File  acceptat.gif   14.95KB   0 downloads

 

...lee



#81 Bones-69 OFFLINE  

Bones-69

    Chopper Commander

  • 176 posts
  • Location:Australia

Posted Wed Nov 22, 2017 6:59 AM

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?



#82 Lee Stewart OFFLINE  

Lee Stewart

    River Patroller

  • 3,434 posts
  • Location:Silver Run, Maryland

Posted Wed Nov 22, 2017 7:08 AM

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



#83 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • Topic Starter
  • 960 posts
  • Location:Lansing, NY, USA

Posted Wed Nov 22, 2017 9:05 AM

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, Wed Nov 22, 2017 9:09 AM.


#84 Bones-69 OFFLINE  

Bones-69

    Chopper Commander

  • 176 posts
  • Location:Australia

Posted Wed Nov 22, 2017 4:04 PM

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?



#85 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • Topic Starter
  • 960 posts
  • Location:Lansing, NY, USA

Posted Wed Nov 22, 2017 9:43 PM

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



#86 senior_falcon OFFLINE  

senior_falcon

    Dragonstomper

  • Topic Starter
  • 960 posts
  • Location:Lansing, NY, USA

Posted Wed Nov 22, 2017 10:01 PM

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.

 

 

Attached Files






0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users