Mesen - NES Emulator

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

Quick test on Visual NES with this code starting at $0000:

Code: Select all

  SEI
  CLD
  LDX #$FF
  TXS
  INX
  STX $2000
  STX $2001
loop:
  LDA $2002
  BPL loop
loop2:
  LDA $2002
  BPL loop2
  LDA #$80                 
  STA $4017                
  CLI                      
loop3:
  jmp loop3
In hex:

Code: Select all

78 D8 A2 FF 9A E8 8E 00 20 8E 01 20 AD 02 20 10
FB AD 02 20 10 FB A9 80 8D 17 40 58 4C 1C 00
And surprisingly, it does appear to clear the IRQ flag:

Code: Select all

cycle: 0A7887 hpos: 1F vpos: F1 ab: 080A db: 0A cpu_a: 80 cpu_x: 00 cpu_y: 00 cpu_db: BF cpu_ab: 4017 io_rw: 00 io_ce: 01 cpu_frame_irq: 01 
cycle: 0A7888 hpos: 1F vpos: F1 ab: 080A db: 0A cpu_a: 80 cpu_x: 00 cpu_y: 00 cpu_db: 80 cpu_ab: 4017 io_rw: 00 io_ce: 01 cpu_frame_irq: 00 
As soon as it gets to scanline 241 (F1) and the write to $4017 occurs, cpu_frame_irq goes back to 0 (unless I'm looking at the wrong signal - the cpu_ prefix is Visual NES' way of fixing name conflicts between both cores). It looks like the effect is immediate, too, rather than being delayed by a few cycles like the sequence reset is.
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Mesen - NES Emulator

Post by lidnariq »

Sour wrote:As soon as it gets to scanline 241 (F1) and the write to $4017 occurs, cpu_frame_irq goes back to 0 (unless I'm looking at the wrong signal - the cpu_ prefix is Visual NES' way of fixing name conflicts between both cores). It looks like the effect is immediate, too, rather than being delayed by a few cycles like the sequence reset is.
While I can reproduce that behavior in Visual2A03 (SEI / LDA #$80 / - manually set /frame_irq low then high - / STA $4017) I can't see which node is pulling frame_irq low. The cycle of the write, the S-R latch flips without obvious reason.

There are eight transistors that directly affect or are affected by frame_irq and /frame_irq -
t12655 and t12662 - frm_d AND frm_/seqmode can pull /frame_irq low
t12691 - the S/R latch, frame_irq pulls /frame_irq low
t12695 - /res pulls frame_irq low
t12739 - the S/R latch, /frame_irq pulls frame_irq low
t12783 - frm_intmode pulls frame_irq low
t12785 - ultimately allows reading the IRQ status from $4015
t12794 - reads from $4015, during φ1, pulls frame_irq low
t12838 - frame_irq pulls something low that pulls irq_internal high

So I literally don't understand how what the simulator says is happening happens.
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

I made a small NROM test - I ran it on Visual NES & it passes (screen output is half broken as usual, but the nametable was updated with the "pass" string). If someone could test this on a NROM board of sorts, that'd be great - otherwise a powerpak/everdrive would be ok, too (assuming I didn't screw something up in the test). Might be interesting to run on PAL & NTSC - although I'd imagine the results will be the same.

It's meant to output "1 FAIL" or "0 PASS". It writes pass if no IRQ occurs after writing $80 to $4017 when an IRQ was pending.
Mesen/Nestopia fail this at the moment, FCEUX/Bizhawk pass - so the behavior seems to vary between emulators.

The (terrible) asm6 source code is also included (thanks to tokumaru for the template, and rainwarrior for the CHR data!)
Attachments
FrameCounterIrqAckTest.zip
(31.17 KiB) Downloaded 147 times
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Mesen - NES Emulator

Post by lidnariq »

I've (lightly) modified your code to run on my mapper 218 cart and (heavily) modified to build under my ca65 toolchain. (That was silly, I really should have just ported the "prepare m218" function I've already written for xa65 and ca65 to asm6 for future inclusion instead)

Testing: I reliably see "1 FAIL" on my hardware. (2A03G)
Attachments
FrameCounterIrqAckTest-m218.zip
(4.9 KiB) Downloaded 142 times
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

Some code in your version seems to be writing #$E0 to $01:
LDA #$E0
STA $01

$01 is used by the irq handler to check if an IRQ did run or not, so that might be why it's always failing?
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Mesen - NES Emulator

