No testtone sound on OPL3 channels 3+4

[Wilba]

I finally finished off my OPL3 module, using the OPL3 chipsets I got from the bulk order.

Good news: They work, sort of.

Bad news: They work, sort of.

Here’s the troubleshooting log so far.

NB: I refer to parts by references on schematic PDF, actual part references on SmashTV’s PCB and website are DIFFERENT!

I uploaded the FM testtone app and only got the 1kHz tone on channels 1+2.

Tested connectivity in the opamp stages and voltages, all seems OK.

Swapped around opamp ICs to prove they all work fine.

Took out IC5 and bridged between IC3:O3 and IC5:O3, got audio out of channel 4. Also bridged between IC3:O4 and IC5:O4, got audio out of channel 3. TL074 in IC6 seems to be good (and tracks between IC5->IC6).

Probed with noise generator (aka. my finger attached to a resistor lead) at IC4:AOUT and get buzz on channels 3+4, otherwise it remains perfectly silent. Note probing on IC2:AOUT results in same kind of buzz on channels 1+2 mixed with the 1kHz testtone. Therefore, TL074 in IC5 seems to be good.

I was fairly confident also that the YAC512 in IC4 must be good too, since it’s taking in input at pin IC4:SWIN and outputting it to IC4:CH1 and IC4:CH2 into the opamps and making sound on channels 3+4.

So… I cut the track going into IC4:DIN and connected IC4:DIN to IC1:DOAB… in other words, make both YAC512 use the same output from the YMF262 - the “known good” 1kHz test tone signal… and I get test tone on channels 3+4!!! Note also, if I leave IC4:DIN open (floating), it goes into insane noise mode as you would expect from garbage values going into a DAC and then amplified.

Therefore, I am pretty certain that both YAC512 are perfectly fine, and that the problem is the YAC512 in IC4 just is not getting any test tone signal at all.

I ran through possible problems between YMF and YAC512 and they are just not there.

The connections are good.

IC1:DOCD to IC4:DIN is good.

All pins of IC4 in common with IC5 are good (and this is backed up with IC4 working and making sound if connected to IC1:DOAB)

Connectivity between PIC and OPL3 is all good. (I doubt I would get any testtone at all if this connection was bad - the registers would be garbage).

I was trying hard to pretend I only had one YMF262 (i.e. to help others in future who really only have one YMF262)… but I had run out of ideas and I really wanted to know if it was a broken YMF262.

So I replaced the YMF262 with another brand new one, and the problem is the same!

I am assured that I should expect the testtone on channel 3+4, but right now I can only start thinking up unlikely explanations such as, the YMF262 really is not outputting on channels 3+4, since the output on DOCD pin is 0.28V (effectively logic low all the time?) whereas DOAB is 2.24V (an average of logic low and high?)

What else could I possibly do to work out what’s wrong?

[nebula]

Here are some shots in the dark …

I’m curious if 0.28 V on DOCD is the voltage you saw before or after you cut the trace.

Did you try the MBFM app?  Does it behave as expected on outputs 1/2?

Another way to prove quite conclusively whether a usable signal is coming from DOCD would be to cut the DOAB line as you already cut the DOCD line, and send the DOCD signal to the upper YAC - that might help erase that final bit of doubt.  But I’m hoping that maybe it’s just a slightly out-of-spec signal that could maybe could be coaxed to work.

I wish we could scope those digital outputs.  You could get a reasonably insightful view using one of the s/h lines (SMPxx) as a trigger source.  I don’t know the input impedence on the YAC, and whether a borderline YMF might benefit from pull-up/down on the DOAB/DOCD lines.

[Wilba]

I’m curious if 0.28 V on DOCD is the voltage you saw before or after you cut the trace.

Both. It’s an output pin and should be unaffected by what it’s connected to.

Did you try the MBFM app?  Does it behave as expected on outputs 1/2?

Yes. Well… I am not entirely sure, because it sounds like a toy keyboard’s piano patch and every second (or third, fourth etc) note sounds like it’s louder or has a higher-pitch “tink” to it.

Another way to prove quite conclusively whether a usable signal is coming from DOCD would be to cut the DOAB line as you already cut the DOCD line, and send the DOCD signal to the upper YAC - that might help erase that final bit of doubt.  But I’m hoping that maybe it’s just a slightly out-of-spec signal that could maybe could be coaxed to work.

What final bit of doubt? OK I did this anyway. Both YACs work identically. Connect to DOAB pin, they produce 1kHz testtone. Connect to DOCD pin, they produce silence.

I wish we could scope those digital outputs.  You could get a reasonably insightful view using one of the s/h lines (SMPxx) as a trigger source.  I don’t know the input impedence on the YAC, and whether a borderline YMF might benefit from pull-up/down on the DOAB/DOCD lines.

