2 chips is still not a problem for that output but if you really need to add something boost drive capability you can gain space by using a single inverter (or AND or OR or non inverting buffer) chip. But these buffers are not necessary unless you have a something like 20cm long trace where capacitance along the way starts to matter.

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

2 chips is still not a problem for that output but if you really need to add something boost drive capability you can gain space by using a single inverter (or AND or OR or non inverting buffer) chip. But these buffers are not necessary unless you have a something like 20cm long trace where capacitance along the way starts to matter.

I'm more than happy to remove it (which in fact I now did), even though in the grand scheme of things it's not helping much in terms of costs- this keeps being a pretty expensive thing to build 😀
But still, for any possible future use, there now really is one less EOL piece from China to bother with.

If it weren't for such an expertise in this thread, I'd definitely have kept it in, just to be safe 😉 So, thank you both, Marmes and Tiido!

640K!enough wrote on 2022-04-04, 19:19:

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.

Of course, I couldn't resist trying it...😁 But, it's obviously become too smart for this machine now:

Due to being much too late already, I haven't tested much, yet, but it's hanging with or without memory managers.

MJay99 wrote on 2022-04-05, 00:32:

Due to being much too late already, I haven't tested much, yet, but it's hanging with or without memory managers.

I'm not quite sure how, but somewhere between the machine I use to develop these things (which is almost never on the local network, much less the Internet) and the machine I used to upload the file, it was corrupted. I have replaced the file, in ZIP format this time, so hopefully its integrity checks will alert you to a problem like this before you try running the executable.

640K!enough wrote on 2022-04-05, 03:31:

I have replaced the file, in ZIP format this time, so hopefully its integrity checks will alert you to a problem like this before you try running the executable.

It's working perfectly fine now, thank you again! 😀 I can instantly hear the different background noise floor when it switches to the CSFM.

Just one thing that came to my mind, since it's now (re-)setting SB mixer values: would it technically also be possible to maybe make it set a predefined volume difference to the original values while switching? E.g. realizing that the external FM in its default might be 50% louder in a certain card, one might think calling it with a percentage flag to reduce the volume accordingly right at the switch time (a static config file would probably be better, but I know it would add quite some overhead to this idea, so not even suggesting that).So, e.g. calling it something like this > fmswitch /opl2csfm=150

On a future version of this card, I might also try and reduce the level of the external OPL before it enters the CS, but it seems like a more flexible solution if it could be done in software.

Still, even without this, it's already more than I could have ever expected - so, a huge thank you!

MJay99 wrote on 2022-04-05, 23:22:

I can instantly hear the different background noise floor when it switches to the CSFM.

I'm actually still questioning this. From your picture, you seem to be using a Rev E chip. Even the pre-production, less-refined version of Orpheus does not exhibit this behaviour, as far as I have noticed. Was this still apparent when you were switching between two EEPROM configurations (with IFM bit set/clear)? It could be a software problem, but could also be a separate design issue. Have you tried using CWDINIT and CWDMIX (instead of UNISOUND)? Do you get the same behaviour if you don't get too close to maximum "Synth" volume?

MJay99 wrote on 2022-04-05, 23:22:

Just one thing that came to my mind, since it's now (re-)setting SB mixer values: would it technically also be possible to maybe make it set a predefined volume difference to the original values while switching?

It can certainly be done, but since you seem to spend most of your time in Sound Blaster emulation mode (where UNISOUND leaves the chip), it will be difficult to calibrate. Remember that the SB Pro mixer is quite crude, with only seven different volume levels. Since you're only ever using one FM synth at the time, I don't see what there is to be gained by painstakingly equalising the volume levels. Unless you're noticing excessive clipping at normal listening levels (Madbrain's FANK5.A2M, included with Adlib Tracker II, is a good test for this), I think adding external hardware-level attenuation to the OPL3 signal would be a mistake.

640K!enough wrote on 2022-04-07, 02:59:

Was this still apparent when you were switching between two EEPROM configurations (with IFM bit set/clear)? It could be a software problem, but could also be a separate design issue.

