Jump to content
IGNORED

XB Game Developers Package


senior_falcon

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 2
  • 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

  • 6 months later...

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.

  • Like 7
  • Thanks 2
Link to comment
Share on other sites

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.

hummingbird.jpg.c5ef8d9e33556179f764619677742def.jpg

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

 

JUWEL5+GEM.zip

  • Like 18
  • Thanks 5
Link to comment
Share on other sites

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 by fabrice montupet
  • Like 3
Link to comment
Share on other sites

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! ;)

 

  • Like 8
Link to comment
Share on other sites

  • 1 month later...

@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?

Link to comment
Share on other sites

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 by senior_falcon
Edited for clarity
  • Like 7
  • Thanks 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...
  • Recently Browsing   0 members

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