NES/SNES 240p dejitter mod

The place for all discussion on gaming hardware
borti4938

Re: NES/SNES 240p dejitter mod

Post by borti4938 »

Good to know, that it might be needed anyway.
On 1Chip consoles the carrier is generated inside the S-CPUN. So there is no problem at all as MCLK_o is feeded into clock input of the S-CPUN anyway.
On 3Chip consoles it might be a problem. Is there anything which kind of artefacts one can look for?

At the moment code looks like that:
Spoiler

Code: Select all

module snes_mult_func(

[...]
  input ColorCarrierPAL_i,
  output ColorCarrier_o
);

[...]

wire MCLK_EXT_pre;

snes_dejitter dejitter_u(
  .MCLK_XTAL_i(MCLK_EXT_i),
  .MCLK_EXT_i(MCLK_EXT_i),
  .MCLK_SEL_i(DEJITTER_BYPASS),
  .CSYNC_i(CSYNC_i),
  .GCLK_o(MCLK_EXT_pre),
  .CSYNC_o(CSYNC_o)
);


reg ColorCarrierNTSC;
reg [1:0] div_cnt;

always @(posedge MCLK_EXT_pre) begin
  if (div_cnt[1]) begin
    div_cnt <= 2'b00;
    ColorCarrierNTSC <= ~ColorCarrierNTSC;
  end else begin
    div_cnt <= div_cnt + 1'b1;
  end
end

assign MCLK_EXT_o = MCLK_EXT_pre;
assign ColorCarrier_o = PALMODE ? ColorCarrierPAL_i : ColorCarrierNTSC;

endmodule
I wonder if it is a good idea to reset on PALMODE change? Mhhhh... up to test
Edit reason: oops - copied wrong code version. Carrier PAL is coming from CDCE913...
Last edited by borti4938 on Sun Apr 14, 2019 7:47 pm, edited 1 time in total.
Bananmos
Posts: 11
Joined: Sun Mar 18, 2018 10:55 pm

Re: NES/SNES 240p dejitter mod

Post by Bananmos »

marqs wrote:
Bananmos wrote:I am indeed using a "Nintendo Super SNES RGB SCART cable SYNC on LUMA for PAL console", bought from retrogamingcables.co.uk. IIRC, I got it because I've read that cable wired for CSYNC might suffer from the checkerboard pattern.
You're mixing c-sync with composite video, there no extra information besides sync in c-sync signal. Anyway, that being a PAL machine, c-sync doesn't have a dedicated pin on multi-AV connector so luma should be easier to use.
Bananmos wrote:Are you saying that the OSSC / dejitter mod is less reliable for sync-on luma, or something has been configured incorrectly? Everything does seem to work better than ever before as of now...
It depends on how CSYNC_o is connected. If CSYNC_o is not inserted on luma path, then the output will have a short scanline followed by a long scanline. Since that occurs right after vsync, it's still possible to mask the unevenness by post-coast option as you did.
Oh right.

The way my csyncs are connected are as shown i the photo and quote from the videogameperfection post I linked to. Namely:
* csync_i is taken from the S-RGB pin7 (but without lifting it and breaking existing PCB connection)
* csync_o goes to the top solder pad of the removed R28 resistor

So I take it from your summary that the problem with my current soldering is that it only changes csync, but my sync-on-luma cable will still be outputting the unmodified csync on the luma cable? So in essence I get a half-way house where the MCLK_o is de-jittered, but the sync signal is not, because the cable will be using taking sync from a luma signal that is based on the unmodified original csync?

Will using Borti's method fix it? i.e.:
* Lift S-RGB pin7 to detach it
* Connect (disconnected) PCB signal that used to got to pin7 to CSYNC_i on de-jitter board
* Connect CSYNC_o from de-jitter board to lifted pin7 on S-RGB

I guess this should make the S-RGB correctly output the modified sync on the luma channel, and I should no longer need the post-coast option?
borti4938

