N64 RCP overclock tearing correction - an ongoing pursuit

[MRKane]

Hello all. Long time lurker, but I've never had much of a need to post as I just do my little thing and never break much new ground.

I was talking with a friend of mine when she mentioned the video by ElectionAsh that claims to have an overclocked RCP with tearing (that funny graphical glitch the N64 gets when you mess with the clock) corrected by a FPGA board.
Source: https://youtu.be/NCbkDgCIKRQ

This lead me to wonder if using an UltraHDMI would correct the tearing as it essentially bypassed the DAC. I didn't have any clocks handy so opted to use the X1 from a rotten N64 board and drop it into X2 on the board I was testing with. This didn't seem to change the issue and the tearing remained as expected.
Video: https://youtu.be/icpLodGPV9w

So now I'm left wondering where to go. Every five years or so I get it into my head that I want to somehow bolster N64 performance, and we have a claim that it's possible to fix the tearing using the FPGA, but I don't know that I see too much of a repeatable pattern on my own unit. This warrants more investigation at least, although I'd say that MarshalH will be too busy to help with such a minor idea and I don't have the money to design a FPGA.

Of course from what I've read in the past it could also have to do with the nature of how the RCP processes the image - the information here seems to be full of conjecture, but from a systems angle the bottleneck will either be the RCP or the RDRam, and I have two two Toshiba TC59R1809HK chips that boast better performance than the stock N64 RDRam chips so that could be worth pursuing but it's a finicky operation and could lead to a dead system.

I am very open to suggestions here, and would love any help that can be offered. It'd be really awesome to come up with a solution we could all use.

[MRKane]

Unsurprisingly the "improved" ram didn't give different results.

I think I was hoping that the VI would read from the framebuffer better given reduced latencies and improved tolerances, but it'd appear that the solution to the issue doesn't lie in that part of the system.

EDIT: So as an added twist Hypatia found that turning AA on/off in Goldfinger shifted the point where the visual "tearing" happens on an overclocked system. It'd suggest that VI read is affected by the AA process. Go figure.

[MRKane]

So I finally had a few clocks show up today and put in a horribly unstable header arrangement.

The core thing to note is that changing the X1 clock throws video off wildly, however the UltraHDMI produces a clean and clear image despite this, although audio will be sped up and pitched up.

I only had a 20.0mHz and 17.7mHz clock so decided to test that and found that increasing both clocks in tandem reduced the degree of visual artifacting on the screen! Frankly I'm thrilled with this as I figured this would be a hardware limit.

Video of PD with minimal glitches and smoother framerate: https://www.youtube.com/watch?v=TUlZI7gzJyw

I'll keep testing with different clocks as they arrive in the post, but I'm almost calling this experiment complete!

P.S. You bet it gets hot. Quick. And is properly unstable.

[MRKane]

So I recently wondered if the video would work were the chip set to the correct clockrate. Finding myself short on the necessary bits to do this correctly I opted to simply jumper from one N64 to the other.

Suffice to say that it didn't work. Could have been my Michael Mouse setup, difficult place to drop a wire (someone put an UltraHDMI cable over the chip! How rule!) or simply just a stupid idea.
https://www.youtube.com/watch?v=hZ5K5jRiKDQ

[MRKane]

So the assortment of clocks I ordered arrived today.

I could push X1 up to 25.0mHz but no higher as the console wouldn't boot.
X2 wouldn't boot at 20.0mHz and that was the next up from 17.7mHz that I had.

So now within the realm of a 1.5x speed I checked the timing for comparison and found it wildly out, with a 26 second video I took capturing 31.85 seconds of "game time" which suggests that things aren't quite linear. I dropped a switch on the CPU to give some control between 1x and 1.5x and didn't feel that the 1x provided better performance. Interestingly at 1x speed the "game speed" as demonstrated by the clock in PD was ever so slightly slower than actual time with a 26 second video capturing 20.55 seconds of game time.

Frustratingly I still can't get the Everdrive to work, and even then it wouldn't be a good measure of performance improvement as both clocks have been changed so this is left sitting in the realm of non-qualitative measurement, ie. videos and guesswork.

https://www.youtube.com/watch?v=miuaTgaULt0

https://www.youtube.com/watch?v=Y-rxROhngj0&t=1s


And you bet my pet bird "Fluffy" helped out, and I think that's why there are green dots in the HDMI feed - I think he pulled on the ribbon a bit too much.

https://www.youtube.com/watch?v=3NxiZBS_-pE




So...drawing to the end of a long road for me, and I really don't feel that I've found a "win" at this stage. I'm sure I could get a 20% boost without corrupted video if I could use the Everdrive and adjust the gameplay speed of Perfect Dark or Goldeneye directly, but the Everdrive just won't boot.



I think for the next part of this experiment I'll see about looking at the different X2 clocks and at what point the video tears begin to happen - I might be able to squeak out a little performance that way, and a little is better than nothing.