Jump to content
IGNORED

XB Game Developers Package


Recommended Posts

I'm just getting this working on my system but am consistently running into an error while trying to assemble my 2-line XB program (using classic99 via WINE on a Mac).

 

Program is:

 

10 PRINT "HELLO"
20 GOTO 10

 

I have my classic99 DSK2 configured like this:

240171768_ScreenShot2022-12-04at11_11_55AM.thumb.png.f9aecc76353c7cf53abfa030ca90d05c.png

I save my program via 

SAVE DSK2.HELLO-M,MERGE

 

Then I use the Compiler to create the HELLO.TXT file without errors.

However, when I go to assemble the file, it always fails with the same error (regardless of whether the program is 2 lines or 50):

 

1450329209_ScreenShot2022-12-04at11_14_59AM.thumb.png.1490744d56d37855cbaa2bcce69d3abc.png

 

Being a newbie I'm at a loss. Any suggestions?

 

EDIT> I tried compiling it targeting the TI Editor/Assembler and used that to assemble, same error, with the addition of "DUPLICATE DEFINITION" to the error message.  I also specified a LIST file but it is 0 bytes.

 

The compiled file (DSK2.HELLO.TXT) contains:

       DEF RUNEA,RUN,RUNV,CON
RUNEA  B @RUNEA5
FRSTLN
L10
       DATA PRINT,SC1
L20
       DATA GOTO,L10
LASTLN DATA STOP
OPTBAS DATA 0
NC0
ZERO   DATA 0
ONE    DATA 1
PI     DATA 3
RND    DATA 0
NV0
SC0
SC1    DATA SC1+2 
       BYTE 5,72,69,76,76,79
       EVEN
SV0
SA0
NA0
FRSTDT
LASTDT
       EVEN
ENDCC
       COPY "RUNTIME1.TXT"
       COPY "RUNTIME2.TXT"
       COPY "RUNTIME3.TXT"
       END

 

Edited by retrodroid
Link to comment
Share on other sites

On 12/4/2022 at 11:19 AM, retrodroid said:

I'm just getting this working on my system but am consistently running into an error while trying to assemble my 2-line XB program (using classic99 via WINE on a Mac).

 

Program is:

 

10 PRINT "HELLO"
20 GOTO 10

 

I have my classic99 DSK2 configured like this:

240171768_ScreenShot2022-12-04at11_11_55AM.thumb.png.f9aecc76353c7cf53abfa030ca90d05c.png

I save my program via 

SAVE DSK2.HELLO-M,MERGE

 

Then I use the Compiler to create the HELLO.TXT file without errors.

However, when I go to assemble the file, it always fails with the same error (regardless of whether the program is 2 lines or 50):

 

1450329209_ScreenShot2022-12-04at11_14_59AM.thumb.png.1490744d56d37855cbaa2bcce69d3abc.png

 

Being a newbie I'm at a loss. Any suggestions?

 

EDIT> I tried compiling it targeting the TI Editor/Assembler and used that to assemble, same error, with the addition of "DUPLICATE DEFINITION" to the error message.  I also specified a LIST file but it is 0 bytes.

 

The compiled file (DSK2.HELLO.TXT) contains:

       DEF RUNEA,RUN,RUNV,CON
RUNEA  B @RUNEA5
FRSTLN
L10
       DATA PRINT,SC1
L20
       DATA GOTO,L10
LASTLN DATA STOP
OPTBAS DATA 0
NC0
ZERO   DATA 0
ONE    DATA 1
PI     DATA 3
RND    DATA 0
NV0
SC0
SC1    DATA SC1+2 
       BYTE 5,72,69,76,76,79
       EVEN
SV0
SA0
NA0
FRSTDT
LASTDT
       EVEN
ENDCC
       COPY "RUNTIME1.TXT"
       COPY "RUNTIME2.TXT"
       COPY "RUNTIME3.TXT"
       END

 

I was able to test compiling the included "HELLO" sample on my son's windows laptop using stock 32-bit classic99 and see the exact same failure at the assembling step.  Any idea what might be wrong?

Link to comment
Share on other sites

  • 1 month later...

