Jump to content
IGNORED

XB Game Developers Package


senior_falcon

Recommended Posts

If you're running from XB you need that line, otherwise you don't need it.

 

Are your sounds not working in just the compiled program or in XB as well.

 

The steps I use to successfully get it working are

 

use SLCONVERT to create the list

 

Assemble to generate the OBJ

 

use COMPRESS to create the VDP data to read in, set whether it's in low or high memory, it will generate the addresses for each sound.

 

Merge the data with your XB file

 

Read the compressed data into the VDP before playing the sounds

2810 READ A$::IF A$="" THEN 2820::CALL LINK("CWRITE",A$)::GOTO 2810
2820 RETURN

 

 

Use CALL LINK("PLAY",[address#]) to play each sound in your game

 

When you compile it should work just fine.

 

Remember any CALL SOUND statements in your program will override anything playing on player 1

 

 

 

 

Where is it not working for you? Are you getting errors when you assemble the soundlist?

Link to comment
Share on other sites

I will try to make some sense of the interchanges above, but please ask when there are more questions:
unhuman:
Attempting to Assemble... Get
UNDEFINED SYMBOL - 0005
Opry99er:
Look at your /S file and see what the 5th line in the compiler assembly source file says.
Opry99er is right here. The one thing I would suggest is to use windows format source code files which can be easily viewed with a text editor (Notepad, Notepad++ or similar) Compare the compiled code with the original XB code and you should be able to find what is going on. Read page 15 of the compiler manual: "In case of trouble..." Also, do not use Asm994a to assemble sound lists; use the TI assembler instead. This is the 4th option in the game developers package menu.
unhuman:
Not sure what this is, but...
TIFILES n€žPn ........................ I have no idea what this lline is either!
ZERO DATA 0
ONE DATA 1
PI DATA 3
RND DATA 0ÿ NC1 DATA 1054NC2 DATA 6176NC3 DATA 7194NC4 DATA 7218 I have no idea why these lines are bunched together - they should be like the 3 lines above with one statement per line. Do they look this way in a text editor?
NC5 DATA 0
NC6 DATA 1NC7 DATA 50 ditto for the next 3 lines
NC8 DATA 2NC9 DATA 150
NC10 DATA 3NC11 DATA 350
Maybe because I'm using the old Random? Trying the new way. What old Random? What new way?
LASooner:
Your music is not using player 2 correct?
Because if it is that's what causing it. If it's not any standard CALL SOUND statement will also interrupt it
3010 !PLAYER2 tells the sound list compiler to use player2
unhuman:
The music is indeed *NOT* using player 2. I had it all working and sounding great - in XB. Then I went to compile and it won't and sounds bad back in XB. I am using > 640 bytes so I do CALL LINK("XB256", 1054) as directed as my first statement. Going to take a little break.
Not sure what is meant here. Are you saying that you want to use player2 and the compiler is not doing it? Or is you intention to NOT use player2?

 

LASooner:

You can't have the XB256 line in when you compile

Exactly right and see my response to Retrospect below:

 

Retrospect:

Hi LaSooner
At which point do we have to use the line CALL LINK("XB256",xxx) to reserve memory? before the program is pasted in with the merged sound list?
NEVER use CALL LINK("XB256",xxx) in the XB program you are writing. That does the digital equivalent of Lucy pulling the football away when Charlie Brown tries to kick it. Either put it in the XB256 loader or else load XB256, then CALL LINK("OFF"), then CALL LINK("XB256",XXX) to restart with the additional memory reserved.
I'm having the same trouble now, as I did a few years ago. My soundlists don't work when compiled. I've never been able to work it out even with the manual.
I wish you had posted your troubles 2 years ago when this was fresh in my memory. Now I have to figure it out all over again to see if the problem is with the program or with the docs. Everything has worked in my tests so if it doesn't work for you I need to know why.
Link to comment
Share on other sites

It's probably a case of me not doing the CWRITE command. I'll keep stabbing at it until I get it right because I want my next game, whatever it may be, to be able to take advantage of this soundlist feature in XB256. I've done it once before on a little game but it was nothing flashy, years back.

 

Edit:

 

Yes if you look at LaSooner's reply to me, his line 2810 and line 2820 I think I might have missed them out, thinking they were not needed. Obviously, they are.

Edited by Retrospect
Link to comment
Share on other sites

It's probably a case of me not doing the CWRITE command. I'll keep stabbing at it until I get it right because I want my next game, whatever it may be, to be able to take advantage of this soundlist feature in XB256. I've done it once before on a little game but it was nothing flashy, years back.

 

Edit:

 

Yes if you look at LaSooner's reply to me, his line 2810 and line 2820 I think I might have missed them out, thinking they were not needed. Obviously, they are.

 

Yeah, that's the line that loads the data into the VDP.

Edited by LASooner
  • Like 1
Link to comment
Share on other sites

The example that is written in the manual works fine. There may be a problem using the noise generator. I will look some more today.

 

Also, be a little careful using really short sound statements. You have 5 sound statements in a row, each is 10 milliseconds or 1/100 second. This rounds up to 1/60 second and five in a row would be 5/60 second long or 1/12 second when compiled, which is pretty short. In XB it should be noticeably longer: The CALL SOUND takes about 1/50 second, so adding that in means it would take at least twice as long to go through the 5 statements.

  • Like 1
Link to comment
Share on other sites

I have found a couple of minor problems with the sound list compiler and XB256:

1 - Because of the added subprograms in XB256 you can get a "Memory Full" message when you CALL LOAD("DSK1.SOUNDLIST.OBJ"). This is an easy fix and I will deal with it in the next revision, but for now you can CALL LOAD(8195,0) to free up the space needed. This can result in overwriting some of the IV254 routines, so after creating and saving the sound list you should reload XB256 if you intend to do anything with IV254.

2 - For a yet unknown reason, if the first sound list you play goes to player2, then it will not play. Once a sound list has been played using player1 then player2 works as expected.

Edited by senior_falcon
  • Like 1
Link to comment
Share on other sites

LASooner found a bug in the sound list player. CALL LINK("PLAY",vdpaddress) is used to start playing a sound list. You can interrupt a sound list before it is finished and start a different one. The problem is that if the sound list that is playing uses, lets say, 2 sound generators and the new one only uses one, then the second generator is not turned off. This happens when using Player2 (normally used for sound effects). I have to check, but I wouldn't be surprised if it happens with Player1 as well. This won't be a problem if all your sound lists use the same number of generators. Now that the problem is known I just have to find a solution, which should be pretty straightforward.

  • Like 2
Link to comment
Share on other sites

It's not a huge deal to do that, in trying to fix it, I added a line of muted channels to the end of my sound , seems the mistake was not adding it to the beginning. I'll try that out instead. You think it can be any duration?

 

In XB, for muting at the beginning, it is probably safest to use the shortest duration—just in case the next sound for the same channel does not have a negative duration to start immediately.

 

In ALC, you do not need to think about duration at all, unless you are relying on the sound table player in the console ISR.

 

...lee

Link to comment
Share on other sites

In fbForth 2.0, I routinely silence all four channels before starting a new sound table. I think I used the original name MUTE for the routine that does it. :ponder:

 

...lee

Although simple, that would not work here. There are two sound players that can play sounds simultaneously. You can have background music with sound effects like explosions, laser shots etc. on top of the music. Clearing all the generators would kill the background music as well. So the routine has to be a little smarter than that and only turn off the generators that are used by the sound list being played.

 

LASooner has found a nice workaround until this is fixed.

Edited by senior_falcon
Link to comment
Share on other sites

Although simple, that would not work here. There are two sound players that can play sounds simultaneously. You can have background music with sound effects like explosions, laser shots etc. on top of the music. Clearing all the generators would kill the background music as well. So the routine has to be a little smarter than that and only turn off the generators that are used by the sound list being played.

 

I do not know its utility for you, but I use two sound players in fbForth 2.0, as well, but, when player #2 is playing, player #1 is muted by sending its sound-chip information to a dummy address. When player #2 is finished, player #1 resumes sending info to the sound-chip. As a result, player #1’s tune is not suspended, but, rather, truly muted for the duration of player #2’s tune.

 

...lee

Link to comment
Share on other sites

Sorry for the long delay. TL;DR it's all working.

 

My responses in BLUE

 

 

 

I will try to make some sense of the interchanges above, but please ask when there are more questions:
unhuman:
Attempting to Assemble... Get
UNDEFINED SYMBOL - 0005
Opry99er:
Look at your /S file and see what the 5th line in the compiler assembly source file says.
Opry99er is right here. The one thing I would suggest is to use windows format source code files which can be easily viewed with a text editor (Notepad, Notepad++ or similar) Compare the compiled code with the original XB code and you should be able to find what is going on. Read page 15 of the compiler manual: "In case of trouble..." Also, do not use Asm994a to assemble sound lists; use the TI assembler instead. This is the 4th option in the game developers package menu.
unhuman:
Not sure what this is, but...
TIFILES n€žPn ........................ I have no idea what this lline is either!
ZERO DATA 0
ONE DATA 1
PI DATA 3
RND DATA 0ÿ NC1 DATA 1054NC2 DATA 6176NC3 DATA 7194NC4 DATA 7218 I have no idea why these lines are bunched together - they should be like the 3 lines above with one statement per line. Do they look this way in a text editor?
NC5 DATA 0
NC6 DATA 1NC7 DATA 50 ditto for the next 3 lines
NC8 DATA 2NC9 DATA 150
NC10 DATA 3NC11 DATA 350
Maybe because I'm using the old Random? Trying the new way. What old Random? What new way?
I *THINK* this was the CALL LINK("RXB256", 1054). It's working now. Maybe time away + re-reading the manual fixed my steps.
LASooner:
Your music is not using player 2 correct?
Because if it is that's what causing it. If it's not any standard CALL SOUND statement will also interrupt it
3010 !PLAYER2 tells the sound list compiler to use player2
unhuman:
The music is indeed *NOT* using player 2. I had it all working and sounding great - in XB. Then I went to compile and it won't and sounds bad back in XB. I am using > 640 bytes so I do CALL LINK("XB256", 1054) as directed as my first statement. Going to take a little break.
Not sure what is meant here. Are you saying that you want to use player2 and the compiler is not doing it? Or is you intention to NOT use player2?
I am going to use Player1 for Music and Player2 for sounds. It seems to work. As mentioned, linking RXB in the program is bad.

 

LASooner:

You can't have the XB256 line in when you compile

Exactly right and see my response to Retrospect below:

 

Retrospect:

Hi LaSooner
At which point do we have to use the line CALL LINK("XB256",xxx) to reserve memory? before the program is pasted in with the merged sound list?
NEVER use CALL LINK("XB256",xxx) in the XB program you are writing. That does the digital equivalent of Lucy pulling the football away when Charlie Brown tries to kick it. Either put it in the XB256 loader or else load XB256, then CALL LINK("OFF"), then CALL LINK("XB256",XXX) to restart with the additional memory reserved.
This is great to know. Removing this seems to have fixed my compilation, too. My game now works, compiled with sound, so it'll be fixing timing + other stuff.
I'm having the same trouble now, as I did a few years ago. My soundlists don't work when compiled. I've never been able to work it out even with the manual.
I wish you had posted your troubles 2 years ago when this was fresh in my memory. Now I have to figure it out all over again to see if the problem is with the program or with the docs. Everything has worked in my tests so if it doesn't work for you I need to know why.

 

Link to comment
Share on other sites

Glad to know it is working for you now.

I have just tested the fixes to the sound list bugs. Before, when a sound list used 2 generators it would shut them both off when the sound list was over. But if you interrupted the sound list with another sound list that used only one generator then the second would not be turned off. That now works as expected. Also you will not have to do the CALL LOAD fix to be able to load the sound lists. I have changed the autocomplete routine in XB256 so you can press F3 to easily kill the auto complete routine. Also, I need to make a few revisions to the manual. Should be out soon.

  • Like 4
Link to comment
Share on other sites

I found an error in the XB256 manual. On page 17 is this sentence:

Then load the XB program with the music/sound effects; then MERGE “DSK2.SLCOMP2-M” to load the sound list converter and then RUN the program.

This should be:

Then load the XB program with the music/sound effects; then MERGE DSK1.SLCONVERT to load the sound list converter and then RUN the program.

 

(EDIT) Have just gone through the sound list section of the XB256 manual and corrected a number of discrepancies. It is still a bit of a learning curve, but better instructions can't hurt!

Edited by senior_falcon
  • Like 4
Link to comment
Share on other sites

  • 2 weeks later...
Here is the latest version of the XB Game Developer's Package "Dolcetto". The changes are:

COMPILER: A couple of bugs were fixed. If you broke a compiled program running from XB and if CALL LINK("FREEZE") had been used then sprite motion was turned off when you ran the program again. Under certain conditions the sound list processor could leave one or more sound generators turned on

XB256: Both bugs described above could cause the same trouble with XB256 and have been fixed. COMPRESS had a few changes so it provides better prompts when saving data. You can turn off the autocomplete routine in XB and XB256 by pressing F3 when prompted OLD DSK.

The biggest change is that all the documentation has been revised with extensive changes to the sound table section of the XB256 manual. SLCONVERT in particular was very poorly described and because of that was almost unuseable. Using it should be much easier now.


Edit - April 6, 11PM I had some residual files in the folder which was the result of trying to have a TI compatible version and a Classic99 compatible version. and I did not rename one of the files. I have re-uploaded DOLCETTO or you can just edit line 190 in LOAD:

190 CALL LOAD(-7,4):: RUN "DSK1.COMPILER" - not COMPILERW

edit april 12. Uploaded DOLCETTO1 which fixes the dumb mistake I made in CALL KEY while saving a few bytes of code.

DOLCETTO1.zip

Edited by senior_falcon
  • Like 5
Link to comment
Share on other sites

Were you able to fix the issue with COMPRESS where you had to capture the full character set in 2 passes and then remove the DATA line with "" in the first set?

Yes. The problem there was that somehow an older version of COMPRESS was distributed. That problem is fixed (and was before if only I had used the right file - doh!)

Also some minor improvements to the interface of COMPRESS so it suggests unique filenames for the various sections of VDP memory. The problem you had with sound lists leaving generators hanging is fixed. The problem Walid found with TI-Rex not moving the sprites is fixed. Autocomplete in XB and XB256 can be turned off with F3 at the first prompt. Sound list part of manual should be easier to understand, although the nature of the beast is still a steep learning curve.

  • Like 1
Link to comment
Share on other sites

Yes. The problem there was that somehow an older version of COMPRESS was distributed. That problem is fixed (and was before if only I had used the right file - doh!)

Also some minor improvements to the interface of COMPRESS so it suggests unique filenames for the various sections of VDP memory. The problem you had with sound lists leaving generators hanging is fixed. The problem Walid found with TI-Rex not moving the sprites is fixed. Autocomplete in XB and XB256 can be turned off with F3 at the first prompt. Sound list part of manual should be easier to understand, although the nature of the beast is still a steep learning curve.

 

 

Good deal. Guess I need to come up with a new game to take advantage of all this. Thanks Harry!

Link to comment
Share on other sites

Quick question: my game Laser Strike I do not think it to be a cartridge-worthy game, but I would like to see how it performs when compiled. Can compile XB games be saved to tape?

No problem saving to disk as an XB program. Remember that you need the 32K memory expansion. For a cassette, in theory yes, because it is a normal XB program. But there may be a problem: I don't think you can save more than about a 12K program to cassette. I believe that IV254 is not an option for cassette programs.

It might be possible to make a custom loader that saves and loads a large program to/from cassette in two sections.

 

(edit) I just looked at LaserStrike which seems pretty responsive for a TI BASIC game. It looks as if compiling it would be pretty straightforward. One common problem is with RND, but you should have no trouble. You have lines like this:

69 ON INT(RND*4)+1 GOTO 71,77,83,89 which should be fine. RND*.5 is a no-no. Also there seem to be no floating point numbers so that is good.

Since it is written in BASIC you could use my TI BASIC compiler which I think would free up some memory.

Just tried compiling and all seems right. The end program takes about 12K which I think will fit on a cassette. You'll have to figure out where to slow it down!

Edited by senior_falcon
Link to comment
Share on other sites

I goofed. In making the transition from two versions, one for text and one for DV80 format files, I forgot to change the LOAD program. Line 190 should be running COMPILER and not COMPILERW. The package has been re-uploaded or you can just change line 190 of LOAD. See post #194 or post #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...