SPS is generally required for Orpheus, and since we're "tricking" UNISOUND into thinking that it is working with an Orpheus card, this would be perfectly reasonable behaviour. Orpheus was designed with that in mind, and does not use those pins for data transfer to peripheral devices.

To avoid polluting the UNISOUND thread, I didn't ask the crucial questions, but will do so now:

1. Are you connecting the external synth via a DAC, or trying to use the wavetable serial port to make a digital connection?
2. Can you post clean photos of the card, showing your modifications?

If nothing else has worked so far, I should be able to put together a quick, stupid utility to select the synth, based on your answers. Since you are using UNISOUND, I assume your WSS base I/O address and control base address are 534H/120H?

It is worth noting, however, that you cannot have both a digital connection via the wavetable serial port and use XD0-7 for data transfer. If you're not, then we should be in business.

yeah post some more info on how you did this - it seems you are in good 640k!enough hands though 😀

640K!enough wrote on 2022-03-29, 03:15:

1. Are you connecting the external synth via a DAC, or trying to use the wavetable serial port to make a digital connection?

The first point seems to be exactly where our mental images of the implementations are incongruent (therefore making the Orpheus' way fail on my card):
I just added the YMF289 via a DAC (using all the datalines) where as Orpheus seems to be using the pins in their other (WTEN, SPS, SDD) configuration option. I actually based that on an example of the 4232's datasheet:

My way wasn't too much driven by the concept, but more an iterative approach: I had first added a wavetable header, from which I'm coming with an analogue audio back to the CS4237. Then I decided to try and add the OPL also, so I attached it to the XD0:7 pins and taking the DAC-approach to mix its analogue out with the wavetable signal, in order to feed that into the Line-In of the CS.

This is also why I'm almost expecting it would start working if the /XOFi and /XOFe flags were available for the generic CS4237 init of unisound.

640K!enough wrote on 2022-03-29, 03:15:

If nothing else has worked so far, I should be able to put together a quick, stupid utility to select the synth, based on your answers. Since you are using UNISOUND, I assume your WSS base I/O address and control base address are 534H/120H?

Well, that would be mighty awesome if that were possible and it would save me from probably quite a few hours of trying to figure out how to send the needed flags to the card via debug (which is something I've never even tried so far) 😀
The WssBaseStart is indeed at its default of 534h and the CtrlBaseStart is the 120h default also.

640K!enough wrote on 2022-03-29, 03:15:

It is worth noting, however, that you cannot have both a digital connection via the wavetable serial port and use XD0-7 for data transfer. If you're not, then we should be in business.

I'm definitely not using the digital connections - both the WT and the OPL are connected via their dedicated DACs. The WT is being fed the Midi-TX line, the OPL is getting the XD7:0-pins (plus SCS, XIOR and XIOW).

640K!enough wrote on 2022-03-29, 03:15:

[*]Can you post clean photos of the card, showing your modifications?

I'll attach a picture of the card a little later, but it's probably not gonna help showing much - it's a black PCB, and all the traces are impossible to see (it's also become an insanely populated area). The schematic would probably help to show more:

keropi wrote on 2022-03-29, 07:30:

yeah post some more info on how you did this - it seems you are in good 640k!enough hands though 😀

Which is something I couldn't appreciate more - and I want to thank you both for even taking the time!

I would do this :
74HCU04
It would help you I think.
On your SCH I would remove C74.

MJay99 wrote on 2022-03-29, 12:19:

The first point seems to be exactly where our mental images of the implementations are incongruent (therefore making the Orpheus' way fail on my card):
I just added the YMF289 via a DAC (using all the datalines) where as Orpheus seems to be using the pins in their other (WTEN, SPS, SDD) configuration option.

Now we're getting somewhere! In the other thread, you mentioned something about wavetable mixing, which I took to mean that you had connected the new synth digitally via the serial port. I could have saved us both a whole lot of confusion and back-and-forth discussion by asking about that in the first place (though the UNISOUND thread was hardly the place for it).

In this case, the implementation used by UNISOUND will not work without modification. So for now, you would probably be better off going back to your original EEPROM content, in whichever default IFM state you prefer (with no SDD, SPS, WTEN). This configuration also makes switching between the two simpler, and a basic DOS-based tool for that is attached (EDIT: see below for newer version). Remember that it is pretty simple/stupid, with no validation, detection or error-checking. If the card isn't at 534/120, it will either wait forever, or fail after some time and dump you back to the command line. When it does work, it simply checks whether external synth or IFM is active, and switches to the other one.

When you have a chance, please report back on whether that appears to have worked.

EDIT: The attached tool doesn't touch the mixer registers. The sequence would be init with UNISOUND, then use FMSWITCH to select synth. Depending on what UNISOUND does with the mixer registers, you may need to adjust the volume for the selected synth to get audible output (with CWDMIX, for example).

Marmes wrote on 2022-03-29, 18:10:

I would do this : 74HCU04 It would help you I think. On your SCH I would remove C74. […]
Show full quote

I would do this :
74HCU04
It would help you I think.
On your SCH I would remove C74.

Marmes, thank you for your help, too! May I ask if the 7404 is more intended to delay or reshape the MCLK - or has there been any other intention that I am not seeing right now (e.g. some 3 to 5V level shifting)? I'll definitely keep it in mind, in case I'm starting to think the DAC is failing. Right now, my theory is that initializing the part with WTEN, SPS and SDD is making the YMF go nuts on the data, since it seems to be working fine when I init it with my INI (without those flags) instead of the Orpheus one (which introduces them) and it also fails when I a) remove those flags, but b) use unisound on a fake orpheus name in my config.

