Announce: EmuZWin 2.4.1.0 with exact AY sound

edited April 2004 in Emulators
EmuZWin 2.4.1.0 with exact AY sound released today. In "exact sound" mode, should be very, very close to real sound. (My ears are sick, my head is splitting onto thousands pieces after hearing hundreds times dozens of demos today... But I happy finishing this job :) )
Post edited by Vladimir Kladov on

Comments

  • edited April 2004
    Great !
    Can't wait to try that out.
    Did you fix anything with the beep emulation too ?
    I was playng around with some games to find out wich one was user friendly to recolor, and I found out that games like Hydrofool ( with pseudo 3 channel beep sound ) really sound bad and out of time, making the overall feeling real bad.In this specific example, the menu tune sounds terrible distorted, but once the game starts and the AY sound chip gets in action everything is fine.And am playng sound througt sound card, not PC speackers.
    Any particular reason for that ? Just curious...( I really love your emulator ) :)

    Q
  • edited April 2004
    I found out that games like Hydrofool ( with pseudo 3 channel beep sound ) really sound bad and out of time, making the overall feeling real bad.In this specific example, the menu tune sounds terrible distorted, but once the game starts and the AY sound chip gets in action everything is fine.And am playng sound througt sound card, not PC speackers.
    Any particular reason for that ? Just curious...( I really love your emulator ) :)
    I had a look at it. the intro sounds different in different multicolor timing. For me it seems sounds better in a mode which I called "Timing Spectrum+2A/+3". And very like to this but different a bit though more similar in multicolor turned off, and in Pentagon timing. Actually, 256 Colors mode turns any multicolor off and contended timing too. So it is better to test first when multicolor is off.
  • edited April 2004
    EmuZWin news:

    Version 2.4 Release 1.1 (23-Apr-2004):
    [+] High Quality Magnification Filter added (in Effects). Implemented for GUI modes (not planned for Direct-X), not working at the same time with Gigascreen or 256 Color, MMX and power processor are required.
    [+] Another sound emulation algorithm with really exact sound (both AY and MIC). More sound options (AY Pitch, MIC On).
    [+] Volume control in the status bar added (can be turned off in the Configuration).
    [+] Custom Speed in percents added (from 48% to 10000%, actual top of speed depends on a host machine speed and current modes/effects selected). And now, Num[*] switches between last set Custom Speed (Alt+S) and 100% Speed (by default between 200% and 100% as earlier).
    [-] Interface I and TR-DOS were not compatible in multicolor mode - fixed.
    [-] Multicolor +3 timing fixed (tables were incorrectly initialized, could crash the emulator).
    [-] Changes in port recognision: port 7FFD assumed if out XXFD and XX could not be treated as AY port (Eyeache2 demo).
    [-] When ROM paths were reset in the Configuration, the emulator could not start properly. Fixed.

    And some words here. With Exact sound emulation option on (default), the EmuZWin becomes not so fast. But this option can be turned off. At least, old worst (but fast) sound production algorithm is used while speed is greater then 200%. Thanks to all for suggestions, bug reports, etc. The work is continuing but in sound emulation I made all that is possible (I hope).
  • edited April 2004
    But Vladimir, dear,

    I thought you had exact AY emulation already! Were you lying about that in the last release?

    And is this any better? is it "really exact" now, or should I wait for a future version next year?
  • edited April 2004
    On 2004-04-23 17:13, Vladimir Kladov wrote:
    [-] Changes in port recognision: port 7FFD assumed if out XXFD and XX could not be treated as AY port (Eyeache2 demo).

    Is there a reason you're not just using the mask/value pairs from the FAQ here?
  • edited April 2004
    BN^2: I thought you had exact AY emulation already! Were you lying about that in the last release?
    That was "exact" for rules, what I've fixed. In this version, rules are the same, but now, sound is emulated tact-by-tact (I mean tact of Z80), and then approximated for each 1/50 second sound buffer, so emulation became even more exact.

    But I still doubt if all OK there. I heard live AY only once, about 9 years ago, on a bad apparature, and I just can not remember how it sound. I just can compare sound with other emulators, and with a WinAmp plugin playing vtx-files. For me it is very suspect that noises become very similar when I turn "exact" (tact-by-tact) emulation off. I suppose that may be I had a mistake in noise generation, but may be otherwise, such noise is from the vtx plugin just because it uses usual approximation. I don't know, only people hearing real AY now can say me what is more correct.
    Philip Kendall: Is there a reason you're not just using the mask/value pairs from the FAQ here?
    I found that Eyeache2 demo stopped working when I used it. Either mask should be extended with a rule:
    00XX.XXXX.1111.1101 = 7FFD. I decided just to suppose that XXFD mean 7FFD is no other port (BFFD or FFFD) are recognized. But a rule when using some addresses to access two ports at the same time also should work.
  • edited April 2004
    BTW, I now uploaded 2.4.1.1b with an additional noise pitch control in the Configuration. Musicians, please tell me in what position it closier to the original sound, and I'll make this value corresponding to x1. For now, it is set to be close to WinAmp plugin as I could hear it with my ears (not a musician, yes).
  • edited April 2004
    Eye ache 2 works fine with port decoding set up as per the FAQ. Sound like you have an error somewhere else that's causing this effect.

    Regards,

    Jon.
  • edited April 2004
    May be.

    But with following code it did not work:

    procedure out_FD( Addr: Word; Value: Byte );
    begin
    if Addr and $C002 = $C000 then
    Out_FFFD( Value );
    if Addr and $C002 = $8000 then
    Out_BFFD( Value );
    if (Addr and $C002 = $4000) and not Port_7FFD_Locked then
    out_7FFD( Value );
    end;

    But with following one it works:

    procedure out_FD( Addr: Word; Value: Byte );
    var Handled: Boolean;
    begin
    Handled := FALSE;
    if Addr and $C002 = $C000 then
    begin
    Out_FFFD( Value );
    Handled := TRUE;
    end;
    if Addr and $C002 = $8000 then
    begin
    Out_BFFD( Value );
    Handled := TRUE;
    end;
    if ((Addr and $C002 = $4000) or not Handled ) and not Port_7FFD_Locked then
    out_7FFD( Value );
    end;
  • edited April 2004
    Eyeache 2 often does port writes using OUT (#FD),A. You are using the A register as the high byte of the port address for that opcode?

    That demo runs fine here with the port decoding from the FAQ too.


    [ This Message was edited by: Woody on 2004-04-25 11:24 ]
  • edited April 2004
    On 2004-04-25 11:22, Woody wrote:
    Eyeache 2 often does port writes using OUT (#FD),A. You are using the A register as the high byte of the port address for that opcode?
    Yes, certainly.
    That demo runs fine here with the port decoding from the FAQ too.
    Problematic value I found was: A=18H. I know this is good for 128 model, and bad only for +3 model, but I do not distinct it a lot. For my emulator, these models distinct only in contended timing a bit (at least meanwhile). So, my change is applying 128 (without +3) port recognision always, if to follow the FAQ. Nothing else. I do not a revolution, yes?

    BTW, Klive 1.1 also does not work with Eyeache2 in 128 model too. Symptoms are the same: no animation though sound is going some time, and when sound should change after finishing first animation stage, Spectrum crashes. All other emulators what I tested handle it normally.

    And why I do not allow to select an exact hardware as other emulator authors do.

    First, this is far from real world, at least for my country: any hardware features, devices etc. could be attached to an existing model, if it were there and some tech skill to get a solderer and do what you wish. I had Leningrad48K with TR-DOS, no problem. Some people had AY on 48K. Etc.

    Second, some snap formats (.SNA) have not information on exact model used, and some other ones having such info (.Z80) are written sometimes with emulators which do not provide such info by a correct way (now, I totally ignore it. I know, this is bad, but just no time to implement it. Later I'll do this). So, when you load .SNA and hardware model always is switching to a certain one, this is not very good idea and should be at least optional feature, especially if switching to another model requires of Spectrum reset. This can be solved loading tape image, but you all know: sometimes snap image comes without tape image, and sometimes it is necessary to save a snap in one emulator to load it in another - may be for test purposes, may be just because the second emulator does not support some tape/disk format or loads it very long etc., but it is desirable to check how it emulates loaded demo/game.

    And especially, why I provided switching timing model on-fly. In many cases while loading a demo / game, you do not exactly know for which timing model it is written. This is not very good idea to select model (and Spectrum resets), when load demo, when (sometimes) wait until walking it to a certain point, and when find that a model was selected incorrectly, and start this loop again. In my case, this requires only 3 mouse clicks to check for certain timing model: no Spectrum reset, no reloading, no waiting.
Sign In or Register to comment.