XB Game Developers Package

[retrodroid]

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:

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

 

 

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 December 4, 2022 by retrodroid

[retrodroid]

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:

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

 

 

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?

[fabrice montupet]

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

[1980gamer]

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?

[fabrice montupet]

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

[1980gamer]

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.

[senior_falcon]

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:

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

 

 

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.

[senior_falcon]

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!

[fabrice montupet]

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 🙂

 

[sometimes99er]

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

[+OLD CS1]

A regular expression search-and-replace works in Notepad++.

[sometimes99er]

2 minutes ago, OLD CS1 said:

A regular expression search-and-replace works in Notepad++.

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

[RXB]

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.

[fabrice montupet]

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.

[+OLD CS1]

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.

[senior_falcon]

I am almost ready with an update to the XB Game Developer's Package.

There have been some issues with putting the runtime routines in low memory, but most of those problems have been worked out.

When putting the runtime routines into low memory, there is room for all of them if the XB256 routines are not used. If you are using XB256 and some of the additional routines such as speech, disk access, etc then not all of the routines will fit in low memory. The goal is to fit as much a possible into low memory and put the little bit that is left into high memory along with the compiled code. I have worked out a nice way to do this and hope to finish writing it tonight.

[senior_falcon]

This post has the latest version of the Extended BASIC Game Developer's Package "Juwel5"

The biggest additions are faster and more versatile utilities for making cartridges. MAKECART8, which is used to make a rom cartridge from a compiled program, is much faster than the previous version, plus it has changes that should avoid problems regardless of which rom bank is selected at startup.  There is another utility that can combine multiple cartridges into a much larger multiple cartridge. You can have a compiled program load and run any other program in the cartridge, allowing a large XB program with many program files to run from a single cartridge. Or you can have a cartridge start with a menu program that allows you to select from multiple compiled programs.

The cru access recently added to XB 2.9 G.E.M. can now be compiled. Also CALL MOVE from XB 2.9 can be compiled.

There was a bug that caused problems when adding a comment to a line containing an IF/THEN/ELSE statement. This has been fixed.

The docs received the usual additions and editing. I am sure there are some other changes to the program that I have forgotten about.

(There is a tutorial showing how to make this multi cartridge.)

 

JUWEL5+GEM.zip

[fabrice montupet]

Thank you very much. Again, you made a great and very useful work. This new version speedup significantly the compiling and cartridge making process.

It is for my the ultimate development kit for any XB programmers.
I don't see what it lacks, it so complete, powerful and very well documented. Maybe the great Tursi "Flicker" routine to bypass the 5th sprite limitation. I think that this would bring a so precious and needed feature.  

Edited July 30, 2023 by fabrice montupet

[Tursi]

I don't think my flicker routine ever worked quite properly under XB itself... but it wouldn't take long to reimplement, since the concept is pretty simple.

 

This toolkit is pretty insane, I would have done just about anything for it back in the day!

 

[Retrospect]

With everything we have now, and this too, we've never had it so good.  It's a great time to be into the TI.  I'm still resting but I'm tinkering occasionally and the new xb gem and cartridge maker is fantastic.  

[senior_falcon]

Thanks to all for the kind words.

[1980gamer]

@senior_falcon I think I was able to create demos several years ago with sound list player.

Playing music while my program executed uninterrupted.

 

My attempt to do the same on a recent project, is pausing the program until the entire "background" music plays.

 

I don't remember if I had to use a different channel than any sound FX? 

 

I am looking to pick this back up after a much-needed break. But I don't want to start "stuck". LOL

 

Any thoughts on why calling a list would halt execution?

[senior_falcon]

Don't know why that would be a problem. Can you PM the program to me along with a description of where the problem lies.

 

(edit) Also, does this happen when running from XB256, when compiled, or both?

 

Edited September 9, 2023 by senior_falcon

[1980gamer]

PM Sent...

Thank you in advance for your help and guidance!

 

[senior_falcon]

The problem is easy to understand. (Once you understand it!)

Without giving away too much of your code, the program has:

635 CALL LINK("PLAY",2432)     starts the sound list

640 CALL LOAD(-31879,TM)      reset the timer
650 GOSUB 1590

 

Sub 1590 reads the joystick, fire button and keyboard. If you use the joystick it comes to these lines: (I have omitted some lines)

1648 IF JY<>0 OR JX<>0 OR K=0 OR K=5 OR K=2 OR K=3 THEN CALL SOUND(100+DEL,2222,30)
1670 IF JY<>0 OR JX<>0 OR K=0 OR K=5 OR K=2 OR K=3 THEN CALL SOUND(100+DEL,420,25,222,29)
1690 RETURN

 

If XB comes to a CALL SOUND while still playing a sound list, it first must finish the current sound list. Only then can it move on to perform the CALL SOUND.

The solution is simple - just make the sound duration negative.

Instead of CALL SOUND(100+DEL,2222,30) you can have CALL SOUND(-100-DEL,2222,30)  or CALL SOUND(-(100+DEL),2222,30)

Then the currently playing sound list is stopped and the new CALL SOUND is played.

Edited September 10, 2023 by senior_falcon
Edited for clarity