Re: NES/SNES 240p dejitter mod

Post by borti4938 »

Should work. Remind that you may have to increase Vth for sync if you observe sync dropouts on the OSSC. It's a PAL 1Chip issue IIRC.
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: NES/SNES 240p dejitter mod

Post by marqs »

borti4938 wrote:Good to know, that it might be needed anyway.
On 1Chip consoles the carrier is generated inside the S-CPUN. So there is no problem at all as MCLK_o is feeded into clock input of the S-CPUN anyway.
On 3Chip consoles it might be a problem. Is there anything which kind of artefacts one can look for?
Isn't 1Chip the more problematic case if subcarrier is generated by dividing (periodically gated) MCLK by 6 inside S-CPUN? A screenshot of the issue is shown here. The short scanline occurs much earlier on SNES, though, so the problem might just get completely masked by vblank and potential overscan.
borti4938 wrote:At the moment code looks like that:
Spoiler

Code: Select all

module snes_mult_func(

[...]
  input ColorCarrierPAL_i,
  output ColorCarrier_o
);

[...]

wire MCLK_EXT_pre;

snes_dejitter dejitter_u(
  .MCLK_XTAL_i(MCLK_EXT_i),
  .MCLK_EXT_i(MCLK_EXT_i),
  .MCLK_SEL_i(DEJITTER_BYPASS),
  .CSYNC_i(CSYNC_i),
  .GCLK_o(MCLK_EXT_pre),
  .CSYNC_o(CSYNC_o)
);


reg ColorCarrierNTSC;
reg [1:0] div_cnt;

always @(posedge MCLK_EXT_pre) begin
  if (div_cnt[1]) begin
    div_cnt <= 2'b00;
    ColorCarrierNTSC <= ~ColorCarrierNTSC;
  end else begin
    div_cnt <= div_cnt + 1'b1;
  end
end

assign MCLK_EXT_o = MCLK_EXT_pre;
assign ColorCarrier_o = PALMODE ? ColorCarrierPAL_i : ColorCarrierNTSC;

endmodule
ColorCarrierNTSC should be generated using MCLK_EXT_i, using MCLK_EXT_pre will otherwise replicate the issue.
Bananmos
Posts: 11
Joined: Sun Mar 18, 2018 10:55 pm

Re: NES/SNES 240p dejitter mod

Post by Bananmos »

borti4938 wrote:Should work. Remind that you may have to increase Vth for sync if you observe sync dropouts on the OSSC. It's a PAL 1Chip issue IIRC.
Hmm, I just realised that removing R28 might have thrown in a spanner in the works here... if the instructions I got from videogameperfection were for hooking up to a csync cable, then I suppose R28 should have been left intact, in order to have the csync signal go through this resistor? I have the R28 saved it in a bag, but it will be a bit fiddly to solder it back as it's so tiny.

D1 was also removed, again just because I followed the videogameperfection instructions blindly. Would this removal cause problems for sync-on-luma?

I sure wish there were some more detailed instructions for the PAL 1CHIP, and a bit more schematic-based instructions for other system variants as well. What I've done feels very much pieced-together from multiple place with missing context, and as my confusion shows it's easy to get a few things wrong when you're not really following a proper schematic and don't know the exact reasons for why components are removed / re-routed.

Anyway, hopefully your awesome combined board will simplify the process for others once it's available. :)
borti4938

Re: NES/SNES 240p dejitter mod

Post by borti4938 »

Bananmos wrote: Hmm, I just realised that removing R28 might have thrown in a spanner in the works here... if the instructions I got from videogameperfection were for hooking up to a csync cable, then I suppose R28 should have been left intact, in order to have the csync signal go through this resistor? I have the R28 saved it in a bag, but it will be a bit fiddly to solder it back as it's so tiny.
R28 connects the 12V to the MultiOut, which is present on Pin 3 in PAL consoles. Just take a look here: https://circuit-board.de/forum/index.ph ... -bekommen/

