Which multisync monitors are you using and are you feeding sync to a TTL sync input? LM1881 doesn't help with sync jitter, and I doubt your problem is related to that. However, LM1881 sync output is 5Vpp while c-sync level (to unterminated input) of SNES is 2.4Vpp, which is still technically TTL but possibly not high enough for some monitors' sync inputs..

Interesting what you say about the output voltage, without passing c-sync from LM18881 I get an image without sync: a mess. I also found that the M1438 doesn't like the md1 c-sync (directly from the encoder) and indeed passing that through the LM1881 moves the upper part of the screen to the right.

Can anyone who has installed this post what kind of TV they have? I'm just curious to see which TVs have confirmed compatibility improvements after the mod. (Crossing my fingers that it will help my X900E.)

Can anyone who has installed this post what kind of TV they have? I'm just curious to see which TVs have confirmed compatibility improvements after the mod. (Crossing my fingers that it will help my X900E.)

My TV is a TCL, so it was already very compatible. In my case, it just meant I could use 3x, 4x, and 5x with the SNES, too. Those already worked on other systems. If your TV works with other systems, all this mod does is bring the NES/SNES in line with those so that it works the same.

Can anyone who has installed this post what kind of TV they have? I'm just curious to see which TVs have confirmed compatibility improvements after the mod. (Crossing my fingers that it will help my X900E.)

What kind of issues does the X900E have with the SNES?

_________________plus ça change,plus c'est la même chose, The more that things change, The more they stay the same.- RUSH- Circumstances

Just installed a dejitter board on my SNES mini (RGB modded, of course). Thank you to ebeb for suggesting the raspberry pi can do direct jtag programming of the 1502AS. That saved me at least $30, since I already own a pi.

A couple observations:

1) I was hoping this mod would improve compatibility with elgato camlink capturing. Unfortunately, it seems to have made it worse. Previously, I could capture stable line2x and line3x. However, now line3x is also unstable. But, line2x looks really good! 2) This increased incompatibility with the camlink could be due to this mod apparently resulting in > 60hz signal. At least that's what the OSSC reports. I don't own a scope, to dig further on that front. The OSSC reports 60.05hz to 60.08 hz, on all of the testing I've done so far (at least 10 boots).3) Is there any reason that the installation instructions for the SNES mini say to use S-RGB pin 7? I had the csync mod already in place, using S-RGB pin 18. I tested with snes_dejitter csync_i connected to both pins. The best indication that I saw of which might be better, was the camlink not able to properly identify the resolution with csync_i connected to S-RGB pin 7, but is able to when connected to S-RGB pin 18.

None of that is to say that this isn't a cool mod, because in fact it is very cool. Thank you to all the clever contributors and big brains that brought this to fruition.

Do other 240p sources work fine? If so, I think it's probably a safe bet that the dejitter mod will fix the problem. I have 2 different capture cards that would not sync SNES video through an OSSC no matter what linemulti or passthrough mode I used, after the dejitter board it works in all modes.

_________________plus ça change,plus c'est la même chose, The more that things change, The more they stay the same.- RUSH- Circumstances

The SNES normally runs higher than 60 Hz, this just stabilizes it. And in my mini, I just grabbed sync off a via underside of the motherboard, same place Voultar grabs it from with his mods. The via is connected to pin 7, so it's basically the same thing. Works fine for me.

Thanks bigcheese. That post was from over a week ago but I guess this was my first post and needed admin approval. But anyway I got help on the vgp forums, and marqs was gracious enough to chime in. Turned out I made a few mistakes, most importantly my scart cable wired for sync on composite. I rerouted the dejitter board csync_o to pin 9 and broke the composite circuit and voila, it's working flawlessly. Capturing at line5x 1920x1200, and everything below now.

Got this installed in my NES101 tonight and it is working great! Finally I get perfect video even at 5x on the OSSC. I'll add the guide to my wiki within the next few days. Marqs, feel free to take any of the pictures and add to your page, too.

Just found this thread today, I have been waiting for a few years for a mod like this!

My setup is an NES front-loader that is RGB-modded. I connect it via the JP-21 port of a Micomsoft XRGB-3. I run the XRGB-3 in line-doubler mode and output the VGA to a powered VGA splitter box with one side going directly to my CRT computer monitor and the other going to an Epiphan VGA capture device (USB 3.0). The jitter on the CRT monitor isn't too bad - I can just vertically move my image up until it is gone as it doesn't affect very far down the picture, but the capture device on the other hand - HORRIBLE. The jitter carries down roughly 1/3 of the image making it virtually un-watchable when I make recordings.

