Nintendo 64 De-blur

[Calle W]

Sorry I haven’t replied for a few days, easter was busy and all that. Turning off HPLL2x hass actually solved my issues for the most part.

Video lpf: 16Mhz
Sync lpf: 2.5MHz
Sampling phase: 247 degrees (some games look a bit better at 258 though). Had to adjust this from 281 due to turning HPLL2x off.

With HPLL2x turned off I can switch games without issues. I decided to do turn it off for other profiles as well. I was able to get similar results with different settings too. Video lpf off and sync lpf off gave the same results at around 33 degrees or something.

Are minimal values of sync/video lpf preferred over higher values? I’m not really seeing any differences. I guess I should be happy that everything is working now. Line5x seems to be a bit more picky with settings though. Haven’t reached as good results as I have with line4x yet, but I don’t use it that much anyway.

Tried to take some pictures but they didn’t come out all that great. Screenshots via my capture card might give an ok comparison even though there is color conversion involved. I’ll see if it’s worth the time to do so.

Thanks for the help, paulb_nl. It’s super appreciated. I’m loving the de-blur look of many games! I wonder how this stacks up against the UltraHDMI and the new N64RGB revision/firmware.

[paulb_nl]

It seems I was wrong about HPLL2x not being used in the optimized mode. When Marqs was working on fixing the unstable optimized modes he removed HPLL2x from the optimized modes but I missed that he put it back later. Not sure why though since it was the cause of the unstable optimized modes.

Higher lpf values means less filtering. With video lpf off you may see noise so you should mostly just leave it on Auto. It was recently found that the THS7314 amp used in SNES/N64 mods already has a lpf so you should set Video lpf to off in that case. But with N64 I also didnt see any difference with video lpf on or off so I just leave it on Auto.

For sync lpf I always leave it at 2.5Mhz max because otherwise it might lose sync in some cases. You won’t see a difference except that the image might shift horizontally.

[Calle W]

Everything is working now. So nice to not have to worry about fiddling with settings anymore. Turned off video lpf for my N64 profile and set sampling phase to 202 (315 for line5x) degrees.

I also managed to take some decent enough pictures of my final results: https://imgur.com/a/PTKoC

As you can see, Mario’s nose sort of bleeds out a bit to the left, but it’s less noticeable in person. It’s basically a trade off. If I set the sampling phase one to three steps lower it’s perfect on the left but not on the right. I think I’ve found a nice middle ground now. Thanks again for taking your time to answer all my questions.

[paulb_nl]

Yea the N64 needs around 386.6 samplerate so with current settings its not going to be 100% perfect. Its not really noticeable unless you’re very close to your display.

[awe444]

N64 needs around 386.6 samplerate

Would non-integer samplerate values (e.g., 0.1-scale precision) be a possibility for a future firmware update?

[Calle W]

While we’re talking about samplerates, I was asking on shmups if anybody knows the exact refresh rate of an N64, but I didn’t get an answer. When test-recording in VirtualDub for example, the software settles at around 59.8261. When trying to calculate the refresh rate using the dot clock rate etc. I can’t really get close to this value.

The OSSC reports 59.82Hz and 263 lines per field. Would be nice to find out an exact value.

[awe444]

The exact refresh rate for a standard-spec NTSC 480i signal is (2 * 4500000)/(286 * 525) = 59.9400599. For an NTSC 240p signal, the integer 525 gets changed to 526, resulting in the slightly different refresh rate (2 * 4500000)/(286 * 526) = 59.8261054. See the Wikipedia article on NTSC for an explanation and the history behind these numbers.

[marqs]

@paulb_nl: there are some advantages by keeping HPLL2x enabled even if optimizied modes. After previous changes, random phase error due to HPLL2x should be much smaller (between 1/12th and 1/8th of a dot) as multiple samples per dot are captured. Apparently it’s still noticeable though, so I’ll need to consider removing HPLL2x from those modes. It’s also possible to enable finer tuning of samplerate in optimized modes if needed, but available precision would then depend on line multiplication mode.

@Calle W: To calculate exact refresh rate, you’ll need to know exact pixel clock frequency, number of dots per line and lines per frame. Assuming that in N64 320×240 the said parameters are 12.170453MHz, 773.25 and 263, then v_hz = 12170453Hz/(263*773.250) = 59.845Hz.