It definitly is and was. I've now played with it a little more (after having received another OPL for another test): so far, it looks like the OPL is always staying active when the IFM is selected and continuously providing MCLK and LCLK to the DAC. With these CLKs alive, but no data on the MDATA, the DAC seems to output a low level noise floor (so, actually in both configurations). With the OPL gone, the faint noise floor goes away, too (which I can do in my hardware setup, since the clocks for the YMF and CS are coming from the MK1420) - funny enough, this wouldn't be possible if I'd have clocked the CS from the YMF (as I am doing for the next planned version).

What's currently still not explained to me is: why does it suddenly get amplified immensely when the switch to the IFM happens and being reduced to almost inaudible levels when the external OPL is selected again (with no observable change on the DAC's Line-Out). Is this a to-be-expected behaviour of the CS4236 / CS4237B (which I both tried to rule out a defective IC, too)?

These are two shots from one of the AOUTs of the DAC, with the OPL3 playing and not playing (please ignore some of the displayed info, it's been the first time and even the first 30 minutes of using this oscilloscope):

What I am wondering now is: would it be possible to use the YMF289's power-down feature to maybe try and silence this path when the IFM is on (since it only seems to happen with the OPL in place)?

The datasheet shows this:

What are the thoughts on this - easily doable and sounding reasonable, or pointless and hopeless? 😁

Well, this issue can be closed now, too. I actually had two things contributing to this: one being that during consolidating component values, I accidently left a double valued resistor around a TL082C I use for mixing two inputs together, therefore amplifying the signal 2:1 (though that was the minor issue and mostly just explaining the higher volume of the external OPL).
The more important one: I somehow overlooked that there should be some filtering between the DAC and the following stage, so adding that, it's pretty much perfect now.

All in all, I'm very happy with the possible solution, as the only real 'patch' it needs is a piggy-back cap on two resistors:

Crystal FM still ends up being somewhat quieter than the external synth, but not so much that it's worth worrying about. It's good that you solved that to your satisfaction.

Since you're planning to eliminate the added clock-generation circuitry in the next revision, there is probably no point in exploring the power-down mode of the YMF289.

It will help to use a modern DAC chips, the output from YMF is standard RJ16 format that pretty much every DAC out there supports. No need to use the noisy and otherwise shitty Yamaha DAC or the Crystal one.

I love the aligned components in this pic, everything so tidy 😀

Tiido wrote on 2022-04-13, 05:26:

It will help to use a modern DAC chips, the output from YMF is standard RJ16 format that pretty much every DAC out there supports. No need to use the noisy and otherwise shitty Yamaha DAC or the Crystal one.

I'm totally open to trying others and there's actually just another Digikey order waiting to be sent out.
But, since I'm far from being an expert in those regards (unlike yourself): off the top of your head, is there any specific DAC you'd suggest / recommend me trying?
On a first, quick look into what Digikey is offering, I am almost only getting the CS4334 as a search result.

640K!enough wrote on 2022-04-13, 01:51:

Crystal FM still ends up being somewhat quieter than the external synth, but not so much that it's worth worrying about.

Indeed, and I fully agree. It's slightly noticeable (now that it is so easily and quickly switchable), but there's definitely no need to adjust the speaker volume - I'm very much ok with that.
Also the wavetable header is now coming in at a good volume.

640K!enough wrote on 2022-04-13, 01:51:

Since you're planning to eliminate the added clock-generation circuitry in the next revision, there is probably no point in exploring the power-down mode of the YMF289.

Certainly true, but my curiosity is probably gonna kick me into trying it on this card, still. 😀

It also doesn't hurt to be learning something new, either (which is actually one of the major reasons why I even started with this card), so I guess I'll be reading up on how to push some register values on the weekend or next week 😀

PCM1781 is a very good option, it takes RJ16 and I2S (selectable by a pin) and has a lot better analog performance than that Crystal DAC.

Thank you, Tiido! It might not be fully final, but I managed to squeeze it in: