shmups.system11.org

Shmups Forum
 
* FAQ    * Search
 * Register  * Login 
It is currently Sat Apr 20, 2019 8:12 am View unanswered posts
View active topics



Post new topic Reply to topic  [ 427 posts ]  Go to page Previous  1 ... 11, 12, 13, 14, 15
Author Message
 Post subject: Re: NES/SNES 240p dejitter mod
PostPosted: Sun Apr 14, 2019 7:36 pm 


User avatar

Joined: 01 Apr 2016
Posts: 398
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: show
Code:
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...
_________________
Visit my projekts: GitHub, OSH Park


Last edited by borti4938 on Sun Apr 14, 2019 7:47 pm, edited 1 time in total.

Top
 Offline Profile  
 
 Post subject: Re: NES/SNES 240p dejitter mod
PostPosted: Sun Apr 14, 2019 7:46 pm 



Joined: 18 Mar 2018
Posts: 9
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?


Top
 Offline Profile  
 
 Post subject: Re: NES/SNES 240p dejitter mod
PostPosted: Sun Apr 14, 2019 7:49 pm 


User avatar

Joined: 01 Apr 2016
Posts: 398
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.
_________________
Visit my projekts: GitHub, OSH Park


Top
 Offline Profile  
 
 Post subject: Re: NES/SNES 240p dejitter mod
PostPosted: Sun Apr 14, 2019 9:29 pm 


User avatar

Joined: 15 Dec 2012
Posts: 621
Location: Finland
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: show
Code:
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.


Top
 Offline Profile  
 
 Post subject: Re: NES/SNES 240p dejitter mod
PostPosted: Sun Apr 14, 2019 9:46 pm 



Joined: 18 Mar 2018
Posts: 9
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. :)


Top
 Offline Profile  
 
 Post subject: Re: NES/SNES 240p dejitter mod
PostPosted: Mon Apr 15, 2019 4:12 am 


User avatar

Joined: 01 Apr 2016
Posts: 398
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:
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.
_________________
Visit my projekts: GitHub, OSH Park


Top
 Offline Profile  
 
 Post subject: Re: NES/SNES 240p dejitter mod
PostPosted: Thu Apr 18, 2019 8:16 pm 


User avatar

Joined: 01 Apr 2016
Posts: 398
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...
_________________
Visit my projekts: GitHub, OSH Park


Top
 Offline Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 427 posts ]  Go to page Previous  1 ... 11, 12, 13, 14, 15

All times are UTC


Who is online

Users browsing this forum: bestinshow, ChuChu Flamingo, Frank_fjs and 9 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

Search for:
Jump to:  
Space Pilot 3K template by Jakob Persson
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group