Post by lidnariq »

When I relinked and used variable names it ended up moving the counter to address 2 instead. (Word at 0 contains a pointer for uploading the mapper 218 CHR)

My rewrite does reliably "fail" in Nestopia, and "pass" in FCEU/FCEUX.

(I also specify mapper 7 w/ 1KB CHRRAM instead of mapper 218)
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

Ah, my bad. So either it varies from one model to another, or the Visual 2A03 isn't behaving properly in this case (which would be a pretty big coincidence, but you never know.)
lidnariq
Posts: 11432
Joined: Sun Apr 13, 2008 11:12 am

Re: Mesen - NES Emulator

Post by lidnariq »

Tangentially related, I found a silly bug in Mesen's mapper 218 implementation. If I specify "PPU A13 is connected to CIRAM A10", that's byte $A9 in the header. Mesen's loader fixes that to become byte $A8, which is then parsed as "PPU A12 is connected to CIRAM A10".

Honestly, using the 4-screen bit in the header to mean various 1-screen layouts is stupid and I think submappers should be used instead (and that goes for UNROM512 as well!), but ...


Sour wrote:So either it varies from one model to another,
Er, do you have a hardware report that disagrees with mine?
or the Visual 2A03 isn't behaving properly in this case
Visual2A03 is based on a decapped 2A03G, not one of the other revisions. So theoretically it should behave the same as the IC in my NES. That it doesn't—especially given that I don't see why frame_irq is pulled low on the node that it does—strongly implies there's something weird going on with the simulator.
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

lidnariq wrote:Tangentially related, I found a silly bug in Mesen's mapper 218 implementation.
Ah, yea, that's because Mesen implements the suggestion to have 4-screen + vertical = Screen A only mirroring in NES 2.0 files, which conflicts with the logic I used for 218. It's a simple fix, though. (But I agree this is pretty hacky at this point.)
lidnariq wrote:Er, do you have a hardware report that disagrees with mine?
Nope, just (wrongly) assumed the Visual 2A03 wasn't the same model :) At this point, I'd be tempted to agree it's probably just an issue with the simulation (unless someone else gets a different result on their end)
mkwong98
Posts: 282
Joined: Mon May 30, 2011 9:01 pm

Re: Mesen - NES Emulator

Post by mkwong98 »

Sometimes I get the "Copy Nametable" function glitch. May be the game is updating the nametable? Anyway to avoid this?
Attachments
1942error.png
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

mkwong98 wrote:Sometimes I get the "Copy Nametable" function glitch. May be the game is updating the nametable? Anyway to avoid this?
Thanks - this should be fixed (for all 3 viewers) in this build: download

Support for color emphasis/grayscale bits in HD packs was added, too. Nothing has changed in the definition files, the HD frame just gets altered to match the emphasis/grayscale bits (this is only precise on a scanline level, though, based on the first pixel in the scanline)
It also adds 2 new conditions: ppuMemoryCheck/ppuMemoryCheckConstant which work like the memoryCheck/memoryCheckConstant variations, but use PPU addresses instead ($0000-$3FFF, where anything > $3F00 is the palette)

The build also contains 2-3 fixes for minor debugger UI issues.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Mesen - NES Emulator

Post by rainwarrior »

I have two 8-bit Xmas ROMs (2012 and 2014), not sure if they're publicly released so I can't share them, but they seem to indicate a problem with the UNROM 512 mapper:

I'm noticing CHR bank switching and other glitches with these ROMs that don't occur in FCEUX. I suspect it's the register only covering $C000-FFFF in the variants of the board that have LED lights attached, since they use an additional register at $8000-BFFF (conveniently also required for self flashing, so generally enabled by the battery save flag).

Edit: doesn't actually seem to be a conflict in the $8000-BFFF range, I rescind this suggestion. There is a CHR banking problem when played in Mesen but I'm not sure what it is yet. Forcing XMAS 2012 to 8k CHR-RAM hides the problem, but XMAS 2014 relies on 32k CHR banking.

Edit: the bug is actually really weird, what is happening is that one of the CHR pages is being corrupted.

What appears to happen is that when CHR bank 00 is selected and the nametable at PPU $2XXX is written to, CHR-RAM at $6XXX is also written to at the same time, corrupting it. This actually triggers a breapoint for CHR write at that address range, too! I have no idea why this is specifically happening for the $6000 page, but that's what seems to be the problem. Somehow writing to $2XXX (at least the first 1K anyway, the game only uses the frst nametable) when CHR bank 0 is selected is also writing to CHR $6XXX.