Logic seems to suggest that DOAB and DOCD should have identical output “characteristics”… since they’re identical data streams intended to go into identical DACs, etc.

I can rule out PCB mistakes between YMF and YAC because I even lifted up the DOCD pin and touched/soldered wire directly to the pin, from a known-good “this wire made the YAC work” state.

Therefore the problem is either:

A) both YMH262 I soldered do not output on DOCD at all, ever.

B) both YMF262 are not having the correct registers set.

I am liking B as the more likely explanation, but I can’t find any problems between Core and OPL3 module,

I was using a PIC18F4620 in an ultracore PCB… I’ve since switched to a PIC18F452 in an ultracore PCB, with MIOS 1.9f (freshly burned with bootloader also).

Uploaded testtone multiple times.

Uploaded interconnection test also.

I do notice A0 isn’t exactly 0V when not logic high… it’s 0.11V… I guess this is because RD5 is also being used in J15 for LCD comms, so my meter is averaging it (i.e. it’s 5V 2/100th of the time).

BTW nebula did you get your OPL3 working?

Has anyone validated the OPL3 chipsets they got through me are all working perfectly?

[T.K]

I checked the testtone application on my MBFM to ensure that this isn’t related to a SW issue - it works, all 4 channels output the 1kHz sinewave

Best Regards, Thorsten.

[nILS]

Wilba and I have ruled that out already. This is all very odd

Yes. Well… I am not entirely sure, because it sounds like a toy keyboard’s piano patch and every second (or third, fourth etc) note sounds like it’s louder or has a higher-pitch “tink” to it.

This is an issue that I had recently as well (after upgrading to version 1d). Only happens very rarely and only after the initial powerup, so a power off-on cycle fixes it. I haven’t had a closer look at what might cause that tough.

[nebula]

BTW nebula did you get your OPL3 working?

I make PCB’s using the “toner transfer” method, and I did etch an OPL board, and I started building it…

… normally when using the Pulsar toner transfer, after applying the toner you then apply the “TRF” (toner reactive foil), which makes the toner-based resist less porous, for better traces.  For some reason I guess I got too excited when I made my OPL3 board because I forgot to use the foil.

I got the surface mount ICs on just fine, but the rest of the board is just an absolute mess - solder doesn’t want to stick to it.  It is such a mess, in fact, that I kinda want to just pitch it and start a new one.  Like, it’s the worst PCB I’ve ever made.  So part of me wants to find time to fix it, and part of me wants to make a new one … but as I also discovered, the layout for the OPL board on UCAPPS is arguably the least home-etch friendly of all of them.  Small traces, small pads, tiny holes close together, holes in the middle of ground planes, orphaned ground planes … I need to either buy Smash’s boards or create a new layout.  Most likely the former.  Hmmm… maybe I’ll do that right now.

[Wilba]

I don’t know much about self-etched boards, but can’t you clean up the copper with something?

No disrespect towards SmashTV’s boards… they’ve got solder mask and ENIG plating, but I’m so used to double-sided boards with plated through-holes that I found the OPL3 board a bit of a step backwards and really missed the solder being sucked into the hole instead of blobbing on top.

I think once I’ve got this OPL3 fully working, I might work on a new double-sided OPL3 module PCB with slightly better component placement… maybe with a Core on there too, and MIDI/audio sockets… or maybe I’ll just get nILS to do it

[Wilba]

btw I’m still stuck!

I don’t like troubleshooting by randomly swapping things… I can’t see how the ultracore, or the OPL3 PCB could be the problem, and have full confidence the pre-built testtone firmware should work…

I might try swapping the YMF262 for a salvaged one, but even this is a stretch of logic (like I bulk-ordered a batch of crippled YMF262?)

[nebula]

I don’t know much about self-etched boards, but can’t you clean up the copper with something?

The copper on my board got partially etched, so it’s pitted, which for me just compounds the same soldering problems you’re seeing.  Nevertheless I’ll try to find some time tomorrow to clean it up. 

I’m so used to double-sided boards with plated through-holes that I found the OPL3 board a bit of a step backwards and really missed the solder being sucked into the hole instead of blobbing on top.

That’s the problem with this layout: the pads for the resistors etc are so small that the holes really should be plated, because there’s almost nothing for solder to grab on to. 

I think once I’ve got this OPL3 fully working, I might work on a new double-sided OPL3 module PCB with slightly better component placement… maybe with a Core on there too, and MIDI/audio sockets… or maybe I’ll just get nILS to do it

Makes sense to combine this one with a Core, since the existing Core doesn’t already have a header suitable for this.

