NES/SNES 240p dejitter mod
NES/SNES 240p dejitter mod
NES and SNES are known to use slightly inconsistent scanline timing in their 240p output signals. 2C02 PPU in NTSC NES / Famicom nominally outputs 262 scanlines, each consisting of 1364 MCLK cycles which equals 341 PPU cycles (MCLK is divided by 4). However, length of the pre-render scanline (#14 after vsync) is 4 MCLK cycles shorter in certain circumstances - typically every other frame in most games with some exceptions like Battletoads (no short scanlines during game stages). Apparently the cycle skipping was designed to reduce composite video artifacts, but there's no reliable info (the fact that similar 2C03 "RGB-PPU" in PlayChoice 10 systems does not render short scanlines speaks for it, though). However, there are 2 issues with the implementation:
1. Horizontal sync pulses are not periodic, and frame time is not constant either
2. First visible scanline (#15) preceded by a short scanline is offset left by one dot since clipping of horizontal sync period is postponed to the end of the visible scanline. When short scanlines occur every other frame, pixels on the first visible scanline are jittery
In the days of CRT, those didn't cause really any problems. Slight sync jitter didn't disturb scanning, and first "visible" scanlines were masked by overscan, hiding any inconsistencies. However, with modern digital systems things are a bit different. PLLs in video digitizers use horizontal sync as their reference and assume it to be perfectly periodic. If not, sampling clock starts to jitter (typically stabilizes after a few equal-length scanlines) and PLL may lose its lock in the worst case. The problem is prone to get amplified in devices like OSSC which generate their output video clock directly from output of sampling PLL - even if that manages to keep its lock, resulting clock will be jittery and other PLLs/clock circuitry in the chain (e.g. in HDMI receiver) may not be able to cope with it. Even though 1/341th of a line does not sound much, it is enough to upset many TVs and video capture cards (PC displays seem to generally be more tolerant).
For some time I've had an idea for a small modification that compensates the skipped tick in time domain by gating system clock for equal amount of time (4 cycles). Since Nintendo's CPU/PPU should contain only static logic, gating the clock should be OK. I finally got around trying the idea last week on a Famicom + NESRGB combo. MCLK and CSYNC signals were routed to external FPGA which monitors timing and outputs gated clock "GCLK" and jitter-free CSYNC. That seemed to do the trick even though I only forwarded GCLK to PPU and NESRGB with CPU using the original clock for simplicity. In theory, CPU may try access PPU during those gated cycles (resulting to invalid read/write), so a more robust solution would also route GCLK to CPU. Ideally the logic (which is not much) would also be integrated on the CPLD on NESRGB board, so there would be no need for extra HW aside from a couple resistors and wires. The mod solves problem #1, but #2 still remains. Fixing the sync is probably enough for most people (who are fine with ignoring / masking the first visible scanline), but #2 could still be fixable on NESRGB via a line buffer or heuristics.
Below are timing diagrams illustrating the operation:
Normal scanline, 1364 MCLK cycles:
Short scanline, 1360 MCLK cycles. Activates nes_dejitter logic which gates clock for 4 cycles, normalizing horizontal sync period:
Sample videos (nes_jitter initially off, enabled after 3-5 seconds)
Grid
Timing info (if CPU was gated as well, there should be no difference as the mod should be completely transparent to the system then)
Contra (first row demonstrates problem #2)
I'll try the same mod on SNES next. Its PPU is similar so I see no reason why it would not work. The short scanline actually occurs deeper in vblank so problem #2 does not even exist with it. However, apparently its 576i mode uses long (1368-cycle) scanlines which can not be dejittered with this mod, leaving those few playing PAL interlaced games with the jittery sync.
Update 05/2018: Design files for an add-on board and installation instructions for several models are avaialble on Github. Pre-assembled boards are expected to be available on Videogameperfection.com sometime in June.
Update 07/2018: Pre-assembled boards are now available on Videogameperfection.com, both as standalone and with installation service.
1. Horizontal sync pulses are not periodic, and frame time is not constant either
2. First visible scanline (#15) preceded by a short scanline is offset left by one dot since clipping of horizontal sync period is postponed to the end of the visible scanline. When short scanlines occur every other frame, pixels on the first visible scanline are jittery
In the days of CRT, those didn't cause really any problems. Slight sync jitter didn't disturb scanning, and first "visible" scanlines were masked by overscan, hiding any inconsistencies. However, with modern digital systems things are a bit different. PLLs in video digitizers use horizontal sync as their reference and assume it to be perfectly periodic. If not, sampling clock starts to jitter (typically stabilizes after a few equal-length scanlines) and PLL may lose its lock in the worst case. The problem is prone to get amplified in devices like OSSC which generate their output video clock directly from output of sampling PLL - even if that manages to keep its lock, resulting clock will be jittery and other PLLs/clock circuitry in the chain (e.g. in HDMI receiver) may not be able to cope with it. Even though 1/341th of a line does not sound much, it is enough to upset many TVs and video capture cards (PC displays seem to generally be more tolerant).
For some time I've had an idea for a small modification that compensates the skipped tick in time domain by gating system clock for equal amount of time (4 cycles). Since Nintendo's CPU/PPU should contain only static logic, gating the clock should be OK. I finally got around trying the idea last week on a Famicom + NESRGB combo. MCLK and CSYNC signals were routed to external FPGA which monitors timing and outputs gated clock "GCLK" and jitter-free CSYNC. That seemed to do the trick even though I only forwarded GCLK to PPU and NESRGB with CPU using the original clock for simplicity. In theory, CPU may try access PPU during those gated cycles (resulting to invalid read/write), so a more robust solution would also route GCLK to CPU. Ideally the logic (which is not much) would also be integrated on the CPLD on NESRGB board, so there would be no need for extra HW aside from a couple resistors and wires. The mod solves problem #1, but #2 still remains. Fixing the sync is probably enough for most people (who are fine with ignoring / masking the first visible scanline), but #2 could still be fixable on NESRGB via a line buffer or heuristics.
Below are timing diagrams illustrating the operation:
Normal scanline, 1364 MCLK cycles:
Short scanline, 1360 MCLK cycles. Activates nes_dejitter logic which gates clock for 4 cycles, normalizing horizontal sync period:
Sample videos (nes_jitter initially off, enabled after 3-5 seconds)
Grid
Timing info (if CPU was gated as well, there should be no difference as the mod should be completely transparent to the system then)
Contra (first row demonstrates problem #2)
I'll try the same mod on SNES next. Its PPU is similar so I see no reason why it would not work. The short scanline actually occurs deeper in vblank so problem #2 does not even exist with it. However, apparently its 576i mode uses long (1368-cycle) scanlines which can not be dejittered with this mod, leaving those few playing PAL interlaced games with the jittery sync.
Update 05/2018: Design files for an add-on board and installation instructions for several models are avaialble on Github. Pre-assembled boards are expected to be available on Videogameperfection.com sometime in June.
Update 07/2018: Pre-assembled boards are now available on Videogameperfection.com, both as standalone and with installation service.
Last edited by marqs on Wed Jul 04, 2018 10:38 pm, edited 2 times in total.
-
citrus3000psi
- Posts: 668
- Joined: Wed Dec 25, 2013 11:56 pm
- Location: Indiana
Re: NES/SNES 240p dejitter mod
Amazing work, I’ll be watching this thread. Good stuff.
Re: NES/SNES 240p dejitter mod
Awesome work! I was actually just chatting with Ste of HD Rectalvision while you posted this and sent him over the link because I thought he would be interested. He said that he and Nick were working on a similar investigation early in the summer before they got derailed with YPbPr cable sales & support. Anyway he agrees with all the results, including the parts about how it’s due to non-constant timings instead of the common misconception of high vertical refresh rate and how PLLs lose lock in modern TVs. Additionally, he told me earlier in the year he mocked up an FPGA build which samples the CSYNC line at a very high-rate, analyzes it to find where the short-line is, and restructures/outputs a new sync pattern so that all the timing is equalized over consecutive frames. He only tried the fix with YPbPr inputs on problematic TVs (Vizio), but his intention was to implement this in their HDMIzer project to correct for NES/SNES problems as part of the decoding process. He mentioned he also gets distortion at the top of the screen on the rough build he had going, but might be able to do a better job distributing the timing to make it less noticeable. Anyway, he mentioned that this might be something which the OSSC might be able to handle on its own as a setting, instead of doing internal modifications on a per console basis.
Here is oscilloscope data he sent me which shows the short-line which occurs. The blue plot is the time discrepancy between lines. The big dip is where the current line is shorter than all the rest.
Here is oscilloscope data he sent me which shows the short-line which occurs. The blue plot is the time discrepancy between lines. The big dip is where the current line is shorter than all the rest.
Re: NES/SNES 240p dejitter mod
As far as I know, the NES' 6502 is a staight clone of the MOS 6502(*), so it's not really static and in fact has a minimum clock frequency (50 kHz) because it uses dynamic latches. The short time you need to adjust the line timing should be fully within specs though.marqs wrote:Since Nintendo's CPU/PPU should contain only static logic, gating the clock should be OK.
(*) except for five transistors which were omitted to disable decimal mode, avoiding MOS/Commodore's patent on it
GCVideo releases: https://github.com/ikorb/gcvideo/releases
Re: NES/SNES 240p dejitter mod
I'm so glad that this is being looked into. SNES/SFC jitters on my Ikegami monitor, and it's quite bothersome. I understand that it's a problem for some JVC monitors as well. As far as I know, all 240p SNES games have it.
One idea I've been concocting is to rig up an Arduino so that it runs on the SNES's master clock. Arduinos come with a 16MHz clock, but are apparently OK up to 22MHz. After being triggered to start by a vertical sync pulse (which could even come from an LM1881) it would generate its own sync, and it would make one line 1362 clocks every frame instead of alternating 1360 and 1364.
This would have the advantage of being less invasive and potentially more stable. However, your solution makes the timing truly correct, and it would allow the few games that use the interlaced mode to function properly as well. (Note that the interlaced mode does not have this timing problem.)
One idea I've been concocting is to rig up an Arduino so that it runs on the SNES's master clock. Arduinos come with a 16MHz clock, but are apparently OK up to 22MHz. After being triggered to start by a vertical sync pulse (which could even come from an LM1881) it would generate its own sync, and it would make one line 1362 clocks every frame instead of alternating 1360 and 1364.
This would have the advantage of being less invasive and potentially more stable. However, your solution makes the timing truly correct, and it would allow the few games that use the interlaced mode to function properly as well. (Note that the interlaced mode does not have this timing problem.)
Re: NES/SNES 240p dejitter mod
SamIAm:
Have you thought out the Arduino approach?
Before we start cutting traces, we should make sure this will be possible :p
Right now, I can't think of anything that would prohibit this.
I'd also look at Vsync and then generate my own Hsyncs for the next 240 lines.
Drift would be a concern but then again, it's only 240 lines until the next Vsync.
If we never miss a Vsync, this might work.
(This is still trying to work with a regular 16Mhz board / async from the SNES.)
Each generated line would have to be just a little shorter than the regular ones.
In PsNee, I've managed to sample a ~22kHz signal accurately.
Have you thought out the Arduino approach?
Before we start cutting traces, we should make sure this will be possible :p
Right now, I can't think of anything that would prohibit this.
I'd also look at Vsync and then generate my own Hsyncs for the next 240 lines.
Drift would be a concern but then again, it's only 240 lines until the next Vsync.
If we never miss a Vsync, this might work.
(This is still trying to work with a regular 16Mhz board / async from the SNES.)
Each generated line would have to be just a little shorter than the regular ones.
Or thisand it would make one line 1362 clocks every frame instead of alternating 1360 and 1364
In PsNee, I've managed to sample a ~22kHz signal accurately.
Re: NES/SNES 240p dejitter mod
Being able to use a 16MHz Arduino would mean we would have an external solution, which would be great, but there would probably be some issues. I think that the Vsync pulse itself is offset by the earlier Hsync pulse, and is effectively jittery, too. Also, an Arduino may not be able to sample the Vsync pulse accurately and consistently enough. This is why I was thinking that it would be better to have it run on the SNES master clock, detect only one Vsync pulse as a reference, then go off entirely on its own from there.
That still might not work, though. Converting that one line to 1362 clocks on every frame would have the effect of making the Hsyncs more stable, it's true, but the position of the color information on each line would shift every other frame. In other words, the whole screen might jitter.
Marq's idea of halting the whole production for the extra ticks really is much better. It's just a question of whether or not it ever causes problems in the SNES itself.
That still might not work, though. Converting that one line to 1362 clocks on every frame would have the effect of making the Hsyncs more stable, it's true, but the position of the color information on each line would shift every other frame. In other words, the whole screen might jitter.
Marq's idea of halting the whole production for the extra ticks really is much better. It's just a question of whether or not it ever causes problems in the SNES itself.
Re: NES/SNES 240p dejitter mod
This sounds like a trial and error thing. I like those ;p
It would be great to be able to do this with just an Arduino or similar.
Your SNES master clock suggestion sounds like a good starting point.
This site has good results up to 32Mhz: https://www.avrprogrammers.com/howto/max-speed
21.47Mhz should be good then!
There's a few other clocks available from PPU2 if need be.
For video timing, there are several timing signals. Unfortunately no separate H/V syncs but the blanks instead.
http://problemkaputt.de/fullsnes.htm#sn ... tsppuchips
It would be great to be able to do this with just an Arduino or similar.
Your SNES master clock suggestion sounds like a good starting point.
This site has good results up to 32Mhz: https://www.avrprogrammers.com/howto/max-speed
21.47Mhz should be good then!
There's a few other clocks available from PPU2 if need be.
For video timing, there are several timing signals. Unfortunately no separate H/V syncs but the blanks instead.
http://problemkaputt.de/fullsnes.htm#sn ... tsppuchips
Re: NES/SNES 240p dejitter mod
It's not doable on OSSC, since incoming sync is directly fed to the digitizer chip so FPGA cannot modify it.Voultar wrote:Anyway, he mentioned that this might be something which the OSSC might be able to handle on its own as a setting, instead of doing internal modifications on a per console basis.
Which SNES model is that capture from? It seems a bit different to my capture of SHVC-CPU-01 board below (no serration pulses, short line on 1st line after vsync).Voultar wrote:Here is oscilloscope data he sent me which shows the short-line which occurs. The blue plot is the time discrepancy between lines. The big dip is where the current line is shorter than all the rest.
Ah, I only recalled that earlier 6502 implementations used (pseudo) NMOS logic, but yes, they seemed to include dynamic logic as well.Unseen wrote:As far as I know, the NES' 6502 is a staight clone of the MOS 6502(*), so it's not really static and in fact has a minimum clock frequency (50 kHz) because it uses dynamic latches. The short time you need to adjust the line timing should be fully within specs though.
I initially thought about alleviating the scanline length discrepancy via external method as well, but it wouldn't remove the issue completely (should still make it compatible with all but most picky displays) and would not be as clean as the internal method.
I've now tested the mod with SNES and it seems to work just as well. Below is an overview pic which shows that short scanline is line #2 after vsync:
I've planned to next design a small adapter board for the mod which can be installed on (hopefully) various SNES motherboards. It'd include a CPLD and generate 21.477272MHz clock (via 3.579545MHz oscillator and PLL) autonomously instead of relying on SNES crystal and clock generation circuitry. That should help installation a bit, and also make 60Hz modded PAL consoles run at exact same refresh rate as NTSC machines.
Who said any traces need to be cut? I've now installed the mod on Famicom (with NESRGB) and SNES by just removing/rearranging a couple SMD parts on the boardrama wrote:Before we start cutting traces, we should make sure this will be possible :p
Re: NES/SNES 240p dejitter mod
Ste said that it's also an SHVC-CPU-01, but has a newer revision PPU2. Only the oldest revision of PPU2 has serration pulses, and actually causes lots of problems when interfacing into arcade CRTs. The blue plot in that image is a little confusing. Nick programmed it such that the blue data values display the time discrepancy between lines but plot the point at the beginning of the line which is being measured. So, therefore, that plot shows that the 2nd line after VSYNC is the short-line which matches your own data.marqs wrote:Which SNES model is that capture from? It seems a bit different to my capture of SHVC-CPU-01 board below (no serration pulses, short line on 1st line after vsync).
Re: NES/SNES 240p dejitter mod
Fantastic! It would be such a relief to have a fix for this.I've now tested the mod with SNES and it seems to work just as well.
Count me in as a potential buyer!
-
mikejmoffitt
- Posts: 629
- Joined: Fri Jan 08, 2016 7:26 am
- Location: Tokyo, Japan
Re: NES/SNES 240p dejitter mod
Nice mod to fix the classic jitter. Technically the NES PPU contains a little dynamic state (OAM data is known to decay without the refresh provided by the active display area) but for a few cycles this won't be problematic at all.
Re: NES/SNES 240p dejitter mod
I've now started design of a board which should be flexible yet as simple as possible. I selected Lattice ispMACH 4000ZE CPLD instead of modern alternatives (like MAX V) since it has easily solderable package, 5V tolerant inputs etc. benefits.
I couldn't find schematics for 1-CHIP / PAL SNES models, but apparenenly on PAL boards MCLK is generated by a PLL instead of an oscillator circuit. The mod board supports both oscillator and external clock configurations, and they can be both installed if dual-frequency configuration is desired. CSYNC output circuit is identical to the one found on early SNES revisions, so it should be compatible with various cables.
The preliminary schematic is available here - comments are welcome.
I couldn't find schematics for 1-CHIP / PAL SNES models, but apparenenly on PAL boards MCLK is generated by a PLL instead of an oscillator circuit. The mod board supports both oscillator and external clock configurations, and they can be both installed if dual-frequency configuration is desired. CSYNC output circuit is identical to the one found on early SNES revisions, so it should be compatible with various cables.
The preliminary schematic is available here - comments are welcome.
-
citrus3000psi
- Posts: 668
- Joined: Wed Dec 25, 2013 11:56 pm
- Location: Indiana
Re: NES/SNES 240p dejitter mod
Looks great. I have thoughts of combining this cpld and rgb bypass. My mini still needs a bypass board.marqs wrote:I've now started design of a board which should be flexible yet as simple as possible. I selected Lattice ispMACH 4000ZE CPLD instead of modern alternatives (like MAX V) since it has easily solderable package, 5V tolerant inputs etc. benefits.
I couldn't find schematics for 1-CHIP / PAL SNES models, but apparenenly on PAL boards MCLK is generated by a PLL instead of an oscillator circuit. The mod board supports both oscillator and external clock configurations, and they can be both installed if dual-frequency configuration is desired. CSYNC output circuit is identical to the one found on early SNES revisions, so it should be compatible with various cables.
The preliminary schematic is available here - comments are welcome.
Perhaps we could think of some cool IGR commands with the extro i/o.
Re: NES/SNES 240p dejitter mod
Sounds cool Marqs.
For my own learning, why are you using a crystal instead of an oscillator? This is my first time seeing a circuit like that where a crystal is connected to a CLK and GPIO. I have only seen crystals on things with a XI and XO pins. For CPLD and FPGA I have only seen oscillators used. I was under the impression a crystal takes specialized circuitry inside the IC to make it resonate; and oscillators are self resonating.
For my own learning, why are you using a crystal instead of an oscillator? This is my first time seeing a circuit like that where a crystal is connected to a CLK and GPIO. I have only seen crystals on things with a XI and XO pins. For CPLD and FPGA I have only seen oscillators used. I was under the impression a crystal takes specialized circuitry inside the IC to make it resonate; and oscillators are self resonating.
Re: NES/SNES 240p dejitter mod
What about the ATF15xx CPLD Family by microchip. It's a 5V operating chip. As programming environment you can use either WinCUPL or the Quartus II 13.0sp1 (latest version supporting Max7000 series) togehter with the programming files converting tool pof2jed.marqs wrote:I've now started design of a board which should be flexible yet as simple as possible. I selected Lattice ispMACH 4000ZE CPLD instead of modern alternatives (like MAX V) since it has easily solderable package, 5V tolerant inputs etc. benefits.
You won't find any schematics.marqs wrote:I couldn't find schematics for 1-CHIP / PAL SNES models, but apparenenly on PAL boards MCLK is generated by a PLL instead of an oscillator circuit.
Also regarding the PLL, here is my assumption:
Also a 1Chip NTSC uses the PLL for generating the MCLK. The configuration is done by the state on pin 111 of the S-CPUN (low -> NTSC -> clock multiplier 1 | high -> PAL -> clock multiplier 6/5). That's why one has to change the clock in on pin 9 for NTSC/PAL multinorm mods.
In a small CPLD you can include also other things: controller sniffing (IGR commands), region patching, glitch free clock switching for 1Chip multiregion mods, satellaview modem emulationcitrus3000psi wrote: Looks great. I have thoughts of combining this cpld and rgb bypass. My mini still needs a bypass board.
Perhaps we could think of some cool IGR commands with the extro i/o.
Re: NES/SNES 240p dejitter mod
I initially planned to use an oscillator, but 21.477272MHz ones are not available as far as I checked. Then I though about using a widely available 3.579545MHz oscillator and PLL (e.g. 501MLFT) for 6x multiplication. However, that would mean some extra components (PLLs unfortunately are not integrated on CPLDs, especially low-end ones), so I started looking for other solutions. A crystal can be used with normal GPIO pins with some caveats - here's a good application note from Lattice. 21.477272MHz crystals are not the most common, but I found them stocked on Mouser and it is also possible to snatch the one from target SNES/NES board (NTSC only) as well or alternatively connect console's oscillation circuit output to MCLK_EXT input (if dual-freq is not required).becker wrote:For my own learning, why are you using a crystal instead of an oscillator? This is my first time seeing a circuit like that where a crystal is connected to a CLK and GPIO. I have only seen crystals on things with a XI and XO pins. For CPLD and FPGA I have only seen oscillators used. I was under the impression a crystal takes specialized circuitry inside the IC to make it resonate; and oscillators are self resonating.
Thanks for the tip! ATF1502AS seems like a great candidate as its core & I/O are 5V, thus removing need for regulators.borti4938 wrote:What about the ATF15xx CPLD Family by microchip. It's a 5V operating chip. As programming environment you can use either WinCUPL or the Quartus II 13.0sp1 (latest version supporting Max7000 series) togehter with the programming files converting tool pof2jed.
Hmm, PAL consoles (using original crystal) should then be compatible with the proposed add-on board if PLL output is wired to MCLK_EXT and 21.477272MHz crystal is installed on its slot. Pin 111 of S-CPUN would select the correct clock when connected to CLK_SEL.borti4938 wrote:You won't find any schematics.
Also regarding the PLL, here is my assumption:
Also a 1Chip NTSC uses the PLL for generating the MCLK. The configuration is done by the state on pin 111 of the S-CPUN (low -> NTSC -> clock multiplier 1 | high -> PAL -> clock multiplier 6/5). That's why one has to change the clock in on pin 9 for NTSC/PAL multinorm mods.
Re: NES/SNES 240p dejitter mod
I have an Ikegami monitor too, but haven't really noticed it, are you using RGB cables?SamIAm wrote:I'm so glad that this is being looked into. SNES/SFC jitters on my Ikegami monitor, and it's quite bothersome.
I didn't even know about jitters, apparently it's when the picture/scanlines is non-stable, see:
Re: NES/SNES 240p dejitter mod
When will this be available? I will definitely take one
Re: NES/SNES 240p dejitter mod
An updated schematic with ATF1502AS is online. Altera/Atmel toolchain seemed to work ok, but ATMISP programming SW didn't recognize my generic FT2232 programmer. Maybe I just need to spoof its USB VID/PID since the official ATDH1150USB programmer seems to be FT2232-based as well.
Quite soon, the proposed design above just needs to made into a PCB and tested.LDigital wrote:When will this be available? I will definitely take one
Re: NES/SNES 240p dejitter mod
Might something like micro's Dual Frequency Oscillator project be of help?:-marqs wrote:I initially planned to use an oscillator, but 21.477272MHz ones are not available as far as I checked. Then I though about using a widely available 3.579545MHz oscillator and PLL (e.g. 501MLFT) for 6x multiplication. However, that would mean some extra components (PLLs unfortunately are not integrated on CPLDs, especially low-end ones), so I started looking for other solutions. A crystal can be used with normal GPIO pins with some caveats - here's a good application note from Lattice. 21.477272MHz crystals are not the most common, but I found them stocked on Mouser and it is also possible to snatch the one from target SNES/NES board (NTSC only) as well or alternatively connect console's oscillation circuit output to MCLK_EXT input (if dual-freq is not required).
https://nfggames.com/forum2/index.php?topic=5744.0
Re: NES/SNES 240p dejitter mod
That is one way of creating the clocks, but it'd need quite a few components and programming of one additional chip. I'd guess majority of potential users of this mod are fine with just a single clock, and those who need dual-frequency are usually owners of PAL SNES with 21.28137MHz clock already available on console PCB. The board is still compatible with DFO mod for those who have it, but its native dual-frequency support is a good alternative for people requiring it (unless they have a NTSC console).Link83 wrote:Might something like micro's Dual Frequency Oscillator project be of help?:-marqs wrote:I initially planned to use an oscillator, but 21.477272MHz ones are not available as far as I checked. Then I though about using a widely available 3.579545MHz oscillator and PLL (e.g. 501MLFT) for 6x multiplication. However, that would mean some extra components (PLLs unfortunately are not integrated on CPLDs, especially low-end ones), so I started looking for other solutions. A crystal can be used with normal GPIO pins with some caveats - here's a good application note from Lattice. 21.477272MHz crystals are not the most common, but I found them stocked on Mouser and it is also possible to snatch the one from target SNES/NES board (NTSC only) as well or alternatively connect console's oscillation circuit output to MCLK_EXT input (if dual-freq is not required).
https://nfggames.com/forum2/index.php?topic=5744.0
Re: NES/SNES 240p dejitter mod
Are you planning to put everything open source?
Personally I would love to include the dejitter mod into the multiregion mod by putting clock selecting, region bit patching and optionally controller sniffing in the CPLD. This will save a lot of ICs.
Personally I would love to include the dejitter mod into the multiregion mod by putting clock selecting, region bit patching and optionally controller sniffing in the CPLD. This will save a lot of ICs.
Re: NES/SNES 240p dejitter mod
Yes, the design will be open-source with a permissive license. I'm also hoping Tim will make an alternative NESRGB firmware with the dejitter logic which would remove the need for additional hardware with NES/FC.borti4938 wrote:Are you planning to put everything open source?
Personally I would love to include the dejitter mod into the multiregion mod by putting clock selecting, region bit patching and optionally controller sniffing in the CPLD. This will save a lot of ICs.
Re: NES/SNES 240p dejitter mod
First PCB design finished and ordered:
Next up is putting project files and instructions together while waiting for the boards to arrive.
Next up is putting project files and instructions together while waiting for the boards to arrive.
-
- Posts: 7681
- Joined: Wed Jan 26, 2005 1:28 am
- Location: Bedford, UK
- Contact:
Re: NES/SNES 240p dejitter mod
Will this product turn a SNES RGB output into a Genesis one?
This industry has become 2 dimensional as it transcended into a 3D world.
Re: NES/SNES 240p dejitter mod
So there is no need to do this mod for the people that use a CRT, right?marqs wrote:In the days of CRT, those didn't cause really any problems.
Re: NES/SNES 240p dejitter mod
???neorichieb1971 wrote:Will this product turn a SNES RGB output into a Genesis one?
Re: NES/SNES 240p dejitter mod
The Composite Video look of such a modified console is a bit hard to predict. We will have to wait for some pictures / videos.
It will definitely look different but most likely not like a Genesis, especially regarding any rainbow banding.
It will definitely look different but most likely not like a Genesis, especially regarding any rainbow banding.
-
- Posts: 7681
- Joined: Wed Jan 26, 2005 1:28 am
- Location: Bedford, UK
- Contact:
Re: NES/SNES 240p dejitter mod
In regards to the OSSC. Will this mod bring compatibility levels up to the Megadrive/Genesis level? Some TV's can only display SNES/NES to x2 where as the Sega consoles can go up to x5. If you did this mod would your OSSC to TV compatibility also be able to reach x5?ApolloBoy wrote:???neorichieb1971 wrote:Will this product turn a SNES RGB output into a Genesis one?
This industry has become 2 dimensional as it transcended into a 3D world.