On Sun, 2004-04-18 at 05:43, Stephen Anthony wrote:
> OK, I update the TIA registers with 'Update_tia_sound' whenever they
> change. Then, once per frame, I make sure the internal queue is full
> by using 'Tia_process' with the appropriate amount of data. Finally,
> during the SDL audio callback, it reads out of the queue and plays it.
This is O.K. in principle. By only putting out sound once per frame you
are less responsive to changes in the tia registers though.
> Now, after looking at your tiasnd.asm, soundq.asm, and tialine.asm, that
> seems to be what you do.
Appearances can be deceiving. I don't remember the details, but what we
do on a frame by frame basis with sound depends on how the game is being
synchronized.
> But it only works if the fragment buffer is
> 512 bytes. Any larger than that, and the sound goes off. Since you
> use a frag size of 1536 bytes (or more), I can't figure out what's
> going on.
If you are doing anything substantial during the callback routine like
copying a buffer, this may be causing problems. Forgive me if my memory
is bad, I haven't looked at the code for nearly two years, but I think
we just pass a buffer pointer and a size during the callback routine. I
think of the callback routine as being like an interrupt handler, and
it's not a good idea to spend a lot of time in an interrupt handler.
> Also, if I initialize the TIA sound registers with a sample rate of
> anything other than 31400, again the sound goes off. But according to
> the comments from Ron Fries, that shouldn't happen. So either I'm
> reading the comments incorrectly, or something is screwy in the TIA
> sound routines.
I don't know about this. But for us, the Ron Fries code basically bit
the dust a long time ago. If nothing else, our version is currently all
in asm. But by now, our concept of things is different than how he
thought about things. We think in bytes, he thinks in buffers. We do
no sample rate conversions. Thats up to hardware or SDL. But I leave
in the comments because we did start with it.
> I'll be glad when this is all over. I originally signed on to do two
> things:
>
> 1) Convert the codebase to SDL, which is pretty much done.
> 2) Add an in-game GUI like ScummVM or Mame, and move away from being a
> commandline program. I've started this, but the &%#$# sound problems
> are wasting my time.
Actually I was just kidding about not looking at Stella since version
0.2. I ran 0.7 on DOS quite a bit back in the early days, and I ran a
version of CyberStella when I was working on the Windows port.
CyberStella has some bugs in the Direct-X stuff but the sound wasn't
that bad. If it were me, I might have just gone ahead and fixed the
bugs, because by having direct access to Direct-X, I think it's possible
to do sound with much lower latency. I've never liked the fact that in
Windows I need such a big buffer to keep things running smoothly. I
don't like the lag. I even thought about *borrowing* some code from
CyberStella to get things running under Windows. But for me, it looked
easier to do SDL from scratch than to move the massive amount of
Direct-X code. And there is such a thing as *good enough* I guess.
Plus there's the portability thing. But SDL is just a layer trying to
make things that may be very different underneath look the same. I
guess I'm not too surprised that things work a little differently on the
different operating systems.
So... Yeah, if you want to add z26 support to KStella, that would be
great, if it's not too much work, but there will probably be other front
ends as well. Choice is good. Someday we might build something in, but
that's not anywhere near the top of our list.
Good Luck!
John
----------------------------------------------------------------------------------------------
Archives (includes files) at http://www.biglist.com/lists/stella/archives/
Unsub & more at http://www.biglist.com/lists/stella/