With much of the tech stuff in this thread being over my head - will this mod fix this problem for me with my setup?

Not sure if this will be at all useful for anyone looking to programming their dejitter board with a pi, but thought I would post it in case someone wants/needs it. Hopefully save others some time with the openocd installing, configuration of various pieces of the pi, etc.

There is a gui version and a non-gui version. The non-gui version may fit on a 2GB SD card, but I would go with a 4GB minimum, for either image, to be safe.

Connect 5V and ground from GPIO header to dejitter board JTAG connector before powering on pi. Hot-plugging the JTAG signal lines is no problem, but hot-plugging 5V may cause a voltage error, requiring the pi to be rebooted.

Login: piPassword: raspberry

As far as I can tell, GPIO implementation on Pi models with the 2x20 GPIO header has not changed over the various model revisions, with the exception of the base address being different on Pi 3, compared to its predecessors. /home/pi/openocd-pi.conf contains instructions for changing the base address within the file, to ensure compatibility. Openocd-pi.conf contains much useful information, including GPIO header pin assignments, for connecting to dejitter board for programming. It also contains information on testing invididual GPIO header pin functionality using an LED, which can be helpful in understanding GPIO pin assignments. Open openocd-pi.conf in a text editor:> sudo nano /home/pi/openocd-pi.conf

Once you have read through openocd-pi.conf and done any initial testing, connect dejitter board to GPIO header/pi, and run the following commands:

3. OpenOCD auto-probing should report a TAP controller with id 0x0150203f. You can now open another terminal to interact with openocd and program the chip:telnet localhost 4444> svf /home/pi/snes_dejitter.svf

or

> svf /home/pi/snes_dejitter_new.svf

*There are 2 versions of the svf in /home/pi:snes_dejitter.svf - converted from 3-month old pof file contained on marqs' github page, in output_files. This is an older version of the program file, and may increase compatibility on certain SNES modelssnes_dejitter_new.svf - 1-month old svf file contained on marqs' github page, in output_files. This is the newest version of the program file, and adds support for Famicom HVC-CPU-07

4. The programming procedure should finish with no error, after which you can finish installation by powering off hardware and disconnecting the programmer.

Last edited by NoAffinity on Thu Jul 19, 2018 1:56 am, edited 4 times in total.

Hey all, I'm running into jitter problems when capturing my RGB-modded SNES mini with my Magewell Pro Capture HDMI. The top half or so of the image jitters back and forth a pixel or two. I'm hoping this mod can fix the problem.

If anyone is building boards or has any, I'd love to take one off your hands (happy to pay for your efforts and for shipping). Building one myself is a little bit too involved for me at this moment, but I would definitely be able to install it. Would greatly appreciate being able to do this mod ASAP since my current setup sorta relies on it. Switching everything back to s-video would be pretty disappointing, given how great the RGB mod looks on my CRT!

If not, @marqs, do you have a more certain date for when these will be in your store? This is a very cool mod and almost serendipitous how I realized I needed it just as June is coming to a close...

And one question about it: this shouldn't affect the SNES framerate or gameplay behavior at all, right? I assume as much and from reading the entire thread up until this point that's how it would seem, but it would certainly be undesirable if it were the case that the timing of various frame-precise inputs were to change with this mod. Even if people are uncertain I'd still be interested in trying the mod, and could perhaps perform some testing to see if anything is affected by it.

So there's definitely an improvement, but the X900E still appears to be a really fickle TV -- playing with the settings on the OSSC showed some promise and could make the video drop outs more or less frequent, so there may be some combination of settings that stabilizes this. When I have more time I'm going to dig into this.

I've got a second board and I'm waiting to install this in a NES-001 with NESRGB -- has anyone done this and have any instructions or guidance?

I've got a second board and I'm waiting to install this in a NES-001 with NESRGB -- has anyone done this and have any instructions or guidance?

I imagine it is similar to the Famicom install Marqs has on GitHub. If no one has done it, if you can find a schematic I'm sure we can help out. I basically just traced what he did and found the similar components in the NES-101. Essentially, the oscillator circuit lives between pin 29 of the CPU and pin 18 of the PPU. You are removing the oscillator Crystal and disconnecting the oscillator circuit from that path, then putting in a jumper to connect those pins directly (if needed; the NES-101 already has them connected). The rest of the connections are between the dejitter board and the NESRGB, so those are all the same.

