Nintendo 64 De-blur

[awe444]

you can’t assume these old consoles to exactly follow NTSC spec

I agree, but I’m curious how often “not following spec” reflects an actual characteristic of the system as opposed to being based on some online source citing some imprecise or inaccurate frequency. Imprecise values might come from direct measurement or rounded decimal conversion of an integer ratio, while inaccurate values can come from propagating an imprecise value through some calculation like those in the above posts.

Take for example the 12.170453 MHz you quote a few posts earlier. If the N64’s frequency multiplier is applying (17/5)x multiplication to an NTSC crystal, and the NTSC crystal is a standard (315/88) MHz, then the exact value should be (17/5)*(315/88) = (1071/88) MHz, which when rounded to the same number of decimals is 12.170455 MHz. So there’s a 12.170455 MHz – 12.170453 MHz = 2 Hz discrepancy between your value and mine. Is this discrepancy because the N64’s NTSC crystal isn’t exactly standard frequency, or is because of rounding error? Or does random variation in the actual output frequency vary by at least this much, making the whole discussion meaningless?

Like the N64, most classic consoles have an NTSC (or PAL) crystal whose frequency gets multiplied by some ratio p/q where p and q are (relatively small) integers. This is why both the line rate and refresh rate are at least close to spec if not exactly spec. Knowing the p/q ratio for each console is a useful starting point for clock rate determination, and thus samplerate determination for OSSC tuning. The pineight table is a nice resource for this reason. We should add the p/q multiplier for each console onto the OSSC Optimal Timings page, as well as the (theoretical) samplerates they imply assuming standard spec linerate, i.e., (4500/286) kHz. If in reality deviations from spec do exist, we should document those deviations there as well.

Here are some to start:

clock_rate = (315/88) MHz * (p/q), sample_rate = clock_rate / ((4500/286) kHz)

N64 640x240p and 640x480i: p/q=17/5, sample_rate=1547/2=773.5
NES/SNES/PS1 256x240p: p/q=3/2, sample_rate=1365/4=341.25
Genesis/PS1/Saturn 320x240p: p/q=15/8, sample_rate=6825/16=426.5625
Saturn 704x480i: p/q=4/1, sample_rate=910/1=910
PS1 384x240p: p/q=15/7, sample_rate=975/2=487.5
PS1 512x240p: p/q=3/1, sample_rate=1365/2=682.5
PS1 640x240p and 640x480i: p/q=15/4, sample_rate=6825/8=853.125

[Calle W]

Since there are no scheduled improvements on the OSSC wiki, I assume finer tuning of sampling rate will be put on the feature request list a long with everything else for a while. Would be a really nice feature though. I’m glad I asked about the refresh rate. =)

[marqs]

@awe444: N64 doesn’t have (315/88) MHz NTSC crystal, but a crystal that should be 4x subcarrier frequency. MX8350 then divides that by 4 to get f_sc (actually I checked one N64 board and it had MX8330MC but it works similarly). In my calculations I used specified VCLK frequency (as shown in datasheet) divided by 4 as N64’s pixel clock.

As for your clock_rate/sample_rate formulas, they can be used for a ballpark estimate (e.g. (4500/286) kHz is only accurate for 525i@59.94Hz systems). For exact sample rate (and accurate refresh rate if needed) one still has to know console-specific details such as DAC rate, source crystal frequency and PLL factors (p/q). I guess dot clock number on the wikipage could at least be expanded.

[timson72]

Hi guys,just got my OSSC and wondered what setting people had settled on?. I have a simple RGB mod running through a RGB scart to OSSC.

[James-F]

Line5x does a couple tricks internally to generate active width of 1920/1600. For 320×240 mode, horizontal parameters are multiplied by 5, so with default settings H.samplerate=2130, H.active=1600, H.backporch=245, H.synclen=155. However, these would not be valid settings for 1920-column mode (1920+245+155>2130) so H.synclen is reduced by 120, H.backporch by 160, and H.active increased by 2*160. The final parameters thus are H.samplerate=2130, H.active=1920, H.backporch=85, H.synclen=35, H.frontporch=90.

If you set H.samplerate=386 for N64, then notice that 5*386=1930, leaving practically no time for sync & porch signals. Setting output format to 1600×1200 will solve this, but you also need to keep H.synclen>24 (same applies for all L5 optim. modes) to avoid underflowing it.

This is crucial information to understanding Advanced Timing.
I had no idea that the line multiplier multiplies the base timing parameters after the sampling.
Please add this to the Wiki.

The Wiki page is very vague about signal path and advanced timing.
It would be great to have more information so that more users can make their TV work with the OSSC.

[Harrumph]

In optimized mode yes, but not in generic mode, as far as I understand.

[Author]

Posts