Well, if the CSFM works, but the external OPL doesn't, there's quite a bit to question and check - it's basically what all this idea was about 😀
The first and easiest thing I could think of is: where does the output of the OPL chain go? Does it route back into the CS4237, or does it get mixed into something (somewhere) else? Maybe it's just a muted input?

How are you initializing the card? I'd suggest unisound for it and enabling all inputs and outputs for testing (/V99 /VF99 /VL99 ...) with /XOFe and /XOFi you can also switch between the external and internal OPL and then e.g. play a simple .RAD via e.g. MODMXT - that'll avoid most other software issues.

Or did you attach the OPL differently than I'm expecting? With the YMF262 I simply used the old YMF262->YAC512->LM3403 stack (my first version with a YMF289B went through a PCM1781 in the end, but these went into insane prices by now).

If that's not it, then it might need some basic (scope) checking on the OPL, Op-Amp, etc.
I'd start with (in my case): do the OPL, YAC, LM get VCC? Does the OPL get a clock input and is the reset fine?

Or, you could start from the other side and follow things back from the OpAmps also and see if there's maybe already some audio there...

Edit: removed the CV part - misremembered that it is the +2.5V reference.

Here's my schematic. The LIN and RIN lines go to the normal line-in circuit.

I considered that it could be because it's muted, but I shouldn't get that FM chip not detected error in duke3d if it was just muted, I would expect.

I'll check the other things later when I get a chance!

At a first quick glance, most of it (OPL -> YAC -> TL074) looks fine to me - and your RIN / LIN are going into the CS via capacitors, correct?

But as much as I am not an expert on the analog part (so, a huge caveat emptor there):

The output stage reminds me of a schematic I saw on an electronics forum... which didn't work for me, either. As far as I remember, R33 & R29 did pretty much kill the signal for me.
But again, it's been a bit since I've been sitting on this and I am by no means an expert - so, better triple check my words here, or maybe there's even others with more expertise who'd want to chime in 😉

I'd have liked to try the TL074 here also, just for the fun of it, but sadly it seems that I don't have any hiding somewhere... 😀

yeah, I bought 100 of the TL074s when I built the original project that my schematics are based on. This design was actually from Eivind Bohler's ITX Llama and his OPL3 module. I based it on that since it's a known working design.

Yes, the RIN and LIN lines have passives on them. I'm attaching the schematic here for reference.

Actually now that I’m looking at it, I have resistors on the line coming from the TL074 and the CS side. Would that cause the issue? The sound effects work totally fine like this but I wonder if it would cause an issue for music. I can’t see how though. This is just the output stage. I figured it would be an issue on the address or data lines. Any OPL3 pros out there???

That's exactly where I was looking at also - but you're right, that shouldn't be able to cause a detection error indeed.

And that error really seems to be a sign of something more upstream being wrong, because: I just tested Duke Nukem 3D with Soundblaster for Sound FX and either Adlib or Soundblaster for FM with choosing either the CSFM or OPL3 upfront - both worked perfectly fine and without an error message. So, that issue really is probably somewhere way before all of this analog part.

Just to sum it up: Sound effects (which are always coming from the CS4237B) are always working. CSFM, when selected, is also working (for music). Only the external OPL isn't showing any signs of life?

Maybe we should start with the eeprom then: would you want to PM or attach me the INI you used? Then I could diff it against the one I used (probably tomorrow) and see if all the settings are the same.

MJay99 wrote on 2024-10-08, 22:58:

That's exactly where I was looking at also - but you're right, that shouldn't be able to cause a detection error indeed. […]
Show full quote

That's exactly where I was looking at also - but you're right, that shouldn't be able to cause a detection error indeed.

And that error really seems to be a sign of something more upstream being wrong, because: I just tested Duke Nukem 3D with Soundblaster for Sound FX and either Adlib or Soundblaster for FM with choosing either the CSFM or OPL3 upfront - both worked perfectly fine and without an error message. So, that issue really is probably somewhere way before all of this analog part.

Just to sum it up: Sound effects (which are always coming from the CS4237B) are always working. CSFM, when selected, is also working (for music). Only the external OPL isn't showing any signs of life?

Maybe we should start with the eeprom then: would you want to PM or attach me the INI you used? Then I could diff it against the one I used (probably tomorrow) and see if all the settings are the same.

The INI file I used is just the default PNP37.ini file with the modifications you mentioned earlier in the thread. I tried some other .INI files as well but they didn't work either. I'm not sure what I'm missing here. it's going to end up being something so silly though I'm sure.
Is there any DOS magic I can use to verify if the chip itself is working properly?

I'd say, start with unisound, e.g. like this (it's probably all redundant information, but doesn't hurt to start from a shared baseline):
UNISOUND - Universal ISA PnP Sound Card Driver for DOS v0.81b

SET BLASTER=A220 I5 D1 (unless those are otherwise blocked and you can add more flags later)
unisound /vf99 /vc99 /vl99 /XOFi (your card should be the only one in the system for this test and command - and this is surely not a perfect or recommended setting, just to make sure everything is at max)

