NES/SNES 240p dejitter mod

[ldeveraux]

Are there any reliable installation pics for the boards? Mine arrived today and just realized RetroModWiki is down. I can probably try to follow the written instructions on Github, but pictures would sure be helpful.

The wiki was moved to a different URL so it could be hosted for free. NES install is here, but SNES is also still available. https://retromods.game.blog/nes-famicom ... d-install/

Oh thanks, I'd hoped they weren't gone forever! I'll dejitter mod my SNES and NES this weekend!

[ldeveraux]

Are there any reliable installation pics for the boards? Mine arrived today and just realized RetroModWiki is down. I can probably try to follow the written instructions on Github, but pictures would sure be helpful.

The wiki was moved to a different URL so it could be hosted for free. NES install is here, but SNES is also still available. https://retromods.game.blog/nes-famicom ... d-install/

So I did both mods last night with great success. The NES was a bit tougher to get working 100%, but thanks again. Jitter is gone!

[copy]

Has anyone come to any further conclusions about conditioning the dejittered subcarrier?

I have wired up my NESRGB 1.4 so that the new subcarrier will go through the NESRGB's original SC circuit components: a 2 kΩ series resistor and a 27 pF parallel cap. But I don't really know what I'm doing. Can anyone advise if this arrangement should work correctly for proper dejittered composite and s-video? More importantly, will it be safe for the CPLD and video encoder?

[copy]

Gave my NES a try with the configuration I described above. I've only had partial success with the dejittered subcarrier. The composite and s-video outputs no longer have that discolored portion at the top of the screen.

Unfortunately the s-video picture has tons of garbage in dark areas, like flickery horizontal noise jumping around. I think it's also present in composite but is harder to see.

I wonder if my patch wire for the subcarrier is picking up interference? Or are my resistor/cap values the culprit?

[copy]

Well, nevermind. My problem seems to be that I own terrible quality SNES composite and s-video cables. (My NESRGB goes to a Nintendo multiout.) I tried the same cables on my SNES tonight on a hunch, and sure enough, same noise.

Crazy how I never knew how noisy these cables were back when I used them on small CRTs. This includes the official Nintendo composite pack-in cable, and a couple of third-party s-video ones. I assume if I bought the Retro Access s-video cable, the results would be much better.

So anyway, it seems the subcarrier output works as intended! Thanks marqs for adding this feature.

[Jon Nielsen]

Hello all. First of all, thanks for the this thread and everything posted in it. Good stuff. I did the mod recently after getting my hands on a guinea pig NTSC SNES.

While I'm happy with the results from following the SHVC-CPU-01 guide on the DeJitter github, I'd like to ask for help with implementing a couple of ideas:

Dual sync output on CSYNC and composite. Having removed components near the multiout and connected CSYNC from the DeJitter PCB, I'd like to also have dejittered sync go out through pin 9. This way RGB cables with sync stripper circuitry will also pick up the dejittered sync. I don't care about the composite video signal at all.

Is this at all possible without feeding the CSYNC through the RGB encoder chip (thus having to restore the components near the multiout)?
Is it safe to do so by simply bridging pin 3 to pin 9?
Will a sync stripper pass the sync through or would its filters affect the sync signal?

The second improvement I'd like to make is to add PAL support, having prepared and put in SuperCIC+UIGR mods. The systems' oscillator is disabled via the mod so right now PALMODE is obviously not working.

Would it be possible to restore PAL functionality by using a DFO mod to pass through suitable PAL clock ?

Any advice or feedback welcome.

Thanks!

[unmaker]

Hello all. First of all, thanks for the this thread and everything posted in it. Good stuff. I did the mod recently after getting my hands on a guinea pig NTSC SNES.

While I'm happy with the results from following the SHVC-CPU-01 guide on the DeJitter github, I'd like to ask for help with implementing a couple of ideas:

Dual sync output on CSYNC and composite. Having removed components near the multiout and connected CSYNC from the DeJitter PCB, I'd like to also have dejittered sync go out through pin 9. This way RGB cables with sync stripper circuitry will also pick up the dejittered sync. I don't care about the composite video signal at all.

Is this at all possible without feeding the CSYNC through the RGB encoder chip (thus having to restore the components near the multiout)?
Is it safe to do so by simply bridging pin 3 to pin 9?
Will a sync stripper pass the sync through or would its filters affect the sync signal?

