Jump to content
IGNORED

TI-99 Sound Limitation?


Banquo

Recommended Posts

This is something I've been curious about for a while. In some games like Burgertime the game's music constantly cuts off and restarts every time a sound effect plays, like when you're walking over a bun, which is rather annoying. Other games like Frogger have no background music at all, probably to avoid that problem I'm guessing. However the Colecovision has no trouble playing both sound effects and music simultaneously in these same games. Doesn't the TI-99/4A and the Colecovision use the same sound chip though? I was just wondering what the limitation with the TI was.

  • Like 1
Link to comment
Share on other sites

There is actually no limitation. You can turn on the sound processor, and it will continue without control. It is probably caused by the automatic sound list processing. Since it loads the sounds from VDP, there is no way to query the current VRAM pointer, so when you interrupt the music played from the list, you don't know where you were when you want to continue. But no one needs to use the built-in sound list player.

 

(You may also use GROMs for sound lists, but typically, third-party games use machine language and the VDP.)

 

Just checked: The current position should be copied in 83CC, so that could be possible. Maybe it is just a "worst practice" phenomenon? (Everyone using the same bad example.)

  • Like 5
Link to comment
Share on other sites

2 hours ago, mizapf said:

There is actually no limitation. You can turn on the sound processor, and it will continue without control. It is probably caused by the automatic sound list processing. Since it loads the sounds from VDP, there is no way to query the current VRAM pointer, so when you interrupt the music played from the list, you don't know where you were when you want to continue. But no one needs to use the built-in sound list player.

 

(You may also use GROMs for sound lists, but typically, third-party games use machine language and the VDP.)

 

Just checked: The current position should be copied in 83CC, so that could be possible. Maybe it is just a "worst practice" phenomenon? (Everyone using the same bad example.)

I do believe there may be errors in the program code that result in all these sound-related interruptions. Something like, for example, an LDA instruction instead of an LDY or LDX.

 

~Ben

  • Like 1
Link to comment
Share on other sites

Texas Instruments examples for programming sound centered on the playlists as implemented in the console ROM... only one playlist could play at a time... so early titles just lacked imagination... 

 

For instance now we have sound list players that will allow 2 lists, and it will just steal a channel from the main list for use with sound effects. When the short sound list ends, the channel goes back to use by the main playlist.

 

 

  • Like 6
Link to comment
Share on other sites

1 hour ago, jedimatt42 said:

For instance now we have sound list players that will allow 2 lists, and it will just steal a channel from the main list for use with sound effects. When the short sound list ends, the channel goes back to use by the main playlist.

 

Yeah...fbForth 2.0 works something like that. It will handle 2 sound lists. The user can interrupt the first sound list by killing the first list and becoming the new first list, playing a second sound list by waiting for the first one to finish, or muting the first one while the second, presumably shorter list plays, after which the first list unmutes and continues playing as though not interrupted. The mute/unmute process actually continues playing the first list without a pause. It just sends sound information to a dummy address instead of the sound port, then resumes sending to the sound port when unmuted. Programming the mute/unmute process was actually quite a lot of fun. It was the result of a challenge from Mark Wills (@Willsy), the creator of TurboForth.

 

...lee

  • Like 6
Link to comment
Share on other sites

Do all the TI99 games use the interrupt driven sound player?

It can be done from within the user program so that the program has intimate knowledge of where the list is playing at any given moment using a cooperative thread.

The 9900 makes this pretty efficient by using a separate workspace for the player thread. It does take some fine tuning to make the music play at consistent speed so that might persuade people to take the interrupt method but there are other ways to do it.

  • Like 1
Link to comment
Share on other sites

Yeah...There are a lot of ways to skin this sound cat. The way I do it in fbForth 2.0 is, in fact, interrupt driven, but it does not use the console’s sound player. Rather, it is handled by fbForth’s ISR.

 

In addition to what I mentioned in my post above, there is a FIFO sound stack provided that allows for stacking sound tables to await their turn to play. Unlike TI Basic and Extended Basic, a waiting sound table does not pause program execution. If that were actually a desirable feature, the programmer would need to handle it another way—most easily accomplished with PLAYING? to monitor sound activity.

 

...lee

  • Like 1
Link to comment
Share on other sites

Yeah, but nothing forced you to use the interrupt routine at all - you could poll the VDP for your interrupt sync on both machines.

 

I think it's that (as noted above) TI's documentation focused on the ROM player because that was what they provided, and the machine just didn't live long enough for the commercial developers to start digging in for better ways to do things. If all you had was the Editor/Assembler manual, then you'd really only understand the built-in sound list player because the only comment beyond that was a single throw-away paragraph that it was possible to directly access the sound chip, but it was really hard and scary. ;)

 

Edited by Tursi
  • Like 3
Link to comment
Share on other sites

37 minutes ago, RXB said:

GPL has IO command that can play sound lists, but of course uses the interrupts, so I do not feel it was throwaway.

 

The throw-away paragraph in the “Sound” chapter of the Editor/Assembler Manual referred to by @Tursi is “Section 20.2 Direct Access to the Sound Generator”, which has nothing at all to do with GPL. It does not matter that there happens to be a GPL I/O command that can manage sound lists, the Editor/Assembler Manual is not about GPL programming. I agree with @Tursi that the relevant paragraph is, indeed, “throw-away” because it offers no programming assistance for direct access except to say you can write directly to the sound port. That certainly implies to me that the Editor/Assembler Manual authors thought it beyond the needs/desires of its readers and, therefore, only worthy of an aside, indicating that they were aware it could be done but were not interested in discussing it further.

 

...lee

  • Like 2
Link to comment
Share on other sites

2 hours ago, Lee Stewart said:

 

The throw-away paragraph in the “Sound” chapter of the Editor/Assembler Manual referred to by @Tursi is “Section 20.2 Direct Access to the Sound Generator”, which has nothing at all to do with GPL. It does not matter that there happens to be a GPL I/O command that can manage sound lists, the Editor/Assembler Manual is not about GPL programming. I agree with @Tursi that the relevant paragraph is, indeed, “throw-away” because it offers no programming assistance for direct access except to say you can write directly to the sound port. That certainly implies to me that the Editor/Assembler Manual authors thought it beyond the needs/desires of its readers and, therefore, only worthy of an aside, indicating that they were aware it could be done but were not interested in discussing it further.

 

...lee

So built in OS Sound Processing and the on board Chips has nothing to do with Assembly even written in Assembly? Hmmm interesting weird logic.

  • Like 1
Link to comment
Share on other sites

3 hours ago, RXB said:

So built in OS Sound Processing and the on board Chips has nothing to do with Assembly even written in Assembly? Hmmm interesting weird logic.

 

Rich, that has absolutely nothing at all to do with what I said. You are making stuff up. Please, re-read what I said.

 

...lee

  • Like 1
Link to comment
Share on other sites

4 hours ago, RXB said:

So built in OS Sound Processing and the on board Chips has nothing to do with Assembly even written in Assembly? Hmmm interesting weird logic.

No, I get it.  He is saying that as TI expected people to use the ISR sound routine, even though with assembly programmers can access the 9919 directly, TI gave it short shrift in the documentation.

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

3 hours ago, RXB said:

So built in OS Sound Processing and the on board Chips has nothing to do with Assembly even written in Assembly? Hmmm interesting weird logic.

Rich, you're off base on this one. :) The I/O command sets up a sound list and uses the interrupt generator, I was referring to (and Lee backed me up) the single paragraph in the Editor/Assembler manual that describes direct access to the sound chip, which the I/O command is /not/.

 

Not an attack on GPL. :)

 

  • Like 4
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...