and the guy goes on to say there is graphics corruption when you reach a certain point:
Are there any problems associated with overclocking the NES?
Yes, there are, albeit minor. The NES CPU incorporates the inner workings of the 6502 microprocessor with custom sound hardware. So, when the CPU clock rises, so does the audio pitch. This is not severe enough for most to consider a problem until you reach clocks as high as, say, 3.3 MHz. Past this sort of level, there can also be strange glitches, I noted graphical problems, presumably from the timing of the CPU and PPU being altered massively. Crashes don't seem common at all on the machine I tested, but of course, your milage can and will vary. Your results may be almost entirely different!
Ah, of course it's possible to feed the CPU with a totally different clock, but then it will break synchro between PPU and CPU and that is BAAAD !
Because :
- PPU reads and writes (regs $2000-$2007) may (and probably will) randomly fail ! The CPU adress decoder can change while the PPU is clocked !
- All games with timed code will be screwed up
- Music will play higher, hardware decay, sweep and time-out will run faster too
- Frame APU and DMC IRQ will happen in a much briefer delay, wich may affect some games in a weird way.
The only way to do this proprely would be something like adding a PLL between the system quartz and the CPU clock.
The main problem is that metastability issues can come up between the CPU and PPU. This is unrelated to the effect on games due to differing timing; it could directly affect latch operation.
Let's hypothetically say that during the one scanline before vblank, the CPU ran at 100x the normal speed... Obviously stuff which depends on turning off the screen early to gain some vblank time would fail, but how would that impact slow games or other situations?
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!
If you would clock the CPU at 2.1 GHz it would burn / do nothing instead of having it's normal operation. Even if it would work, ALL PPU reads and writes will fail miserably because the PPU won't latches it's reads and writes, because it won't be clocked during the time the CPU write/read it's $200x registers.
Overclocking an NES...I'll have to try this just to see how well it'll work...although I'm having enough problems with my 1-wire cic-less front-loader.
I've run lots of games on my NES system at some pretty crazy clockrates, as low as 2.6 MHz and as high as 4.2 MHz; and I've never encountered a crash that didn't result from a bad clock connection. When solidly attached everything was very stable. Graphical corruption was rare with the exception of some shakiness for logical reasons of the status bar in games which used MMC3. I'll do more further testing once I get my new Famicom model 2 overclocked as I have a wider selection of titles for it. Suffice to say I didn't notice any severe enough breakdown in 2A03/PPU communication to cause serious graphical corruption on the display-- however I throw it out there as a warning just in case someone is going to be upset if their system doesn't work perfectly at all speeds. Honestly you have to expect that taking things out of spec.
I haven't seen any games yet that don't rely on vertical interrupts for their timing so no games have run too fast. I would expect most games breaking this convention would likely be shoddily programmed and perhaps not worth playing?
I'll bet anything Battletoads won't work on an overclocked NES.
Zelda might also have a problem when scrolling (mainly vertically), due to the large time between sprite 0 hit and the $2006 writes (some 15 scanlines in between, IIRC). Probably won't affect gameplay, though. Final Fantasy's full-scene raster effects (timed from NMI) will also be problematic (this may or may not affect gameplay).
Games that don't do any raster effects will have zero problems, while games that do can range from having no problems (if timing isn't critical) to having major graphical issues (if timing is critical). In the case of Battletoads, timing is measured from NMI and must be very precise, or else the game will lock up (due to a failed sprite 0 hit caused by the status bar being out of place).
"Last version was better," says Floyd. "More bugs. Bugs make game fun."
Very interesting. I'll have to get a copy of BattleToads to test with. I imagine Final Fantasy is expensive so I doubt will be getting that however-- esp. since I don't enjoy playing RPGs and I'd have it solely for testing purposes.
Now, I'm not as clear on the intercomponent communication in the NES/FC as say, the MegaDrive/Genesis-- to my understanding NMI is a logic level present on an RP2A03 pin timed by the CPU's interaction with the bus, like some sort of a 'go-ahead' signal for the PPU as far as I can tell. I assume the rate at which this line goes high/low relies on input clockrate to the 2A03 and if this changes it will alter the rate at which any events timed by it occur. I am thinking about this correctly? If the NMI pin going high/low is a regular timed event and not dependent on actual system conditions perhaps I'll look into disconnecting that pin from the board and substituting a regular imitation signal that mimics normal operation at ~21.477 MHz input clock. I get the feeling it isn't quite that simple or regular a signal, however.
Ah, I think I'm starting to get this NMI bit. The PPU is sending that signal on every VBlank at a regular 60 or 50 Hz and the time the CPU is listening is decreased if its clockrate is higher, it looks like...
