My point is, we need the code to know how it fixes things.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
FHorse (13:22:05 17/09/2016)
regarding count_errors the conflict depends from the bits 5-7 of the read of $4016 or $4017
if return 0x40 (standard controllers) there is conflicts
http://wiki.nesdev.com/w/index.php/Standard_controllerФеос (13:25:48 17/09/2016)
Open bus???!!!
FHorse (13:25:56 17/09/2016)
yes
Феос (13:25:59 17/09/2016)
OUCH
so having conflicts/errors there is a bug in the console itself?
FHorse (13:27:09 17/09/2016)
rather than a bug, a conflict :D
Феос (13:46:59 17/09/2016)
can you at least tell me what to count as test success or fail there?
FHorse (13:50:29 17/09/2016)
What I believe is that it is correct that there are "errors" with standard controllers. And I also believe that there are no precise points where errors (stars) occurs.
should be tried on more than one console to be sure.
Феос (13:51:14 17/09/2016)
do you think the test is useless in terms of accuracy and simply highlights undefined behavior that is always there?
FHorse (13:51:26 17/09/2016)
yes
Conclusion: I believe the test should be removed from our table.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
@feos: I guess I agree with removing them from the table. The tests DO provide some information, it's unfortunate they aren't timed strictly enough to be consistent though. But the behaviour is also tested in dmc_dma_during_read4/dma_4016_read, and in a stricter way, so I guess those other ones are redundant.
@Koh1fds: I'll add that to the list on the OP, but don't expect it to be worked out soon. It won't be easy to work backwards from an IPS patch alone, and there are many other mappers to work on first. If you know any other info about that hack it would certainly be helpful to have.
@Koh1fds: I'll add that to the list on the OP, but don't expect it to be worked out soon. It won't be easy to work backwards from an IPS patch alone, and there are many other mappers to work on first. If you know any other info about that hack it would certainly be helpful to have.
If you look at properties of the rom it have 64 x 8 = 512 kb of CHR rom. As far as i know there is no other roms on mapper 25 (or other mappers that emulates konami vrc2/4) that have this amount of CHR rom. Maybe this helps.
Another proof that count_errors/_fast is not related to accuracy:
Link to video
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
With a big thanks to Sergunov, we can confirm that greyscale check really does happen 2 ppu clocks later then originally thought (putting it right at the end of the pipeline.) I expected this would be true since otherwise the nmi_sync test makes no sense, but it is really good to have real video conifrmation of it.
Basically I modified the scanline/scanline test to change greyscale instead of background rendering. If they happened at the same time, we would expect the same pixels that are on in the background test to be grey scaled in the other test. However it is evident (V2 in the post above) that this is not the case, and in fact greyscale impacts things 2 pixels to the left.
With this, we can put the NMI_sync test as a 'pass' on NESHawk, making it currently the only emulator to do so (well, accurately anyway), although this is a trivial thing to add for other emulators since it is purely post processing.
Adelikat and I have also been making pretty rapid progress on the mapper front, Big thanks to him for doing the upfront coding work that I'm not quite able to do myself yet.
One other thing that is evident from the scanline tests is that something is definitely up with the nametable toggle (test number 2.) I don't see any reason why this should be occuring later but it is very evident form the test videos that it is, so something else to investigate I guess.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
When I convert the recent Ninja Gaiden movie to bk2 (inserting 2 frames at the start), neshawk ignores the A button around frame 6794, as well as any other input on that frame (except for Power and Reset), while still acting like I'm pressing Left, even if I remove that and press Right for that frame. Yet it reacts on any input changes at the surrounding frames. Quicknes works as expected there.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
Due to different power up behaviour, adding frames is no longer the way to sync FCEUX runs. The correct thing to do is remove 1 frame.
I did so and the run syncs correctly through the first level. It then desyncs at the ladder in level 2. Currently looking into why it happens, looks like it misses a 'right' press.
Will edit this post if I get any more info.
EDIT: nevermind problem is already obvious, it's a DMC hit. Hmmm, this is troublesome, it's certainly possible that this same hit would happen on console, but it's also possible it wouldn't. It would be nice if there were a way to add a method into the emulator to avoid this probabalistic behaviour but at the same time this is cycle accurate and correct, so fatal hits like this just come up now and then.
Anyone have any thoughts?
Also, I would be really really interested to see what happens on console. If code execution is tied closely enough Vblank, this hit might be deterministic, or at least happen with a high probability.
EDIT2: the old run desyncs in the exact same place, but that one is known to sync on console. We need more information, such as if the old run always syncs or only a certain percentage of the time.
I'm extremely busy but want to provide information to find resolution to this, so I will try to verify this and see if the same desync happens on console, pre- and post-conversion. Give me a week or two, I should have things set back up to verify by then.
feos: Thanks for bringing this up.
I noticed this after the 1.11.7 release, and it happens in all three NG games, though the tweaks since then have changed when it happens with a given input file. My intuition was that input that hadn't been made to account for this behavior would be pretty unlikely to sync on console, but lacked the hardware knowledge to really back that up.
Using the latest build (1.11.6.273) the published NGII run first runs into it at 10273 (or at least that's the first obvious de-sync), but pressing all buttons except B and select lets the input "get through." It happens again at 10892, where UDLRSs_A allows it continue to 11906. Button mashing won't help there since Ryu needs to move to the left.
As for NGIII: 997M @ 3541, 2507M @ 1934 & 1955.
Alyosha: Is the "button mash" effect something you'd expect to work as I described above? Short of hardware testing, what sort of additional information might be helpful?
True: looking forward to hearing about whatever you find.
If someone throws together a test rom, we'll be able to run it on Famicom AV.
Warning: When making decisions, I try to collect as much data as possible before actually deciding. I try to abstract away and see the principles behind real world events and people's opinions. I try to generalize them and turn into something clear and reusable. I hate depending on unpredictable and having to make lottery guesses. Any problem can be solved by systems thinking and acting.
@Scumtron: Short Answer: Yes, button mashing can resolve the conflict.
Long Answer: What's happening here is the DMC unit is changing the address from the controller port to wherever it's reading the DMC byte from. Once it's done, it puts the address back to the controller port. An unfortunate side effect of this is that this causes the controller port to see this as an extra read, and pushes the next key press onto the shift register.
Normally the port is polled 8 times for the 8 keys, but this extra poll from the DMC means one button is lost. The last button read is 'right' and the behaviour is that any reads after the 8th returns '1'='the key is pressed' so normally in this situation you see an extra right press and one lost key. Ninja Gaiden and other DMC using games compensate for this by polling the entire controller twice. What games do after this differs though. Some games, like SMB3, if they detect a conflict will do the whole routine again, and repeat until there is no conflict (which is where the possibliity of the 2 second SMB3 run from SGDQ comes from.)
Other games though, like Ninja Gaiden here, if they detect a conflict, just give up and fall back to the previous frame's input. This is fine for casual play where you mostly wouldn't notice, but under TAS conditions this is obviously fatal.
Mashing buttons simply makes the game think that both reads match (by hitting all the buttons after the extra poll took place, it looks like nothing is wrong.)
@feos: Something that would immediately help with determining if BizHawk's implementation of this is correct is running dmc_dma_during_read4/dma_4016_read with different buttons held down on the controller. Of particular interest would be the results from holding down A,B, A+B. This would at least confirm that the basics are all correct.
Beyond this I'm not sure what besides hardware testing can shed any more light on this. I tried adding and subtracting a few CPU or PPU cycles at startup see if I can get different sync behaviour. At best I can make it to about half way through level 3, but it seems inevitable that there will be a DMC hit somewhere. I'm not sure how the original run survived, could be a result of CPU - PPU alignment but I don't really know.
I removed the extra DMC read and both the new and old Ninja Gaiden runs sync just fine on NESHawk without it (after removing one frame at the beginning as before), so that is definitely the only problem. So I guess we just need to wait for results from True's console testing to see what happens.
Also I'm still making progress on mappers, so hopefully soon the only left to tackle will be the VS stuff.
I just saw that Bizhawk is banned for the ACE category on https://www.speedrun.com/smb3 for emulation inaccuracy. I can't find anything else on that topic there though. Maybe that should be cleared up?
@sergunov: Oh cool thanks, yup that is same result BizHawk gives. Also the third party controller hangs becuase it returns zeroes instead of 1's after the 8th read (this is what they say on the wiki anyway.)
@Potato Stomper: That's interesting. I will try to run the currently published any%run and see if it works when I have a bit more time. Maybe we can clear that up, thanks for pointing it out.
EDIT: Quickly tested it and it worked just fine. Ended the game in the exact same way. I should also point out that the current 100% run desyncs in the exact same way on console as on BizHawk, so I think it's quite accurate for SMB3 at this point.
@Potato Stomper: That's interesting. I will try to run the currently published any%run and see if it works when I have a bit more time. Maybe we can clear that up, thanks for pointing it out.
EDIT: Quickly tested it and it worked just fine. Ended the game in the exact same way. I should also point out that the current 100% run desyncs in the exact same way on console as on BizHawk, so I think it's quite accurate for SMB3 at this point.
Huh, makes you wonder why they even banned it in the first place. Some of the ACE runs are as old as a year ago. Was BizHawk emulating SMB3 inaccurately back then?
EDIT: I figured I'd ask on the forums there just for the sake of being 100% sure there are actually no problems. Just waiting for someone to reply.
Well, this is a response I got from Kirua:
"Producks and/or Tompa would be able to give more details or at least respond more accurately but basically BizHawk (and VC) handle memory corruption differently from NES, which means that some wrong warp setups would be possible on them while being impossible on NES. Other than memory corruption they're perfectly fine (or even better than some NES emus i guess although it's kinda irrelevant for RTA to use fceux or bizhawk if it's not any%) so it's not a problem for other categories."
Most likely that is referring to how NesHawk handled illegal opcodes in previous versions. Many were poorly emulated, and at least one that should have crashed the system was emulated as basically a NOP and let code execution continue.
So as described in that post, this might allow things on emulator not possible on console, since console would crash but emulator wouldn't.
Any of those such problems should be cleared up by now though, all opcodes are emulated correctly, and NESHawk is much more accurate in basically every respect.
Is there a specific version of Bizhawk I should be testing against here? The latest version does not sync the latest published Ninja Gaiden as described in the posts.
If you can, provide the BK2 you'd like me to test and point me to the version of the software to test against and from which I can extract button information for console verification.
EDIT: The input frames from the fm2 synced on real console.
EDIT 2: Scum pointed me to what I need, thanks. I'll write a script to verify the fceux-dumped input stream against bizhawk, and dump the desyncing run from bizhawk and verify against console. I'm not sure what will happen for the former, but I am assuming the run will not (de)sync in the same manner for the latter.
@true: Thanks for your efforts so far. That the run syncs at all is baffling. FCEUX doesn't emulate DMC conflicts , so a run made on it for a game with seemingly common ones and weak error correction seems to have little chance of syncing , yet it somehow makes it. Are you able to check ninja gaiden 2? That would be another good test case .
Also I have a suggestion if you have the time . DMC conflicts seem to be pretty common , but would be undetectable if it happened on a frame where ryu is just running left or right with no other inputs. So would it be possible to make the bot stop replaying the file at the first DMC hit? I am very curious where it happens and would be very useful in debugging.
And if there are none at all, well then it's back to the drawing board since I would have no idea what's happening.
EDIT:
for reference, here are all the frames that BizHawk says a DMC conflict occurs on up to desync in level 2. There are about 50, but only 1 happens in a fatal place. So , about 1% of frames have a conflict on them, more or less.
90 , 305 , 497 , 696 , 714 , 733 , 736 , 754 , 767 , 952 , 989
1075 , 1167 , 1267 , 1282 , 1551 , 1606 , 1645 , 1799 , 1816
1983 , 2039 , 2141 , 2190 , 2208 , 2243 , 2252 , 2291 , 2300
2304 , 2352 , 2353 , 2449 , 2457 , 2462 , 3265 , 3336 , 3371
3462 , 3492 , 3563 , 3683 , 3785 , 3804 , 3996 , 4031 , 4139
4189 , 4200 , 4219 , 4265
EDIT2:
true wrote:
I'll write a script to verify the fceux-dumped input stream against bizhawk, and dump the desyncing run from bizhawk and verify against console. I'm not sure what will happen for the former, but I am assuming the run will not (de)sync in the same manner for the latter.
Can you go into more detail on this and how you do this? How is the input stream different from the per-frame inputs? Are you just cataloging what the emulator says $4016 gives at each poll?
true: Thanks for your efforts so far. That the run syncs at all is baffling. FCEUX doesn't emulate DMC conflicts , so a run made on it for a game with seemingly common ones and weak error correction seems to have little chance of syncing , yet it somehow makes it. Are you able to check ninja gaiden 2? That would be another good test case.
I don't have Ninja Gaiden II. It is a TLROM board and I'm not sure I have a donor for that. Actually, I do have a TKROM board, that might work. Give me some time, work has me very busy.
Keep in mind our bots don't play back the exact input stream on NES specifically because of this glitch, and partially because of emulation quality. They play back in a "windowed" mode where an input has a window in which it can be repeated. If we had a hit, the game has error correction, and it isn't processing enough data to affect future frames, then the game has a chance to sync.
Alyosha wrote:
Also I have a suggestion if you have the time . DMC conflicts seem to be pretty common , but would be undetectable if it happened on a frame where ryu is just running left or right with no other inputs. So would it be possible to make the bot stop replaying the file at the first DMC hit? I am very curious where it happens and would be very useful in debugging.
And if there are none at all, well then it's back to the drawing board since I would have no idea what's happening.
Probably, but it isn't programmed to look for this. I would need to change the code, but honestly the DMC hit might be too fast that I might still be stuck in a read routine. TASLink might be the better check for this until I get my new bot done.
Alyosha wrote:
EDIT2:
Can you go into more detail on this and how you do this? How is the input stream different from the per-frame inputs? Are you just cataloging what the emulator says $4016 gives at each poll?
Re: input stream, it is exactly the "frame" inputs. The script I wrote will replay the only-valid-inputframes data, ignoring "lag" frames as reported by the emulator. If this is glitchy or buggy in any way, or if the emulation quality is poor, the game won't sync.
Because bird emulator only seems to support single frame input, or at least because I haven't implemented anything for it it if it actually does support it, my script effectively mimicks the window mode of a robot on actual hardware. If the input syncs on an NES, but doesn't in the emulator, the emulation probably has a problem.
Re: register access, bird emulator has poor way of detecting this (as far as I know right now - am I wrong?) compared to say lsnes, which has extensive callbacks for controller polling operations. FCEUX also doesn't have a way to do this, so I just dump input by frame on NES console. This is necessary anyway because of this bug.
----
Testing hardware-validated per-frame input data (dumped from FCEUX runs) against 7727a70 NESHawk, I get the following results:
- Ninja Gaiden doesn't even start. The second start press is eaten or something, so we get the intro graphic after starting the game.
- Legend of Zelda shows promise, as it syncs to Level-3. However Link can't get through the first door to the left, he doesn't go up high enough.
I think there's more at fault than DMC hits with NESHawk. This matches my expectations based on prior experience with NESHawk, so it's possible something is still off in emulation here. I am open to more tests. Perhaps we can discuss on IRC?
^ oh , good timing.
DMC is tested to grueling levels with blargg's test suite, so if something is still wrong I don't know what it is.
The DMC re-read happens in 3 CPU cycles, so maybe it's possible it's not getting picked up by the bot?
Yeah if you are available to do something on IRC let me know where to go, because I do have several things I need clarified before I can make any real headway.
freenode #tasvideos or #tasbot is fine.
In the case of Zelda above, the dumped run matches an uncorrected FM2. Correcting the FM2 does sync. It looks like I messed something up when I was testing, because I implemented skip/inserting blank frames in the script, and setting skip=1 has it syncing now...at least until about frame 3800, where Link hits an enemy... Corrected FM2 does get past this point.
