shmups.system11.org

Shmups Forum
 
* FAQ    * Search
 * Register  * Login 
It is currently Wed Jun 26, 2019 5:48 am View unanswered posts
View active topics



Post new topic Reply to topic  [ 445 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: 403
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: 11
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: 403
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: 643
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: 11
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: 403
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: 403
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  
 
 Post subject: Re: NES/SNES 240p dejitter mod
PostPosted: Tue Apr 23, 2019 9:38 pm 


User avatar

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


Top
 Offline Profile  
 
 Post subject: Re: NES/SNES 240p dejitter mod
PostPosted: Sat Apr 27, 2019 5:31 pm 



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


Top
 Offline Profile  
 
 Post subject: Re: NES/SNES 240p dejitter mod
PostPosted: Sat Apr 27, 2019 10:48 pm 


User avatar

Joined: 02 Apr 2018
Posts: 62
Location: Arkansas
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


Top
 Offline Profile  
 
 Post subject: Re: NES/SNES 240p dejitter mod
PostPosted: Sun Apr 28, 2019 5:47 pm 


User avatar

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


Top
 Offline Profile  
 
 Post subject: Re: NES/SNES 240p dejitter mod
PostPosted: Wed May 01, 2019 11:27 pm 


User avatar

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


Top
 Offline Profile  
 
 Post subject: Re: NES/SNES 240p dejitter mod
PostPosted: Mon May 06, 2019 3:08 pm 



Joined: 18 Mar 2018
Posts: 11
@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.


Top
 Offline Profile  
 
 Post subject: Re: NES/SNES 240p dejitter mod
PostPosted: Tue May 07, 2019 3:07 am 


User avatar

Joined: 01 Apr 2005
Posts: 303
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?


Top
 Offline Profile  
 
 Post subject: Re: NES/SNES 240p dejitter mod
PostPosted: Sun May 26, 2019 11:10 am 


User avatar

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


Top
 Offline Profile  
 
 Post subject: Re: NES/SNES 240p dejitter mod
PostPosted: Sun May 26, 2019 11:25 am 



Joined: 20 Feb 2016
Posts: 266
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/forums/topic/black-screen-in-yoshis-island-snes/


Top
 Offline Profile  
 
 Post subject: Re: NES/SNES 240p dejitter mod
PostPosted: Sun Jun 23, 2019 12:36 pm 



Joined: 29 Apr 2016
Posts: 156
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_dejitter/tree/master/installation/SNS-CPU-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?


Top
 Offline Profile  
 
 Post subject: Re: NES/SNES 240p dejitter mod
PostPosted: Sun Jun 23, 2019 2:43 pm 



Joined: 19 Jul 2017
Posts: 1259
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_dejitter/tree/master/installation/SNS-CPU-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.


Top
 Offline Profile  
 
 Post subject: Re: NES/SNES 240p dejitter mod
PostPosted: Mon Jun 24, 2019 12:12 pm 



Joined: 29 Apr 2016
Posts: 156
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?


Top
 Offline Profile  
 
 Post subject: Re: NES/SNES 240p dejitter mod
PostPosted: Mon Jun 24, 2019 2:31 pm 


User avatar

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


Top
 Offline Profile  
 
 Post subject: Re: NES/SNES 240p dejitter mod
PostPosted: Mon Jun 24, 2019 9:13 pm 


User avatar

Joined: 19 Jan 2016
Posts: 279
Location: Sweden
Hooray!
_________________
OSSC TV Compatibility report thread


Top
 Offline Profile  
 
 Post subject: Re: NES/SNES 240p dejitter mod
PostPosted: Mon Jun 24, 2019 10:16 pm 


User avatar

Joined: 15 Dec 2012
Posts: 643
Location: Finland
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)?


Top
 Offline Profile  
 
 Post subject: Re: NES/SNES 240p dejitter mod
PostPosted: Mon Jun 24, 2019 11:10 pm 



Joined: 05 Aug 2015
Posts: 6
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.

Top
 Offline Profile  
 
 Post subject: Re: NES/SNES 240p dejitter mod
PostPosted: Tue Jun 25, 2019 6:11 am 


User avatar

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


Top
 Offline Profile  
 
 Post subject: Re: NES/SNES 240p dejitter mod
PostPosted: Tue Jun 25, 2019 7:30 pm 


User avatar

Joined: 19 Jan 2016
Posts: 279
Location: Sweden
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?
_________________
OSSC TV Compatibility report thread


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

All times are UTC


Who is online

Users browsing this forum: Rotanibor and 11 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