If you do it my way, you can use luma will have the dejittered sync included.
marqs wrote:Isn't 1Chip the more problematic case if subcarrier is generated by dividing (periodically gated) MCLK by 6 inside S-CPUN? A screenshot of the issue is shown here. The short scanline occurs much earlier on SNES, though, so the problem might just get completely masked by vblank and potential overscan.
Ahhhh... I didn't get the point the first time. Maybe a false friend in language or it was simply too late :D
I now understand the problem. Sure, the 1Chip will have this potential problem, too. The 3Chip SNES NTSC version also, but probably not the PAL version as subcarrier is generated by S-CLK from the basic 17.734MHz Xtal.

OK, I do have an input from the CDCE913 for the NTSC subcarrier, too. I put a solder jumper on PCB to connect it. So I can simply switch between both inputs:

Code: Select all

assign ColorCarrier_o = PALMODE ? ColorCarrierPAL_i : ColorCarrierNTSC_i;
This makes thinks easier.

As it is not implemented in the first PCB version, I can take a look for this artefact this evening.
borti4938

Re: NES/SNES 240p dejitter mod

Post by borti4938 »

marqs wrote:A screenshot of the issue is shown here. The short scanline occurs much earlier on SNES, though, so the problem might just get completely masked by vblank and potential overscan.
I tried to look for such discolouring in upper lines, but I haven't seen that.
At the moment, the next batch of prototypes are on their way to me. I will test some more SNES soon...
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: NES/SNES 240p dejitter mod

Post by marqs »

borti4938 wrote:
marqs wrote:A screenshot of the issue is shown here. The short scanline occurs much earlier on SNES, though, so the problem might just get completely masked by vblank and potential overscan.
I tried to look for such discolouring in upper lines, but I haven't seen that.
At the moment, the next batch of prototypes are on their way to me. I will test some more SNES soon...
Ok, it's good if there's no need for extra arrangements with SNES. I pushed the nes-fix branch update on repo which includes subcarrier output feature, will be updating documentation soon.
Bananmos
Posts: 11
Joined: Sun Mar 18, 2018 10:55 pm

Re: NES/SNES 240p dejitter mod

Post by Bananmos »

I tried improving the mod today by doing as Borti suggested, lifting pin7 of the S-RGB chip to connect it to CSYNC_o and connecting CSYNC_i to where pin7 was, using a via.

And it seems to have had no effect. I still have the same behavior: Unless I bump the post-coast setting, I get picture dropouts with the OSSC, primarily in 3x mode.

Because the post-coast setting fixed the issue, I'm not that bothered by it in practice.

Installation photos for reference:
Image

Image


Interestingly, I noticed a more deterministic problem with sync loss today, in Megaman X: Just before the stage select screen gets shown after entering a password, the TV will lose sync. And then again when selecting a boss, right after the screen has gone black. Here's a video of it in action:
Megaman X sync loss

Not sure if this is known behavior...
User avatar
Arthrimus
Posts: 106
Joined: Mon Apr 02, 2018 5:49 pm
Location: Arkansas

Re: NES/SNES 240p dejitter mod

Post by Arthrimus »

Instead of connecting Csync_o to pin 7 of the S-RGB encoder, try connecting the top pad of R9 on the Dejitter board to pin 7 of the S-RGB. That will deliver 5V C-sync pulses instead of 2V which may be too low for reliable performance with the S-RGB encoder. Also, are you using a cable wired for luma sync like Borti suggested or are you still using C-sync?
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
borti4938

Re: NES/SNES 240p dejitter mod

Post by borti4938 »

Unloaded output is about 2.5V high and 0V low. This is fair enough for the S-RGB, which has 2.0V input high min. and 0.8V input low max. IIRC.

@Bananmos: have you considered to higher the sync Vth in the OSSC menu? PAL 1Chip SNES is known to need higher threshold for some consoles (mine, too) if you use sync on luma or composite to work correctly.
borti4938

