Slashdot Mirror
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!
This is known to be useful on the Dreamcast, where it improves emulator performance.
#naabhaprzrag, #sverubfr-000, #agi-fcbafberq, negvpyr[pynff*=' negvpyr-ary-'] { qvfcynl: abar !vzcbegnag; }
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, and the NES one here.
This poo is cold.
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.
Nestopia (as well as BSNES and ZSNES and, I believe, other emulators) use Blargg's NTSC filter to produce the TV-like output. Truly an amazing piece of work.
As far as accuracy goes, the C64 emulator Hoxs64 is pretty damn accurate, going so far as to emulate analog stuff in the disk drive. Wow.
The roots of education are bitter, but the fruit is sweet.
--Aristotle
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.
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.