The second improvement I'd like to make is to add PAL support, having prepared and put in SuperCIC+UIGR mods. The systems' oscillator is disabled via the mod so right now PALMODE is obviously not working.

Would it be possible to restore PAL functionality by using a DFO mod to pass through suitable PAL clock ?

Any advice or feedback welcome.

Thanks!

https://github.com/borti4938/SNES_Multi ... Jitter_QID

[Jon Nielsen]

https://github.com/borti4938/SNES_Multi ... Jitter_QID

Thanks! Looks interesting. I'll study this and see if it can be applied in putting together a solution.

[Jon Nielsen]

Edit:
Back to the drawing board. Should have paid more attention, just noticed the detail about SJ32 jumper on borti's AIO. Will need to see if something similar can be set with the DFO board I have as this is indeed not a 1CHIP.

Okay. I've studied to some degree how the posted AIO project works, started myself blind on SNES schematics, assembled and tested another AIO without the DeJitter.

In preparation a separate DFO board is now installed which is currently forced to 17mhz (21mhz left as an option DeJitter needs to be moved or removed). P2 is not yet connected to anything on the SNES or DeJitter boards.

The plan is to combine the approaches in the SNSP-CPU-02 and SHVC-CPU-01 guides from marqs85's github.

Idea would be to first route the 17mhz-forced DFO P2 to cartridge pin 1 or to the disabled oscillator (C5/R6 removed) pins. Open question: Are these equivalent and possible to use as described here?

Then:
- Remove R73 and use for MCLK_o and MCLK_EXT_i
- Move CSYNC_i to S-ENC pin 8
- Connect SuperCIC/UIGR mode to CLK_SEL_i

If anyone with in-depth knowledge of these boards can chime in, I would be thankful.

Just to be clear, the point of all this is:
- Restore functionality of UIGR/SuperCIC mod which can now be considered pointless except for the cooler LED color
- Learn how the console and these fascinating mods work
- Play some original PAL SNES games long enough to realize why I wanted to go 60hz to begin with

Cheers

Jon

[maxtherabbit]

Can anyone help out with getting OpenOCD to work with this USB Blaster?


The github page specifies that the original Altera blaster has fixed clock, and is too fast to program the dejitter board. However it mentions that the "blaster II and clones" should work.

The pictured blaster was purchased off ebay for peanuts, so I assume it's a clone. There are hundreds of similar listings for these guys floating around, so I assume it also is very common.

When trying to run OpenOCD I get an informational message saying this device doesn't support configurable speed. If this is accurate, then I'm probably simply out of luck with this specific dongle. But the absolute unadulterated nightmare that is trying to get working drivers and binaries for this shit leaves me with some doubt that maybe I just have the software misconfigured

Code: Select all

C:\Users\alexg\Desktop\openocd-0.10.0\bin>openocd
Open On-Chip Debugger 0.10.0
Licensed under GNU GPL v2
For bug reports, read
        http://openocd.org/doc/doxygen/bugs.html
Warn : Adapter driver 'usb_blaster' did not declare which transports it allows;
assuming legacy JTAG-only
Info : only one transport option; autoselect 'jtag'
adapter speed: 1000 kHz
Info : No lowlevel driver configured, will try them all
Info : usb blaster interface using libftdi
Info : This adapter doesn't support configurable speed
Warn : There are no enabled taps.  AUTO PROBING MIGHT NOT WORK!!
Info : TAP auto0.tap does not have IDCODE
Info : TAP auto1.tap does not have IDCODE
Info : TAP auto2.tap does not have IDCODE
Info : TAP auto3.tap does not have IDCODE
Info : TAP auto4.tap does not have IDCODE
Info : TAP auto5.tap does not have IDCODE
Info : TAP auto6.tap does not have IDCODE
Info : TAP auto7.tap does not have IDCODE
Info : TAP auto8.tap does not have IDCODE
Info : TAP auto9.tap does not have IDCODE
Info : TAP auto10.tap does not have IDCODE
Info : TAP auto11.tap does not have IDCODE
Info : TAP auto12.tap does not have IDCODE
Info : TAP auto13.tap does not have IDCODE
Info : TAP auto14.tap does not have IDCODE
Info : TAP auto15.tap does not have IDCODE
Info : TAP auto16.tap does not have IDCODE
Info : TAP auto17.tap does not have IDCODE
Info : TAP auto18.tap does not have IDCODE
Info : TAP auto19.tap does not have IDCODE
Info : TAP auto20.tap does not have IDCODE
Warn : Unexpected idcode after end of chain: 21 0x00000000
Warn : Unexpected idcode after end of chain: 53 0x08000000
Warn : Unexpected idcode after end of chain: 85 0x00000000
Warn : Unexpected idcode after end of chain: 117 0x00000000
Warn : Unexpected idcode after end of chain: 149 0x00000000
Warn : Unexpected idcode after end of chain: 181 0x00000000
Warn : Unexpected idcode after end of chain: 213 0x00000000
Warn : Unexpected idcode after end of chain: 245 0xf8101000
Warn : Unexpected idcode after end of chain: 469 0x07ffffff
Warn : Unexpected idcode after end of chain: 501 0x00000000
Warn : Unexpected idcode after end of chain: 533 0x00000000
Warn : Unexpected idcode after end of chain: 565 0x00000000
Warn : Unexpected idcode after end of chain: 597 0x00000000
Warn : Unexpected idcode after end of chain: 629 0x00000000
Error: double-check your JTAG setup (interface, speed, ...)
Error: Trying to use configured scan chain anyway...
Warn : AUTO auto0.tap - use "jtag newtap auto0 tap -irlen 2 -expected-id 0x00000
000"
Error: auto0.tap: IR capture error; saw 0x0000 not 0x0001
Warn : Bypassing JTAG setup events due to errors
Warn : gdb services need one or more targets defined