If not, @marqs, do you have a more certain date for when these will be in your store? This is a very cool mod and almost serendipitous how I realized I needed it just as June is coming to a close...

The batch should arrive to VGP in a few days. I'm not the one running the store, though, so you'd need to ask BuckoA51 about more detailed availability or just wait until they pop up in the store page.

ggj wrote:

So there's definitely an improvement, but the X900E still appears to be a really fickle TV -- playing with the settings on the OSSC showed some promise and could make the video drop outs more or less frequent, so there may be some combination of settings that stabilizes this. When I have more time I'm going to dig into this.

There's a couple things you could check:

1. Make sure the ground wire between dejitter board and snes PCB is as short as possible - there has been at least one case where a long wire resulted to to noise issues which affected sync stability.

2. If your CSYNC cable has a series resistor on sync line, you should replace R10 (3.3k) on snes_dejitter board with a 8.2k resistor to bring sync to nominal level. This change has been applied to the manufactured v1.2 batch that goes on sale soon.

3. You could try an older version of snes_dejitter.svf which has a bit different timing. The new version has been tested with SHVC-CPU-01 and Famicom (HVC-CPU-07) so I'd assume it should also work fine on SNS-CPU-GPM-02, but you never know.

2. If your CSYNC cable has a series resistor on sync line, you should replace R10 (3.3k) on snes_dejitter board with a 8.2k resistor to bring sync to nominal level. This change has been applied to the manufactured v1.2 batch that goes on sale soon.

marqs, I have a v1.2 board, with 3.3k resistor at R10. My SNES is Mini (SNN-CPU-01). My cable is csync with 470 ohm resistor on sync line. It seems to be working fine, which is to say, it improved compatibility to line5x on a device it was not compatible with above line3x. Should I replace R10 with an 8.2k resistor?

2. If your CSYNC cable has a series resistor on sync line, you should replace R10 (3.3k) on snes_dejitter board with a 8.2k resistor to bring sync to nominal level. This change has been applied to the manufactured v1.2 batch that goes on sale soon.

marqs, I have a v1.2 board, with 3.3k resistor at R10. My SNES is Mini (SNN-CPU-01). My cable is csync with 470 ohm resistor on sync line. It seems to be working fine, which is to say, it improved compatibility to line5x on a device it was not compatible with above line3x. Should I replace R10 with an 8.2k resistor?

No need to do so if you don't have issues, the sync level is still way above OSSC's default sync voltage threshold.

On a Pal SNES SNS-CPU-GPM-02 (moded with 50/60 switch) and sync on luma RGB scart cable dejitter mod will work or a C sync cable is mandatory?

I have a similar question. I'm not sure why the csync signal itself needs to be passed through the mod board; if the clock is gated properly won't it affect the sync signal timing anyway?

I'll be testing this mod with HD retrovision cables which work with sync on composite. My hope is that the mod will properly alter the sync signal present there as well. But some clarity on how the mod affects the sync on composite and sync on luma signals would be greatly appreciated.

The mod generates the properly timed sync. Essentially you remove the oscillator on the system and replace it with this mod. So it takes the signal from the CPU, sets the timing, then passes to the output. At least that is my understanding of it.

As far as sync on luma etc, the only real difference is what pin the cable is wired for. You can send the same signal through the luma output or a c-sync output or a composite output. The difference is that usually there is also luma information on the luma line and composite video on the composite line. But since the receiving end doesn't care about that and only looks at the sync anyway, it doesn't really matter if the luma/video info is there or not. Just make sure you connect the output of this board to the right pin on the output jack for the cable you are using.

The mod generates the properly timed sync. Essentially you remove the oscillator on the system and replace it with this mod. So it takes the signal from the CPU, sets the timing, then passes to the output. At least that is my understanding of it.

As far as sync on luma etc, the only real difference is what pin the cable is wired for. You can send the same signal through the luma output or a c-sync output or a composite output. The difference is that usually there is also luma information on the luma line and composite video on the composite line. But since the receiving end doesn't care about that and only looks at the sync anyway, it doesn't really matter if the luma/video info is there or not. Just make sure you connect the output of this board to the right pin on the output jack for the cable you are using.