btw I’m still stuck!

I know … sorry for the hijack 

[nILS]

I think once I’ve got this OPL3 fully working, I might work on a new double-sided OPL3 module PCB with slightly better component placement… maybe with a Core on there too, and MIDI/audio sockets… or maybe I’ll just get nILS to do it

*cough* done

Swapping for a salvaged one does seem reasonable. As well as posting pics of the board. Ya know, even heroes make mistakes every once in a while…

[me=nILS]ducks[/me]

[Wilba]

pft…

[T.K]

I might try swapping the YMF262 for a salvaged one, but even this is a stretch of logic (like I bulk-ordered a batch of crippled YMF262?)

I think that I found a logical explanation for this failure effect.

From the beginning: first I had the idea, that this failure could happen if D6 and D7 are clamped to 0V, since bit #6 and #7 of address 0xc0..0xc7 control the audio channel C/D assignments. But by “forcing” these bits to 0 via SW there was no sound at all.

But I didn’t give up and tried out other bits forced to 0.

Finally with D2 forced to 0 I noticed the described behaviour: I hear a sine sound on Channel A and B, but not on Channel C and D

So - could it be that our hero forgot to run the interconnection test completely before asking for support in the forum?

And could it be, that our hero cannot differ between a 1kHz sound, and a ca. 500 Hz sound? (because with D2 forced to 0V the resulting frequency is ca. one octave lower)

I’m curious - unfortunately this nice explanation doesn’t work if I try this out on the MIDIbox FM firmware - most patches sound completely wrong.

/Edit: another possibility - maybe our hero swapped two data lines?

Best Regards, Thorsten.

[Wilba]

So - could it be that our hero forgot to run the interconnection test completely before asking for support in the forum?

No, it could not be

I’ve done the interconnection test for every pin, also checking adjacent pins are not 5V, testing directly on the YMF262 pin (i.e. above the solder joint!)

And could it be, that our hero cannot differ between a 1kHz sound, and a ca. 500 Hz sound? (because with D2 forced to 0V the resulting frequency is ca. one octave lower)

No, it could not be

I compared with a 1kHz sample.

and just for completeness, I pulled out the wire to D2 and clamped D2 to ground… and I get 500Hz (well it sounds an octave lower than 1kHz, can’t say exactly what frequency it was). So I don’t think it’s D2 being grounded.

I’m curious - unfortunately this nice explanation doesn’t work if I try this out on the MIDIbox FM firmware - most patches sound completely wrong.

Well I’ve only tried the default patch with MIDIbox FM firmware, and I have no reference to compare whether this sounds right or wrong.

/Edit: another possibility - maybe our hero swapped two data lines?

As above, I’ve already checked continuity and done the interconnection tests.

I power the ultracore with a ~7.5V DC input from a “wallwart”, that goes through a bridge rectifier and 7805, and I connect this 5V/ground supply to the OPL3 module… and I have a separate bipolar power supply (mains transformer, bridge rectifier, caps, 7812/7912, etc.) supplying the +12V/gnd/-12V to the OPL3 module. (I’m reusing the one I built for AOUT_NG, it’s worked perfectly for that). Because I’m not concerned with ground loops at the moment (I just wanted to get it working)… the grounds from both power supplies are connected on the OPL3 module… i.e. I have a +5V/gnd wire pair connecting Core with OPL3.

I just discovered an interesting phenomenon: when I power off the bipolar PSU while the 1kHz tone is playing, sometimes it changes into a 500Hz tone, then I can turn it back on and get the 500Hz tone. Sometimes it just goes silent. Sometimes it resets the Core. However, if I power on the bipolar PSU after I boot the Core, then there’s no problems. Also there’s no problems if I power on the bipolar PSU before I boot the Core. Strange things happen only if I power off the bipolar PSU while the Core is still powerered. Maybe introducing spikes on the common ground makes weird things happen… resetting the YMF262 etc.

I fully expect this issue to be caused by some simple little oversight and be thoroughly embarrassed therefore I wouldn’t be posting here unless I’d really done every possible test multiple times and tested for continuity, shorts, voltages, etc. multiple times.

I think I’ll swap the YMF262 with a salvaged one now… at least I’ll be doing something constructive, I’m all out of other tests.

[stryd_one]

I compared with a 1kHz sample.

Sorry to go slightly OT here but it seems worth a mention…

When I read that line by TK, I did think to myself: in all fairness, Wilba is a geek before a musician, so maybe he can’t do mental 1khz recognition… And then I thought, yaknow, a lot of people would be in that boat; not knowing what 1khz should sound like…

Maybe it’s worth putting a recording of a correct testtone in the zip with the testtone app, for users to have as a reference?

