Nintendo 64 RGB Blur fixing

[ajdesmarais]

No. I'm suggesting that you generate /cs and send it on pin 3. Don't use sync that was natively generated on the Nintendo PCB.

It seems to make no difference in the video quality. I severed the multi-out pins from the board and ran the CS75 out from the N64 RGB directly to the port. When I run it through the composite, I get no video (using a csync cable) and when I run it through Luma, I get video like I posted above (using a sync on Luma cable).

[bobrocks95]

Running CS75, when you already have a cable that's expecting TTL sync (i.e. has in-line resistors on the sync line) may be your problem.

[ajdesmarais]

Running CS75, when you already have a cable that's expecting TTL sync (i.e. has in-line resistors on the sync line) may be your problem.

So I should run the signal from CS# instead? I honestly can't remember if my cables have resistors in them, but it's simple enough to try, I guess. I still don't really see how that's causing the weird video issue I have. I was getting my sync signals from the stock board originally anyway...

--- Actually, I just tried running from CS# directly to both Luma and Composite, and it makes no difference in the signal on either of the appropriate cables.

I'm going to resolder all of my connections tomorrow just to make sure I didn't cross anything, but I think crossing would have caused something more noticeable than the problem I have.

[mikejmoffitt]

That isn't a sync problem. Check all your VDP data lines.

[ajdesmarais]

That isn't a sync problem. Check all your VDP data lines.

I re-soldered everything and it's gotten much better, but I still have some color abnormalities. Is it possible I damaged the picture processor? If I did, would the same color issues show up on the composite output?

Weirdly, I seem to be able to affect the color noise by putting my thumb over the soldered inputs, and also by putting it over the VDC pads that I'm not even using. I'm kind of baffled. I know the immediate solution would seem to be that I soldered something wrong, but I've done it over 4 times and I keep getting this exact same result.

[borti4938]

I need to try capacitors. I think that's the solution. Wondering why NESRGB has 220uF caps on output and this has only 75ohm resistors and no caps

I tried putting a 330uF cap between Vcc and gnd on amp. didnt help.

Look inside the data sheet of the THS7374: on the modding board the DC coupling is used. On the NESRGB you have another amplifier at the end.

However, also the caps does not change anything for me.

I keep a deeper look on the noisy pattern and I made two observations:

1. It seems like that you have a short drop down of the end of each pixel.
2. The noise is reduced if one uses slow slew rates. Please try that out...

These points keep me to the point where I think that it has to do something with the output registers and their timings...
What I do not understand why the noisy pattern is gone if you use a separate MultiAV!?

Still no luck here
leonk - have you find anything new?

[ajdesmarais]

Csync cable was the cure. Don't use a Luma sync with this mod. Cheers, it looks so nice now

This is another really weird issue I'm having. I suppose it doesn't really matter, but since it clashes with what other people are saying, I figured I'd mention it.

My RGB mod ONLY works on Luma Sync. I have three Nintendo multi-out SCART cables, two wired with Csync for the NES and SNES, and one with Luma sync for my old N64 mod. If I plug my new N64 board into the NES cable, I get audio, but a very wavy picture. If I plug it into my SNES cable, I get no picture at all, and occasional, very distorted audio. The system works fine on the Luma sync cable though. The weird part is that none of this changes whether I take the sync signal from the N64 as is, or if I run it directly from the RGB board to the multi-out (and disconnect the original pin) from CS# or CS75. I have tried every conceivable combination of cables and signals, and the only thing that gets me a picture is sync on Luma. The funny part is that was easily the cheapest cable of the three.

[andykara2003]

Mine works fine with C-sync and the official Gamecube scart cable..

[leonk]

Still no luck here
leonk - have you find anything new?

Sorry.. didn't get a chance to play with it. Overwhelmed with NES HDMI installs the past 2 weeks.

[that1crzywhtguy]

Csync cable was the cure. Don't use a Luma sync with this mod. Cheers, it looks so nice now

This is another really weird issue I'm having. I suppose it doesn't really matter, but since it clashes with what other people are saying, I figured I'd mention it.