Re: NES/SNES 240p dejitter mod

Post by borti4938 »

marqs wrote:
borti4938 wrote:
marqs wrote:A screenshot of the issue is shown here. The short scanline occurs much earlier on SNES, though, so the problem might just get completely masked by vblank and potential overscan.
I tried to look for such discolouring in upper lines, but I haven't seen that.
At the moment, the next batch of prototypes are on their way to me. I will test some more SNES soon...
Ok, it's good if there's no need for extra arrangements with SNES. I pushed the nes-fix branch update on repo which includes subcarrier output feature, will be updating documentation soon.
I was experimenting a bit today on a SNS-APU-01 console (which has S-RGB encoder). I switched color subcarrier using the CPLD. It's quite interesting to that the composite picture is extremely jittery in NTSC if I use subcarrier from teh PLL. However, if I use subcarrier derived from the dejittered clock, the picture is fine. I went back to my SNSP-1CHIP-01 and confirmed that behaviour, too. I doubt that it's a TV (model for tests Toshiba 40L2443D) problem. Not sure though - it's too late...

Need to find a 3Chip with S-ENC to see if it's the same there...
Bananmos
Posts: 11
Joined: Sun Mar 18, 2018 10:55 pm

Re: NES/SNES 240p dejitter mod

Post by Bananmos »

@Borti
Tried increasing (and decreasing) the sync voltage setting, and there's no difference. Increasing post-coast appears to be the only remedy for this TV.
User avatar
Triple Lei
Posts: 376
Joined: Fri Apr 01, 2005 8:17 am

Re: NES/SNES 240p dejitter mod

Post by Triple Lei »

Bananmos wrote: Not sure if this is known behavior...
I've had that Mega Man X thing happen on my RGB-modded SNS-101/OSSC combo too, but only with the HD Retrovision cables. When I switched to a SCART cable, the issue went away.

Could you expand on that post-coast solution though?
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: NES/SNES 240p dejitter mod

Post by marqs »

borti4938 wrote:I was experimenting a bit today on a SNS-APU-01 console (which has S-RGB encoder). I switched color subcarrier using the CPLD. It's quite interesting to that the composite picture is extremely jittery in NTSC if I use subcarrier from teh PLL. However, if I use subcarrier derived from the dejittered clock, the picture is fine. I went back to my SNSP-1CHIP-01 and confirmed that behaviour, too. I doubt that it's a TV (model for tests Toshiba 40L2443D) problem. Not sure though - it's too late...
Was it just chroma jitter, perhaps caused by the two PLL outputs not being synchronous? I think subcarrier shouldn't affect sync or luma, i.e. you should have perfectly stable B/W output even with the subcarrier completely disabled. Anyway, generating subcarrier by dividing MCLK (dejittered or not) is probably the safest solution.
Triple Lei wrote:I've had that Mega Man X thing happen on my RGB-modded SNS-101/OSSC combo too, but only with the HD Retrovision cables. When I switched to a SCART cable, the issue went away.
HD Retrovision cables are probably wired to use sync on luma / composite so for that you'd also need to apply the change for S-RGB as discussed here.
paulb_nl
Posts: 340
Joined: Sat Feb 20, 2016 5:05 pm

Re: NES/SNES 240p dejitter mod

Post by paulb_nl »

Bananmos wrote:
Interestingly, I noticed a more deterministic problem with sync loss today, in Megaman X: Just before the stage select screen gets shown after entering a password, the TV will lose sync. And then again when selecting a boss, right after the screen has gone black. Here's a video of it in action:
Megaman X sync loss

Not sure if this is known behavior...
This is a voltage glitch with the 1-CHIP and composite video/luma sync. That is what increasing analog sync Vth fixes. It also happens with some other games: https://www.videogameperfection.com/for ... land-snes/
copy
Posts: 232
Joined: Fri Apr 29, 2016 10:38 pm

