Jump to content
IGNORED

Altirra - Mono/stereo problem


Foebane

Recommended Posts

I am currently using the latest version of Altirra (2.60), but there is a problem with games and demos that use stereo on it:

 

1. If I select Mono for stereo programs, some will adapt to mono but others will attempt to play it and sound bad.

2. If I select Stereo for mono programs, the sound only comes out of the left speaker, silence on the right.

 

Is there going to be a fix to this problem in an upcoming version? Who should I contact to make sure this happens?

 

It's more of an inconvenience than anything, but I've had to indicate in my Atari files which sound mode to use so as to get the best out of them.

 

 

Link to comment
Share on other sites

Stereo programs should attempt to detect a second Pokey and not use it if not found. Mixing mono sound across both speakers is not standard stereo Pokey behaviour. The issue was already discussed in the Altirra thread, and the author concluded no changes were required.

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

Anything to do with Altirra is down to Phaeron, he's the sole developer..

 

As FJC said, its been this way since inception and unless Phaeron has changed his mind it was concluded that it stays this way.

 

And to be honest, if you know its a stereo program then set it to it, same with mono, what you are asking is for Altirra to check if the program wants Stereo or mono and alter itself which is the opposite of the way it should be, it should be the program looking at the hardware and adjusting itself. I'm not sure anyone wants Altirra to stop itself just to scan an entire program looking for Stereo references and then run..

 

But I could be wrong :)

Edited by Mclaneinc
Link to comment
Share on other sites

I'm not asking for autodetection of mono/stereo, just that if it's mono, then the mono left channel is also put on the right. It could even be optional.

 

I know that the Atari 8-bit cassette system was famous for using one side for data and the other for audio, but does that have to extend to POKEY itself?

Link to comment
Share on other sites

but Altirra is working correct as original hardware?

 

"If it's mono, then the mono left channel is also put on the right. It could even be optional."

 

it's up on the software to compensate. Learned the lesson with Arsantica 1 I guess... as Triace composed the last song in mono while BeWu did the stereo soundtrack...

Edited by Heaven/TQA
Link to comment
Share on other sites

I am currently using the latest version of Altirra (2.60), but there is a problem with games and demos that use stereo on it:

 

1. If I select Mono for stereo programs, some will adapt to mono but others will attempt to play it and sound bad.

2. If I select Stereo for mono programs, the sound only comes out of the left speaker, silence on the right.

 

Is there going to be a fix to this problem in an upcoming version? Who should I contact to make sure this happens?

 

It's more of an inconvenience than anything, but I've had to indicate in my Atari files which sound mode to use so as to get the best out of them.

 

 

you do know that stereo is acheived with a second POKEY right? one handles the left, the other handles the right. 'stereo' vs. 'mono' determines whether altirra emulates a second POKEY. If you have two POKEY's, and you're running mono software, it's only going to ever access one POKEY. That's the way it works, there's nothing broken here.

  • Like 2
Link to comment
Share on other sites

The only change I would propose - if a mode switch is done on an "active" machine, put the Pokey/s into an active rather than init state. Changing modes midstream tends to be problematic as stereo detection is generally something that's only done once.

I agree! It's very nice to be able to switch back and forth between stereo and mono without rebooting.

 

I built a version for my own use with the following patch:

 

--- a/src/Altirra/source/pokey.cpp
+++ b/src/Altirra/source/pokey.cpp
@@ -227,14 +227,17 @@ void ATPokeyEmulator::ColdReset() {
 }

 void ATPokeyEmulator::SetSlave(ATPokeyEmulator *slave) {
-       ColdReset();
        if (mpSlave)
                mpSlave->ColdReset();

        mpSlave = slave;

-       if (mpSlave)
+       if (mpSlave) {
                mpSlave->ColdReset();
+               mpSlave->WriteByte(0xF, 0);
+               mpSlave->WriteByte(0xF, 3);
+               mpSlave->WriteByte(0x8, mAUDCTL);
+       }

        UpdateMixTable();
 }

