It works. I have a 3-Chip PAL SNES with a partially broken S-CLK that doesn't provide a 21MHz output anymore, so I lifted pin 4 of it and fed the system with a DFO instead. Haven't encountered any issues yet.marqs wrote:but I see no reason why you couldn't bypass S-CLK and generate suitable clock elsewhere. I can't confirm this as I don't have a PAL 3-chip or its schematic here but it probably doesn't take long until someone tries it.
NES/SNES 240p dejitter mod
Re: NES/SNES 240p dejitter mod
GCVideo releases: https://github.com/ikorb/gcvideo/releases
Re: NES/SNES 240p dejitter mod
Right, he didn't state it was impossible, but to make it switchable seemed to be a particular challenge.marqs wrote:Perhaps you misunderstood his post - it's not possible with a simple crystal swap but I see no reason why you couldn't bypass S-CLK and generate suitable clock elsewhere. I can't confirm this as I don't have a PAL 3-chip or its schematic here but it probably doesn't take long until someone tries it.Harrumph wrote:Am I reading this right? True 60.09Hz on a PAL 3-chip?! Borti wrote on assembler forums about a year ago that this might never be possible. https://assemblergames.com/threads/pal- ... tor.65575/
Really awesome if this is truly fixed now!
Anyway, I was a bit confused and didn't realise S-CLK is a discreet chip on the PAL board. I took a look at the schematics available for PAL and NTSC SNES, so I am now a bit more familiar with the differences.
Can I perhaps hope that Borti is looking into a new revision of SuperCIC PCB for 3-chips that include the dejitter mod and can bypass the S-CLK for 60Hz mode? I am not knowledgable or skilled enough to come up with a solution on my own...
Re: NES/SNES 240p dejitter mod
@Unseen:
What about the composite video? I was experiencing some artefacts on my experiment where I multiplexed the color carrier to the S-ENC with two crystals (i.e. not derived from the MCLK).
@Harrumph:
At the moment I don't have the time to refactor the modding kit, now. However, I do have the plan to inlcude misc function into a CPLD or even a small cheap FPGA (Lattice have some nice) incl. all the stuff discussed here. This allows me to get rid of the large amount of ICs. Also I want to split the function of the IGR, where some parts go into the SuperCIC and some into the CPLD/FPGA.
Everything is just in my brain now and coarse ideas...
But don't count on that within the next few month. At the moment my main focus is on the N64A progress.
What about the composite video? I was experiencing some artefacts on my experiment where I multiplexed the color carrier to the S-ENC with two crystals (i.e. not derived from the MCLK).
@Harrumph:
At the moment I don't have the time to refactor the modding kit, now. However, I do have the plan to inlcude misc function into a CPLD or even a small cheap FPGA (Lattice have some nice) incl. all the stuff discussed here. This allows me to get rid of the large amount of ICs. Also I want to split the function of the IGR, where some parts go into the SuperCIC and some into the CPLD/FPGA.
Everything is just in my brain now and coarse ideas...
But don't count on that within the next few month. At the moment my main focus is on the N64A progress.
Re: NES/SNES 240p dejitter mod
Looks ok (for composite) to me in 50Hz mode, but I get a slowly moving interference pattern on the color bleed check in the 240p test suite when I switch to 60Hz.borti4938 wrote:What about the composite video? I was experiencing some artefacts on my experiment where I multiplexed the color carrier to the S-ENC with two crystals (i.e. not derived from the MCLK).
The motion speed and direction of the interference pattern can be influenced by touching either of the two crystals (i.e. changing their temperature), so it's very like an artifact caused by using non-synchronized clocks.
GCVideo releases: https://github.com/ikorb/gcvideo/releases
Re: NES/SNES 240p dejitter mod
Just an idea:
Remove X1 and then use the DFO to switch the S-CLK input between ~17.734MHz in PAL and ~17.898 in NTSC.
For Composite Video: lifting pin 6 of S-CLK and switching output of pin 6 S-CLK (PAL) and pin 3 S-PPU2 (NTSC) with a small logic to pad 6 of S-CLK.
Remove X1 and then use the DFO to switch the S-CLK input between ~17.734MHz in PAL and ~17.898 in NTSC.
For Composite Video: lifting pin 6 of S-CLK and switching output of pin 6 S-CLK (PAL) and pin 3 S-PPU2 (NTSC) with a small logic to pad 6 of S-CLK.
Re: NES/SNES 240p dejitter mod
That could work, but I can't test it on my system.borti4938 wrote:Remove X1 and then use the DFO to switch the S-CLK input between ~17.734MHz in PAL and ~17.898 in NTSC.
Is the phase shift network between the S-CLK and S-ENC identical in PAL and NTSC consoles?For Composite Video: lifting pin 6 of S-CLK and switching output of pin 6 S-CLK (PAL) and pin 3 S-PPU2 (NTSC) with a small logic to pad 6 of S-CLK.
GCVideo releases: https://github.com/ikorb/gcvideo/releases
Re: NES/SNES 240p dejitter mod
Not sure if the circuit is identical. But I've tested it maybe two years ago and it worked quite well, dispite of the few kHz shift in NTSC mode due to the PAL clock reference.
Re: NES/SNES 240p dejitter mod
I wouldn't mind trying that actually, but unfortunately VGP only have the 3.3V version. Well, actually they are out of stock anyway...borti4938 wrote:Just an idea:
Remove X1 and then use the DFO to switch the S-CLK input between ~17.734MHz in PAL and ~17.898 in NTSC.
-
citrus3000psi
- Posts: 668
- Joined: Wed Dec 25, 2013 11:56 pm
- Location: Indiana
Re: NES/SNES 240p dejitter mod
I wanted to make sure I'm reading the schematics correctly.
On an NTSC machine I can feed the MCLK_EXT_i a 21.477272 clock from S-CLK. And since I'm using the machines consoles own clock I don't need to route GClk_o back to anything.
And MCLK_SEL_i should be pulled high.
On an NTSC machine I can feed the MCLK_EXT_i a 21.477272 clock from S-CLK. And since I'm using the machines consoles own clock I don't need to route GClk_o back to anything.
And MCLK_SEL_i should be pulled high.
Re: NES/SNES 240p dejitter mod
MCLK_EXT_i is primarily for PAL-mode clock, which is automatically selected if you wire CLK_SEL input from 50/60Hz switches etc. mod that provides the selection signal. For a pure NTSC console, you should leave MCLK_EXT_i and CLK_SEL pins open as the board itself generates NTSC-mode clock and uses it by default. GCLK_o must be always connected as it is the dynamically gated clock that drives logic.citrus3000psi wrote:I wanted to make sure I'm reading the schematics correctly.
On an NTSC machine I can feed the MCLK_EXT_i a 21.477272 clock from S-CLK. And since I'm using the machines consoles own clock I don't need to route GClk_o back to anything.
And MCLK_SEL_i should be pulled high.
-
citrus3000psi
- Posts: 668
- Joined: Wed Dec 25, 2013 11:56 pm
- Location: Indiana
Re: NES/SNES 240p dejitter mod
Thanks for the clarification!marqs wrote:MCLK_EXT_i is primarily for PAL-mode clock, which is automatically selected if you wire CLK_SEL input from 50/60Hz switches etc. mod that provides the selection signal. For a pure NTSC console, you should leave MCLK_EXT_i and CLK_SEL pins open as the board itself generates NTSC-mode clock and uses it by default. GCLK_o must be always connected as it is the dynamically gated clock that drives logic.citrus3000psi wrote:I wanted to make sure I'm reading the schematics correctly.
On an NTSC machine I can feed the MCLK_EXT_i a 21.477272 clock from S-CLK. And since I'm using the machines consoles own clock I don't need to route GClk_o back to anything.
And MCLK_SEL_i should be pulled high.
Re: NES/SNES 240p dejitter mod
Hi, this sounds like an awesome mod. But I do have some questions:
1) Does the board allow for the behaviour to be turned off with a switch if you don't want it?
I know this might sound like an odd question, because why on earth would you *want* that extra PPU cycle, with all problems it can bring on some displays?
Well, the thing is (and this is probably irrelevant to 99.999% of the people who want to just play games) - Blargg's nmi_sync library allows sync:ing the CPU to the PPU as exactly as possible: 1 pixel jitter on NTSC, and 1.5 pixel jitter on PAL:
http://wiki.nesdev.com/w/index.php/Cons ... ronization
The long-winded explanation is for PAL only, but the same principle applies in the NTSC case. And I believe the library itself uses the shorter frame to make the remaining jitter on NTSC be just one pixel.
Blargg's library enables new awesome uses of the PPU that I hope will show themselves in homebrew software eventually. I'm not sure what would happen if every frame is the same length, but I presume that the code would basically revert to the PAL case of a slightly bigger jitter of 1-2 pixels. And it'd be a shame to totally lose that "feature" of 1 pixel less jitter on an NTSC NES...
2) And speaking of losing features, I think Tim's NESRGB board is a great mod that I'm happy with overall, but it does have a bug that would be worth fixing if the hardware is being upgraded anyway: http://forums.nesdev.com/viewtopic.php? ... lit=NESRGB
Again, no commercial games would be affected. But for a homebrewn NES game I'm developing I've coded a pretty neat water effect that spends 2 scanlines to rewrite the entire palette to look more blue. Rewriting the palette requires turning off rendering, and in order to not get the rainbow colour effect I also set the monochrome bit to displays some grays and whites during these writes. The result is a sort-of-believable shimmering water surface of whites'n'grays on a CRT, and on the Hidef NES (which correctly emulates the PPU quirk of displaying the palette colour during palette writes)
But on Tim's NES RGB my water surface shows up as black instead, which is kind of ugly.
If my homebrew game ever gets released, I won't let the NES RGB stand in the way of the nice-looking water, and would just tell NESRGB owners to switch to composite, or just squint and pretend that the water surface looks white. ...but it would be great if this bug could be fixed in a new revision.
3) Last, just a personal question on why my setup behaves weirdly: I have an OSSC and a PAL 1chip SNES modded with the SuperCIC mod. The SNES keeps losing the picture on my HDTV in 60Hz, but is fine in 50Hz. I know the most plausible reason is that shorter scanline, which this mod would fix.
But the odd thing is that my NES (which has Tim's RGB mod) runs at the same 60.08Hz frequency, has the same shorter scanline as the SNES, and should suffer from the same problem. But curiously, it delivers where the SNES fails and never seems to lose picture with my HDTV.
So I am quite surprised that one system works perfectly with my HDTV but not the other. Does anyone have any thoughts on why?
1) Does the board allow for the behaviour to be turned off with a switch if you don't want it?
I know this might sound like an odd question, because why on earth would you *want* that extra PPU cycle, with all problems it can bring on some displays?
Well, the thing is (and this is probably irrelevant to 99.999% of the people who want to just play games) - Blargg's nmi_sync library allows sync:ing the CPU to the PPU as exactly as possible: 1 pixel jitter on NTSC, and 1.5 pixel jitter on PAL:
http://wiki.nesdev.com/w/index.php/Cons ... ronization
The long-winded explanation is for PAL only, but the same principle applies in the NTSC case. And I believe the library itself uses the shorter frame to make the remaining jitter on NTSC be just one pixel.
Blargg's library enables new awesome uses of the PPU that I hope will show themselves in homebrew software eventually. I'm not sure what would happen if every frame is the same length, but I presume that the code would basically revert to the PAL case of a slightly bigger jitter of 1-2 pixels. And it'd be a shame to totally lose that "feature" of 1 pixel less jitter on an NTSC NES...
2) And speaking of losing features, I think Tim's NESRGB board is a great mod that I'm happy with overall, but it does have a bug that would be worth fixing if the hardware is being upgraded anyway: http://forums.nesdev.com/viewtopic.php? ... lit=NESRGB
Again, no commercial games would be affected. But for a homebrewn NES game I'm developing I've coded a pretty neat water effect that spends 2 scanlines to rewrite the entire palette to look more blue. Rewriting the palette requires turning off rendering, and in order to not get the rainbow colour effect I also set the monochrome bit to displays some grays and whites during these writes. The result is a sort-of-believable shimmering water surface of whites'n'grays on a CRT, and on the Hidef NES (which correctly emulates the PPU quirk of displaying the palette colour during palette writes)
But on Tim's NES RGB my water surface shows up as black instead, which is kind of ugly.
If my homebrew game ever gets released, I won't let the NES RGB stand in the way of the nice-looking water, and would just tell NESRGB owners to switch to composite, or just squint and pretend that the water surface looks white. ...but it would be great if this bug could be fixed in a new revision.
3) Last, just a personal question on why my setup behaves weirdly: I have an OSSC and a PAL 1chip SNES modded with the SuperCIC mod. The SNES keeps losing the picture on my HDTV in 60Hz, but is fine in 50Hz. I know the most plausible reason is that shorter scanline, which this mod would fix.
But the odd thing is that my NES (which has Tim's RGB mod) runs at the same 60.08Hz frequency, has the same shorter scanline as the SNES, and should suffer from the same problem. But curiously, it delivers where the SNES fails and never seems to lose picture with my HDTV.
So I am quite surprised that one system works perfectly with my HDTV but not the other. Does anyone have any thoughts on why?
Re: NES/SNES 240p dejitter mod
The mod doesn't change clock relationship between CPU and PPU if their clock is derived from the same output (unlike OP video that was for PPU only). Current board revision does not have an "off" option, but with NES you could use clock selection (NTSC/PAL) pin for that.Bananmos wrote:1) Does the board allow for the behaviour to be turned off with a switch if you don't want it?
I know this might sound like an odd question, because why on earth would you *want* that extra PPU cycle, with all problems it can bring on some displays?
Well, the thing is (and this is probably irrelevant to 99.999% of the people who want to just play games) - Blargg's nmi_sync library allows sync:ing the CPU to the PPU as exactly as possible: 1 pixel jitter on NTSC, and 1.5 pixel jitter on PAL:
http://wiki.nesdev.com/w/index.php/Cons ... ronization
The long-winded explanation is for PAL only, but the same principle applies in the NTSC case. And I believe the library itself uses the shorter frame to make the remaining jitter on NTSC be just one pixel.
Blargg's library enables new awesome uses of the PPU that I hope will show themselves in homebrew software eventually. I'm not sure what would happen if every frame is the same length, but I presume that the code would basically revert to the PAL case of a slightly bigger jitter of 1-2 pixels. And it'd be a shame to totally lose that "feature" of 1 pixel less jitter on an NTSC NES...
If any effect relies on how composite signal is affected by the short scanline, then yes, that doesn't work. Your described issue with NESRGB is different, though.Bananmos wrote:2) And speaking of losing features, I think Tim's NESRGB board is a great mod that I'm happy with overall, but it does have a bug that would be worth fixing if the hardware is being upgraded anyway: http://forums.nesdev.com/viewtopic.php? ... lit=NESRGB
Again, no commercial games would be affected. But for a homebrewn NES game I'm developing I've coded a pretty neat water effect that spends 2 scanlines to rewrite the entire palette to look more blue. Rewriting the palette requires turning off rendering, and in order to not get the rainbow colour effect I also set the monochrome bit to displays some grays and whites during these writes. The result is a sort-of-believable shimmering water surface of whites'n'grays on a CRT, and on the Hidef NES (which correctly emulates the PPU quirk of displaying the palette colour during palette writes)
But on Tim's NES RGB my water surface shows up as black instead, which is kind of ugly.
If my homebrew game ever gets released, I won't let the NES RGB stand in the way of the nice-looking water, and would just tell NESRGB owners to switch to composite, or just squint and pretend that the water surface looks white. ...but it would be great if this bug could be fixed in a new revision.
With SNES, the short scanline is shortly after VSYNC which is even worse for the digitizer. At that point its PLL is still recovering from coast (where it basically runs without hsync reference while vsync is active), and then suddenly hsync period gets shorter. I assume you have coast values at defaults (1/0) which is pretty much required for SNES, while other systems (including NES) typically work with general recommendation of 3/3.Bananmos wrote:3) Last, just a personal question on why my setup behaves weirdly: I have an OSSC and a PAL 1chip SNES modded with the SuperCIC mod. The SNES keeps losing the picture on my HDTV in 60Hz, but is fine in 50Hz. I know the most plausible reason is that shorter scanline, which this mod would fix.
But the odd thing is that my NES (which has Tim's RGB mod) runs at the same 60.08Hz frequency, has the same shorter scanline as the SNES, and should suffer from the same problem. But curiously, it delivers where the SNES fails and never seems to lose picture with my HDTV.
So I am quite surprised that one system works perfectly with my HDTV but not the other. Does anyone have any thoughts on why?
Re: NES/SNES 240p dejitter mod
Thanks for your reply marqs!
The incorrect behaviour during palette updates is an issue I'd really like to see fixed in the NESRGB solution if possible. Though I suspect it might not be feasible with the current wirings...
One last thought though: I don't quite understand why this issue couldn't be rectified by the OSSC itself, with no need for hardware modding? If the output clock rate could be set to run at 2x the PPU pixel clock, then the length of odd/even frames would be frame_clocks,frame_clocks+2,frame_clocks,frame_clocks,... and so on. So why couldn't the OSSC buffer just buffer an extra PPU pixel clock, delay the signal and output a consistent frame_clocks+1 (equivalent to PPU_clocks_in_a_frame+0.5).
I'm feeling my simple idea must be missing some fundamental limitation, but I'm not sure what... except that it would obviously complicate the FPGA implementation, just to support two very quirky consoles.
Ah, right... read it more carefully now, and as you are gating the main ~21MHz before it even goes into the CPU/PPU, like you say everything should stay the same with no changes to the video signal vs CPU alignment. No need for any "off" switch then.... neat solution!The mod doesn't change clock relationship between CPU and PPU if their clock is derived from the same output (unlike OP video that was for PPU only). Current board revision does not have an "off" option, but with NES you could use clock selection (NTSC/PAL) pin for that.
Yes, sorry for derailing the topic a bit. Indeed it has nothing to do with this hardware mod but just the NESRGB itself, and was directed to Tim. I only brought it up because I saw Tim was posting here, and that there was talk about patching the NESRGB mod to include this mod.If any effect relies on how composite signal is affected by the short scanline, then yes, that doesn't work. Your described issue with NESRGB is different, though.
The incorrect behaviour during palette updates is an issue I'd really like to see fixed in the NESRGB solution if possible. Though I suspect it might not be feasible with the current wirings...
Ah, that explains why the SNES fares worse then. I do have those values set to the defaults, and I guess I'm pretty convinced this mod would fix it. So when will pre-orders be available?With SNES, the short scanline is shortly after VSYNC which is even worse for the digitizer. At that point its PLL is still recovering from coast (where it basically runs without hsync reference while vsync is active), and then suddenly hsync period gets shorter. I assume you have coast values at defaults (1/0) which is pretty much required for SNES, while other systems (including NES) typically work with general recommendation of 3/3.
One last thought though: I don't quite understand why this issue couldn't be rectified by the OSSC itself, with no need for hardware modding? If the output clock rate could be set to run at 2x the PPU pixel clock, then the length of odd/even frames would be frame_clocks,frame_clocks+2,frame_clocks,frame_clocks,... and so on. So why couldn't the OSSC buffer just buffer an extra PPU pixel clock, delay the signal and output a consistent frame_clocks+1 (equivalent to PPU_clocks_in_a_frame+0.5).
I'm feeling my simple idea must be missing some fundamental limitation, but I'm not sure what... except that it would obviously complicate the FPGA implementation, just to support two very quirky consoles.
Re: NES/SNES 240p dejitter mod
First of all I'd like to thank you Marqs for all of the hard work you've done with the OSSC and this dejitter mod. Last month I built an OSSC which is brilliant, and yesterday I put together and programmed a couple of these dejitter boards for my Snes and Super Famicom. I've got one of them installed in my Super Famicom, a CPU-01 board, but I was wondering if there were any updates on the installation instructions for 1CHIP Snes models. My Snes is a 1CHIP, and I would love to get the dejitter board working on it too.
plus ça change,
plus c'est la même chose,
The more that things change,
The more they stay the same.- RUSH- Circumstances
I install and sell mods at arthrimus.com | SNES RGB Bypass+Dejitter available now! | Watch me live stream my work on YouTube
plus c'est la même chose,
The more that things change,
The more they stay the same.- RUSH- Circumstances
I install and sell mods at arthrimus.com | SNES RGB Bypass+Dejitter available now! | Watch me live stream my work on YouTube
Re: NES/SNES 240p dejitter mod
hello PLEASE can you explain how i have to do this mod? my s.clk chip is dead hot and my snes is black screen, please help me thanksUnseen wrote:It works. I have a 3-Chip PAL SNES with a partially broken S-CLK that doesn't provide a 21MHz output anymore, so I lifted pin 4 of it and fed the system with a DFO instead. Haven't encountered any issues yet.marqs wrote:but I see no reason why you couldn't bypass S-CLK and generate suitable clock elsewhere. I can't confirm this as I don't have a PAL 3-chip or its schematic here but it probably doesn't take long until someone tries it.
Re: NES/SNES 240p dejitter mod
If your S-CLK chip gets very hot, it is completely dead and you need a new one.Arnold101 wrote:hello PLEASE can you explain how i have to do this mod? my s.clk chip is dead hot
GCVideo releases: https://github.com/ikorb/gcvideo/releases
Re: NES/SNES 240p dejitter mod
you know where to find it?Unseen wrote:If your S-CLK chip gets very hot, it is completely dead and you need a new one.Arnold101 wrote:hello PLEASE can you explain how i have to do this mod? my s.clk chip is dead hot
also you have modded yours to give the 21mhz clock externaly, how you do it? i can do the same?
Re: NES/SNES 240p dejitter mod
Edit: Posting deleted. Spamming me with a PM pointing back to a forum thread means you don't get any help from me.
Last edited by Unseen on Thu Apr 05, 2018 8:21 pm, edited 1 time in total.
GCVideo releases: https://github.com/ikorb/gcvideo/releases
Re: NES/SNES 240p dejitter mod
FPGA pixel/processing clock on OSSC is directly derived from output clock of digitizer chip (which generates it from hsync) so if jitter is present on it, there's not much FPGA can do about it.Bananmos wrote:One last thought though: I don't quite understand why this issue couldn't be rectified by the OSSC itself, with no need for hardware modding? If the output clock rate could be set to run at 2x the PPU pixel clock, then the length of odd/even frames would be frame_clocks,frame_clocks+2,frame_clocks,frame_clocks,... and so on. So why couldn't the OSSC buffer just buffer an extra PPU pixel clock, delay the signal and output a consistent frame_clocks+1 (equivalent to PPU_clocks_in_a_frame+0.5).
I'm feeling my simple idea must be missing some fundamental limitation, but I'm not sure what... except that it would obviously complicate the FPGA implementation, just to support two very quirky consoles.
I just updated general instruction/description a few days ago, but still waiting to receive more reports/pictures on 1-CHIP installations. For 1-CHIP, you basically need to first remove its existing crystal (X1) and its load capacitors from the board, and also disable MCLK_o voltage divider on snes_dejitter board (leave R14 open, optionally short R13). Then hook MCLK_o from dejitter board to Xin of S-CPUN (pin 9) or X1 pad that is connected to Xin. After that, you'll need to tap CSYNC_i from SNES PCB (pin 7 of S-RGB should be OK), and finally wire CSYNC_o to an isolated multi-AV pin as usual.Arthrimus wrote:First of all I'd like to thank you Marqs for all of the hard work you've done with the OSSC and this dejitter mod. Last month I built an OSSC which is brilliant, and yesterday I put together and programmed a couple of these dejitter boards for my Snes and Super Famicom. I've got one of them installed in my Super Famicom, a CPU-01 board, but I was wondering if there were any updates on the installation instructions for 1CHIP Snes models. My Snes is a 1CHIP, and I would love to get the dejitter board working on it too.
Re: NES/SNES 240p dejitter mod
stay calm, 1 second before i sent the pm there was no new reply from you. I'm asking for help not for trouble. Please help me if you canUnseen wrote:Edit: Posting deleted. Spamming me with a PM pointing back to a forum thread means you don't get any help from me.
Re: NES/SNES 240p dejitter mod
I've successfully installed this mod on 1CHIP-01, GPM-02, and APU-01 boards with the guidance of marqs. Pictures of these installations and instructions for these board revisions are now on the github page for this project. Huge thanks to marqs for making this happen. I can now finally capture SNES output from the OSSC with my Epiphan AV.IO capture card.
plus ça change,
plus c'est la même chose,
The more that things change,
The more they stay the same.- RUSH- Circumstances
I install and sell mods at arthrimus.com | SNES RGB Bypass+Dejitter available now! | Watch me live stream my work on YouTube
plus c'est la même chose,
The more that things change,
The more they stay the same.- RUSH- Circumstances
I install and sell mods at arthrimus.com | SNES RGB Bypass+Dejitter available now! | Watch me live stream my work on YouTube
Re: NES/SNES 240p dejitter mod
I see no link to Github, Schematics, Guide, on the first post.
Where do I start with this?
edit:
Found the link to github on the second page.
Where do I start with this?
edit:
Found the link to github on the second page.
Re: NES/SNES 240p dejitter mod
This is really great, thanks for your work and for open-sourcing everything. Any plans to sell these? I'd definitely be interested. I ordered the PCB / BOM but I've never soldered surface mount stuff before so I think it's going to be a real challenge for me to assemble myself.
Re: NES/SNES 240p dejitter mod
Is there anywhere I can buy a pre-flashed board? I'd love to solve my jitter issues with the OSSC, but I don't quite have the know-how to flash the firmware etc.
-
- Posts: 707
- Joined: Sun Aug 21, 2016 5:18 pm
Re: NES/SNES 240p dejitter mod
I would also love to buy a pre-assembled board. Mostly out of laziness. Side question, if I have an RGB bypass board (Voultar's kit) for my SNES 1-chip (a Jr model), would the steps change at all? Sync is fed through the bypass board, so I am assuming I would run sync through this first and then into the bypass board, but maybe it would just run directly to the output instead?dadjumper wrote:Is there anywhere I can buy a pre-flashed board? I'd love to solve my jitter issues with the OSSC, but I don't quite have the know-how to flash the firmware etc.
-
citrus3000psi
- Posts: 668
- Joined: Wed Dec 25, 2013 11:56 pm
- Location: Indiana
Re: NES/SNES 240p dejitter mod
I have a board design, just have to assemble and test. It works as rgb bypass board as well. No ETA as time is always a problem. But its on my soon list.
-
- Posts: 707
- Joined: Sun Aug 21, 2016 5:18 pm
Re: NES/SNES 240p dejitter mod
So this would be one board that combines the RGB bypass board and the dejitter? That would be pretty neat (though, since I already own the RGB board, seems like it would be cheaper for me to just add dejitter).citrus3000psi wrote:I have a board design, just have to assemble and test. It works as rgb bypass board as well. No ETA as time is always a problem. But its on my soon list.
Re: NES/SNES 240p dejitter mod
The basic de-jitter board will be also available pre-assembled - I just uploaded v1.2 design that adds 2 extra SMD jumpers to account for different SNES revisions without the need of removing any components from snes_dejitter board itself. It should be now good enough for mass-manufacturing.
Re: NES/SNES 240p dejitter mod
dadjumper wrote:Is there anywhere I can buy a pre-flashed board? I'd love to solve my jitter issues with the OSSC, but I don't quite have the know-how to flash the firmware etc.
I'm about to order and build some of the v1.2 boards this week. I could build a couple extra if anyone wants one. PM me if you're interested, I'll probably be making my parts order tomorrow.thebigcheese wrote: I would also love to buy a pre-assembled board. Mostly out of laziness. Side question, if I have an RGB bypass board (Voultar's kit) for my SNES 1-chip (a Jr model), would the steps change at all? Sync is fed through the bypass board, so I am assuming I would run sync through this first and then into the bypass board, but maybe it would just run directly to the output instead?
plus ça change,
plus c'est la même chose,
The more that things change,
The more they stay the same.- RUSH- Circumstances
I install and sell mods at arthrimus.com | SNES RGB Bypass+Dejitter available now! | Watch me live stream my work on YouTube
plus c'est la même chose,
The more that things change,
The more they stay the same.- RUSH- Circumstances
I install and sell mods at arthrimus.com | SNES RGB Bypass+Dejitter available now! | Watch me live stream my work on YouTube