shmups.system11.org

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.

Right, he didn't state it was impossible, but to make it switchable seemed to be a particular challenge.
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...

@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.

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.

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.

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.

That could work, but I can't test it on my system.


Is the phase shift network between the S-CLK and S-ENC identical in PAL and NTSC consoles?

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.

I wouldn't mind trying that actually, but unfortunately VGP only have the 3.3V version. Well, actually they are out of stock anyway...

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.

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.

Thanks for the clarification!

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?

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.
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.
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.

Thanks for your reply marqs!



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!



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.

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?

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.

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.

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 thanks

If your S-CLK chip gets very hot, it is completely dead and you need a new one.

you know where to find it?
also you have modded yours to give the 21mhz clock externaly, how you do it? i can do the same?

Edit: Posting deleted. Spamming me with a PM pointing back to a forum thread means you don't get any help from me.

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.
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.

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 can

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.

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.

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.

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 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?

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.

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).

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.

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.