NES/SNES 240p dejitter mod

[copy]

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

Perfect, thank you.

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 think I be wrong about the 1CHIP above? I have thoroughly confused myself.

Now I'm leaning toward that the NTSC 1CHIP actually does need the clean subcarrier from snes_dejitter, if I follow past discussion correctly (1, 2, 3, 4). Can any experts confirm? (marqs or borti4938, if you're still around...?)

[marqs]

Now I'm leaning toward that the NTSC 1CHIP actually does need the clean subcarrier from snes_dejitter, if I follow past discussion correctly (1, 2, 3, 4). Can any experts confirm? (marqs or borti4938, if you're still around...?)

Yes, you need stable subcarrier if you want to avoid color artefacts with composite / S-video.

[NewSchoolBoxer]

I think it's getting lost in the shuffle that the dejitter mod isn't needed for most scalers or any analog capture cards I'm aware of. I was in a thread where I clarified dejitter mod is intended for OSSC. I run stock SNES off 1chip and 2chip aka 3chip consoles to the analog inputs on my 2003 Plasma and 2009 LCD no issues. Reading this thread, I get that sync jitter doesn't exist on PAL, though the mod is useful on PAL consoles modified with Super CIC to play with NTSC timings.

Maybe it's time for a mod redesign. Arthrimus' eShop and Video Game Perfection are out of dejitter mod stock due to the CPLD chip being out of stock.

Was a CPLD necessary over similarly priced $3/€3 microprocessors that are very much in stock? Other potential change is the timing crystal.

21.477 MHz crystals and their (1/6) 3.58 MHz cousins are still available but I don't know about a few years from now. The crystal in the bom is out of stock and the only one left is not recommended for new designs.

I learned that MEMS oscillators can be programmed to oscillate at any frequency between 1 and 110 MHz and you can buy your own programmer + 10 MEMS for $54/€53. This is the 21.377 MHz MEMS oscillator I ordered to try out. The design is simpler and easier using an active oscillator over a passive (crystal) resonator, yet 21.477 MHz crystal oscillators don't exist. Reading on the science of MEMS vs crystals, basically the maker of one disses the other.

MEMS costing a little more doesn't matter in non-production quantities. Being smaller than a crystal is a plus and immunity to EMI may be relevant. Can say it's worse in other important respects but it's future proof.

[copy]

Yes, you need stable subcarrier if you want to avoid color artefacts with composite / S-video.

Thanks marqs, and much appreciation again for this project. Looking forward to revising my SNES installs soon.

I think it's getting lost in the shuffle that the dejitter mod isn't needed for most scalers or any analog capture cards I'm aware of. I was in a thread where I clarified dejitter mod is intended for OSSC. I run stock SNES off 1chip and 2chip aka 3chip consoles to the analog inputs on my 2003 Plasma and 2009 LCD no issues.

I think it's been well communicated and discussed that this mod is only needed if you have downstream devices that can't lock onto the irregular sync. I found the Sony X900E and X950G TV lines to be totally incompatible, for example, so the mod was a lifesaver for me.

Plus I would argue that even if your equipment is compatible today, that may not be true for your next display etc. So the mod is still valuable because it addresses the issue at the source, and thus futureproofs the console for pretty much any video devices going forward.

Maybe it's time for a mod redesign. Arthrimus' eShop and Video Game Perfection are out of dejitter mod stock due to the CPLD chip being out of stock.

It is a shame it is unavailable now. Arthrimus has paused his business unfortunately. I hope VGP plans to restock the mod sometime. I do see Digikey estimates more CPLD stock in mid-October.

[maxtherabbit]

The Datapath VisionAV-SDI will not capture a stock SNES, it must be dejittered. That's at least one example of an analog capture card.

[marqs]

The Datapath VisionAV-SDI will not capture a stock SNES, it must be dejittered. That's at least one example of an analog capture card.

Out of interest, is that via RGB (DVI-I) or via composite? The former is apparently handled by ADV7604 which is one of the newer (still over 10 years old) Analog Devices video ADC chips.

