Clicks in TS/TSFM Mode

[zxshock]

Noticed this during the demo loop for "Ball Quest" (https://files.scene.org/view/parties/2006/chaosconstructions06/game/ballques.zip)

If you look at the recordings there are noticeable clicks at 18.25 seconds, 20.5 seconds, 42.5 seconds and twice at 45.5 seconds (item pickups in first ingame demo). This also happens on Pentagon 1024SL 2.2
ZX_Multisound-ZX_Evolution.mp3

For comparision, this does not happen with a NedoPC TSFM (plugged into the AY socket, chips taken from my ZX Multisound to rule out defects)
TSFM-ZX_Evolution.mp3

Hardware:
ZX Multisound Revision A2, Firmware a696ecd (also happens with e952ec2)
TSFM (http://nedopc.com/TURBOSOUND/ts-fm.php, EPM7032 firmware from 29.05.2022)
ZX Evo Rev. C + dualConf (baseconf 21.09.2024 beta, AVR Boot 25.05.2019)

EDIT: deleted - nonsense

[UzixLS]

The issue is caused by differences in the implementation of TurboSound configuration. In TurboSound, the configuration is changed as follows: the processor selects certain "virtual" (non-existent in the actual 2149/2203 chips) ports. The sound card checks the upper bits of the selected port, and if they are all set to "1", the remaining lower bits are used to modify the configuration.
Bit 0 - selects the active Yamaha chip
Bit 1 - enables reading the FM status register of the Yamaha chip (only for 2203)
Bit 2 - enables/disables the FM part of the Yamaha chip (only for 2203)
Bit 3 - enables/disables the SAA1099

The whole catch lies in bit #3. In the original TS and TSFM projects by NedoPC, this bit is not part of the configuration; instead, it is checked against "1" along with the other upper bits.
In TSFMPro by NedoPC, MultiSound, and ZXM-SoundCard Extreme rev01 V0100, this bit is used as a configuration bit.
Apparently, Ball Quest was written with the original TS/TSFM in mind, which is why it sounds distorted on MultiSound (and, in theory, on all other cards with SAA1099).

I tried modifying the MultiSound firmware to account for this bit during the comparison, and the clicks in Ball Quest disappeared. However, this breaks the SAA's operation because its third bit is always set to 1, meaning the SAA is disabled.
Another possible approach is to configure bits 0-2 only when bits 3-7 are set to "1", while for configuring bit 3, only bits 4-7 are checked. But I'm not sure if this "sitting on all chairs at once" approach might break other software, especially those using both the 2203 and SAA1099 simultaneously, so I'd prefer to leave things as they are. Moreover, other cards with SAA have exactly the same issue.
I think the best solution would be to patch Ball Quest so it accounts for the possible presence of SAA on the sound card.

[zxshock]

That's good to know this issue also exists with TSFMPro and ZXM-Soundcard (that would have been the first thing to check from my side if I had the hardware). Maybe the firmware can be adapted so your fix is applied when disabling SW1.2?

Otherwise I fully agree that it's likely best to keep the firmware as is and fix the issue in software.

Either way, thank you very much for getting back so quickly. I just contacted alone_coder about a potential fix in software.

[zxshock]

Okay, I did tinker around a bit in top.v and found a solution that might just do what I proposed.
It basically changes the first "else if", checking for saa_ena to be 0 and the upper 5 bits and adds a second "else if"-block checking saa_ena to be 1 and "only" checking the upper 4 bits to the TSFM section.
This way disabling the SAA1099 dip switch is taken into account and TSFM goes into a "old style (non-pro NedoPC TSFM)"-mode, when enabling it goes back to the current implementation. Used revision a696ecd of the sources.
Maybe worth adding to the main branch unless I'm missing something? I guess it might still fail in case an old style implementation assumes bit3 to be 0 for whatever reason.

Full relevant code from top.v (barely used github before, therefore I don't even know how to add proper 'code' with line numbers in comments)

/* TURBO SOUND FM */
wire port_bffd      = a[15:14] == 2'b10  && a[3:0] == 4'b1101 && ym_ena;
wire port_fffd      = a[15:14] == 2'b11  && a[3:0] == 4'b1101 && ym_ena;
wire port_fffd_full = a[15:13] == 3'b111 && a[3:0] == 4'b1101 && ym_ena; // required for compatibility with #dffd port
reg ym_chip_sel, ym_get_stat;
wire ym_a0 = (~n_rd & a[14] & ~ym_get_stat) | (~n_wr & ~a[14]);
assign n_ym1_cs = ~(~ym_chip_sel && (port_bffd || port_fffd));
assign n_ym2_cs = ~( ym_chip_sel && (port_bffd || port_fffd));

always @(posedge clk32 or negedge rst_n) begin
    if (!rst_n) begin
        ym_chip_sel <= 0;
        ym_get_stat <= 0;
        fm1_ena <= 0;
        fm2_ena <= 0;
    end
    else if (port_fffd && ioreq_wr && d[7:3] == 5'b11111 && saa_ena == 1'b0) begin
        ym_chip_sel <= ~d[0];
        ym_get_stat <= ~d[1];
        fm1_ena <= d[2]? 1'b0 : 1'bz;
        fm2_ena <= d[2]? 1'b0 : 1'bz;
    end
    else if (port_fffd && ioreq_wr && d[7:4] == 4'b1111 && saa_ena == 1'b1) begin
        ym_chip_sel <= ~d[0];
        ym_get_stat <= ~d[1];
        fm1_ena <= d[2]? 1'b0 : 1'bz;
        fm2_ena <= d[2]? 1'b0 : 1'bz;
    end
end

assign ym_m = clk3_5;


/* SAA1099 */
wire port_ff = a[7:0] == 8'hFF && saa_ena && !rom_m1_access;
assign n_saa_cs = ~(port_ff && ioreq_wr);
wire saa_a0 = a[8];

wire port_fffd_saa = a[15:14] == 2'b11 && a[3:0] == 4'b1101 && saa_ena;
reg saa_clk_en;
always @(posedge clk32 or negedge rst_n) begin
    if (!rst_n)
        saa_clk_en <= 0;
    else if (port_fffd_saa && ioreq_wr && d[7:4] == 4'b1111)
        saa_clk_en <= ~d[3];
end

assign saa_clk = saa_clk_en? clk8 : 1'b0;

EDIT: Seems like TSFMPro has jumpers for that - http://svn.nedopc.com/dl.php?repname=tsfmpro&path=%2Ftrunk%2Fdoc%2Ftfmpro_c_doc.pdf ... I guess disabling FM or limiting to one chip is a bit of overkill, as I never encountered any issues with that in almost 20 years of using a TSFM.

[UzixLS]

EDIT: Seems like TSFMPro has jumpers for that

Jumpers does not affect how address decoded.

line 141 http://svn.nedopc.com/filedetails.php?repname=tsfmpro&path=%2Ftrunk%2Fcpld%2Frtl%2Fbus.v

line 40 http://svn.nedopc.com/filedetails.php?repname=tsfmpro&path=%2Ftrunk%2Fcpld%2Frtl%2Fcfg.v

[zxshock]

Please ignore - see below!
I'm confused (but then again I've never learned Verilog or Z80 debugging) ... and managed to get rid of the clicking in another way.

Doesn't seem to be related to bit3 (already wondered, as commenting out the whole SAA1099 section didn't help), but rather bit2?
Issue can also be fixed by commenting out lines 122 and 123, which of course disables FM. Still doesn't explain why checking for d3 to be 1 also fixed things - but at this point I'm just guessing

I've now made this change to the TSFM section, using SW1.5 for setting fm_ena and it seems to have fixed Ball Quest at the cost of disabling FM via the previously unused switch.

Code removed

Maybe this comes down to the different implementations of the FM enable in hardware? Open drain vs. 2 seperate signals (TSFM, TSFMPro, ZXM Soundcard)

EDIT: Seems indeed to be related to the schematic and/or how FM enable is formed. Pulling both YM3014 fixed the clicking with the original/unchanged firmware.

[UzixLS]

This should not be surprising. The clicks are not caused by the addressing itself, but by an unintentional change in the hardware configuration that is caused by the addressing.

[zxshock]

Seems like the classic TSFM checks for Bits3-7 to be 1
See: http://nedopc.com/TURBOSOUND/tfm_plm_src.zip turbofm.tfm line 75
_SELECT = _A9 or not(BC2 and BC1 and BDIR and A8 and DA[7] and DA[6] and DA[5] and DA[4] and DA[3]) or not(_RES);

Therefore I guess the approach of going into a "Legacy" mode from Post 4 when disabling SAA1099 via SW1.2 seems viable?

EDIT: Ah, thanks for explaining - makes perfect sense ... as said I'm virtually unexperienced with CPLD/FPGA stuff from a design standpoint.