Nintendo 64 RGB Blur fixing

[leonk]

How did you wire your sync connection? Which pad did you use (CS75 or CS#)? I plan on using a Csync cable myself and want to make sure I wire this correctly.

I installed the mod for him. Given that most people reuse SNES SCART cables, I used CS# (TTL level). The only time I would suggest using CS75 is if you have a custom made-for-this-mod SCART cable with no resistors inline with the CS pin (pin 3 of multAV plug for NTSC consoles)

[Nintendude94]

How did you wire your sync connection? Which pad did you use (CS75 or CS#)? I plan on using a Csync cable myself and want to make sure I wire this correctly.

I installed the mod for him. Given that most people reuse SNES SCART cables, I used CS# (TTL level). The only time I would suggest using CS75 is if you have a custom made-for-this-mod SCART cable with no resistors inline with the CS pin (pin 3 of multAV plug for NTSC consoles)

Awesome! I plan on using an SNES SCART cable.

Thanks!

[borti4938]

Using CS# (TTL-sync; actually it is LVTTL here) or using CS75 has nothing to do with "reuse SNES Scart cable" or "made-for-this-mod SCART cable with no resistors inline with the CS pin". A SNES Csync cable also does not have a resistor within the sync wire!

It has to do something with the termination inside your TV set (or scaler)! If this device needs TTL sync and has high impedance input at sync, you need CS#. If your receiving device has 75ohm termination inside (and this the the general case with modern TVs and scalers), you need CS75. If you use CS# in the later case and use the N64 for longer times, you may harm the CPLD as the CPLD is not designed to drive such a load!

No, it's the one where debtor can be switched on / off using a switch at pad A.

Ah ok, I'll advise my customers wait a few weeks for the boards to be updated before ordering then.

I don't know if viletim plans to ship the board with the controller-functions firmware. Actually, the current one is a slightly modified version of the code I uploaded on GitHub.

[Ikaruga11]

Seems like a lot of people are having issues with the RGB Board producing jailbars.

[leonk]

Hi Borti. I'm sorry but you are actually mistaken.

The "known" scart cable manufacturers do install resistors inside their snes scart cables. For example, retro console accessories puts a 330ohm resistor inside the snes end on pin 3 (csync for usa consoles)

If I connect the sync type to cs75 (on n64rgb or even nesrgb) and use this cable; it will work fine with pvm (pvm seems to have sync booster). But I get black screen with xrgb mini (its sensitive to sync level. it expects 75 ohm terminated as certain Vpp)

The best solution of course is to have all our consoles output cs75 and not bother with adding resistors into cables. But its easier to just say "buy snes scart rgb cable and you can use it on all Nintendo consoles". It's also much easier to find these premade cables with resistor.

[borti4938]

That known scart cable manufactures do install resistors within the sync wire is new for me and also in my point of view a not adequate solution. The SNES is designed to drive TTL sync with high input impedance. So in my point of view the console should be modified if one wants to drive csync with 75ohm load and not the cable. That's why I have a 'direct' sync wire in my mind if you talk about 'standard SNES cable with csync'.

And again: the CPLD is NOT designed to drive such load even if have an additional 330ohm resistor implemented in the cable. Even if you do not harm the CPLD directly, at least you shorten the lifetime. (edit: not full true story; please look a few posts below...)
Btw: the same /similar cable used on the SNES and the N64 gives different sync-levels: Upp=926mV vs. Upp=611mV. Standard is Upp=300mV for 75ohm termination; both far away.

I don't really know what the problem is with the X-RGB mini and why it is so picky with the sync level. If it is 75ohm terminated, the designer should use standards, too.
(I don't have a Framemeister and I know why...)

Seems like a lot of people are having issues with the RGB Board producing jailbars.

Seems like a problem as a combination of the mod and the receiving device.
I would make a guess and say it has to do something with the R2R ladder, but on the other hand the NESRGB has a R2R ladder as the DAC, too. Maybe someone, who observes the particular problem, wants to try mikejmoffitt solution with the DAC-IC!?

[leonk]

I got a ton of N64RGB boards here, PVM and mini. want to point me to the "fix" I can try out?

[leonk]

Btw: the same /similar cable used on the SNES and the N64 gives different sync-levels: Upp=926mV vs. Upp=611mV. Standard is Upp=300mV for 75ohm termination; both far away.

So using the same resistor value in the SCART cable with N64 vs SNES will result in lower CSYNC mV level on N64 than SNES? How can this still be bad for the CPLD?

[Ikaruga11]

Are there any jailbars or undesirable effects if you're just using a CSync RGB SCART cable and connecting it to a BVM via BNC?

[borti4938]

Btw: the same /similar cable used on the SNES and the N64 gives different sync-levels: Upp=926mV vs. Upp=611mV. Standard is Upp=300mV for 75ohm termination; both far away.

So using the same resistor value in the SCART cable with N64 vs SNES will result in lower CSYNC mV level on N64 than SNES? How can this still be bad for the CPLD?

First of all, I'm sorry. I had a wrong value in mind (see explanation)
It's important how much current is drawn out of the actual I/O pin. In the data sheet you can find two values for 3.3V LVTTL: 16mA and 8mA. The first value is the IOH (current going out of the I/O) and the second one the IOL (current going into the I/O). I only had the 8mA in my mind
So, if you output 3.3V out of the I/O and have a load of 405ohm (cable neglected) you have to draw 8mA. So it's fine...

I got a ton of N64RGB boards here, PVM and mini. want to point me to the "fix" I can try out?

- Have you ever tried to use a firmware with slew slow rates on the outputs?
- Have you tried to add 47pF caps at the MultiAV to GND for each color?
- Have you tried to add a 0.1uF cap for each VCC/GND pin pair at the MaxII?
- Do you use flat ribbon cable between N64 and modding board or have you separated all wires?

[andykara2003]

My modder's wired the console for csync on both the composite video pin and the csync pin so I'll get csync on both "normal" rgb cables and ones wired for csync. This comes at the expense of losing composite video which I'm fine with as I'm not bothered about composite. I use Gamecube scart cables for my RGB N64's - is this setup OK?

[leonk]

BORTI IS CORRECT!!!! Tim. Please comment on this if you see it.

Installed ANOTHER N64RGB today. Found an -04 board (basically NS1xxx PCB with components missing for csync which is great! It also means I soldered sirectly to VDC-NUS and eliminate noise that might enter new ribbon). For AV port, I ran wires perpendicular to main board!

Unfortunetly. Same problem. PVM clean. XRGB mini jailbars.

BUT I got an OSSC here! and unlike XRGB I got granular control over LPF!

Well, in 2X mode and AUTO LPF, the OSSC looks good. Time to tone down the LPF.

At 35Mhz/HDTV 1, the OSSC output is identical to XRGB mini! Same jailbar pattern. With LPF off, wow. Very noisy image. Even more so than NESRGB install I just did and A/B tested.

So there you have it. Noise enters somehow in the output of the RGB amp, not input. Wonder if Tim never noticed this because he's on old XRGB firmware which has LPF settings dialed up! Also, I'm guessing PVM also has LPF and hence why it's clean.

I can post pics if anyone wants.

[holaplaneta]

Amazing detective work!! Would love to see some pictures!

[leonk]

My install (under microscope for first pic):







LPF setting followed by how it looks using OSSC:









Note all that noise in the last pic with LPF turned off. It's horrible!!

[borti4938]

Some points you could rather quickly check up:

• First thing you could try is to separate the wires from the flat cable; i.e. running single separated wires from the VDC-NUS to the N64RGB and also from the modding board to the MultiAV. At the moment they are sticked together.
• Second: try to use a thicker (or a second) wire for 3.3V. It's just a try...
• A third point is what happens if you shorten the wires, e.g. by moving the modding board more to the right. The wires has to be as short as possible; although your installation and cable length looks fine. But just give it a try.
• And a fourth point: what happens if you put the modding board away from the heat sink. I never thought about it but I'm curious if this has an impact. (just put the board aside for a test)

I will look on my OSSC this afternoon, too. But your pics look familiar to me.
What I can also offer you is to send one of my boards for testing to you. In addition to viletims board it has more decoupling caps at the CPLD (I use a MaxV), 47pF caps at the outputs as well as ferrit beats on all inputs. It's just based on viletims schematics with minor changes, hence I never published it and would just give it away for testing.

[leonk]

I can tell you that the problem is in the output of RGB amp - not input. If I use a nintendo port from a dead gamecube (instead of N64 port) all the noise goes away!! So noise is being picked up somehow by the port.

I tried thicker wires, but it didn't help.

[borti4938]

Ahhhh... Extremely interesting! Btw: I do have the same problem with the OSSC, too.

What I can see is that there is a GND plane around the RGB pins on the upper side and a +5V plane at the underside, which might be the problem here. Today I have no time but I will investigate that within the next days, too... Some ideas / a few shots how to fix that:

• support the +5V voltage regulator on the N64 mainboard with additional electrolytic caps (at input and output)
• replace the +5V voltage regulator by a modern one
• remove the +5V plane around the RGB pins somehow
  • either bent up the RGB pins somehow
  • or cut away the +5V plane and reconnect pin 10 with 5+V

[leonk]

Hi Borti I already tried removing the 5V plane by cutting it. It didn't help.

[borti4938]

ok, that was just the first thing which blew my mind. What else have you tried so far?

[leonk]

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.

[zeruel85]

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.

If you use SNES NTSC SCART cable or Gamecube PAL SCART one, the capacitors are inside the cables.
Maybe it was intended in this way.

[leonk]

The problem is the caps are too far down the stream! They're next to the TV, not next to the source.

NESRGB has 220uF caps on RGB amp. And I also have 220uF at end of cable next to TV. If you amplify the signal next to source, you have less chance of noise creeping in and messing up your pic. (that's the theory anyways)

[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!?

[korpse413]

I am looking for feedback on my N64RGB output. I recently took some video to help convey to anyone who would possibly know what was wrong (if there even is anything wrong). I started a thread a few weeks back viewtopic.php?f=6&t=59224 and figured I should update my current findings.

co.uk SNES CSync scart (I can provide pictures of the innards) - display BVMD20F1U - yes, I realize me capturing the screen of a crt is taboo; I will try and get my capture card working soon.

https://youtu.be/enoo8fwS26Q : Super Mario 64 (no controller) - the reason I go no controller is because the text that states "No Controller" seems to portray my issues perfectly. Also notice the edges of Mario's Hat, and the far corners of the game (might be overscan artifacting).

https://youtu.be/uk36ysR01NE : Mario Party - Intro movie with the characters jittery, Toad jittery in game, Mario and Luigi's faces blurry.

Is there something I can do to prevent this all from happening? Is this the damn blur filters doing?

[mikejmoffitt]

I'm nearly done with my N64 board, finishing up a little mechanical design and some cost-saving decisions. I will try my 240p output to the XRGB3 and see how it does with regards to interference.

[mikejmoffitt]

Gimme a week or so and I can test this.

[ajdesmarais]

I just installed this new RGB board but it seems to have an issue. The video looks like this. I'm using a Luma for cync. I suppose I could try wiring it up differently, but it doesn't seem like a sync issue...

[leonk]

looks like 15 bit mode!

Also. Suggest sync is generated by your video generator. As already posted in this thread, sync on luma can manifest as picture shifted due to time delay between sync and video

[ajdesmarais]

So you're talking about using composite for sync? Interestingly enough, when I use my SNES SCART cable (sync on composite), I get no image or sound at all, which confuses me even further.

I suppose I could always cut the composite lead from the board and run the sync directly from the RGB board, but I'd only do that as a last resort.

[leonk]

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.