</hijack>

[Wilba]

Or… just put a link in the readme?

http://lmgtfy.com/?q=1+khz+sample

[T.K]

No, it could not be

Too bad, it was such a nice logical explanation

I just discovered an interesting phenomenon: when I power off the bipolar PSU while the 1kHz tone is playing, sometimes it changes into a 500Hz tone, then I can turn it back on and get the 500Hz tone. Sometimes it just goes silent. Sometimes it resets the Core. However, if I power on the bipolar PSU after I boot the Core, then there’s no problems. Also there’s no problems if I power on the bipolar PSU before I boot the Core. Strange things happen only if I power off the bipolar PSU while the Core is still powerered. Maybe introducing spikes on the common ground makes weird things happen… resetting the YMF262 etc.

This shouldn’t be a problem so long the bipolar PSU is powered on before the application is booting, because the driver will reset the YMF262 in MBFM_REG_Init to ensure defined starting conditions before OPL registers will be initialized.

Best Regards, Thorsten.

[Wilba]

Too bad, it was such a nice logical explanation

I agree!

[Wilba]

I have sound on channel 3+4 now, hooray, however, I’m still not sure exactly why it didn’t work before…

Following the line of reasoning that the OPL3 PCB was fine (despite what nILS calls “solering drunken money style”)… the problem had to be bad signals/data going into the OPL3 module… and it couldn’t be the firmware. So even if interconnection tests and all connectivity tests pass, what I realised today was that interconnection tests really only find what’s obviously wrong, it doesn’t prove a connection is right and must work… consider crosstalk and EMF and a whole host of other things that could stuff things up. So I thought, perhaps something is wrong with the cable.

I was using what I thought were long but not too long ribbon cables - 35cm between the connectors on ultracore and OPL3 modules. I tend to make my cables longer than they really need to be, so I can space things out while working on them, and shorten or reuse the cable for something else. Now I don’t think 35cm is too long - that’s the length I use between my MB-6582 and the QuadZIF, and there’s a lot of parallel data pumping through those without a problem. Similarly, I have equally long ribbon cables between Core and MIDI sockets and such.

But I decided to shorten them anyway, moving the IDC connectors at the ultracore end closer to the OPL3 so I could directly solder the wires on the other side to a SmashTV Core. I shortened both the D0-D7 cable and the RS/A0/A1/WR cable from 35cm down to 15cm… and channels 3+4 worked!

Just to prove this was the reason (cable length, not bad connectors), I added new connectors back at the end, and did some tests… channels 3+4 still work when the D0-D7 cable is 35cm but they do not work when the RS/A0/A1/WR cable is 35cm

I guess I’m most confused by how this subtle difference manifests itself into two channels not working, as opposed to random functionality.

How can an extra 20cm of cable can cause such a problem? How is it possible that shortening only the control wires (and not the data wires) causes slightly wrong data to go in one register? Why is the YMF262 so susceptible to crosstalk/noise/whatever over long cables but the same problem never happens in 35cm of ribbon cable between a SID socket and a SID? As I said before, I have sound on channel 3+4 now, hooray, however, I’m still not sure exactly why it didn’t work before…

p.s. thanks to all that helped, you all can haz free lazers, except nILS… drunken monkey style, wtf…

[T.K]

How can an extra 20cm of cable can cause such a problem? How is it possible that shortening only the control wires (and not the data wires) causes slightly wrong data to go in one register? Why is the YMF262 so susceptible to crosstalk/noise/whatever over long cables but the same problem never happens in 35cm of ribbon cable between a SID socket and a SID? As I said before, I have sound on channel 3+4 now, hooray, however, I’m still not sure exactly why it didn’t work before…

The specified pulsewidth for the CS# and WR# input (tCSW and tWW in the datasheet) is 100 nS. The MBFM_REG_Write routine generates a pulse of ca. 200 nS to be on the safe side, but it could be that with such a long cable the pulse will be shorter due to the higher impedance, accordingly the required timings will be violated.

It would be interesting if it works better with long cables if more than one NOP is inserted between CS=0 and CS=1, e.g. try:

        bcf     MBFM_LAT_CS, MBFM_PIN_CS        ; activate chip select line
        nop
        nop ; + 100 nS
        nop ; + 100 nS
        bsf     MBFM_LAT_CS, MBFM_PIN_CS        ; release chip select line
[/code]









Note that this change has to be done at two places.







Best Regards, Thorsten.

[nebula]

Yay!  Good news, and it puts to rest the fear that the YMF batch could have issues.

How does that MBFM patch sound now?  Do you still get that weird “every 4th note louder” thing, or does that seem resolved as well?