Thanks, here are the results: -Both Bionic Commandos sync to the end. -With a small modification (altered the PPU/APU sync after reset in CPU::Reset), Battletoads syncs at first, but then desyncs a bit after the warp. -Both streemerz runs desync. streemerz_joe desyncs almost right away. The other one gets relatively far (maybe ~2 mins in?) and eventually desyncs in a room that had ~10 clowns. For the bugs after compilation, the build process is silly and you need to build 2x for it to work properly (otherwise the resource files will be missing from .exe) - it shouldn't be an issue except the very first time you build it. Also, I just commited support for MD5 hash checks in bk2 files (had only implemented SHA1 ones since it seemed like they were the only thing used), you'll need that if you want to try the Bionic Commando/Battletoads movies.
DId you mean altered PPU/CPU sync? because I don't think battletoads is affected by the APU in any way.
Mesen has an option to at least simulate OAM decay.
A high-level description of what the test does and what the numbers shown on the screen mean would be really helpful in trying to figure this one out.
1) you sprites seems just disappers instantly , not by time? 2) not some bits memory corrupted, your just clear all to zeros? you may simulate some bit corruption using random. 3) sprite 0 visually no changes on hardware (but as I understand 'sprite hit' logic broken) even after 4 seconds.
For the sprite flashing, I don't know - it could be the Famicom, it could be the flash cart being used, or it could be some undiscovered behavior that no emulator emulates properly.
BANKF:C343 LDX #$C3BANKF:C2C2 BIT PPU_SPR_DATAI've looked - they did timed code change in a new rom , LDX #$D2 was changed to LDX #$C3
is there a frame counter in mesen? I found a lag counter but couldn't find the frame counter. Also , what do think of powering on nes from CPU reset routine ? This is what biz hawk currently does and it would make it easier to compare trace logs.
LDA #$80
STA $2003
LDA #2
STA $4014 ; SPR_DMA getting the precise timing for this thing to work will probably be relatively hard + there might be some edge cases that might exist, too.
=Messing around with it, I managed to make Mesen pass like 3 out of the 13 scenarios, but nothing better than that.
Surprisingly, there wasn't - I've never had a need for one, and nobody ever asked for one until now. I just added one though - it's in Options->Emulation->Advanced Not sure what you mean by powering from a reset routine? Both power & reset in Mesen call CPU::Reset which runs the PPU/APU for a number of clocks while the CPU is starting and fetching the reset vector's value, etc.
What happens on hardware, seems how it's works based on time/ chips temperature: When you just turn on console, you will see picture same as bug emulation on. after 1,5-2min bug disappear and you will see picture same as without bug emulation.
I mean counting the CPU cycles that takes in the trace logger so it starts at 8 (9?) instead of 0. EDIT: Also I'm noticing that Mesen seems to not be resetting everything completely on reloading a game / doing a power cycle. I am working with the game Bible Buffet (USA) (Unl) (v6.0) and when I first open Mesen and load the game, it takes 9 lag frames to get to the title screen. But, if I subsequently load the game or do a power cycle, it takes 10 lag frames, any ideas what is causing that?
The CPU calls MemoryRead()/MemoryWrite() for every CPU cycle - the first thing done in either of them is to call IncCycleCount(), which runs the PPU/APU. So this is done before actually reading/writing to memory. If what you're checking is vblank-based, it might be worth mentioning that Mesen sets vblank on cycle 0 (scanline 241) and clears it at cycle 1 (scanline -1) - whereas the timing sheet on the wiki says it should be set on cycle 1, iirc. I think Nintendulator also does this, but unsure. I feel like I took a look at this in the simulators before, but can't recall the result.