One of the great advantages of XB256 is to be able to compile programs (the best solution ever for XB developers to get the max speed for a program).
One way to increase the speed, the compiler only accept integers. So in XB256 it is necessary to use the INT function when dividing a value to be sure that both XB256 program and compiled run exactly the same.
But the INT consumes memory...
On a XB256 program I am working on, integers conversion is made 37 times and the memory consumed with it is memory that can't be used to make longer program.
So, could it be possible to modify XB256 (as an option) to disable floating numbers? and so forget INT. Maybe a crazy idea... 🙂

Link to comment
Share on other sites

3 hours ago, fabrice montupet said:

One of the great advantages of XB256 is to be able to compile programs (the best solution ever for XB developers to get the max speed for a program).
One way to increase the speed, the compiler only accept integers. So in XB256 it is necessary to use the INT function when dividing a value to be sure that both XB256 program and compiled run exactly the same.
But the INT consumes memory...
On a XB256 program I am working on, integers conversion is made 37 times and the memory consumed with it is memory that can't be used to make longer program.
So, could it be possible to modify XB256 (as an option) to disable floating numbers? and so forget INT. Maybe a crazy idea... 🙂

I think you only need the INT to test UN-compiled.

I am pretty certain when you compile, the INT is implicit.  To be honest, I always use INT from habit.  I don't think I have ever tested this, but I think I read it?

Link to comment
Share on other sites

6 minutes ago, fabrice montupet said:

I wonder if you have well understood what I wanted to say, maybe my English is bad.

I didn't I guess.  So, by default.  No floats in XB256.

What I was saying is... Just don't use them in the program.    X=INT(a*b)  will give the same result as X=a*b  when it is compiled.

 

This can cause a problem when testing before you compile.  So, I see what you are saying.

Link to comment
Share on other sites

On 12/4/2022 at 1:19 PM, retrodroid said:

I'm just getting this working on my system but am consistently running into an error while trying to assemble my 2-line XB program (using classic99 via WINE on a Mac).

 

Program is:

 

10 PRINT "HELLO"
20 GOTO 10

 

I have my classic99 DSK2 configured like this:

240171768_ScreenShot2022-12-04at11_11_55AM.thumb.png.f9aecc76353c7cf53abfa030ca90d05c.png

I save my program via 

SAVE DSK2.HELLO-M,MERGE

 

Then I use the Compiler to create the HELLO.TXT file without errors.

However, when I go to assemble the file, it always fails with the same error (regardless of whether the program is 2 lines or 50):

 

1450329209_ScreenShot2022-12-04at11_14_59AM.thumb.png.1490744d56d37855cbaa2bcce69d3abc.png

 

Being a newbie I'm at a loss. Any suggestions?

 

EDIT> I tried compiling it targeting the TI Editor/Assembler and used that to assemble, same error, with the addition of "DUPLICATE DEFINITION" to the error message.  I also specified a LIST file but it is 0 bytes.

 

The compiled file (DSK2.HELLO.TXT) contains:

       DEF RUNEA,RUN,RUNV,CON
RUNEA  B @RUNEA5
FRSTLN
L10
       DATA PRINT,SC1
L20
       DATA GOTO,L10
LASTLN DATA STOP
OPTBAS DATA 0
NC0
ZERO   DATA 0
ONE    DATA 1
PI     DATA 3
RND    DATA 0
NV0
SC0
SC1    DATA SC1+2 
       BYTE 5,72,69,76,76,79
       EVEN
SV0
SA0
NA0
FRSTDT
LASTDT
       EVEN
ENDCC
       COPY "RUNTIME1.TXT"
       COPY "RUNTIME2.TXT"
       COPY "RUNTIME3.TXT"
       END

 

When compiling, at one point you are asked "Assembling with Assm994a?"  You have pressed "Y" for that option, which I can tell from your source code listing where it says:
COPY "RUNTIME1.TXT"

COPY "RUNTIME2.TXT"

COPY "RUNTIME3.TXT"

If you had pressed "N" then the code would be COPY "DSK1.RUNTIME1.TXT", etc.

The assembler you use must match the choice you made when compiling.

Assm994a runs under windows, so another clue would be that the menu skips the assembler and points to the Loader option.

Link to comment
Share on other sites

9 hours ago, fabrice montupet said:

One of the great advantages of XB256 is to be able to compile programs (the best solution ever for XB developers to get the max speed for a program).
One way to increase the speed, the compiler only accept integers. So in XB256 it is necessary to use the INT function when dividing a value to be sure that both XB256 program and compiled run exactly the same.
But the INT consumes memory...
On a XB256 program I am working on, integers conversion is made 37 times and the memory consumed with it is memory that can't be used to make longer program.
So, could it be possible to modify XB256 (as an option) to disable floating numbers? and so forget INT. Maybe a crazy idea... 🙂

Sorry, but that would not be practical. It would require a major rewrite of XB to do this. For what it's worth, when comparing 10 X=3/8 with 10 X=INT(3/8), the INT only requires 3 more bytes which comes to 111 extra bytes used.

For most of the CALLs in XB, values that are passed are rounded to the nearest integer, so if this involves something like HCHAR, you might be able to work around it that way.

I think a version of XB that uses only integer arithmetic could offer a significant speed increase and so could be useful for some applications. That sounds like a wonderful opportunity....For someone else!

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

11 hours ago, senior_falcon said:

 the INT only requires 3 more bytes which comes to 111 extra bytes used.

37 times 3 bytes correspond to 111 bytes consumed, indeed. But in reality, INT can consumes much more by taking up space in a line, it can prevent to add some other data in a very long program line and force to create a new line. I am creating a game that need the most available memory so each byte freed is welcome.

But if a such feature requires to rewrite XB, yes it is not a good idea because of the amount of work to involve. So, indeed, my ask was crazy 🙂

 

  • Like 1
Link to comment
Share on other sites

15 hours ago, senior_falcon said:

Sorry, but that would not be practical. It would require a major rewrite of XB to do this. For what it's worth, when comparing 10 X=3/8 with 10 X=INT(3/8), the INT only requires 3 more bytes which comes to 111 extra bytes used.

For most of the CALLs in XB, values that are passed are rounded to the nearest integer, so if this involves something like HCHAR, you might be able to work around it that way.

I think a version of XB that uses only integer arithmetic could offer a significant speed increase and so could be useful for some applications. That sounds like a wonderful opportunity....For someone else!

Tough project I started on many years ago. 

Everyone is forgetting all the Floating point in ROM 0 of the TI99/4A would have to be just never used or the Floating Point in XB ROMs.

 

Next Project in RXB is ask Lee Stewart to help make a routine for RXB to fetch ROW & COLUMN value in Assembly to avoid FP slow down.

Example in Hex is >40 >07 >00 >00 >00 >00 >00 >00 in Floating Point equals 7 in integer the advantage of Floating Point is use of Scientific Notation.

i.e. Exponents using decimal point and E to symbolize the Exponents

 

Every single command in XB is designed around Floating Point. ABS, ASC, ATN, CHAR, CHR$, COINC, COLOR, COS, DELSPRITE, DISPLAY, DISTANCE....etc...etc...

 

A rewrite of XB would have to be a Floating Point and Integer version of XB for every single command.

Or a command to insert like INT(floating Point Number) that would replace that value and use nothing but INTEGER which I tried was way to slow to be useful.

 

Anyhow I have speeded up XB quite specifically a bit to date and will keep doing that work.

Link to comment
Share on other sites

1 hour ago, sometimes99er said:

I guess the easiest solution would be to have your original source code with INT, to test in XB, and then have a macro in an editor, or a small Python program, strip your source code of "INT(" and corresponding closing ")" and create a second source, - the one to be compiled.
😉

In my mind, stripping the INT just for the compilation operations and not in XB has no real interest because the compiler ends to ignore all INT all along its compiling operations as it only works with integers. (But sure, Harry will be able to talk more about what the compiler do in internal). My goal is (was) to get (and use) the maximum memory available during the development of the game, thus in XB256. And of course, to leave the minimal free memory as possible just for the compiler to do its job.

Link to comment
Share on other sites

4 hours ago, sometimes99er said:

Sure this can/will remove the correct closing parenthesis ? I mean there could be more parentes in an expression like (( )) ().
😉

You do not have to match the exact closing parenthesis of INT(...) in the formula, just the last closing parenthesis in a group, and consider that it is the last and nothing else will follow except for a mathematical operator, a space, a concatenation symbol (ampersand,) or a statement separator.  Sometimes I need to tweak it a little, but it does work.

  • Like 1
Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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

  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...