Looks like a problem with the triangle channel linear counter. Should be an easy fix.
I'll look into it in the next couple of days. Thanks for the report.
EDIT: fixed
Yes. Dip switches are part of the sync settings and are not controls like ‘insert coin’. You can find them in one of NESHawk’s menus (I’m not at my computer right now though to check which one .)
An interesting development has come up in NES emulation recently that might lead to better possibilities for console verification.
You can read about the details here: http://forums.nesdev.com/viewtopic.php?f=3&t=18113
Basically, a bus conflict exists when writing to ppuaddr ($2006) which causes incorrect scrolling to happen. The most obvious effect of this is the background glitching out.
But, a side effect of this is that it can effect sprite zero hit (since sprite zero hit requires a non-zero background pixel.)
Any game that happened to run into this in the past would fail on console since it was completely unemulated. I'm thinking Battletoads warpless probably ran into this at some point, but haven't tested for sure.
The results are still coming in but it seems completely consistent and easy to emulate. There is also the possibility that other registers (notably ppuscroll at $2005) might have similar difficulties.
This is pretty exciting since console verification (at least from my perspective looking at the emulator side) was basically stuck without any leads, and now things are starting to open back up again.
So expect some relatively big commits coming down the line. Overall very few games should be effected, but it may cause desyncs in some cases.
Alright, a bit of exciting news, I finally figured out how to sync movies between Mesen and NESHawk!
This took me many hours of frustration only to find that the problem was just a flag that was set differently between Mesen and NESHawk at power on.
But now I should be able to do sync testing between them and look for differences in a way that actually makes sense.
I already tried with Streemerz and the results are encouraging, perfect sync at similar power on state. And since Streemerz is known to be a ppu timing sensitive game, this brings fresh hope that it should be verifiable on console (once I re-make a run with the Mesen settings.)
I also started implementing the new finds with $2006 writes, but so far it has minimal impact (since most games rightly stay away from this case.) But still it's an important accuracy improvement, with more edge cases still to come.
Assuming these things sort out existing problems with getting basic runs to sync on console, it will finally be time to look ahead to the dreaded DMC DMA cases and games that use a reset sequence.
I made some improvements to NESHawk that give a roughly 5 fps boost in performance through some simple code optimizations.
Some gems of wisdom include:
if (true)
else if (false)
replaced by simply:
if (true)
else
I also rewrote the audio handling to bring it in line with other cores and simplify it a bit.
Note that these changes break savestates (but not sync)
Joined: 9/12/2014
Posts: 541
Location: Waterford, MI
Is the nanjing mapper supported? The one with ff7 on nes? I'm not sure if this was an emulator bug or game bug, but on fcuex, the equipment in that game was pretty selective for some reason. What I mean is, when red XIII joined the party, he came with some good equipment. Removing that equipment for someone else doesnt seem to make any difference? Also, equipment that is dropped in one area like before guard scorpion saved up for tifa before air buster, the strength stats somehow maxes out and says her strength stat is very high. When in battle, it doesnt seem to have any effect.
How would they screw that up? Some pointer goes somewhere else? Not read right?
I have updated NEShawk's startup state to match console testing I have been doing. Now several more timing sensitive games console verify that didn't work before. Donkey Kong, Nightshade, Roger Rabbit all sync on console through full runs.
I nice side effect of the state I chose (out of 3 more or less equally reasonable options) is that the runs of Battletoads still sync, with very minor adjustment for initial lag frames. I have console verified the current 2 player warps run to verify this, will post videos when I organize everything.
I've also made some other small updates to how input is polled so that games like Bionic Commando which hit some edge cases now console verify as well. this game always gave trouble before, but the emulation was never wrong, only the communication between emulator and console.
I'm very confident in the new state, and am hopeful many more games can be verified now, and maybe progress can be made on DMC timing (assuming it's not random.)
As a final side note, the Streemerz runs, which have never worked on console, still work in the new state, that game is a real mystery!
Link to video
Was it necessary to resync these TASes in order to verify them? If so, do you have the resynced movie files available somewhere?
What do you mean by the communication between the emulator and console? Also, if small updates had to be made, how was the emulator never wrong? Isn't input polling, a part of the emulation?
Curious, what were these edge cases?
Yes resyncing was necessary, as I get organized I am putting files here: https://github.com/alyosha-tas/NES_replay_files
I mean things that got sent to lua scripts were slightly wrong (lag detection, input poll event), actual execution didn't change at all (except right now with the start up state update, but that doesn't matter for bionic commando.)
Bionic Commando occasionally encounters situations where input is polled, but then not read because something else interrupts it. Before fixing things up this would result in bad lag detection and mess up the dump. Additionally, the all items run runs into a case where input is polled twice in one frame (it only happens once in the entire run!) and this case was missed by the frame dump script, so it needs the poll dump script.
Link to video
Some interesting new quirks are being discovered in the NES by the folks at NesDev.
In particular, OAM DMA will read data from the external bus whenever the cpu is accessing the external bus. One implication of this is that there are 0x20 bytes at 0x4000 that OAM DMA can read but the CPU cannot (because the CPU will always access registers there.) It works in the other direction too, OAM DMA will access registers if cpu is executing from register space. (Setting this up is very non-trivial, the test ROM Fiskbit came up with is a pretty good emulator test just to get the setup right.)
I just implemented this into NESHawk:
This doesn't really mean anything for TASing, I just think it's cool to see new things still being discovered.
With some more help from Fiskbit in working out some edge cases, and puzzling out a few remaining unknown effects myself, the milestone of being able to console verify NES games with full DMC emulation is finally being achieved. The end result is verification of a resync of Super Mario Bros 3 Warpless:
Link to video
At the moment, I do not have any TASes known to desync on console due to emulation issues. Other games using the DMC channel also work, such as Tiny Toon Adventures 2:
Link to video
(I also have a TAS of Time Lord that syncs on console up to the last boss but very unfortunately desyncs due to uninitialized RAM.)
Starting with 2.7.1, most NES games should be console verifiable with NESHawk.