Re: NES/SNES 240p dejitter mod

Post by copy »

I'm planning to install the dejitter board alongside Voultar's RGB bypass on a 1CHIP, combining these instructions:

https://www.retrorgb.com/snes1chip7374.html
https://github.com/marqs85/snes_dejitte ... U-1CHIP-01

Just to make sure: I would need to run dejitter "CSYNC_o" to "CS" on Voultar's board (and not run CSYNC_o to R12), correct?

Another, unrelated question: Why do the instructions for the Mini advise closing jumper JP3, while all other SNES models need it open?
nmalinoski
Posts: 1974
Joined: Wed Jul 19, 2017 1:52 pm

Re: NES/SNES 240p dejitter mod

Post by nmalinoski »

copy wrote:I'm planning to install the dejitter board alongside Voultar's RGB bypass on a 1CHIP, combining these instructions:

https://www.retrorgb.com/snes1chip7374.html
https://github.com/marqs85/snes_dejitte ... U-1CHIP-01

Just to make sure: I would need to run dejitter "CSYNC_o" to "CS" on Voultar's board (and not run CSYNC_o to R12), correct?

Another, unrelated question: Why do the instructions for the Mini advise closing jumper JP3, while all other SNES models need it open?
If you haven't yet purchased any parts, you might be interested in this combo RGB bypass/dejitter board.
copy
Posts: 232
Joined: Fri Apr 29, 2016 10:38 pm

Re: NES/SNES 240p dejitter mod

Post by copy »

The Arthrimus board is very cool, but I do already have the individual dejitter and RGB bypass boards.

Actually, this led me to checking out Arthrimus's installation videos on YouTube. He's done a couple of installs with separate dejitter and RGB boards, and he did connect dejitter CSYNC_o straight to CS on the RGB bypass. This also makes sense to me after reviewing all of marqs' instructions again, so I'll plan to do this too.

I'm still curious why JP3 should be closed for the Mini. Is this related to marqs' recommendation to tap CSYNC_i from pin 7 of S-RGB, rather than from S-CPUN?
borti4938

Re: NES/SNES 240p dejitter mod

Post by borti4938 »

By the way: the union design for SuperCIC, uIGR, DeJitter and DFO is finished. I put everything to Gitub: https://github.com/borti4938/SNES-AddOn ... Jitter_QID

Image

If anyone wants to participate in a community order, please let me know via personal message. It's not limited to a certian number of participants, yet.
User avatar
Harrumph
Posts: 368
Joined: Tue Jan 19, 2016 10:06 pm
Location: Sweden

Re: NES/SNES 240p dejitter mod

Post by Harrumph »

Hooray!
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: NES/SNES 240p dejitter mod

Post by marqs »