So far, the card actually seems to be working nicely with the external OPL if I don't try to force unisound on it, in order to easily switch between the internal and external FM (which is something I would very much like though, as it's my default tool for an init and would add a fun feature to this thing). That's actually what I tried to gain by asking JazeFox if he could maybe implement it. 😀

Btw. the C74 is just an option - I added it to being able to test routing of the ISA's 14,318 to the oscillator IC and maybe being able to remove the extra generation of that CLK at the MK1420s. As for it not just being a 0 Ohm jumper (which it actually was when I sent the card out for production): I did read somewhere that when using the ISA-bus's CLK, it should be isolated by such a cap - which is why I repurposed it in the schematic from an R to C. It still hasn't even been used or tested at all - so far, the MK1420 is getting its clock from the crystal (which do have 0 Ohms, so I can disconnect them for testing the other option).

You use HCU04 to remove that Mk1420, which is obsolete, an you drive 16.9Mhz both to Crystal and external DAC. I would see Cs4334.

Cheers!

640K!enough wrote on 2022-03-29, 18:33:

When you have a chance, please report back on whether that appears to have worked.

640K!enough, wow, many many thanks - it's working perfectly! I could instantly hear a different (slightly higher) noise floor when using the internal FM instead of the external FM during Freddy's MODM activating the FM - which I wasn't expecting 😁 So, both FM options are working and they can indeed now be switched with your tool - which is awesome!

Seeing your edit, too: That's indeed how I tried it, init with unisound and switching between the FMs with your tool. It's perfect! Thank you very much!

I still owe you an image of what I've been trying to do there (and ignoring the WT thingy, which is waiting for a corrected PCB to be delievered, seems to be all working now):

MJay99 wrote on 2022-03-29, 21:24:

640K!enough, wow, many many thanks - it's working perfectly!

I certainly wouldn't try distributing that as production software, but it's serviceable for testing. I hope that was helpful.

MJay99 wrote on 2022-03-29, 21:24:

I could instantly hear a different (slightly higher) noise floor when using the internal FM instead of the external FM during Freddy's MODM activating the FM - which I wasn't expecting

This could just be a result of the default mixer settings. As you approach maximum amplification, the CS4237 appears to add analogue gain, and beyond a certain point, there can be some noise or persistent hum. Try backing off the volume a little, and see if that doesn't yield a quieter result. The way the Crystal tools configured the mixer, that was a persistent problem, and is part of the reason that ORPHINIT came into existence.

EDIT: You can hear the difference clearly by playing some of the sample files included with Adlib Tracker II. If you have any doubts about whether the switch is actually taking place, try that.

640K!enough wrote on 2022-03-30, 01:09:

I certainly wouldn't try distributing that as production software, but it's serviceable for testing. I hope that was helpful.

It's really perfect for the feature I was looking to get from unisound (which I'd still consider a good addition). But your tool is even better in terms of flexibility (no need to reconfigure the whole card for the FM switch). And this isn't going to be a commercial product at all - just the way I spent some time during lockdowns 😀

640K!enough wrote on 2022-03-30, 01:09:

This could just be a result of the default mixer settings. As you approach maximum amplification, the CS4237 appears to add analogue gain, and beyond a certain point, there can be some noise or persistent hum. Try backing off the volume a little, and see if that doesn't yield a quieter result. The way the Crystal tools configured the mixer, that was a persistent problem, and is part of the reason that ORPHINIT came into existence.