[maxtherabbit]

The Datapath VisionAV-SDI will not capture a stock SNES, it must be dejittered. That's at least one example of an analog capture card.

Out of interest, is that via RGB (DVI-I) or via composite? The former is apparently handled by ADV7604 which is one of the newer (still over 10 years old) Analog Devices video ADC chips.

RGB. I haven't tried it on composite tbh

[marqs]

The Datapath VisionAV-SDI will not capture a stock SNES, it must be dejittered. That's at least one example of an analog capture card.

Out of interest, is that via RGB (DVI-I) or via composite? The former is apparently handled by ADV7604 which is one of the newer (still over 10 years old) Analog Devices video ADC chips.

RGB. I haven't tried it on composite tbh

I see. Perhaps the chip is not configured for best compatibility or analog frontend was never its focus (the chip also includes HDMI/DVI receiver).

[NewSchoolBoxer]

I think it's getting lost in the shuffle that the dejitter mod isn't needed for most scalers or any analog capture cards I'm aware of. I was in a thread where I clarified dejitter mod is intended for OSSC. I run stock SNES off 1chip and 2chip aka 3chip consoles to the analog inputs on my 2003 Plasma and 2009 LCD no issues.

I think it's been well communicated and discussed that this mod is only needed if you have downstream devices that can't lock onto the irregular sync. I found the Sony X900E and X950G TV lines to be totally incompatible, for example, so the mod was a lifesaver for me.

Plus I would argue that even if your equipment is compatible today, that may not be true for your next display etc. So the mod is still valuable because it addresses the issue at the source, and thus futureproofs the console for pretty much any video devices going forward.

Maybe it's time for a mod redesign. Arthrimus' eShop and Video Game Perfection are out of dejitter mod stock due to the CPLD chip being out of stock.

It is a shame it is unavailable now. Arthrimus has paused his business unfortunately. I hope VGP plans to restock the mod sometime. I do see Digikey estimates more CPLD stock in mid-October.

Where do you see a mid-October restock alert? I do see the pin-compatible 15JU44 has 98 units available but takes 3.3V instead of 5V, so won't work with the existing PCB even if being 44-LCC versus 44-TQFP isn't significant.

Can marqs or someone else confirm if 15JU44 will work after adding a 3.3V voltage regulator to the design?
Actually, why do we need a console mod for dejitter? Can't it go in an external device connected on the multiout?

You're emphasizing the usefulness of the $20/€20 dejitter mod that two popular devices benefit from: OSSC and HDRetrovision RGB->YPbPr cables. If you're like 99% of the population that won't solder, it's an extra $50/€50 fee for install before 2 way shipping. That's more than what the cables cost. I'm happy the mod was a lifesaver for you but would you have bought a RetroTINK or Framemeister instead if you knew your televisions didn't handle sync jitter?

I would disagree that sync jitter is well discussed. HD Retrovision has compatibility lists for their cables but they completely dodge listing scalers to to fix the sync jitter. Active discussion, this is it in English and marqs has published the one solution for incompatible decoder chips. I'm not able to understand the Verilog source code however or the NES timing differences.

I admit I had to look up what a CPLD was. So it uses HDL programming like FPGAs and thus an FGPA programmer would be comfortable using over a microprocessor. We need don't the parallelization that CPLDs and FPGAs offer here and detecting 4.7us sync pulses every other frame is not cutting edge tech. I'm confident sync de-jitter is doable using a cheap microprocessor when the ADC from a STM32 or PIC32 can sample over 1 Msps.

Switching to a microprocessor would make the dejitter fix more accessible when a) microprocessors are far more plentiful than CPLDs b) far more people know C or C++ than Verilog or VHDL.

[marqs]

Can marqs or someone else confirm if 15JU44 will work after adding a 3.3V voltage regulator to the design?
Actually, why do we need a console mod for dejitter? Can't it go in an external device connected on the multiout?

