Updated my no$nes emulator,
http://nocash.emubase.de/nes.htm - The main news are: Excessive support for almost every controller and add-on that I've ever heard of. And support for the arcade and hotelbox variants of the NES hardware.
Some things that will be still needed to be worked on are: MMC3 seems to cause various problems, don't know if this is a general emulation bug, or if it's related to different variants of MMC3 boards. And, since the last update, around 100 more or less obscure new mappers have showed up, which still aren't supported. And APU is still lacking DMC sound and APU needs some general testing and tuning, and a bunch of external audio sources also need to be implemented someday. Anyways, at the moment - and after some months of continous work - I am just happy to have finished the update.
How about supporting the variants of NROM-368, with CPROM, CNROM and Vs. System supported:
http://wiki.nesdev.com/w/index.php/NROM-368
Came across them recently too, but forgot to add them to the todo list (did so now). Many thanks for reminding me there! Would have been easy to forget them as they have no own mapper number. Hmmmm... that also leads to: Then I can scrap the sentence in the everynes.htm specs that says that Mapper 0 with more than 32K PRG-ROM is clearly indicating a corrupt file :-/ life isn't that simple. I guess updating the mapper specs may be another 6-months project.
I like the debugging features, but found a little weird that the graphics in the VRAM viewer stretch with the window, and there's no way to snap to an integer scale, so everything is always distorted. I liked the "assumed palette" feature, but it would be nice if we could manually pick palettes too. Also, the BG Map and the tile info graphics are drawn with patterns that are mapped at the end of the frame, which doesn't allow us to debug the upper parts of the screen when patterns are switched mid screen. FCEUX has a "show on scanline" box so that you can sample the PPU on specific scanlines.
I tested several games in this emulator.
There's no DMC channel emulation, so naturally, DMC IRQs don't work either. No frame IRQs either.
Triangle Wave sometimes plays longer than it should in games like Kirby's Adventure.
The Slalom Test fails. Coarse X scroll and Fine X scroll do not seem to be updated correctly. Fine X should update immediately, and Coarse X should be updated on the next scanline due to the timing of the scroll writes.
Super Mario 3 crashes (KIL opcode) when you start a new game, and half of the Nintendo logo is missing.
My Chu Chu Rocket homebrew looks really bad on the emulator, not just IRQ problems, but wrong CHR problems as well. Many emulators get this game wrong, but it's usually always IRQ timing problems. I guess it's a good testcase for debugging MMC3 and timing problems.
Kickmaster doesn't run at all.
"High Hopes" demo mostly works, but has a few scrolling glitches, but the streaming PCM sounds great. I was surprised to hear this when DMC wasn't working.
Elite is very shaky.
PAL sound pitch is too high, it's playing at NTSC-like frequencies.
Battletoads dies (misses the sprite 0 hit).
@ tokumaru
Good ideas! ...and more work to implement them.
Snapping would be neat, and would also require a disable snapping option (else scaling to factor 1.99 would become much smaller as the user may have desired it). The other thing that would be need (and more work) would be smooth resampling.
For palettes, you can select grayscale (useful if palette is all zerofilled). A feature for selecting from the 8 PPU palettes... I don't know how useful it'd be - it would require the user to select palettes manually, in most cases that's probably more user-interaction than you want to do (assuming that you just want to have a short look at what is in vram).
Scanline select could be really comfortable. At the moment (less comfortable), it should work if you place a breakpoint somewhere mid-frame (at least, it SHOULD work, if it doesn't, then I've screwed up something).
@ Dwedit
Thanks! Slalom test... that's the Slalom games, like in VS Slalom? I had noticed that game didn't work when testing VS emulation - but didn't figure out what I did wrong with it - must have been related to the Fine X thing, good to know that!
For APU, until a few days ago, I wasn't even aware of the more subtle PAL vs NTSC differences. The timing constants (like noise frequency table) seem to be different for PAL; and aren't yet emulated. For the normal triangle/rectangle channels, I was thinking that the game is responsible for matching the frequency values to PAL, so I could just use the same FrequencyValue to CpuClockCycle conversion as for NTSC, which should be working "automatically". Maybe I've messed up something else elsewhere - like the fundamental 50Hz base frame rate :-) or it's been just a PAL detection problem - did you try selecting "PAL" manually in setup?
Sound Frequency = CPU speed / 16 / (period value + 1)
NTSC Mode runs the CPU at 1.789772667MHz. PAL Mode runs the CPU at 1.662607MHz.
So the sounds play at a different frequency on the NTSC console vs the PAL console for the same period value. It's roughly one half-step lower on the PAL console. 127.595 cents lower. (Cents is a logarithmic scale, 100 cents is the difference between C and C#)
I was testing this with the High Hopes demo, which only runs in PAL mode. I configured the emulator to force PAL mode. And the sound frequency was about one half-step too high.
About Slalom...
Slalom writes to 2005 during the "hblank time", which is the time between dot 256 and 341. Slalom begins most of its writes between dot 293 and dot 317.
At dot 257 of each scanline, the coarse horizontal scroll bits (.....x.....xxxxx) are copied from the latch value "T" to the vram address value "V".
So even though the game just wrote a new scroll value to 2005, it won't apply until the next time the PPU reaches dot 257.
But changes to fine X scroll apply instantly no matter when the 2005 write took place.
So the game is writing values to $2005 with the low 3 bits containing fine X for the upcoming scanline, and the top 5 bits containing the coarse X for the scanline after that.
Note that write instructions begin at a particular timestamp, but the write only actually happens when the write cycle of an instruction completes. For example, most games do sta XXXX, which takes 4 CPU cycles. The write cycle is the last part of that instruction. If you multiply by 3 to convert to PPU dots (for NTSC), you get 12 dots. So an instruction might begin executing at dot 245, but will finish at dot 257.
Important timings:
Dot 304 of prerender scanline: V = T
Dot 251 of each scanline: Y scroll bits of V are incremented. T is unaffected.
Dot 257 of each scanline: X scroll bits of T are copied to V.
Get these timings good, and all the scrolling glitches disappear. Then you just have to worry about accurate timing for external IRQs, like MMC3.