It is currently Wed Nov 14, 2018 1:15 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 583 posts ]  Go to page Previous  1 ... 18, 19, 20, 21, 22, 23, 24 ... 39  Next
Author Message
 Post subject: Re: Mesen - NES Emulator
PostPosted: Sun Mar 11, 2018 7:20 am 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 526
Quick test on Visual NES with this code starting at $0000:
Code:
  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:
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:
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.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Sun Mar 11, 2018 12:31 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7714
Location: Seattle
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.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Sun Mar 11, 2018 2:26 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 526
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 21 times
Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Sun Mar 11, 2018 7:10 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7714
Location: Seattle
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 22 times
Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Sun Mar 11, 2018 7:21 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 526
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?


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Sun Mar 11, 2018 8:19 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7714
Location: Seattle
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)


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Sun Mar 11, 2018 8:29 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 526
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.)


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Sun Mar 11, 2018 8:37 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 7714
Location: Seattle
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?
Quote:
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.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Sun Mar 11, 2018 8:51 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 526
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)


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Mon Mar 12, 2018 7:30 am 
Offline

Joined: Mon May 30, 2011 9:01 pm
Posts: 205
Sometimes I get the "Copy Nametable" function glitch. May be the game is updating the nametable? Anyway to avoid this?


Attachments:
1942error.png
1942error.png [ 25.27 KiB | Viewed 1049 times ]
Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Mar 14, 2018 8:44 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 526
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.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Wed Mar 14, 2018 11:25 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6949
Location: Canada
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.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Thu Mar 15, 2018 3:52 pm 
Offline

Joined: Sun Feb 07, 2016 6:16 pm
Posts: 526
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.


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Thu Mar 15, 2018 4:22 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 6949
Location: Canada
Well here's your log window:
Code:
------------------------------------------------------
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?"


Top
 Profile  
 
 Post subject: Re: Mesen - NES Emulator
PostPosted: Sat Mar 17, 2018 8:25 pm 
Offline
User avatar

Joined: Sat Jan 09, 2016 9:21 pm
Posts: 492
Location: Central Illinois, USA
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
debuggerBug.png [ 79.66 KiB | Viewed 861 times ]

_________________
My games: http://www.bitethechili.com
Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 583 posts ]  Go to page Previous  1 ... 18, 19, 20, 21, 22, 23, 24 ... 39  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google [Bot] and 5 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group