My RGB mod ONLY works on Luma Sync. I have three Nintendo multi-out SCART cables, two wired with Csync for the NES and SNES, and one with Luma sync for my old N64 mod. If I plug my new N64 board into the NES cable, I get audio, but a very wavy picture. If I plug it into my SNES cable, I get no picture at all, and occasional, very distorted audio. The system works fine on the Luma sync cable though. The weird part is that none of this changes whether I take the sync signal from the N64 as is, or if I run it directly from the RGB board to the multi-out (and disconnect the original pin) from CS# or CS75. I have tried every conceivable combination of cables and signals, and the only thing that gets me a picture is sync on Luma. The funny part is that was easily the cheapest cable of the three.

This doesn't make much sense. The audio should be completed unaffected by the mod, for all the cable. The mod doesn't touch audio, which considering that, sounds like either faulty cables, faulty n64, or that something on the multiout got bridged.

As far as csync goes, are your cables using composite for sync, or pure csync (not the same thing). I suspect they are pure csync, meaning you need to run cs# to the pure sync pin (pin 3), not composite video (pin 9).

[ajdesmarais]

This doesn't make much sense. The audio should be completed unaffected by the mod, for all the cable. The mod doesn't touch audio, which considering that, sounds like either faulty cables, faulty n64, or that something on the multiout got bridged.

This is the thing that still troubles me. I know the cables aren't faulty because they work fine with my NES and SNES. I know the multiout on the N64 isn't faulty because I get audio on both other cables. The SNES is completely stock, so I agree, it makes no sense.

As far as csync goes, are your cables using composite for sync, or pure csync (not the same thing). I suspect they are pure csync, meaning you need to run cs# to the pure sync pin (pin 3), not composite video (pin 9).

D'oh! Will try this when I get home. I keep coming back to try a new mod once every year or so, and I end up forgetting all the terminology. Thanks!

I wonder if this will fix my color interference issue as well, since that is a pretty cheap cable I'm using. Once I get my N64 wired up for pure sync, I can test it on some of my nicer cables.

[mikejmoffitt]

Just ordered this guy. I got it a little smaller, and a bunch cheaper than the boards I'd made before. I think this one can be narrowly price competitive with Tim's board.

[ajdesmarais]

So oddly enough, after PROPERLY wiring up csync on my N64 and testing it on my csync cable, I now have picture (where before it was black) and audio (where before it had none). While I have no idea why I had those problems and why this was a solution, I'm fine with that.

Unfortunately, I'm still getting the color noise which looks like 15-bit mode is trying to come through, and it does indeed go away when I put my thumb over the DNC pads or the 4 below it on the RGB board. Interestingly, I can make the problem WORSE by pressing my thumb over all the micro capacitors on the board. Also weird, but I'm hoping a firmware flash will help fix things up like it did with that1crzywhtguy's problem. Just waiting on my USB Blaster to come in.

It seems the name of the game here is weird problems that have equally weird solutions.

[mikejmoffitt]

15-bit mode

I don't know what this is supposed to refer to. For what it's worth, many games already represent a pixel as a 15-bit word.

If touching makes things change it generally means there's a floating input. It could be your wiring, or it could be a cold joint on the board.

This thread's been completely derailed into a support thread.

[ajdesmarais]

15-bit mode

I don't know what this is supposed to refer to. For what it's worth, many games already represent a pixel as a 15-bit word.

If touching makes things change it generally means there's a floating input. It could be your wiring, or it could be a cold joint on the board.

There's a description earlier as to what 15 bit mode is. Also, while a floating input would INDEED make sense, I have re-soldered my connections multiple times and tested them with a multimeter to make sure I have good connections and no shorts. I keep getting the exact same noise in my output. I doubt I'm making the exact same mistake/cold joint EVERY time I solder. There's another user on this board who had an issue that was altered by touching the RGB board, and a reflash fixed it for him. At this point, it's the only option I have left.

I thought about making another thread for support with the new RGB board, but this thread already seemed to have the most information and answers regarding it.

[bobrocks95]

Does Tim's N64RGB board still have the 3 sets of pads for soldering the data lines to, 2 larger and 1 smaller? I remember way back reading about someone who had to solder to the smaller pads because they were having signal problems.

Other than that, maybe get larger wire for the ground paths for the board? Resistance may be too high for the ground path, given that touching the wire fixes the problem.

Sorry if you've already done one or both of these things.

[mikejmoffitt]

15-bit mode

I don't know what this is supposed to refer to. For what it's worth, many games already represent a pixel as a 15-bit word.

