Jump to content
Banquo

TI-99 Sound Limitation?

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.

Share this post


Link to post
Share on other sites

Good question.. Burgertime really annoys me how it restarts all the time.. bothered me for 30+ years. 🙂  I think they are the same sound chip.

  • Like 1

Share this post


Link to post
Share on other sites

I think it has more to do with programmer and their code.  I've seen many games without that issue.

  • Like 2

Share this post


Link to post
Share on other sites

Definitely the software.. the sound can be continuous if the developer programs for that. For instance rasmus's games.

Sent from my LM-G820 using Tapatalk

  • Like 3

Share this post


Link to post
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 4

Share this post


Link to post
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

Share this post


Link to post
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 5

Share this post


Link to post
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 5

Share this post


Link to post
Share on other sites

Speaking on this topic, Moon Patrol and I think Topper both play music and sound effects without interruption. Are there any other early examples of this?

  • Like 1

Share this post


Link to post
Share on other sites
Posted (edited)

I also remember Midnite (Midnight) Mason or Oh Mummy 

Edited by ti99iuc
  • Like 1

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
Share on other sites

You could set up a custom interrupt player, which is called via 83C4, but I seem to remember that the 99/4 did not support the user-defined interrupt, so maybe earlier games were developed with compatibility consideration.

Share this post


Link to post
Share on other sites
Posted (edited)

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 2

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
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 1

Share this post


Link to post
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.

Share this post


Link to post
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

Share this post


Link to post
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 1
  • Thanks 1

Share this post


Link to post
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 3

Share this post


Link to post
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.

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