So far, I've just tried changing different volumes with unisound and in the end, reducing the FM volume (setting it to lower values or zero by /vF00), it becomes silent. The external OPL coming in via the Line-In is without the hum.
It's not much of an issue to me, just an interesting observation that the internal FM is adding this noise. In the end, the real OPL is the default and the CS-FM just a fun secondary option.

640K!enough wrote on 2022-03-30, 01:09:

EDIT: You can hear the difference clearly by playing some of the sample files included with Adlib Tracker II. If you have any doubts about whether the switch is actually taking place, try that.

There is no doubt at all! 😀 I can instantly hear the difference on e.g. alloyrun.rad and it's also obvious by the difference in background noise. Apart from that, while testing in the beginning, I also removed one of the coupling caps of the external OPL to definitely be sure I'm hearing the right configuration. I've run the switcher about a 100 times now and it hasn't failed one single time (on my card's default config, of course).

Marmes wrote on 2022-03-29, 18:10:

On your SCH I would remove C74.

I've now tested that clock being provided from the ISA-bus (still coupled in via the C74 cap) and it seems to work fine.

As for removing the MK1420 completely: where do you source the 33Mhz from that it provides to the YMF289? I'm guessing it's a dedicated crystal there, then?
So far, I've had no issues sourcing them through e.g. Aliexpress, but I see your point in better not using them for a new design.

Though, I have to admit, that's something I didn't bother with too much till now, as I wasn't really planning anything (commercial) with it.

Mouser and digikey have the crystal, it is a standard frequency found in many CD players and drives.

Tiido wrote on 2022-04-04, 07:08:

Mouser and digikey have the crystal, it is a standard frequency found in many CD players and drives.

Hi Tiido, thanks for taking the time to help! Guess I need to apologize for this misunderstanding though: I meant to ask where Marmes is getting the 33,9 MHz for the YMF289 from on his card (that on my card is coming from the EOL MK1420, which he suggested to remove). I was just wondering if there maybe was a more elegant solution than adding this crystal and its caps instead of the MK1420, though I'm pretty much guessing there is not. 😀

It should be 33.868800Mhz (44100 * 768) goes to YMF289, and MCLK output of the DAC (which is half, exactly what Crystal needs) goes into Crystal, and problem is solved.

I couldn't resist making this tool just a little smarter. It now takes the extra steps of checking the current "context" of the chip (WSS or SB emulation mode), and making sure that volume levels are preserved and the context is the same before being returned to the command prompt. Depending on the hardware configuration stored in the EEPROM, the problem may not have been readily apparent, but it is definitely present.

There are still usually differences in volume between Crystal FM and OPL3, but this isn't accounted for, and in SB emulation mode, it is generally not possible to compensate for this difference in any satisfactory way.

This version further assumes that the SB base address is 220H.

Who knows what else we may end up with if the perfectionist itch strikes again.😀

Tiido wrote on 2022-04-04, 18:14:

It should be 33.868800Mhz (44100 * 768) goes to YMF289, and MCLK output of the DAC (which is half, exactly what Crystal needs) goes into Crystal, and problem is solved.

Hi Tiido, that is actually what I also understood from Marmes' hint - I was really just hoping there might have been an unknown way to maybe not needing the 33.86880MHz crystal.
It really wasn't much of a problem, more a bit of a moot point to me personally, if I'm adding a crystal and 7404 in order to remove the MK1402 (which I was able to easily and cheaply source from China) - even more since it had to be done in the most crowded area of the board. If I could have done it without adding the crystal, I would have instantly been sold on it 😁

Still, of course, I now had to try if routing it was possible - and it was:

So, cheers to both of you! 😁

What is the inverter for ? If it is for making an oscillator you need to bear in mind that almost all crystals bigger than 25MHz are 3rd overtone and you need an additional inductor+capacitor to supress fundamental mode oscillation.
YMF289 already has 3rd overtone oscillator in it so the crystal sould directly connect to it and 16MHz output from YMF is enough to drive the one chip (the Crystal).

Tiido wrote on 2022-04-04, 21:41:

What is the inverter for ? If it is for making an oscillator you need to bear in mind that almost all crystals bigger than 25MHz are 3rd overtone and you need an additional inductor+capacitor to supress fundamental mode oscillation.
YMF289 already has 3rd overtone oscillator in it so the crystal sould directly connect to it and 16MHz output from YMF is enough to drive the one chip (the Crystal).

The YMF would be driving the Crystal and the DAC here - I really just took Marmes' recommendation from above, expecting it to be more than well tested in this configuration already (and even more for him being one of the brains behind a well-known CS-based card).

Marmes wrote on 2022-03-29, 18:10:

I would do this :
74HCU04

Re: Adding an external YMF289 to the CS4237B.