Aside from regulator, 15JU44 would need level shifters on both input and output and new programming file. Propagation delay would be much higher due to the shifters and the slower chip. Reading back sync would take more than 1 clock cycle from launch clock so I'm not sure how robust capturing would be timing-wise, all variation considered. Since the mod needs to drive master clock of the system to eliminate sync jitter, it can't just be passively in multi-out where it could only modify outgoing sync. At best it could there distribute jitter over multiple lines which might help with some displays but most likely not achieve compatibility equal to existing active mod.

I admit I had to look up what a CPLD was. So it uses HDL programming like FPGAs and thus an FGPA programmer would be comfortable using over a microprocessor. We need don't the parallelization that CPLDs and FPGAs offer here and detecting 4.7us sync pulses every other frame is not cutting edge tech. I'm confident sync de-jitter is doable using a cheap microprocessor when the ADC from a STM32 or PIC32 can sample over 1 Msps.

Switching to a microprocessor would make the dejitter fix more accessible when a) microprocessors are far more plentiful than CPLDs b) far more people know C or C++ than Verilog or VHDL.

I originally chose CPLD-based design as it was most clean and straightforward. You really need the parallelization for that kind of "simple" implementation (in terms of logic needed) - doing the same with MCU would require cycle-accurate code (Assembler instead of C/C++) and running it e.g. 4x the output frequency (it's supposed to generate gated/ungated clock signal, accumulate and compare all at the same time). You could always use somewhat different approach to overcome MCU limitations, but most likely that'd involve extra HW and/or added code complexity. Not all MCUs have very good availability either - just a while ago I had to pay over 10€ for a very basic ATMEGA32 which would be ridiculous in normal times.

[NewSchoolBoxer]

Thanks so much for your expert insight. Level shifting between 3.3V and 5V is a solved problem but I didn't consider the added propagation delay and no one is going to like the added cost. If the PCB has to change to use a pin-compatible CPLD, may as well consider non-compatible ones that run at 5V.

My idea on the multiout is comparable to what SamIAm suggested on page 1. Not an exact solution but could work well enough for most purposes. If it's been attempted, I don't see the details in this thread. I expect needing to output artificial black along with the artificial sync pulses that replace the jitter to preserve synchronization. Then it's a matter of how fast the device can switch back and forth between states. I don't have a concern with a typical MCU internal clock of 16 MHz, with over 100 MHz on the high end. Using the Master Clock generated with external crystal (or MEMS) simplifies the coding but I don't think is necessary on the multiout side.

A different approach with a microprocessor instead of a CPLD and no external timer, gives me something to do with my STM32 and MSP430 devkits. That's a good point that microprocessors having more availability than CPLDs is being overly broad. Not going to run out of PIC32s, but specific PIC32MX or PIC32MM models, happens. Cycle-accurate Assembler by NOPing each branch enough times so each possibility has consistent execution time, seems doable on paper. At least I did it in 8-bit PIC16 world that needs a subroutine for multiplication.

[marqs]

My idea on the multiout is comparable to what SamIAm suggested on page 1. Not an exact solution but could work well enough for most purposes. If it's been attempted, I don't see the details in this thread. I expect needing to output artificial black along with the artificial sync pulses that replace the jitter to preserve synchronization. Then it's a matter of how fast the device can switch back and forth between states. I don't have a concern with a typical MCU internal clock of 16 MHz, with over 100 MHz on the high end. Using the Master Clock generated with external crystal (or MEMS) simplifies the coding but I don't think is necessary on the multiout side.

It might make sense to first try clocking the MCU from console's master clock since that way you know how many cycles exactly are needed for each 240p frame output (e.g. 1363 for first 4 lines in every other frame, 1364 otherwise). Obviously you'd need to implement PAL/NTSC and noninterlace/interlace detection so that the number of cycles is always correct. More importantly, running synchronously to console makes sure sync can stay perfectly aligned to video, thus avoiding any microjitter. If you can get that working reliably, then you could try running MCU asynchronously.

[copy]

Where do you see a mid-October restock alert? I do see the pin-compatible 15JU44 has 98 units available but takes 3.3V instead of 5V, so won't work with the existing PCB even if being 44-LCC versus 44-TQFP isn't significant.

On the page for the ATF1502AS-7AX44, enter any number in the "quantity" box and it says: "SHIP DATE ESTIMATE: 10/14/2022"

https://www.digikey.com/en/products/det ... 44/1027047

You're emphasizing the usefulness of the $20/€20 dejitter mod that two popular devices benefit from: OSSC and HDRetrovision RGB->YPbPr cables. If you're like 99% of the population that won't solder, it's an extra $50/€50 fee for install before 2 way shipping. That's more than what the cables cost. I'm happy the mod was a lifesaver for you but would you have bought a RetroTINK or Framemeister instead if you knew your televisions didn't handle sync jitter?

I do solder. When I installed this mod the OSSC had fully replaced my Framemeister due to better picture quality and less lag. I did not want to go back to the Framemeister, and the RetroTINK-5X didn't exist yet. I still argue dejitter is worthy because it increases the chances of compatibility & good performance with future processors and displays which may or may not like uneven sync.

I would disagree that sync jitter is well discussed.

I was only replying to your comment "I think it's getting lost in the shuffle that the dejitter mod isn't needed for most scalers or any analog capture cards I'm aware of." Much of this was discussed in the early pages of this thread.

[nrq]

Hello,

got a weird problem with my dejitter modded Famicom. It has a HVC-CPU-07 board, the dejitter board was ordered in August 2020 from Videogameperfection with NES firmware and the installed NESRGB version is 2.0. So far everything worked fine, but I got a FDS RAM adapter recently and that doesn't seem to play nicely with the dejitter board installed. The RAM adapter alone works, I get the insert disk animation and it's playing its idle animation without problem, it's just when it boots from FDSStick the screen gets garbled as soon as there's disk access. I have two RAM adapters and this happens with both of them. I also have an unmodded AV Famicom that plays with both adapters. There's a bit of a convoluted explanation why I assume it's the dejitter mod, I'll spare you that and skip to the point where I disabled the mod and loading FDS software finally works. Is that a known issue? I googled up and down the past days and couldn't find anything regarding problems with FDS. Is there any way to keep the mod and still play FDS games via FDSStick/actual FDS?

[marqs]

Hello,

got a weird problem with my dejitter modded Famicom. It has a HVC-CPU-07 board, the dejitter board was ordered in August 2020 from Videogameperfection with NES firmware and the installed NESRGB version is 2.0. So far everything worked fine, but I got a FDS RAM adapter recently and that doesn't seem to play nicely with the dejitter board installed. The RAM adapter alone works, I get the insert disk animation and it's playing its idle animation without problem, it's just when it boots from FDSStick the screen gets garbled as soon as there's disk access. I have two RAM adapters and this happens with both of them. I also have an unmodded AV Famicom that plays with both adapters. There's a bit of a convoluted explanation why I assume it's the dejitter mod, I'll spare you that and skip to the point where I disabled the mod and loading FDS software finally works. Is that a known issue? I googled up and down the past days and couldn't find anything regarding problems with FDS. Is there any way to keep the mod and still play FDS games via FDSStick/actual FDS?

Looking at board pictures of the RAM adapter, RP2C33 is clocked by similar 21.47727MHz crystal as FC CPU and PPU. I don't know if it's just a coincidence or if there is some expected timing relationship between these 2 clocks (likely not since they are generated by separate xtals after all), but the latter case could definitely be problematic for the dejitter mod due to skipped cycles.

[nrq]

Looking at board pictures of the RAM adapter, RP2C33 is clocked by similar 21.47727MHz crystal as FC CPU and PPU. I don't know if it's just a coincidence or if there is some expected timing relationship between these 2 clocks (likely not since they are generated by separate xtals after all), but the latter case could definitely be problematic for the dejitter mod due to skipped cycles.

Thanks for looking into that issue. Reason I suspected the dejitter mod in the first place is that I also restored a Famicom "copier" over the past weeks that goes between the RAM adapter and the Famicom which also has its own timing crystal that's connected to a GAL on the cartridge bus and with it inserted I got a lot further on the FDS side, but everything ultimately crashes after a short while.

[marqs]

Thanks for looking into that issue. Reason I suspected the dejitter mod in the first place is that I also restored a Famicom "copier" over the past weeks that goes between the RAM adapter and the Famicom which also has its own timing crystal that's connected to a GAL on the cartridge bus and with it inserted I got a lot further on the FDS side, but everything ultimately crashes after a short while.

I'm not sure if clocking RP2C33 from dejitter board's MCLK_o would help, but since there are no unused cartridge port pins, it would be a cumbersome solution anyway.

[marqs]

Availability of the CPLD chip has improved lately so there should be some boards available in the coming months.

[marqs]

The board is finally back in stock at VGP.

[famiac]

I installed the board from VGP in my HVC-CPU-07 Famicom alongside the NESRGB hardware 1.4 it was running. The console is working fine after the install but i'm still geting flicker in that first scanline. (problem #2 from the first post of this thread)

is this normal behavior? Is the dejitter mod only supposed to fix sync timing?

I followed the install instructions correctly by removing the caps & crystal and soldering the jumper wire. I tried reflashing the cpld with the build from May 2018 but nothing changed. Using the latest firmware from the nes-fix branch on github caused the famicom to stop booting. I reverted to the May '18 build for now. Will try other builds tomorrow.

[marqs]

I installed the board from VGP in my HVC-CPU-07 Famicom alongside the NESRGB hardware 1.4 it was running. The console is working fine after the install but i'm still geting flicker in that first scanline. (problem #2 from the first post of this thread)

is this normal behavior? Is the dejitter mod only supposed to fix sync timing?

As the first post says, the mod is only able to fix problem #1.

I followed the install instructions correctly by removing the caps & crystal and soldering the jumper wire. I tried reflashing the cpld with the build from May 2018 but nothing changed. Using the latest firmware from the nes-fix branch on github caused the famicom to stop booting. I reverted to the May '18 build for now. Will try other builds tomorrow.

The recommendation is to use nes-fix branch for NES/FC since its IO timings are tweaked to be more suitable for those. The latest version should definitely work since the changes added by it (subcarrier output for cvbs/s-video encoding) were explicitly requested by a few people who then used it. Maybe something went wrong during programming - you could try it again. You can also flash a previous version from nes-fix branch which is essentially the same but without subcarrier output.

[famiac]

Thank you for the clarification. I was a bit confused because the Contra sample video shows problem 2 as being fixed. I assumed it was a demonstration of the mod.

Is there a known solution to problem #2?

[marqs]

Thank you for the clarification. I was a bit confused because the Contra sample video shows problem 2 as being fixed. I assumed it was a demonstration of the mod.

If you look closely the video, there is still jitter on very first scanline after enabling the mod.

Is there a known solution to problem #2?

Not with a simple mod like this. Most games do have content only on ~224 lines and it's not a big loss to mask the first line for those which use full 240.

[famiac]

If you look closely the video, there is still jitter on very first scanline after enabling the mod.

i see now. it wasn't obvious on my pc monitor but when i pause the video i notice the top row is shifting right and left between frames.

Most games do have content only on ~224 lines and it's not a big loss to mask the first line for those which use full 240.

Yep i agree not a big loss

[MaRCer]

Super Famicom 1Chip on Sony KDL-55w809c image twitches horizontally by several pixels - is this the same jitter?
https://kinescope.io/embed/1bc89d27-470 ... 7077fd6e3f

[marqs]

Super Famicom 1Chip on Sony KDL-55w809c image twitches horizontally by several pixels - is this the same jitter?
https://kinescope.io/embed/1bc89d27-470 ... 7077fd6e3f

If it only shows up with 240p while 480i (and presumably other 240p sources) work fine, then it's most likely due to the sync jitter.

[shiftednes]

I installed a dejitter mod to a 1-chip system a couple of years ago. The RGB output from it still works great. However, I hooked the system up using composite, to use the 240p test suite on a composite only CRT TV, and the output was black and white. Is this an effect of the dejitter mod or is there something else on the SNES that needs to be replaced? I have seen people mention that composite and s-video might have issues, but I have not seen anyone mention getting black and white output. The only mention I can find where someone was getting black and white output was from a stock system that still had the original crystal oscillator on it with a pot that could be adjusted. My system doesn't have that. All of my equipment and the SNES are NTSC. I have no PAL stuff at all.

[marqs]

I installed a dejitter mod to a 1-chip system a couple of years ago. The RGB output from it still works great. However, I hooked the system up using composite, to use the 240p test suite on a composite only CRT TV, and the output was black and white. Is this an effect of the dejitter mod or is there something else on the SNES that needs to be replaced? I have seen people mention that composite and s-video might have issues, but I have not seen anyone mention getting black and white output. The only mention I can find where someone was getting black and white output was from a stock system that still had the original crystal oscillator on it with a pot that could be adjusted. My system doesn't have that. All of my equipment and the SNES are NTSC. I have no PAL stuff at all.

The mod does have an effect on subcarrier generated by the console. A clean subcarrier is available on CPLD pin 11 which can be routed to replace existing subcarrier (specifics depend on the model).

[Freedy]

Hello!

I installed a borti SNES_MultiRegion_with_DeJitter_QID board but I am experiencing some strange behaviour.

First I closed the SJ63.2 jumper, but i experienced the strange colors on top of the screen with composite video
So I changed the jumper settings, to SJ63.1 closed, SJ63.2 open. Still getting the strange colors. Then I realised that I used the wrong files for the the CPLD(EPM7032AET), used the ones meant for the legacy boards, not for the newest ones which I have.
Reprogrammed with the newest version, but still no luck, colors are still distorted.

Other strange behaviour, somehow the region detection is mixed up. AUTO mode PAL cartridges are full screen, NTSC SFC cartridges are squished, like PAL games. Also, if I force the region to NTSC, with the L+R+SELECT+ A(red) button, the picture is squished, and woth the L+R+SELECT+ X(green) combination, the games are full screen.

Can you help me what to check where to look? I am a bit lost at this point.

Pictures about the installation.
https://imgur.com/a/X9BuLdY

(I'll tidy up some solder joints, shorten some wires later)

EDIT: One mistery is solved I think, I connected the lifted PPU2 pin30 and PPU1 PIN24 to /Vmode, instead of Vmode. I'll try to rewire it soon
EDIT2: region switching got sorted out, but the discoloration via composite video is still present unfortunately.
EDIT3: extra detail, the discoloration is only present in PAL mode.
EDIT4: I checked out the schematics, boardview, and the verilog code, I figured out, that for PAL dejitter is disabled, so it is expected that in case of PAL, does not matter if SJ63.1 or SJ63.2 is closed.
I saw a comment from borti in the verilog source, that "extended PAL base clock (21.28137MHz) for 3Chip consoles)"
This is a NTSC 3chip console, but for both ColorCarrier_opt_o and ColorCarrier_o output, in case of PAL mode, the base clock 17.734475 (PAL) is taken into account, not the "extended for 3chip consoles" regardless if the system is a 1chip or 3chip.

Is this expected? For MCLK_o the extended PAL clock is used, I wouldn't be surprised if this the expected working behaviour, that the extended PAL clock is not needed for the color carrier frequency, only for MCLK.o, but if that's the case, what is causing the discoloured picture in case of PAL mode?

EDIT5: yes, using 17.734475Mhz for pal color carrier frequency should be the right one, I have no idea why the colors are distorted then

[marqs]

I don't see how dejitter functionality could cause discoloration in PAL mode where it's disabled and sync & clocks should be as in vanilla PAL machine. Does it occur both in non-interlaced and interlaced PAL games (latter has sync jitter similar to NTSC 240p). Have you also tested composite with multiple displays?