With this, first POKEY is never touched when you toggle stereo/mono. The second POKEY is disabled and reset if you choose mono and it inherits the configuration of the first POKEY if you select stereo. This seems to be a decent compromise.

 

It still doesn't solve the problem of the OP, but I agree that's not really solvable in the emulator. I suppose it could detect if the program is driving the second POKEY and automatically switch to stereo mode. But that should probably be an optional setting in case there are spurious writes that trigger it. As for Atari software detecting stereo vs. mono, I've been using the stereo detection routine in Draco's SysInfo for Ransack and Bomber and it seems to work well.

Link to comment
Share on other sites

It still doesn't solve the problem of the OP, but I agree that's not really solvable in the emulator. I suppose it could detect if the program is driving the second POKEY and automatically switch to stereo mode. But that should probably be an optional setting in case there are spurious writes that trigger it.

The issue with any option like that, is that writing to the 'second' POKEY on a stock/mono machine actually just writes to the normal POKEY due to partial address decoding. I'm sure there's at LEAST one mono program or game out there that accesses the POKEY at an address that would end up showing up as writing to the second POKEY, and cause an issue. Also, the OS clears out various ranges in memory, which might interfere with the detection process. So overall, it might turn out to be more complex than it seems on the surface.

Link to comment
Share on other sites

But inheriting configuration from first POKEY may not be always goo option, you can have set them to different values (not sure how many songs use it if any). Maybe better is just proceed second POKEY even you have Mono selected, just skipping the actual sound output.

Link to comment
Share on other sites

So overall, it might turn out to be more complex than it seems on the surface.

 

Agreed.

 

But inheriting configuration from first POKEY may not be always goo option, you can have set them to different values (not sure how many songs use it if any). Maybe better is just proceed second POKEY even you have Mono selected, just skipping the actual sound output.

 

Sounds good to me, but I think that would require a larger patch. :) Also, again it should be optional in case there are programs that use non-standard addresses for POKEY registers and expect to be talking to the first one.

Link to comment
Share on other sites

I don't propose to inherit configuration. Just the bare minimum to allow audio to play as normal, which is zero all other registers and set SKCTL = $03.

I tried that and found it didn't work very well for what I wanted to use it for. For example, if you start up one of ivop's sid2gumby tunes and then switch to stereo while the music is playing, then the notes on the right speaker don't sound right because the second POKEY missed out on the AUDCTL configuration it was supposed to have. In this case, inheriting the config from the first POKEY works out well since sig2gumby uses the same config for both. But there's no right answer. The fact of the matter is that the second POKEY just springs into existence with no prior knowledge of what state it's supposed to be in.

 

So that's why Mapa's solution is nice. While in mono mode the second POKEY could just snoop writes to $D21X addresses but let them pass through to the first POKEY as well. Then when stereo is selected, it would already be in the correct state. Then the problem might be that the first POKEY is out of sync though since it was receiving writes for the second as well. So you could have three POKEYs! One snooping as mono and the other two snooping as stereo. Then when you switch you'd be guaranteed they were in the proper configuration. Barring, of course, any interrupts or action the program might have taken based on reading from the wrong set of POKEYs before the switch.

 

But, do I want to pay the price of emulating two or three POKEYs all the time just on the off chance I want to toggle between mono and stereo at some point? Not sure. Maybe just keeping track of the last values written to the registers would be sufficient without doing a full blown emulation.

 

EDIT: Clarification of why inheriting AUDCTL works for sid2gumby but SKCTL=$03 does not.

Edited by Xuel
Link to comment
Share on other sites

I suppose no matter what defaults and behaviours are made, there's none that'll be good for every scenario.

 

Some software does AUDCTL on regular basis, some just does it one time.

Maybe it's something that could go into advanced settings but I suppose it comes down to effort vs return.

 

Possible control settings:

 

Mono to Stereo change behaviour for 2nd Pokey ->

x inherit AUDCTL x AUDCTL=$00

x inherit SKCTL x SKCTL=$03 x SKCTL=$00

 

Stereo to Mono change behaviour for 1st Pokey ->

x leave unchanged x Zero all registers

Edited by Rybags
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...