[awe444]

Having researched this further, I’m now convinced the above-quoted samplerates (386.6 and 773.25) are both incorrect, though pretty close. This table suggests the N64 clock rate is 2*(1071/176) MHz = 12.1704545454 MHz (close to what @marqs cites above), which is exactly 17/5 times the NTSC standard (315/88) MHz = 3.579545454 MHz frequency. The MX8350 clock generator in the N64 is responsible for this factor of 17/5 according to its datasheet. Using this exact 2*(1071/176) MHz clock rate and the exact refresh rate of (2 * 4500000)/(286 * 526) Hz = 59.8261054 Hz from my previous post, the N64 samplerate is

(1000000 * 2 * 1071/176) / (263 * (2 * 4500000) / (286 * 526))

which evaluates to exactly 1547/2 = 773.5 dots/line.

[paulb_nl]

@marqs It would be nice to have some more precision with the samplerate. Do you have an idea how to handle the different precision scales in the timing tweaker with the different multiplication modes? If im understanding correctly, precision in x3/x4 320×240 optimized would be 1/4th and in x5 it would be 1/5th.

@awe444 Nice work. I was searching for the exact N64 pixel clock but didn’t find it yet.

[Calle W]

@awe444 Wow, thank you so much. I was looking at pineight for information, but it just didn’t add up. I wanted to look up the clock generator, but the link to the datasheet on pineight is broken. Didn’t think twice to look it up elsewhere… Haha. Great work! Much appreciated! I love the N64, so this is really nice info for me. Thanks again!

@marqs That’s the exact formula I used. I ended up with the same results and it messed with my head a bit. Any small precision improvement of the samplerate would be a really nice addition. Great to know it’s possible to some extent. Also, just wanted to say that you’ve done a tremendous job with this piece of hardware so far. My best purchase in years!

[awe444]

Glad I could help—and apparently there’s a more general rule for all consoles with exact clock rates listed on the pineight table:

DOTS_PER_LINE = CLOCK_RATE / LINE_RATE = CLOCK_RATE / (N * 4500000 / 286)

where N=1 for 240p/480i, N=2 for 480p. That is, the actual number of lines (263, 525, etc.) cancels out of the equation, since the NTSC signal’s line rate is itself a standard specification. I’m assuming here that any hardware with a custom clock rate need only have a custom dot-per-line value, whereas the line rate is presumably standard across hardware. From what I observe the OSSC reporting on its LCD for different consoles, that does seem to be true, but please share if you know or discover otherwise

[Harrumph]

Line number differ such as NES/SNES has 262, most others 263 and NeoGeo 264. But yes the line rate as in horizontal scan time is more or less constant at roughly 63.6 microseconds, afaik. Edit: that’s only standard for broadcast NTSC TV though, clearly actual line rates vary because otherwise there couldn’t be so many various refresh rates out there.

[awe444]

clearly actual line rates vary because otherwise there couldn’t be so many various refresh rates out there

That’s not obviously true. The question is: across consoles in general, how much of the vertical refresh rate variation is due to different line count (262,263,264, etc) as opposed to differing line rate? Meaning if we compiled two lists, (1) of console line counts and (2) of console line rates, which list would have the most variation? (Leave refresh rate out of the discussion entirely for clarity)

[marqs]

@awe444: you can’t assume these old consoles to exactly follow NTSC spec, so calculations shouldn’t be based on that. As for N64, I think we can agree that it has MX8350 clock generator IC and a crystal based on console region. The datasheet specifies generated VCLK of 48.681812MHz in NTSC configuration (assuming N64 has matching crystal) which is a signal that also clocks video DAC. Based on a couple sources each N64 scanline consists of 3093 VCLK cycles, and each dot clock cycle is made of 4 VCLK cycles during which video & sync data is transferred to DAC in four 7-bit transfers. These numbers suggest that each scanline is 3093/4 = 773.25 dots, but I’d like to see 3093 verified since 3094 would make more sense spec-wise and be in line with what OSSC reports as N64 refresh rate (59.82Hz for 263p, 59.94Hz for 525i). Maybe somebody with N64RGB and USB blaster could check the value via SignalTap.

[Author]

Posts