Re: [fuse-emulator-devel] [ fuse-emulator-Patches-911525 ] Use higher resolution amplitude levels in AY emulation

[Stuart B. <sd...@nt...>]

On Thu, Mar 25, 2004 at 04:07:09PM +0000, Russell Marks wrote:
> Oh dear... I have to admit, I think I've utterly overreacted. Looking
> at the patch again, I think you're right. Unless you do really crank
> up the volume hugely on incredibly quiet stuff, it should be so close
> to being as good as full 16-bit that full 16-bit probably isn't worth
> doing.

I think you had a reasonable point - that 16-bit sound is the right way
of doing this. I have to admit that throwing away the least significant
8-bits only to replace them with zeros (if the device is 16-bit only) is
not ideal.

I'm certainly more interested in correct instruction and display timings
at the moment. (E.g. the second part of Shock.) I don't know for sure
but I assume that instruction timings are the main culprit. The other
thing that concerns me is performance - Shock part 2 at 2x2 won't run at
full speed on my machine (a K7 at 700MHz).

The 8-line patch should be small enough not to cause much of a problem
for a 16-bit sound patch, which would probably only revert the five
lines which do a ">>8". Probably doesn't matter much for the time being.

I'm not entirely sure how to test instruction timings. I think I need a
way to make sure that the interrupt handler starts at exactly the same
t-state in every frame, but I'm not sure how to do that. I imagine that
executing a HALT in contended memory. All I need to do then is set the
border colour, execute the instruction several times, and change the
border colour back... does that sound right?

One thing I've noticed is that when the cursor is obscuring part of the
display, Fuse uses a lot more CPU time. I'm using the GTK-2 UI, with
XFree86 4.2.1.1 and the nvidia drivers. I've also UI-related memory
leaks using memprof to the tune of about 70 bytes/sec.

> In fact, I'd also quite like to use the patch with aylet :-), if
> that's ok?

Of course it is. :-) I'm using it with aylet myself, actually.

[snip]

> This also concerns me, as I'm not sure keeping a lesser alternative
> around (using the current mostly-32-bit-or-more ints) would really be
> much fun. Floats could probably be avoided, but I think I'm right in
> saying that at least the beeper stuff would need some 64-bit maths for
> proper 16-bit output due to the numbers involved.

I don't really know what's involved in emulating the beeper or samples
with the AY accurately. I had assumed that you'd do some subsampling and
take the average of the subsamples... but then I suppose you have to
filter out high frequencies in a way that preserves lower frequencies.
I doubt that I'm qualified to write that code.
-- 
Cheers,

Stuart Brady