[Dr. Claw]

Just wanted to say, installed this board in my SNES (SNS-CPU-GPM-02).

Previously had tried the following:
SNES -> CSYNC SCART -> OSSC -> Sony X900E -- video with garbled audio, frequent video drop out
SNES -> CSYNC SCART -> OSSC -> Sony STRDN1080 -> Sony X900E -- no video or audio

With dejitter board installed:
SNES -> CSYNC SCART -> OSSC -> Sony X900E -- video and audio both working, video drops sporadically and frequently, maybe every 10-60 secs
SNES -> CSYNC SCART -> OSSC -> Sony STRDN1080 -> Sony X900E -- same results as without the AV receiver in the chain

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?

Is this problem strictly with the RGB signal from the SNES?
I have a Sony 4K TV of roughly the same vintage as the one in the above reply (X720E). It seems to handle 240p decently (as 480i, but with proper transparency, flashing images, even resolution switches on PS1 on PS2 like Chrono Chross) over the YPbPr port directly. With RGB/YPbPr cables like RGC or HDRetro's connected to a Sega 240p console (Genesis Model 1, Saturn Model 1), no issues with what it displays.

As for the SNES, I have been mostly using S-Video transcoded to YPbPr (now using Koryuu, was using RetroTink 2X > Cheap HDMI to Component converted Mike Chi demo'd in a video), which as far as I know is still 240p (OSSC says so). Direct feed of that to the TV has no issues.
In OSSC I can go all the way up to 5X, whether I'm going through my Blackbird 4K 5x1 Presentation Switch or directly into an HDMI port in the TV using the transcoded S-Video.

However, with the HD Retrovision cables I have some weirdness:
Direct feed into the Component port results in repeated "blinking" of the image, like it repeatedly drops sync.
Connecting it to a RetroTink, directly into an HDMI port results in stable 480p.
Ditto with the OSSC, albeit at 2X.
The only way to get OSSC above that is to go through the Blackbird.

Only thing I can come up with is that it's because of the RGB signal, even though that's not an issue with other 240p sources, even using HDRetro cables.

[maxtherabbit]

My original installation post lost its images to time and I also updated the method to use the dejittered subcarrier. So let's go through it again.

Install on SHVC-CPU-01. I elected to put the dejitter board on top, to reduce wire lengths.

The primary thing that distinguishes this install will be injecting the dejittered sync back into circuit before the video encoder in the SNES, providing dejittered outputs on CVBS, Y/C and RGBS. Additionally we will be injecting the dejittered subcarrier into the encoder to make sure the encoded signals maintain correct colors.

First, remove C5 and R6 as per marqs' instructions for SHVC-CPU-01. This severs the original xtal circuit from the CPU, PPUs and cart slot.

Spoiler

Next, lift pin 100 and pin 3 of the PPU2. Pin 100 will be our csync source to feed to CSYNC_i on the mod board and pin 3 is the original source of the subcarrier.

Spoiler

Next, scrape the solder resist off of the via immediately to the right of C69 and the one below its right pad. The first via is attached to the pad for PPU2's pin 100 and the other is attached to the pad for PPU2's pin 3. We will be soldering 4Vpp level CSYNC out DIRECTLY from the CPLD's pin 15 (by way of the top pad of R9 which is connected via trace) on the mod board to the first via (originally for PPU2's pin 100) from the top side (do not use CSYNC_o on the mod board) and dejittered subcarrier directly from the CPLD's pin 11 to the second via (originally for PPU2's pin 3) below and connected to C69's right pad.

