I have yet to hear somebody well versed in NES emulation comment on the quality of the Wii's NES emulation. How does it compared to the better free NES emulators?
I'm not sure that people will be able to discuss this topic properly. As was mentioned earlier, Nintendo can simply "pull a Nesticle" and hack the ROMs as needed to make them work properly with an inaccurate emulator rather than spending time to improve the accuracy of the emulator itself. The only halfway-decent way to determine the accuracy of the Wii's NES emulator would be to have a hacker figure out how to shoehorn in blargg's test ROMs or something similar, and we all know that will probably "never" happen.
Ok, but for the games that it does support, do they run correctly? I don't care if they are hacked to run correctly or if they run on a general purpose NES emulator. Are the colors accurate, the audio, the timing, the aspect ratio, etc?
Right, the Wii virtual console is really a game emulator. It's emulating specific games, individually made to work through on a NES-like virtual console, with likely modification of the original game code to work with it. So it can't be evaluated as NES emulator, but it can be evaulated as an <insert game here> emulator. I wouldn't be surprised if they took the opportunity to remove slight graphical glitches in games during the porting process, for example the flickery left side of the line above the status area in Super Mario Bros. 3 (or rather, their virtual console has a more robust split-screen system that naturally eliminates things like this). Obviously they'd prefer to make the virtual console as compatible as possible with the main structure of games, since it pays off several times as compared to having to modify each game (and possibly break it).
I haven't seen it in action. Hopefully I can see it somewhere and scrutinize the basic appearance and sound quality.
Metroid had no programming changes made to it on the GBA nes emulator. The only differences are font-deep.
I highly doubt Nintendo would hack games to fit an emulator.
Dwedit wrote:
Metroid had no programming changes made to it on the GBA nes emulator.
But does the emulator use JMP/BEQ hacks or any other HLE? If acNES has time to run the NES CPU and a software sound core, and PocketNES doesn't, then I wonder where PocketNES's inefficiency lies. And I wonder how Blargg's tests would fail when injected into acNES.
(Aside: Today, for the first time, I experienced the "ac" in "acNES".)
Quote:
I highly doubt Nintendo would hack games to fit an emulator.
Nintendo wouldn't, but other Japanese companies such as Konami did the equivalent.
Castlevania III and a lot of other games brought over from Japan are mapper hacks from the publisher's original mapper (e.g. a VRC) to one of Nintendo's mappers (e.g. MMC5).
Just discoverd that they had released SMB now so I gave it a try. I can confirm that the emulator atleast deals with 8 sprites on a line and I managed to come to the -1 world too ^^
thought I still feel like something isn't sounding right and the colors feels wrong.. I guess I have to play some SMB on my NES too to compare the games.
dXtr wrote:
Just discoverd that they had released SMB now so I gave it a try. I can confirm that the emulator atleast deals with 8 sprites on a line and I managed to come to the -1 world too ^^
thought I still feel like something isn't sounding right and the colors feels wrong.. I guess I have to play some SMB on my NES too to compare the games.
Is
Balloon Fight out? If this is anything like the emulator in
Animal Crossing, then go on a Balloon Trip and hit a spark. Listen as the buzzing sounds completely different from the NES.
The colors feel wrong because the artifacts aren't emulated, or at least they aren't in
AC. It's like playing on a PlayChoice.
tepples wrote:
Is Balloon Fight out?
Not yet.
I bet that the Wii's NES emulation isn't cycle exact. There's a point at world 1-2 (founding the 1-up mushroom) that slows down the gameplay for a few secs on my PAL NES, the slowdown is NOT on the Wii SMB I just purchased.
However, the sprite-flickering seems to be there (as someone already noticed) but I don't think it's entirely correct either, flickering on some NES emulators on the PC looks alot more like the "original flickering"
United States, purchased (as of now):
Super Mario Bros.
The Legend of Zelda
Gradius
Also F-Zero,Comix Zone(still bugs mid right corner second stage thx to lack of cpu time),Sonic 1(it's ver 2 of 3 i think), Mario 64, and Mario Kart 64.
SMB Plays quite well. The advanced, superior composite video encoder they use really shows (the poles are horizontal green, not dot crawling even dithered). 1 thing I did notice was the sound is not absolutely perfect (as it never has been), when getting a mushroom the noise doesn't grind, and marios jump (regardless of size) noise pitch bends a little too high.
Zelda. Since this is the 2003 re-release I'm not sure what to expect, they could've fixed anything...but they did get the DMC samples+the friggin' popping even...that suprised me.
Gradius. No comment.
What suprised me about the VC is that Mario Kart was in the line-up...I though they were using that same GC emu engine for Zelda:OOT (some special edition disc) that was hacked to play Mario64 at one point and time...not to mention framebuffer effects...
BTW, I threw the VC data's for them onto an SD card and looked at them with a hex editor...they're encrypted...damn. That would've been too easy to inject whatever I want (seeing as I have MMC1, UNROM, and NROM-256 at my fingertips lol)
Also, prolly a nogo on the uber h4x to focus the emu on one game, since the difference between gradius and smb is about that of a few banks and some tack-in code.
Mani I can't wait for Mario3 on VC...
+Kirby's Adventure
Never got to try an actual cartridge. But it looks like their IRQ timings are in order...then again, that will really shine with Mario3's "inconsistencies."
Is it just me, or does the game really slow down in some parts;The music still gets all the cpu time it needs, but it just seems oddly slow in some parts with heavy sprites.
Quote:
Is it just me, or does the game really slow down in some parts;The music still gets all the cpu time it needs, but it just seems oddly slow in some parts with heavy sprites.
I've got the cartridge and I've noticed it gets really bad when you use the spark or fire power and a lot of action is going on. I read a site not to long ago about a guy who overclocked his nes and the frame rate drop was gone.
Quote:
I read a site not to long ago about a guy who overclocked his nes and the frame rate drop was gone.
This is almost impossible, because the clock is divided internally to the CPU, and increase the freqency of the main clock will cause the PPU to totally screw up and not be in synch with the TV.
Bregalad wrote:
Quote:
I read a site not to long ago about a guy who overclocked his nes and the frame rate drop was gone.
This is almost impossible, because the clock is divided internally to the CPU, and increase the freqency of the main clock will cause the PPU to totally screw up and not be in synch with the TV.
Easy to solve: Put the CPU and PPU on separate crystals.
as i have not done this myself, i cannot verify it works. but here's the instructions to do it.
http://www.epicgaming.us/nes_oc/howto.php
and the guy goes on to say there is graphics corruption when you reach a certain point:
Quote:
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.
*nes overclocking part needs a splitty*
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?
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).
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.
You could try Rad Racer (also by Squaresoft), but if it would work I really couldn't understand why.
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...
Sory for the necrobumb, but has anybody injected a wad of test ROMS into acNES on any VC game to see how accurate it is?