The HD retrovision cables are wired for sync on composite and are not easy to modify. I'm not sure how to disable the sync on composite signal and replace it with the csync_o signal from the dejitter board, which I'd happily do if it were straightforward and reversible. My SNES Mini already has the RGB mod in place and the only way I know how to disable the sync on composite signal involves removing a resistor that sits underneath the RGB mod board. I don't think I'm going to remove the rgb mod at this point unless absolutely necessary so I would need an alternative method of disconnecting sync on composite.

My question is, how does this mod affect the sync signals already present on the sync-on-composite and sync-on-luma lines? It seems like it *should* affect them since it's gating the system clock before the cpu and gpu. So if the sync signal is already on those lines won't it be gated as well and delayed the appropriate amount? Am I misunderstanding how the mod works? I'd really rather not replace the sync on composite signal if it's not necessary and would also simply like to understand the effect the mod has on the sync on composite and sync on luma signals for my own sake, even if it's not applicable to the solution I'll use. Thanks again for answering!

My question is, how does this mod affect the sync signals already present on the sync-on-composite and sync-on-luma lines? It seems like it *should* affect them since it's gating the system clock before the cpu and gpu. So if the sync signal is already on those lines won't it be gated as well and delayed the appropriate amount? Am I misunderstanding how the mod works? I'd really rather not replace the sync on composite signal if it's not necessary and would also simply like to understand the effect the mod has on the sync on composite and sync on luma signals for my own sake, even if it's not applicable to the solution I'll use. Thanks again for answering!

Sent from my MI 6 using Tapatalk

I could also be misunderstanding it, but AFAIK the mod becomes the sole sync signal since it is replacing the stock oscillator. The factory circuit is disconnected as part of the mod, so sync is only sent wherever you send it from the output of your mod. In my case, I just sent it to the c-sync input of the RGB mod. If you need sync on composite, I believe you need to disconnect the composite signal and connect this in its place.

Marqs, I guess I had not considered this before but does using this mod mean that composite and s-video signals no longer work since we are disconnecting sync and sending from dejitter directly to the output?

Composite video (well, sync on composite at least) was still working on my mini, with the dejitter mod installed, but unbeknownst to me that my cable was wired for sync on composite. I had the dejitter mod wired to pin 3, but my cable was wired for sync from pin 9, and still providing sync. With the help of some folks on VGP, I lifted a 75R resistor just south of solder side pin 9, and routed the dejitter mod to pin 9, in order to get dejitter mod sync.

So, that begs the question, is X1 not responsible for composite video sync?

On a Pal SNES SNS-CPU-GPM-02 (moded with 50/60 switch) and sync on luma RGB scart cable dejitter mod will work or a C sync cable is mandatory?

I have a similar question. I'm not sure why the csync signal itself needs to be passed through the mod board; if the clock is gated properly won't it affect the sync signal timing anyway?

I'll be testing this mod with HD retrovision cables which work with sync on composite. My hope is that the mod will properly alter the sync signal present there as well. But some clarity on how the mod affects the sync on composite and sync on luma signals would be greatly appreciated.

The mod uses CSYNC_i (the signal from PPU that also goes to composite encoder chip) to decide when to gate MCLK, so it can't normalize the source signal itself. You have a couple options if you want to use a cable with sync wired to composite/luma multi-AV pin:

3. If you are using OSSC or some other digitizer which uses or can be set to use H-PLL post-coast of at least 2 scanlines, you can use composite/luma as sync (or original c-sync on the models which have it) without connecting CSYNC_o anywhere. That's because after the mod those outputs have a short scanline immediately followed by a long scanline, i.e. the 3rd scanline after vsync starts at correct time so sync should be stable as long as the digitizer does not try to lock on those 2 post-vsync lines.

The mod uses CSYNC_i (the signal from PPU that also goes to composite encoder chip) to decide when to gate MCLK, so it can't normalize the source signal itself. You have a couple options if you want to use a cable with sync wired to composite/luma multi-AV pin:

Thanks for the info. Can you (or anyone really) provide me with some precise instructions for hw to do 1. and 2. with specifically replacing the composite video signal, that doesn't involve desoldering the RGB mod on my SNES Mini? Hell, instructions on how to use a multimeter to determine how to do these things myself would work too -- I have lots of experience soldering by following directions but not much knowledge of how to figure out what to do myself.

Would be happy to send some $ your way for precise instructions! I know your time and effort isn't free.

So I'm looking at a SNES schematic and it looks like I can disconnect the composite video signal without affecting anything else by removing R30 or R33 -- am I correct in thinking this? If so, is there a preferred choice?