Spoiler

Next, attach wires for CSYNC_i and MCLK_o. MCLK_o will be attached to the PPU2's pin 31 (XIN) which is also directly connected to PPU1's pin 100, the CPU, and cart slot pin 1. CSYNC_i goes directly to the lifted pin 100 on PPU2.

Spoiler

Finally, affix the board and finish connections. Remember to bridge JP2 on the mod board. Power and ground for the dejitter board will come from U11, the reset IC - it's got nice thicc traces going to vias which tie into VCC and ground floods on the back.

Spoiler

[Mrmatt3465]

Hello,

New here but have been researching a lot on SNES mods and RGB bypass/dejitter stuff. I'm trying to see if there is a confirmed method to get CSync dejittered through Sync on composite/sync on luma.

Background:
I have a Super Famicom Jr that I plan on installing Voultar's RGB Bypass amp into as well as Arthrimus' dejitter board. I will be using the HD Retrovision cables. I plan to use an OSSC and would like the functionality of Line3x and higher to work correctly.

So from what I understand, the HD Retrovision cables use sync on composite, so the dejitter function of the board would not have an effect using these cables. It seems some experiments have been done with injecting the CSync directly to pin 7 of the S-RGB chip on the SNES. Looking at Borti's Multiregion+Dejitter install, he has you lift pin 7 on the S-RGB and then connect CSync_i to the pad of S-RGB pin 7, and then connect CSync_o [raw] to pin 7 of S-RGB. This should, from what I understand, inject the dejittered CSync into the S-RGB chip and should then provide dejittered sync on luma/sync on composite. On Arthrimus' board, a CSync_o [raw] is not a pad, so we instead pull from pin 15 of the CPLD.

Extrapolating, to correctly install the Dejitter board in order to obtain sync on luma/sync on composite, I need to lift pin 7 of the S-RGB and connect the pad from pin 7 to the CSync_i of the Dejitter board. On the Dejitter board, I need to connect pin 15 of the CPLD by soldering wire from R9 to pin 7 of the S-RGB. Conversely, if doing this while not using the CSync_o pad on the dejitter board, can I depopulate R9 and solder directly to the pad under it to get the signal from pin 15 of CPLD? Or do I need R9 in place for other functions?

Do I also need to connect the CSync via [next to the RGB vias on the typical RGB bypass amp install] to the CS pad of the Voultar board? Or would I now affix that to the AV pin 3 directly?

Do I need to jumper J3 on the Dejitter board and depopulate R14 because its an SFC Jr without the capacitor in place on say a 1CHIP-01/02?

Thank you for your help.

Matt

[maxtherabbit]

Matt if you are going to inject dejittered csync to the video encoder you need to also send it the NTSC subcarrier from CPLD pin 11. See my post immediately above yours for how to install it on a 3chip

[theastropath]

Hi everyone,

I installed a dejitter board (v1.1) into my NTSC SNS-CPU-GPM-02 a few years ago using the instructions from the github repository. The RGB output has been working great ever since. Today I was looking to hook my system up to a CRT with S-Video or composite so that I could play some Super Scope games, and noticed that the output was monochrome.

Digging through this thread, I think this is to be expected, and I think this is why some people in the last few pages have been discussing feeding the CSYNC_o into the video encoder? If I'm looking at THIS schematic correctly, it looks like I should take the CSYNC_o signal and feed it into pin 8 of the S-ENC chip (after lifting the leg). Does that seem correct?

EDIT: It took a while for this post to get approved, but in the meantime I had tried maxtherabbit's suggestions to grab the subcarrier, but it wasn't working. Looking back, it looks like the clean subcarrier on pin 11 is only being output in a recent version of the firmware (Just noticed that today), so I'll probably have to see if I can remember how I flashed the firmware, throw a new version on there and try again...

[otj]

Does anyone happen to know the values of C3 and R12 on a 1chip-01? I've been looking for a schematic and haven't had any luck finding one.

