Page 3 of 67

Re: Mesen - NES Emulator

Posted: Wed May 11, 2016 7:31 am
by x0000
Hi, Sour
You said
it passes more test ROMs than any other emulator currently available
and I have to disagree. puNES does better, at least on my set.
So, the tests that it failed:
  • ppu_sprite_hit/09-timing.nes
    #4 Flag set too late for upper-left corner
  • ppu_sprite_overflow/03-timing.nes
    #4 Flag cleared too late at end of VBL
  • test_apu_timers/dmc_pitch.nes
    Sounded noticeably wrong
  • tvpassfail
    No real surprise here I guess
  • test_apu_m
    My self-written tests (you can find my post somewhere on this forum). Not all of them are ok due to sync problems, but the ones I've attached should never fail on NES
I don't have a NES right now and can't check this on a real hardware, but I am pretty sure the tests should be correct. And I don't really remember what my tests were about, so don't ask me)

Re: Mesen - NES Emulator

Posted: Wed May 11, 2016 2:17 pm
by Sour
Hey,

Thanks for testing, I did not have any of these tests in my sets.
I was using similar sprite hit & overflow tests, which did pass, but the ones you mentioned don't.
Although, I just tested on the latest puNES release and these 2 tests also fail? They also seem to fail on my potentially out-of-date Nestopia and fairly recent copy of Nintendulator.
I imagine the tests pass on a real NES, but I do not have any way to personally verify this...

Your 3 tests do pass on puNES & Nintendulator, so I'll definitely take a look at those and the DMC test, too.
Thanks again!

P.S: tvpassfail does pass, if you enable the NTSC filter :)

Re: Mesen - NES Emulator

Posted: Wed May 11, 2016 3:12 pm
by Zepper
Uh... What do tests 9,10,11 really do? Care to describe them???

Re: Mesen - NES Emulator

Posted: Wed May 11, 2016 4:43 pm
by x0000
Zepper wrote:Uh... What do tests 9,10,11 really do? Care to describe them???
Well...
x0000 wrote:And I don't really remember what my tests were about, so don't ask me)
I mean, I wrote these tests more than 3 years ago, and I don't have any notes left since then. And I bet even if they existed I would be still unable to tell their purpose.
If I remember correctly all tests checked proper length counter decrease overlapping with writes to 0x4017, but how exactly? Here what I can guess from the listings:
1-4 check if 0x4017 write causing additional HalfFrame/QuarterFrame signals mess up normal decrease
5-8 same in 0x80 mode
9-10 check if lfsr resetting after 0x4017 write mess up normal decrease
11 no idea.

Re: Mesen - NES Emulator

Posted: Thu May 12, 2016 2:01 am
by x0000
Found this in my correspondence with FHorse
x0000 wrote:From wiki:
After 3 or 4 CPU clock cycles*, the timer is reset.
Thats true, but if you count clock cycles as ~W goes low, write commit is actually on ~W goes high. Anyway, It tells that timer is reset after 3 or 4 clocks.
Note: Writing to $4017 with bit 7 set will immediately generate a clock for both the quarter frame and the half frame units, regardless of what the sequencer is doing.
Thats not true at all. First of all, half frame and quarter frame can be generated only on odd cycles. But for 0x4017 it is actually generated on reset_cycle - 1, because reset (as well as any other change of framelfsr) can happen only on even cycle. But if both frame counter and 0x4017 generates half_frame, quarter_frame there still would be only one clock committed.
If someone can explain what I meant there please tell me I am curious too.

Re: Mesen - NES Emulator