copy wrote:I'm still curious why JP3 should be closed for the Mini. Is this related to marqs' recommendation to tap CSYNC_i from pin 7 of S-RGB, rather than from S-CPUN?
Mini doesn't have c-sync output by default so it lacks output filter cap on that multiav pin as well. JP3 just enables on-board filter cap so that c-sync output circuit is identical to other models when hooked to the respective multiav pin.
borti4938 wrote:By the way: the union design for SuperCIC, uIGR, DeJitter and DFO is finished. I put everything to Gitub: https://github.com/borti4938/SNES-AddOn ... Jitter_QID
Nice! Did you figure out a good solution for subcarrier generation or is it left untouched (I've not heard anybody reporting any composite artifacts yet)?
Flea46
Posts: 7
Joined: Wed Aug 05, 2015 8:27 pm

Re: NES/SNES 240p dejitter mod

Post by Flea46 »

Hi everyone, I’ve just bought a de-jitter board from VGP with the NES firmware pre-installed and was hoping you knowledgeable people could lend a hand with installing it into my AV Famicom (HVCN-CPU-01).

I installed a NESRGB board (1.4) into the console last year which has worked flawlessly, but since getting an OSSC I would like to future-proof my Famicom for 4/5x with the new de-jitter board.

I’ve been following the NESN-CPU-01 guide posted by marqs on GitHub but wanted some advice on the correct points to connect. I’ve removed C10 & X1 as recommended, however given I have J8 shorted on the NESRGB for 75ohm I’m not sure how to hookup CSYNC_i & CSYNC_o. I’ve currently got CSYNC_i connected to CS# as the guide suggests, however this pad on the NESRGB is already wired to CSYNC (pin 3) on the multiout. Given the Retro Modding Wiki page is no longer available I also wanted to check that MCLK_o (orange wire) is connected to the correct pin on the adapter board.

Image

Image

Image
Last edited by Flea46 on Tue Jun 25, 2019 8:13 pm, edited 2 times in total.
borti4938

Re: NES/SNES 240p dejitter mod

Post by borti4938 »

marqs wrote:Nice! Did you figure out a good solution for subcarrier generation or is it left untouched (I've not heard anybody reporting any composite artifacts yet)?
I left it as it is due to my test results; I had a four consoles in hand unfortunately no console with a S-ENC an video encoder
- NTSC color carrier generated by dejittered clock (i.e. with a drop out)
- PAL color carrier generated by CDCE913
marqs wrote:
borti4938 wrote:I was experimenting a bit today on a SNS-APU-01 console (which has S-RGB encoder). I switched color subcarrier using the CPLD. It's quite interesting to that the composite picture is extremely jittery in NTSC if I use subcarrier from teh PLL. However, if I use subcarrier derived from the dejittered clock, the picture is fine. I went back to my SNSP-1CHIP-01 and confirmed that behaviour, too. I doubt that it's a TV (model for tests Toshiba 40L2443D) problem. Not sure though - it's too late...
Was it just chroma jitter, perhaps caused by the two PLL outputs not being synchronous? I think subcarrier shouldn't affect sync or luma, i.e. you should have perfectly stable B/W output even with the subcarrier completely disabled. Anyway, generating subcarrier by dividing MCLK (dejittered or not) is probably the safest solution.
In NTSC mode I also tested subcarrier generation using the both clock bases (usual input and dejittered) and I observed the same behaviour. So I use the color carrier using the dejittered clock.
By the way: All outputs at the CDCE913 are derived by a single PLL output, just with different post dividers, which are not switchable without writing registers. Configuration is now as follows
NTSC:
- 21.4772727MHz output
- 3.5795MHz generated inside CPLD by div 6
PAL:
- appr. 106.4MHz PLL out as base and then
- div 6 to get 17.7344MHz (base clock in PAL SNES)
- div 5 to get 21.281MHz (master clock in PAL SNES after S-CLK or S-CPUN)
- div 24 to get 4.4336MHz (color carrier)
User avatar
Harrumph
Posts: 368
Joined: Tue Jan 19, 2016 10:06 pm
Location: Sweden

Re: NES/SNES 240p dejitter mod

Post by Harrumph »

borti4938 wrote: If anyone wants to participate in a community order, please let me know via personal message. It's not limited to a certian number of participants, yet.
Just for clarification, is this community order meant only for advanced users who can program the chips and solder all smd components themselves, or would this be fully populated boards with pre-programmed chips ready to be installed?
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: NES/SNES 240p dejitter mod

Post by marqs »

Flea46 wrote:I’ve been following the NESN-CPU-01 guide posted by marqs on GitHub but wanted some advice on the correct points to connect. I’ve removed C10 & X1 as recommended, however given I have J8 shorted on the NESRGB for 75ohm I’m not sure how to hookup CSYNC_i & CSYNC_o. I’ve currently got CSYNC_i connected to CS# as the guide suggests, however this pad on the NESRGB is already wired to CSYNC (pin 3) on the multiout. Given the Retro Modding Wiki page is no longer available I also wanted to check that MCLK_o (orange wire) is connected to the correct pin on the adapter board.
You must have J8 open, and CS# only connected to CSYNC_i. CSYNC_o is connected to the multi-AV pin where you had CS# wired previously. I'm not sure about that orange wire since I don't have the same adapter board version, but it should be the pin that goes to PPU pin 18.
borti4938

Re: NES/SNES 240p dejitter mod

Post by borti4938 »

Harrumph wrote:
borti4938 wrote: If anyone wants to participate in a community order, please let me know via personal message. It's not limited to a certian number of participants, yet.
Just for clarification, is this community order meant only for advanced users who can program the chips and solder all smd components themselves, or would this be fully populated boards with pre-programmed chips ready to be installed?
It's meant to provide complete PCBs with soldered components and pre-programmed chips ready to install.
Unfortunately, I made a small break in accepting orders. But will continue once I finished first 25.
Flea46
Posts: 7
Joined: Wed Aug 05, 2015 8:27 pm

Re: NES/SNES 240p dejitter mod

Post by Flea46 »

marqs wrote:You must have J8 open, and CS# only connected to CSYNC_i. CSYNC_o is connected to the multi-AV pin where you had CS# wired previously. I'm not sure about that orange wire since I don't have the same adapter board version, but it should be the pin that goes to PPU pin 18.
Thanks for the confirmation, I cleared the jumper, then wired CSYNC-o to the multi-AV as suggested & I'm happy to say it's working correctly :)
copy
Posts: 232
Joined: Fri Apr 29, 2016 10:38 pm

Re: NES/SNES 240p dejitter mod

Post by copy »

I just attempted to rewire my dejitter and NESRGB to enable dejittered composite and s-video (and keep dejittered csync), and my results are mixed. I'm wondering if any experts can speculate on what's happening.

My steps:

1) Removed the 1k ohm resistor (01B) on the NESRGB that leads to pin 10 ("SYNCIN") of the video encoder (BH7236AF). This disconnects the original jittered csync going from the CPLD to the video encoder.