If touching makes things change it generally means there's a floating input. It could be your wiring, or it could be a cold joint on the board.

There's a description earlier as to what 15 bit mode is. Also, while a floating input would INDEED make sense, I have re-soldered my connections multiple times and tested them with a multimeter to make sure I have good connections and no shorts. I keep getting the exact same noise in my output. I doubt I'm making the exact same mistake/cold joint EVERY time I solder. There's another user on this board who had an issue that was altered by touching the RGB board, and a reflash fixed it for him. At this point, it's the only option I have left.

I thought about making another thread for support with the new RGB board, but this thread already seemed to have the most information and answers regarding it.

Floating inputs may not be your inputs, but could be the pads going to the CPLD. It may be worth touching around the CPLD itself, and seeing if THAT needs some reflowing. If the reflash fixed it, though, maybe the bitstream incorrectly configured neighboring pins as inputs, which would be floating.

[Ikaruga11]

Maybe 15-bit mode should just be removed. It makes most games look worse.

[bobrocks95]

Maybe 15-bit mode should just be removed. It makes most games look worse.

It's also completely optional, and only exists in a firmware that you have to flash to the board yourself. It even defaults to off in Borti's firmware.

[that1crzywhtguy]

So oddly enough, after PROPERLY wiring up csync on my N64 and testing it on my csync cable, I now have picture (where before it was black) and audio (where before it had none). While I have no idea why I had those problems and why this was a solution, I'm fine with that.

I'm glad we got that part sorted out!

I'm hoping a firmware flash will help fix things up like it did with that1crzywhtguy's problem. Just waiting on my USB Blaster to come in.

This was the ticket for me, hope it is for you as well. That usb blaster will be good to have anyway if you ever decide to do the NESRGB. Its a fussy mod, but it looks great and that new firmware with the new pallets is fantastic! Anyhow, definately curious to know if your problem is also solved by firmware flashing.

[ajdesmarais]

That usb blaster will be good to have anyway if you ever decide to do the NESRGB. Its a fussy mod, but it looks great and that new firmware with the new pallets is fantastic! Anyhow, definately curious to know if your problem is also solved by firmware flashing.

I actually did the NESRGB mod just over a year ago. I'll definitely look into flashing the new firmware to try those new pallets, though. I was looking for an excuse to open it back up and bypass the lockout chip, which I forgot to do when I modded it originally.

Does Tim's N64RGB board still have the 3 sets of pads for soldering the data lines to, 2 larger and 1 smaller? I remember way back reading about someone who had to solder to the smaller pads because they were having signal problems.

Other than that, maybe get larger wire for the ground paths for the board? Resistance may be too high for the ground path, given that touching the wire fixes the problem.

There doesn't seem to be a group of 3 pads like you describe. There is a group of 5 pads that I assume is used for flashing, and a group of 3 same-size pads closer to the outputs.



I might try running a bigger ground wire sometime. I just used the spare lengths from the ribbon cable that comes with the board. I'm sure most people do the same, so I'm not sure why it wouldn't work for me, but it's worth a try. Thanks!

[bobrocks95]

That usb blaster will be good to have anyway if you ever decide to do the NESRGB. Its a fussy mod, but it looks great and that new firmware with the new pallets is fantastic! Anyhow, definately curious to know if your problem is also solved by firmware flashing.

I actually did the NESRGB mod just over a year ago. I'll definitely look into flashing the new firmware to try those new pallets, though. I was looking for an excuse to open it back up and bypass the lockout chip, which I forgot to do when I modded it originally.

Does Tim's N64RGB board still have the 3 sets of pads for soldering the data lines to, 2 larger and 1 smaller? I remember way back reading about someone who had to solder to the smaller pads because they were having signal problems.

Other than that, maybe get larger wire for the ground paths for the board? Resistance may be too high for the ground path, given that touching the wire fixes the problem.

There doesn't seem to be a group of 3 pads like you describe. There is a group of 5 pads that I assume is used for flashing, and a group of 3 same-size pads closer to the outputs.



I might try running a bigger ground wire sometime. I just used the spare lengths from the ribbon cable that comes with the board. I'm sure most people do the same, so I'm not sure why it wouldn't work for me, but it's worth a try. Thanks!

No, I was talking about the 3 groups of pads (not groups of 3 pads) that are there on the right. If your data inputs are soldered to the larger pads, try the smaller ones on the right. Reflashing is obviously easier so start there of course.