Posted: Thu May 12, 2016 4:07 pm
by Sour
Like the Wiki says, writing to $4017 has a delayed effect (applied 3 or 4 cycles later, to correspond with an odd cycle?).
Writing with bit 7 set to $4017 clocks the half/quarter frames, but does so after the 3/4 cycles delay (this wasn't implemented in my emu).
Additionally, it looks like if the frame counter is reset at or around the same time it clocks the half/quarter frames through its normal process, the extra frame clock that is normally caused by a write to $4017 (with the high bit set) does not occur.

Implementing both of these behaviors makes Mesen pass all of these tests (1 to 11) - although I am unsure of how accurate my implementation is vs the actual NES.

Thanks for making those tests!

Re: Mesen - NES Emulator

Posted: Fri May 13, 2016 12:50 am
by x0000
It cannot be 3-4 cycles delay, it is either 1-2 or 2-3 cycles depending where you count from. Half-frame and quarter-frame signals should happen before lfsr resetting. Or am I wrong?

Re: Mesen - NES Emulator

Posted: Thu May 19, 2016 6:10 pm
by Sour
Hey, just a small update, I just released Mesen 0.1.4.

It fixes all the tests mentioned by x0000 as failing on Mesen:
ppu_sprite_hit/09-timing.nes
ppu_sprite_overflow/03-timing.nes
test_apu_timers/dmc_pitch.nes
test_apu_2 - tests 1 to 11

It also adds support for mapper 15 & 60.


Thanks for the bug reports, x0000 - if anybody knows of any tests or games that fail on Mesen, please let me know!

Re: Mesen - NES Emulator

Posted: Fri May 27, 2016 4:35 pm
by Sour
Another update released - version 0.2.0.

This update adds a lot of video filters (xBRZ, Scale2x, HQX, 2xSai, Super2xSai, SuperEagle), and options for the NTSC filter and configuration common for all filters (Brightness, Hue, Saturation, Scanlines, etc.)

It also adds Google Drive integration - which lets you put your save games & save states in your Google Drive account (to keep an automatic backup and/or sync them across multiple computers).

A number of bugs (crashes, etc.) were fixed as well, and Mesen no longer depends on the MSVC++ 2015 runtime being installed to work - its only requirement is having .NET 4.5.


If you try it out, let me know what you think!

Re: Mesen - NES Emulator

Posted: Mon May 30, 2016 8:12 am
by x0000
Sour wrote:if anybody knows of any tests or games that fail on Mesen, please let me know!
Try out The Incredible Crash Dummies and Kick Master, many of emulators have difficulties running them (although it is basic A12 counter).

Re: Mesen - NES Emulator

Posted: Mon May 30, 2016 10:38 am
by Eugene.S
Mesen is really interesting emulator with many settings and "lots-of-stuff".
I've found a bug in 0.2.0 beta: "Battletoads (U)" and "Battletoads and Double Dragon (U)"
hangs in dendy-mode, this is wrong behaviour.

Re: Mesen - NES Emulator

Posted: Tue May 31, 2016 8:52 pm
by Sour
The Kick Master issue was caused by a race condition (write to $2006 at the same time as the cycle 256 Y scrolling increment). The game expects the $2006 value to win and the scrolling increment to be ignored (but it wasn't), which produced the weird effect on the title screen.

The Incredible Crash Dummies is apparently not an MMC3 game, but uses the MC-ACC chip which has a slightly different IRQ behavior. I implemented the behavior for it and it fixes the game, but this currently relies on proper NES 2.0 headers (submapper 3) since I'm not sure I want to start putting hash checks into Mesen..

As for Battletoads freezing in Dendy mode: Dendy mode was incorrectly giving 21 scanlines worth of vblank after firing the NMI, instead of 20, which caused Battletoads to freeze. Both games seem to work correctly now.

Thanks to the both of you for the bug reports!

Re: Mesen - NES Emulator

Posted: Wed Jun 01, 2016 7:41 am
by Eugene.S
Incorrect APU volume sliders behavior, like fceux has: https://sourceforge.net/p/fceultra/bugs/710/
puNES also had same problem, but it was fixed in 0.95.

Re: Mesen - NES Emulator

Posted: Wed Jun 01, 2016 5:21 pm
by Zepper
Sour wrote:The Kick Master issue was caused by a race condition (write to $2006 at the same time as the cycle 256 Y scrolling increment). The game expects the $2006 value to win and the scrolling increment to be ignored (but it wasn't), which produced the weird effect on the title screen.
That's what I had reported without success. What a shame... How did you fix it? It affects Mega Man 5 too.

Re: Mesen - NES Emulator

Posted: Thu Jun 02, 2016 5:34 pm
by Sour
Eugene.S wrote:Incorrect APU volume sliders behavior, like fceux has: https://sourceforge.net/p/fceultra/bugs/710/
puNES also had same problem, but it was fixed in 0.95.
Thanks, this is fixed as well.
Zepper wrote:That's what I had reported without success. What a shame... How did you fix it? It affects Mega Man 5 too.
In my case, the second write to $2006 occurs after cycle 255, and right before cycle 256 runs. I changed the code so that a write to $2006 that updates the vram address and occurs at that point (post 255, pre 256) will cause the PPU to ignore the Y scrolling increment on cycle 256, preserving the new value that the CPU has written instead (Commit). This fixes Kick Master in my case, and is the only fix I found that did not break any test rom.