2) Soldered a cable from the top of resistor R9 on the dejitter board (which is connected to dejitter CPLD pin 15) to the empty top pad of the removed 1k resistor on the NESRGB, sending the dejittered 4Vpp csync into the NESRGB's video encoder.

3) I retained the CSYNC_o connection from dejitter to my NES's multi-out, to keep csync intact.

(Credit to marqs, paulb_nl, and maxtherabbit for the info on how to do this.)

The good news is that my NES now works with a sync-on-luma RGB cable on the OSSC, so I believe luma has been successfully dejittered. Csync RGB cables also still work.

However, there are a couple of strange side effects:

1) The composite and s-video outputs now have a graduated discoloration at the top of the image. (I tested these outputs on my Framemeister.)

2) The OSSC's 256x240 optim. mode now only shows a narrow vertical slice from the center of the image. Generic 4:3 mode still works perfectly fine.

Does anyone have any ideas on why I'm seeing these issues?
User avatar
marqs
Posts: 1034
Joined: Sat Dec 15, 2012 12:11 pm
Location: Finland

Re: NES/SNES 240p dejitter mod

Post by marqs »

copy wrote: 1) The composite and s-video outputs now have a graduated discoloration at the top of the image. (I tested these outputs on my Framemeister.)

2) The OSSC's 256x240 optim. mode now only shows a narrow vertical slice from the center of the image. Generic 4:3 mode still works perfectly fine.

Does anyone have any ideas on why I'm seeing these issues?
For 1) you need to disconnect BH7236AF video encoder pin 6 and connect that to snes_dejitter CPLD pin 11 which provides clean subcarrier. I think there was some discussion about this a few pages back. The latest firmware from nes-fix branch must also be installed on the board.

2) sounds strange, are you sure your display has showed it correctly in that mode earlier? You might also want to take a look into NESRGB dejitter modification which might be easier in the end if you want to preserve cvbs & s-video.
Post Reply