Fixing PPU Audio Buzz

Hello, new forum user here. I've been trying to find something, anything on google to help me figure out how to get rid of the PPU buzzing in Tri, Noise, DPCM audio pin of the CPU. At least I'm assuming that's what is causing it, because changes in graphics cause the buzzing to change pitch sometimes. The pulse channels don't seem to have this buzzing, but the Tri,Noise,DPCM channels definitely have a high pitched buzzing like a power saw.

Just for convenience sake here is a recording of the buzzing I'm talking about: https://www.box.com/s/p39c3fs2kzsjto44vspn

At first I had tried to just disable the power pin of the 2C02 but this resulted in a non functioning NES so I connected it back up again. I do NOT need video whatsoever cause I'm using this nes specifically for use with MidiNES. I've already disabled the three audio path resistors (20K, 20k, 12k) right before the inverter amp in order to try and remove any connection whatsoever to the RF trash. So If you know of any way I could disable the PPU and keep the NES functioning I would be very appreciative. I know very little about the relationships between the various chips inside the NES or which chips depend on each other to function right, but I'm now beginning to suspect that the PPU and CPU are one of those relationships.

If nothing else I'd at least like a confirmation of if successfully disabling the PPU is even possible or if I'm stuck with the buzzing forever.

While reading tons of forums I've answered my own question.... Disconnecting the vout (pin 21) of the PPU, will cause the buzzing to greatly decrease. It's now at an acceptable level for me. I suppose one could solder a switch on there to be able to regain a video signal, but as it stands now, I have acheived a recordable audio path. (btw - I'm also using low-gains NES/C64 module connected straight to the CPU audio pins.)
Hopefully anyone having the same issue I was having could learn the fix for it here.

I see you already have a solution, but you might consider removing the PPU altogether. Simply removing power from it won't actually cause it to simply stop working, but rather take the entire system down with it.

Or maybe tying the PPU's /SYNC input low (disconnecting it from the inverter) would work...

Doesn't the NES need the PPU to function? As you are aware, I tried disconnecting the power pin of the PPU making it disabled but the NES was then not functioning. are you sure that removing it entirely would keep my NES functional? Have you or anyone else ever removed the PPU entirely with success? if so I will indeed do that, but don't want to go to drastic changes like that without being sure.

No, on the very least, the CPU need the interrupt signal to get the timing for playing music. You would need to make some functional replacement for the interrupt in order to get the CPU to run without a PPU. I bet with you that's how hardware NSF players deal with the interrupt problem (No ppu but there's hardware to generate the vblank interrupt signal in it).

Also I think that tie /SYNC to GND will stall the PPU causing it to not generate interrupts (It's meant to cause a secondary PPU to sync with a exising one who would be running normally, no ?).

The NSF spec specifies generating the clock signal by dividing a 1.0 MHz clock, usually by 16640 (NTSC) or 19997 (PAL). In a pinch, the so-called "APU Frame IRQ" can be used to generate a 60 Hz time base, but NSFs that already write to $4017 need to be patched to use it. How do Nintendo arcade boards that use the 2A03 as an APU generate the time base?

I doubt MIDINES is programmed in a way that would work without PPU. It will probably stall right in the beginning in the code where it (most likely) polls the PPU for two vblanks.

That is what I suspected. I'm just going to leave things as they are now, with pin 21 lifted. The buzzing is almost disappeared and I suspect the last remaining remnants are going to be impossible to vanquish. I might replace the 200µF power cap later on and also might end up throwing a switch on pin 21 to have the option of bringing back the video signal, but I finally deem my NES recordable and gig worthy.

Disabling rendering and setting the palette to sub-black ($0D) minimizes buzzing through my NES+PowerPak.

Great tip, Tepples. This isn't exactly possible with MidiNES, but I have had brainstorms about eventually getting PowerPak and loading it with NSF files composed and exported using FamiTracker. Though I hear that it is quite a bit noisier then even an unmodded NES. Something to do with the extra sound generators in it emulating the Famicom's extra voice expansions. Though I have read of other folks successfully separating the 2 NES channels away from the PowerPak's by tapping into the cart's audio out or something like that, giving it it's own separate sound jack.

All you need is cut the audio out at the CPU and use some shielded cable to run it where you want... something like this :
http://www.tmeeco.eu/BitShit/NESaudioModShot.jpg
(the mess near CPU is my 3D/dolby/whatever stereo modification)

What's the jumper in the RF doing? And yeah I've already got a preamp module amping the two CPU audio pins. This is the module I have if curious. --> http://lowgain-audio.com/images/NES/NESmod09.jpg

I've had another thought. What would happen if I tap into the pin 21 (Vout) of the PPU and build that composite video amp I commonly see around the web for those who are building portables? (You know, the one thats like one 2N4401 transistor and two resistors [33Ω, 220Ω]) Would it just reintroduce the buzzing I just got rid of or do you suspect that it might work to keep my clean audio but regain a video signal? Either way I'm going to try it and come back with a confirmation. I got to get the tranny from somewhere local though. I hate waiting/paying for shipping just for one darn component

The buzzing happens because the audio lines coming from the CPU go between bunch of digital stuff and near the PPU into that inverter-amp. Majority of the noise comes from that inverter. Rest comes from proximity to interference sources. Physically shielding the audio path gets rid of any noise there is in the audio.

So I don't know what I did different, But All I did was solder a switch to the video output pin to be able to toggle it on and off, then that buzzing came back and won't go away even with the pin lifted. This is annoying, I even tried a second NES but it didn't work. I have no clue why it worked for me the first time but not now. Any ideas why the PPU buzzing is still present even with the PPU pin 21 lifted? And yes my audio cable is shielded.

Also the composite video amp did not work when connected straight to the PPU.

Hmmm, does anybody know if there are some pins I can lift that will stop the PPU from RECEIVING and video data from the cart/CPU but keep everything operational? I'm looking at the pinout but it's way over my head. I don't understand what any pin does except simple stuff like CLK and power.

The PPU generally powers up showing a solid color on screen, which means video noise if you cut its link with the CPU thereby ensuring that this color keeps being displayed.

So Blargg, is there nothing I can do to solve my problem? I'm beginning to think My initial success was just a false positive. Though, it sounded just like B00DaW's example in his post:


He says he 'turned the PPU off, but did he do that with code or something hardware side?

Is there any kind of hardware quantizer device? Or one that refuses to change the output signal until the input signal is sufficiently different from it? That'd clean up things like this amazingly well.

Only if the noise floor was low enough to be smaller than your smallest quantization step / threshold, which it might be, depending on the situation. High frequency stuff being filtered before sampling is also a problem, since this ruins the original quantization (you'd need to work at high frequency).

In a really ideal case maybe you'd tap a device that outputs via PWM and just reverse the PWM encoding to get back the digital signal.

And now you know part of why Sony used PDM encoding for SACD.