[leonk]

Well, after multiple back and forth conversations with Tim, Borti and testing I think we know what the issue is... and most of you are not going to like it.

It's a ground loop between the N64RGB and N64 PCB.

(it's going to get a bit geeky, but I'm trying my best to understand the issue)

- current flows from N64 to RGB board via data lines
- the gnd is the return path
- it is the same gnd return path for analog output from RGB pcb
- the changing current from digital gnd is added into the video signal

The only solution is to make the cables as short as possible. Or, remove gnd loop. When I lifted the multiAV port, GND of output was no longer tied to GND of N64 - no return path; no noise. This also explains why Ultra HDMI N64 doesn't suffer from same issue - it has its own output port with GND not tied to N64.

mikejmoffitt N64VGA will have same problem if his output GND will tie back to N64 GND.

Now, as for why CRT doesn't see it but XRGB does?

" The noise is made from very fast spikes coupled into the video signal. The way the video processor works is it samples the video data at a higher frequency than the video data itself. When sampling it may hit one of these fast noise spikes and report it as valid data.

A CRT monitor on the other hand has a linear video amplifier that has a limited bandwidth. The noise spikes on the video signal will not be shown because the are too fast for it. The video processor needs the low pass filtering enabled to behave like the CRT monitor."

There you have it. Lets see now what sort of hardware patch can be created to solve this.

[borti4938]

Thanks for the summary. Last remark on that, why the low pass filter of the THS7374 on the modding board doesn't help? The reason is because the output wires are too long. The noise is injected here, too. One way to cope with that is to put the modding board as close as possible to the MultiAV, i.e. somewhere under the N64 mainboard if that fits (I haven't tried it).

So my temporary solution (next to the video filter on the OSSC) is to detach the THS7374 from the N64RGB board and solder the amp as close as possible to the MultiAV.

Spoiler

Remove the THS7374 from the board and short the pathes for R, G, B and Sync to the pads to use them...


Use a standard modding board

In that way the return path is very short at one end. I will see, how hardware design can changed...

[leonk]

what about lifting gnd pins from multiAV and connect them to n64rgb only? also add another gnd from n64rgb to closest gnd? (audio and other video outs still need gnd) will that work?

[mikejmoffitt]

In making a third and final revision of my PCB, would this be an adequate isolation of return paths for the two major components of the system?

I'm not talking about the layout, but the use of separate grounds and the 10 ohm resistor linking between the two. Digital electronics is my thing, not analog, so if anyone has a better suggestion, please let me know.

Just by the by: I don't plan on selling my board, I plan on leaving it open and making it easy for anyone to build and program their own, so any contributions are more of a community effort and less "making my private project better". I can set up an order link through Macrofab so you can have a fully assembled and tested board arrive at your door for around $60.

(Drawn using TurdCad)

[leonk]

SUCCESS!!!!! I GOT RID OF JAILBARS FROM N64RGB!!

Here's the 2 things you must do:

1) Remove MultiAV port and lift up the 2 GND pins. Protect the existing GND pads from touching the pins (I use electrical tape on pins). Solder socket back down and wires from amp to port. The GND wire now connects above rather than bottom.

IMPORTANT: Both GND pins must tie together. Can't just do 1 and hope cable ties them together!

2) Run short wire from GND pad on N64RGB (next to M A G pads) to frame. I soldered it directly to shield.

All jailbars are gone! Ground loop broken while other ports have single path to ground.

[tacoguy64]

awesome work guys!
I knew you would figure this out. Now to send my system back in for some work

[borti4938]

SUCCESS!!!!! I GOT RID OF JAILBARS FROM N64RGB!!

Here's the 2 things you must do:

1) Remove MultiAV port and lift up the 2 GND pins. Protect the existing GND pads from touching the pins (I use electrical tape on pins). Solder socket back down and wires from amp to port. The GND wire now connects above rather than bottom.

IMPORTANT: Both GND pins must tie together. Can't just do 1 and hope cable ties them together!

2) Run short wire from GND pad on N64RGB (next to M A G pads) to frame. I soldered it directly to shield.

All jailbars are gone! Ground loop broken while other ports have single path to ground.

Nice You were faster than my I was with just my reply to your first question!
Have you tried if it is also sufficient to just use point No.2?

[borti4938]

Edit: duplicated post