I need to remove the dejitter board for someone and they sadly no longer have the original parts.

[Sumez]

As noted in my recent thread on this forum, it seems the dejitter kit has been quietly discontinued [from VGP], to my massive frustration.

What are the specific components that are in shortage, and is there any hope of these ever becoming available again?

[maxtherabbit]

https://arthrimus.com/product/marqs85-s ... itter-mod/

This is where I got mine, no idea what the shipping situation to Europe is though

[DragonQuarter]

I was told by Arthrimus that the RGB Bypass+Dejitter chip would be back in stock several weeks ago, but haven't heard any updates since. I'm sure it's 'cause of chip shortages, but still hoping I can get one of these soon.

[DragonQuarter]

Seems like we won't be getting any future Dejitter chips anytime soon as Arthrimus is on partial hiatus. In any case, hope things get better for 'em!

https://arthrimus.com/partial-hiatus/

Any chance there are other places where one could get a Dejitter chip or an RGB Bypass+Dejitter chip for self-installation?

[NewSchoolBoxer]

Seems like we won't be getting any future Dejitter chips anytime soon as Arthrimus is on partial hiatus. In any case, hope things get better for 'em!

https://arthrimus.com/partial-hiatus/

Any chance there are other places where one could get a Dejitter chip or an RGB Bypass+Dejitter chip for self-installation?

You should be able to order the board here for $9.40 + free shipping to US. Not sure if latest version: https://oshpark.com/shared_projects/gHu1UqML

Can someone tell me if I'm overlooking the obvious? I can't verify jitter until I buy an oscilloscope and I don't use upscalers:

• Retrotink RGB to digital video products handle sync jitter with their FPGA
  240p compatible RGB capture cards tolerate sync jitter with their FPGA (I know E1S has one) or other circuitry
  HD Retrovision RGB to YPbPr cable handles the sync jitter with its unspecified circuitry
  OSSC uses an FPGA but was programmed without jitter awareness and no one has rewritten the software?
  -> OSSC solution is a hardware mod that fair going rate for professional install is $50. Not saying price is unfair.

Can't we make a multiout male in, female out cable and put a fix-on-a-chip solution in it that only de-jitters and has no transcoding or ADC that could be done for cheap? Keep consoles nice and stock and not inflate their resell price?

Being hypothetical with cheapest tech possible:

Maybe we could use a 12 bit adder with clock cycle set to the sync timing marqs posted. Else accumulate on the pixel count. When it ticks to 1360 [0101 0101 0000 in 12 bit binary], a comparator checks for horizontal blanking signal. If present then reset adder. If absent, generate an artificial horizontal blanking signal on the sync line. Throw out RGBS data from console for 4 ticks of adder (1361-1364) then reset adder. No need to touch R, G, B lines if devices ignore them during horizontal blanking.

Big question: If SNES horizontal blanking window is 15.69 μs NTSC, does extending that by 4 MCLK cycles fall within OSSC and HDMI spec tolerance?

Basically, cut off each horizontal line not shortened by one dot and match horizontal blanking window to what it is on that now un-jittered horizontal line. Could use more advanced timing for greater efficiency. Use NTSC SNES +5V DC line for power.

[jcarlos]

My Snes gives a black screen although the CPU works, I have measured SYSCK and XIN signals, but the XIN signal is strange to me, could that be the cause?

[evilsim]

I have an issue installing the Dejitter board (purchased from VGP with a sticker "NES Firmware" on the packet). NES CPU-07 NTSC, NESRGB V2 PCB, standard firmware (2021 purchase).
See image. I've checked everything a few times, but no picture (the PVM doesnt even pickup any sync at all).

Spoiler

The bridge wire where I removed the two capacitors may have something to do with it. There are no direct instructions for CPU07 and I do not have a scope to check for sync.

Any help would be greatly appreciated.

[marqs]

I have an issue installing the Dejitter board (purchased from VGP with a sticker "NES Firmware" on the packet). NES CPU-07 NTSC, NESRGB V2 PCB, standard firmware (2021 purchase).
See image. I've checked everything a few times, but no picture (the PVM doesnt even pickup any sync at all).

Doesn't NESRGB V2 have the option to implement dejitter in itself, not sure why you'd need separate board with that?

[evilsim]

I think the earlier V2 firmwares had it implemented, but he may have taken it out shortly after. I've had a conversation with Tim W about this a while back.