Then I'd get alloyrun.rad from e.g. here:
https://sid.ethz.ch/debian/adlib/Reality%20AdLib%20Tracker/

Then download and play it with MODMXT from another thread here on Vogons:
Mod Master XT 1.0 Released : Play .MOD, .XM and .VGM on a 8088 4MHz

If it plays fine this way, the CSFM (FM-variant inside the CS4237b) is fine (as I'd expect after the what I read before).

Then you could get yourself some .s3m and play that with MODMXT, which would check the SB part. If that works, too, as I'd say it should be after the above, I would say the CS4237b and it's analog output part is mostly fine (but there could still be issues with the connection to the external OPL and the Line-In)

Then I'd switch to the external OPL via
unisound /vf99 /vc99 /vl99 /XOFe

and try to play the alloyrun.rad with modmxt again. If it there's nothing audible then, the issue pretty surely is somewhere between the CS, YAC, OpAmp and back to the CS - LineIn.

After checking that they all receive VCC (and there's 2.5V on the Ref) and the RESET is ok, it's time to get out the scope - I'd start looking for the basics: the oscillator doing its thing, activity on the address and datalines and then: something looking like an audio-signal after the DAC.

If there's no scope at hand: a basic check if the footprint matches the pinout of the oscillator (don't ask why I'm mentioning that 😉 ) and then: maybe a critical view at the soldering and black-box resoldering (I had SMD parts from China that looked nicely soldered, but weren't in the end, as they came with their legs slightly bent)... You could also try and bodge in the 14,3178MHz from the ISA connector, instead of using the oscillator and force the RESET line

Not sure it can drive that, but maybe you could also try to attach a headphone or amplified speaker to the opamps (TL074) output (by e.g. replacing the resistors right after it with 2uF caps as a tombstone (if SMD) and using the other side to connect to a line out jack), to see if there's something resembling audio coming out from it.

If things do fail somewhere on this path, it might help circle in on the issue and help the decision on where to have a closer look.

MJay99 wrote on 2024-10-12, 23:17:

I'd say, start with unisound, e.g. like this (it's probably all redundant information, but doesn't hurt to start from a shared b […]
Show full quote

I'd say, start with unisound, e.g. like this (it's probably all redundant information, but doesn't hurt to start from a shared baseline):
UNISOUND - Universal ISA PnP Sound Card Driver for DOS v0.81b

SET BLASTER=A220 I5 D1 (unless those are otherwise blocked and you can add more flags later)
unisound /vf99 /vc99 /vl99 /XOFi (your card should be the only one in the system for this test and command - and this is surely not a perfect or recommended setting, just to make sure everything is at max)

Then I'd get alloyrun.rad from e.g. here:
https://sid.ethz.ch/debian/adlib/Reality%20AdLib%20Tracker/

Then download and play it with MODMXT from another thread here on Vogons:
Mod Master XT 1.0 Released : Play .MOD, .XM and .VGM on a 8088 4MHz

If it plays fine this way, the CSFM (FM-variant inside the CS4237b) is fine (as I'd expect after the what I read before).

Then you could get yourself some .s3m and play that with MODMXT, which would check the SB part. If that works, too, as I'd say it should be after the above, I would say the CS4237b and it's analog output part is mostly fine (but there could still be issues with the connection to the external OPL and the Line-In)

Then I'd switch to the external OPL via
unisound /vf99 /vc99 /vl99 /XOFe

and try to play the alloyrun.rad with modmxt again. If it there's nothing audible then, the issue pretty surely is somewhere between the CS, YAC, OpAmp and back to the CS - LineIn.

After checking that they all receive VCC (and there's 2.5V on the Ref) and the RESET is ok, it's time to get out the scope - I'd start looking for the basics: the oscillator doing its thing, activity on the address and datalines and then: something looking like an audio-signal after the DAC.

If there's no scope at hand: a basic check if the footprint matches the pinout of the oscillator (don't ask why I'm mentioning that 😉 ) and then: maybe a critical view at the soldering and black-box resoldering (I had SMD parts from China that looked nicely soldered, but weren't in the end, as they came with their legs slightly bent)... You could also try and bodge in the 14,3178MHz from the ISA connector, instead of using the oscillator and force the RESET line

Not sure it can drive that, but maybe you could also try to attach a headphone or amplified speaker to the opamps (TL074) output (by e.g. replacing the resistors right after it with 2uF caps as a tombstone (if SMD) and using the other side to connect to a line out jack), to see if there's something resembling audio coming out from it.

If things do fail somewhere on this path, it might help circle in on the issue and help the decision on where to have a closer look.

ok so when I tested with MODMXT using alloyrun.rad in CS4237 mode it worked fine. when I switched to /XOFe in unisound the file played but no sound is heard. I tested all the power locations on the chips and I have signal +5V more or less at all locations. I tested the reset line with my mini oscilloscope and I'm seeing 4.6ish volts which should be correct I'm assuming since the reset line is active low so having that be high would mean the reset line is not active right?
I have to admit, I'm an extreme noob with oscilloscopes so I don't really know how to use it much more than that. I poked the clock line going to the external crystal and I see voltage, but I can never get it to show me the frequency crystals are running at. this is a problem with all crystals I test though so I'm chalking it up to my skill level. the line directly below that is the clock line that goes to the YAC chip and that isn't showing any activity but again, that could be my inability to use a scope correctly.

I've gone over the schematic several times and compared it to others on the internet. they all see to look the same as mine so I think logically it's correct but clearly there's something wrong somewhere else.
When I switch to the external synth through unisound I hear a pop so that tells me that possibly the output lines from the YMF262 are connect properly but I don't know what to do next. I've used this same circuit on a couple other projects and I'm seeing the same issue on all of them so far so there's something I'm missing somewhere.

According to the datasheet for the YMF262, pin 3 is /IC 'initial clear', which should be held low for 400/F(requency) seconds. So, seeing it high a tiny bit after startup (and 4.6V should be really enough) is fine.

Since the oscillator is still not verified, but really important (and there could be footprint / pin-out issues), I'd suggest we find a way the oscilloscope giving you usable results first 😀

If you're just seeing a high level, it might be a not working oscillator or as you mention or it could be a wrong timebase on your oscilloscope. Since you're seeing elevated voltage, I'm assuming the voltage division setting is somewhat in a sensible range. Maybe it's just a matter of setting the oscilloscope to a more fitting time division. Can you find a button / setting that allows you to change something like a timebase (e.g. 100ms / 1ms / 100ns / 10ns /...)? If it's a cheap one, it might not have enough sampling rate or bandwidth to show this frequency, though, which might be the reason you're not getting much there.
It's just a very basic rule of thumb, but with those 14,318 MHz it should be at least 2.5 times the frequency, so with around 50MHz it might be ok-ish, even though values 5 times above would give better results. More details e.g. here:
https://www.picotech.com/library/blog/oscilloscope-tutorial

But even if it's less than a 50MHz scope, I'd hope it at least might show you some sort of non-flat voltage level, if you set it to its very lowest timebase. It doesn't need to be a properly displayed frequency then, but it should at least not be a fully flat high level.

If all that leads nowhere, I'd take a critical look at the footprint of the oscillator, compared to the oscillator's datasheet (and even if it really is an oscillator and not just a crystal). Oscillators usually have a dedicated pin 1 and need to be put in correctly, whereas crystals might fit two ways (all depending on the package type, of course). In the SMD world, there's also often 3,3V (or lower) ones which might not work here.

But, actually thinking of it again, to circumvent all this work, you could also simply just remove the oscillator and feed in the 14,318 MHz from the ISA-slot (B30 / backside, pin 30), to test if that changes something if you can't measure it:
https://upload.wikimedia.org/wikipedia/common … SA_Bus_pins.svg

Afterwards, I'd suggest looking at the end of the chain with your oscilloscope and go to the op-amp's outputs and check if there's some waveform there when it's playing (with e.g. the lowest timebase your scope can go to) and if you can maybe even make out it changing when some music plays.

If there's nothing at the output of the op-amp, then maybe it's something in the soldering (or defective parts) around the YAC and YMF - because your schematic did look fine to me, too. So if your software doesn't give you DRC errors, I'd say it should be ok, too.

That R55 needs to be minimally 100 ohm or that C54 will cause the opamp to wildly oscillate (result is dirty sound from basically much increased THD and devices down the line may not appreciate the ultrasonic content either). R61 is completely unnecessary and should be 0ohm, there's no gain involved, only a buffer conf (as is it works but will induce noise penalty from the resistor). R49 is not needed at all, if it goes anywhere it goes after C101, but only if Line-In-CS has no biasing of its own whereever it connects to, here I assume the CS means the Crystal chip so R49 isn't needed (it works with but it simply wastes energy by being extra load on the opamp).
EDIT : added few clarifications

Thanks, Tiido, I've removed that excerpt (it does work for me, though).

MJay99 wrote on 2024-10-16, 08:39:

Thanks, Tiido, I've removed that excerpt (it does work for me, though).

was this in response to my schematic or yours?

Mine. And since he's the resident OPL expert, I won't even doubt for a second that he's right. Only thing I can still say then, is: it's giving me more than nothing 😄
Maybe he can have a quick look at your schematic, too and find an issue which I didn't see. That's actually what I was hoping all the time, too - since there's quite some expertise on soundcards in this forum.

I'm curious if anyone has a complete schematic of a working OPL3 end to end. there must be something wrong with mine somewhere, but I can't identify the problem. and of course, I used this same schematic in several projects already because I thought it was a working design. I'm wondering if maybe I'm not soldering the crystal properly? I don't know. I may try to build one on a breadboard and use a through hole part but I'm holding off on re-spinning updated versions of the various projects until this is resolved!