Overclocking the Super Nintendo

Robert Ivy writes "The Super Nintendo is a tricky piece of hardware, but I have finally managed to overclock it up to 5.1 MHz. At this speed, the sprites scatter across the screen; this is likely a sync issue since the CPU is running so far out of spec. I plan on trying lower speeds soon and I will update the guide on UCM." Thank god we got that out of the way!

Re:An A for the effort

[Megane]

The usefulness comes in with games which use the vertical sync as a timebase. If they take too many computations per frame, they will miss the vertical sync, and only sync to every other vertical frame. This causes a slowdown to half speed. Overclocking the CPU allows it to do more work per frame, avoiding slowdowns. There are released games which exhibit this problem, and not all of them are action games. In Harvest Moon, if you have more than ten cows in the barn, slowdowns will happen.

This is known to be useful on the Dreamcast, where it improves emulator performance.

Re:An A for the effort

[despisethesun]

Actually, you can overclock the NES and the Genesis both without really suffering any ill effects, but their hardware was quite a bit more simple than the SNES. You can find the Genesis guide here [epicgaming.us], and the NES one here [epicgaming.us].

Re:Secret of Mana

[j1mmy]

just run it in an emulator. I've played through countless roms (including secret of mana) at 2, 3 or even 4x normal game speed. Many games aren't much more difficult that way, and you spend far less time waiting for useless cutscenes and wandering around.

Re:Emulation

[Mitchell Mebane]

Nestopia (as well as BSNES and ZSNES and, I believe, other emulators) use Blargg's NTSC filter [slack.net] to produce the TV-like output. Truly an amazing piece of work.

As far as accuracy goes, the C64 emulator Hoxs64 [btinternet.com] is pretty damn accurate, going so far as to emulate analog stuff in the disk drive. Wow.

What?

[DigitlDud]

3.58 Mhz isn't the "NTSC frequency."

Anyway you can't update the sprite data on the SNES during h-blank reliably because the PPU pre-fetches sprite data. Also the sprite memory address selector is invalidated outside V-Blank so you can't write to the sprite memory anyway. You can only update sprites during V-blank.

Chances are it's not a syncronization issue but he just broke the processor by running it at that speed and is lucky the game runs at all.

Not even as useful as that

[Anonymous Coward]

Speaking as someone who used to program for the SNES, such a mod won't even alleviate the problem of in-game slowdown without causing the problems that our friend with the 5.1MHz SNES has seen. The SNES itself had a fairly insane timing system to begin with, and countless games have taken advantage of that - including (but not limited to) reliance on cycle-exact opcode and DMA behavior. We're not even talking cycle timing on a per-opcode basis - the SNES hardware is deranged enough that accessing different areas of memory space actually execute their cycles at different clock rates than the 65816's base speed.

The sprite issue is probably being caused by somewhat broken DMA -- which isn't totally unexpected, insofar as it was difficult enough to pull off a proper video DMA transfer with a standard SNES, let alone something so wildly out-of-spec. Additionally, anyone attempting to change system timing can also expect slow work-RAM corruption over time.

In short, this won't even fix slow games. I'll just break things. It's a lot of effort for naught.