This NES belongs to someone who has various displays, all but his 60" Sony TV sync properly. He was sure it was de-jitter problem as other consoles work on that TV, so he posted it to me for the install after buying the board from VGC. Since I have it with me now, I will do what I can to get it working.

I have continuity between where the original clock was and the points where the capacitors were removed, I also tried moving the small cable bridge around to the other pads, no luck. Pin 18 of PPU has continuity to the CPU clock pin as well. I can't see what I am missing Just gives me a black screen and no audio. I have no clock it appears.


EDIT:

Pin 18 of PPU has continuity to the CPU clock pin as well

This was the problem. The output from the dejitter board needs to go to the clock input side - not the ppu output side - my bad!
Another solder point for the output of the dejitter board is either side of the bridge cable which you install during install (between ceramic caps 44 and 45).

[marqs]

Ok, good that it was resolved.

[copy]

My original installation post lost its images to time and I also updated the method to use the dejittered subcarrier. So let's go through it again.

Install on SHVC-CPU-01. I elected to put the dejitter board on top, to reduce wire lengths.

The primary thing that distinguishes this install will be injecting the dejittered sync back into circuit before the video encoder in the SNES, providing dejittered outputs on CVBS, Y/C and RGBS. Additionally we will be injecting the dejittered subcarrier into the encoder to make sure the encoded signals maintain correct colors.

Hey maxtherabbit, thanks for your guide. I'm considering rewiring my dejitter installs like yours to get dejittered CVBS and Y/C.

What's your experience so far with the SNES unit pictured? Have you used it with an OSSC or RetroTINK-5X, and if so did everything work as expected?

Have you also tried this on a 1CHIP or mini? Wondering if you know which pins on the S-CPUN provide the csync and subcarrier.

[maxtherabbit]

My original installation post lost its images to time and I also updated the method to use the dejittered subcarrier. So let's go through it again.

Install on SHVC-CPU-01. I elected to put the dejitter board on top, to reduce wire lengths.

The primary thing that distinguishes this install will be injecting the dejittered sync back into circuit before the video encoder in the SNES, providing dejittered outputs on CVBS, Y/C and RGBS. Additionally we will be injecting the dejittered subcarrier into the encoder to make sure the encoded signals maintain correct colors.

Hey maxtherabbit, thanks for your guide. I'm considering rewiring my dejitter installs like yours to get dejittered CVBS and Y/C.

What's your experience so far with the SNES unit pictured? Have you used it with an OSSC or RetroTINK-5X, and if so did everything work as expected?

Have you also tried this on a 1CHIP or mini? Wondering if you know which pins on the S-CPUN provide the csync and subcarrier.

I play on that console regularly with an OSSC, works great. I don't own a 5X. Have not tried to dejitter a 1 chip

[copy]

After re-reading some earlier posts, I gather I don't need to worry about the subcarrier on the 1CHIPs. I understand the S-CPUN A will output clean subcarrier derived internally from the dejittered master clock. So, all I need to do is inject dejittered csync into the S-RGB.

It is only on the 3-chips that you need to tap dejittered subcarrier from the dejitter board and route it to the video encoder. All correct?

I play on that console regularly with an OSSC, works great. I don't own a 5X. Have not tried to dejitter a 1 chip

Thanks. I probably should have specifically asked if you tried sync-on-luma, sync-on-composite, or HD Retrovision cables. If those cables work on a picky TV through the OSSC, then it should be a good sign that the dejittered CVBS and Y/C are solid.

[maxtherabbit]

After re-reading some earlier posts, I gather I don't need to worry about the subcarrier on the 1CHIPs. I understand the S-CPUN A will output clean subcarrier derived internally from the dejittered master clock. So, all I need to do is inject dejittered csync into the S-RGB.

It is only on the 3-chips that you need to tap dejittered subcarrier from the dejitter board and route it to the video encoder. All correct?

I play on that console regularly with an OSSC, works great. I don't own a 5X. Have not tried to dejitter a 1 chip

Thanks. I probably should have specifically asked if you tried sync-on-luma, sync-on-composite, or HD Retrovision cables. If those cables work on a picky TV through the OSSC, then it should be a good sign that the dejittered CVBS and Y/C are solid.

I only use C-sync with my OSSC, but I know the dejittered CVBS and Y/C are working because I had a TV that was showing distorted colors at the top of the image on those formats before the mod, and that has now been eliminated