Edit: Looked up your implementation and the answer is apparent, you are explicitly mapping it there for the 4-screen mirroring case, except you're not really testing for 4-screen mirroring... you're testing for !_oneScreenMirroring which you've used to conflate 4-screen and 1-screen?

My ROMs are set as horizontal mirroring, incidentally (not sure if that's how the carts are wired, but they only ever write to the first nametable anyway), but I'm pretty sure this mapping should only occur when 4-screen mirroring is requested, not 1-screen, and not hardwired horizontal or vertical.
Sour
Posts: 891
Joined: Sun Feb 07, 2016 6:16 pm

Re: Mesen - NES Emulator

Post by Sour »

The implementation for UNROM-512 is almost completely untested - the only ROM I ever found for it was a demo for a game (forgot which). Everything else appears to not be readily available on the internet (which is well, good for the creators, and bad for me :p). And the single "test rom" I had found posted on the FCEUX bug tracker didn't appear to match the description on the wiki, either.

What does the log window say about the ROM? Mostly interested about whether it's listed as a NES 2.0 rom, and what mirroring it gives the ROM. For your theory to work, the ROM would either marked be as 4 screens (iNES), or marked as 4-screens + horizontal (if it's NES 2.0 - which was a proposal on how to mark a rom as 1-screen mirroring in NES 2.0). It looks like the log window would display "Four screens" in both scenarios, though.
User avatar
rainwarrior
Posts: 8734
Joined: Sun Jan 22, 2012 12:03 pm
Location: Canada
Contact:

Re: Mesen - NES Emulator

Post by rainwarrior »

Well here's your log window:

Code: Select all

------------------------------------------------------
Loading rom: xmas_2014_unrom512.nes
File CRC32: 0x5D8AFC72
------------------------------------------------------
[DB] Initialized - 3100 games in DB
PRG+CHR CRC32: 0x5C1AA732
[iNes] NES 2.0 file: Yes
[iNes] Mapper: 30 Sub:0
[iNes] PRG ROM: 128 KB
[iNes] CHR ROM: 0 KB
[iNes] CHR RAM: 32 KB
[iNes] Work RAM: 0 KB
[iNes] Save RAM: 0 KB
[iNes] Mirroring: Horizontal
[iNes] Battery: Yes
[DB] Game not found in database
Sour wrote:For your theory to work, the ROM would either marked be as 4 screens (iNES), or marked as 4-screens + horizontal (if it's NES 2.0 - which was a proposal on how to mark a rom as 1-screen mirroring in NES 2.0). It looks like the log window would display "Four screens" in both scenarios, though.
The 4-screen bit is clear, and the CHR RAM is set to 32k. With both of these conditions it triggers that "4-screen" mapping of PPU $2000 to CHR $6000 without having a 4 screen setting.

Your code's logic isn't checking for whether it's 4-screen or not to apply that mapping:
  • Is it NES 2.0 ? Yes
  • Is it one screen? No. (This test should be "is it 4 screen")
  • Is there >= 32k of CHR RAM? Yes.
I think the problem in your intended implementation is in InitMapper above. If iNES 1 is used, it should interpret the "4-screen" flag as enabling the 1-screen register instead of hard-wired H/V mirroring. If iNES 2 is used, it should select between 1-screen or the 4-screen if the 4-screen flag is set, depending on H/V, right?

Except your code asks if(IsNes20()) and not if(!IsNes20()). At least, I think it probably works okay with that flipped... but I think it would be better to have the code more directly / semantically asked "Is it 4-screen?" rather than "Is it not 1-screen?"
User avatar
gauauu
Posts: 779
Joined: Sat Jan 09, 2016 9:21 pm
Location: Central Illinois, USA
Contact:

Re: Mesen - NES Emulator

Post by gauauu »

Sour wrote:
mkwong98 wrote:Sometimes I get the "Copy Nametable" function glitch. May be the game is updating the nametable? Anyway to avoid this?
Thanks - this should be fixed (for all 3 viewers) in this build: download
This version crashed on me repeatedly, until I destroyed my ~/.config/mesen directory. At that point roms ran again, but I have the issue (someone mentioned before) where the debugger window is blank, and clicking anywhere in it gives the following error dialog.
Attachments
debuggerBug.png
Post Reply