Out of curiosity, is NES startup state the kind of thing that tends to be similar between different people's NESes or different, or do you only know about your own for now?
I only know about my own, but while there is probably some variation amongst individual units it's probably not by much. I have a standard front loader nes with G model ppu (common.) I expect these results to more or less hold for similar models maybe with slightly more or less overall likelyhood.The proposed state gives a result in read2004 of 8, which True reports as pretty common.
The only caveat is that I would not necessarily expect this to apply to top leaders. It could be, but needs testing.
The state is updated with the -4 value since it has the nice bonus of the Battletoads runs still working.
I think the next big thing to focus testing on is the timing of the DMC glitch. Hopefully it's not random. Figuring this out will allow runs for games like Ninja Turtles.
I also need to find some other MMC3 games that don't use DMC to have more confidence that Nightshade wasn't just a fluke,
It seems power on timing issues aren't entirely solved yet. Paperboy is a game that relies on initial timing to seed house RNG, but somehow on console I never see the arrangement that would result from VBL flag being on, despite many, many tests, which is really strange. I made a post about it looking for advice over at NESdev: http://forums.nesdev.com/viewtopic.php?f=3&p=274594#p274594
I don't think it's a coincidence that all these timing sensitive TASes suddenly work with the new state I have now, so there must be something going on. Paperboy is unusual in that it doesn't sample $2002 until about 800 cycles into the game, so maybe the flag is pulled down by then, it's just a guess but I might have to just implement it for now so that paperboy has a realistic startup house state. I really need a dev cart to test stuff like this.
Also Paperboy is the only TAS I try that requires 3 blank frames to get things syncing, every other game requires 1, so another indicator that something is up.
Well it seems it was all just a coincidence.
I found another power up arrangement this time with VBL false where all the console verified runs still sync but now paper boy now powers up as expected.
The new settings are VBL = false, ofst = 4, even_odd = true.
The mystery house arrangement that still appears on console occasionally is still inexplicable, but that's a puzzle for another time.
The streemerz runs now desync on dev build, which is promising, but I don't yet have a dev cart to try them on console, so moving on to DMC testing for now.
Trying test runs with Ninja Turtles and Tiny Toon Adventures gives promising results, consistent desyncs indicating DMC start up state is consistent, I just need to find it and verify correctness of DMC channel emulation. This is also hindered by not having a dev cart, so progress may be slow.
At least power up timing should be done now.
The streemerz runs now desync on dev build, which is promising, but I don't yet have a dev cart to try them on console, so moving on to DMC testing for now.
Where can I get this dev build? (nevermind, tikevin got me a link)
I can try dumping and test on console.
The streemerz runs now desync on dev build, which is promising, but I don't yet have a dev cart to try them on console, so moving on to DMC testing for now.
Where can I get this dev build? (nevermind, tikevin got me a link)
I can try dumping and test on console.
http://tasvideos.org/userfiles/info/72428431403912808
Here is a movie file that syncs in dev build (slower then published run since it's just a rough resync.)
I think probability of it working from a reset is low (like if you are using a power pak or similar) but it doesn't hurt to try.
Unfortunately still doesn't verify, at least from reset. But over all 6 attempts, it's failing consistently. Around frame 935ish, it fails to grapple properly, and falls instead.
I've made a lot of progress in understanding and emulating the DMC channel, but unfortunately DMC games still don't sync. I don't think I can make further progress without a dev. cart, I need to see the results of count_errors.nes in order to be able to tell what direction I need to shift things.
In the mean time there are a few other loose ends I'll be trying to tie up. DMC games probably won't be syncing for 2.6.3, but hopefully for 2.6.4 I'll have them working, it's really close.
Link to video
I console verified the Battletoads game end glitch run.
I also did the same for a resync ( http://tasvideos.org/userfiles/info/71811602852747684) of the one player warpless run, but that run needs an update so I won't bother making a video of it.
So that's all the current Battletoads runs console verified.
[4410] NES Mega Man 2 by Shinryuu in 23:38.98
Doesn't work for me. The zip glitch at 13:17 fails to work on console. Though I'd like to see someone else try it too.
Castlevania very likely uses uninitialized RAM for RNG. Maybe Gimmick! as well (or at least, I was getting inconsistent desyncs). Super C and Battle City seemed the same way.
I thought I tried Rockman 1, but don't see it in my notes. And I haven't tried the Rockman 4 hack, nor the Double Dragon game.
When you have time, could you please post in the Publication Maintenance thread, with all of your recent verification videos (whose publications haven't been updated yet), so we can get that stuff updated.
When you have time, could you please post in the Publication Maintenance thread, with all of your recent verification videos (whose publications haven't been updated yet), so we can get that stuff updated.
I did, directly above you, but note that I only included runs where the inputs actually play out the same. Donkey Kong, Roger Rabbit and Excite Bike aren't really the same so I didn't include them.
Link to videoLink to video
Here are both versions of Solstice. They needed a little resyncing and don't work directly from FCEUX. Another timing sensitive game.
Additionally here is Ironsword which does work directly:
Link to video
In case you need more games to test:
https://wiki.nesdev.com/w/index.php/Tricky-to-emulate_games
edit:
Looks like you probably already know this page.
While I'm not sure what is the actual stuff you are researching, but I think we have more TASes of NES games using MMC3 mapper that has gameplay part with DMC samples being played. You are looking for games like this, right? If you say yes, I guess I could compile some example games and TASes for you.
I'm a bit surprised that Battletoads worked while Nightshade doesn't.
Reacting to a previous post by Alyosha:
Also Paperboy is the only TAS I try that requires 3 blank frames to get things syncing, every other game requires 1, so another indicator that something is up.
You mean adding 1 empty frame to the TAS so it syncs on console? Some of my NES TASes from around 2016 has notes in the submission text about adding 1-2 empty frames to an FCEUX TAS to make it sync on BizHawk. So.. you required to add even one more empty frame? Or this doesn't covers loading parts of a game between levels, only at the very start of powering up?
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Also Paperboy is the only TAS I try that requires 3 blank frames to get things syncing, every other game requires 1, so another indicator that something is up.
You mean adding 1 empty frame to the TAS so it syncs on console? Some of my NES TASes from around 2016 has notes in the submission text about adding 1-2 empty frames to an FCEUX TAS to make it sync on BizHawk. So.. you required to add even one more empty frame? Or this doesn't covers loading parts of a game between levels, only at the very start of powering up?
The 1-2 blank frames between FCEUX and BizHawk is just due to a programming difference where FCEUX takes a bit longer to "start up" than BizHawk. I don't recall if it was determined yet which behavior was more accurate to the console. Either way, most of the time, if not always, those few frames are lag frames in both emulators, so it shouldn't affect the dumped input for console verification at all. But yes, it will affect emulator sync when moving movies between those emulators.
When I first started verifications, I was told that sometimes you might need to insert a blank frame to get TASes to verify, however, that has never been the case for me. I think this belief may have come about from a scripting bug that ViGrey discovered where the index can be off-by-one when dumping inputs with a script that doesn't account for this.
With paperboy, it sounds like there's something else going on. I could probably try adding a couple blank frames to the dumped inputs and see what happens.
Edit: Idk if Alyosha has a resync for bizhawk, but adding 2-3 frames to the original FCEUX-dumped TAS, doesn't affect the attempt in any way. It consistently desyncs for me by running into a fence, just as it did when I tried this in the past (without adding frames).
Regarding lag frames around loading parts being different, I meant that I'm interested in which behaviour is the correct (FCEUX vs BizHawk). Let me show some example:
#1 From #3893: MESHUGGAH's NES Driar in 05:14.45 submission text:
To make this TAS sync in Bizhawk 1.4.0, you need to add an extra lag frame after showing the level number of 18 and 22.
Elaboration: two (seemingly random, why these) levels requires 1 extra empty frame because they load 1 frame longer.
The submission text links to the BizHawk sync movie after this quote I wrote.
#2 From #3947: MESHUGGAH's NES The California Raisins: The Grape Escape in 04:51.50 submission text:
It's possible to make a BizHawk sync by adding 2 lagframes before the start and 1 lagframe for starting the level.
Elaboration: I think this should apply to the improved movie which is this:
[4053] NES The California Raisins: The Grape Escape by MESHUGGAH & AIVV73 in 04:15.83
This means you need to add 2 empty frames in the very beginning and 1 empty frame for each time I start a level (4 times as there's 4 maps in the level game)
edit: fixed some words
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Link to video
Nightshade does work currently.
For Paperboy, I mean that when I run the bot script, I need to use --blank 3 instead of the usual --blank 1 to get the game to start. It has nothing to do with emulation differences.
I always need 1 blank frame, I guess the first input gets eaten somewhere by the bot, or maybe just by the power on pulse or something, but I have no idea why I need 3 for Paperboy. It could be DMC related, and what I am really seeing is 2 inputs getting lost to DMC glitch, I just haven't investigated it much yet.
The next MMC3 game I am looking at (not using DMC) is 8 Eyes, but converting it to BizHawk did not require any resyncing so probably it is not timing sensitive. I'll try it on console this week hopefully.
I'm also trying to resync Bad Dudes but it desyncs pretty painfully in the second level, not sure I can fix it.
For Paperboy, I mean that when I run the bot script, I need to use --blank 3 instead of the usual --blank 1 to get the game to start. It has nothing to do with emulation differences.
I always need 1 blank frame, I guess the first input gets eaten somewhere by the bot, or maybe just by the power on pulse or something, but I have no idea why I need 3 for Paperboy. It could be DMC related, and what I am really seeing is 2 inputs getting lost to DMC glitch, I just haven't investigated it much yet.
It could be a problem with the TAStm32 too, idk how that firmware works, or maybe it's a problem with the interface script (which I also don't use nor understand). However, this game doesn't appear to suffer from the DMC glitch. I've checked on hardware, the game only polls a single time per frame. And besides, both the TAStm32, and my own device, has clock filtering and handles redundant polls within a given frame (if a game happens to employ that technique).
However, I did notice that this movie doesn't sync in FCEUX, when using New PPU, and where it desyncs is different than when I try on console (dumped using Old PPU).
Did you have to resync this movie to make it work on BizHawk?
No I didn't resync it, I just made a brief test run, just playing through the first level.
Paperboy does use the DMC channel for certain sound effects, (glass breaking, car horn, etc.) and this does occasionally produce a controller glitch (doesn't really matter how many times per frame the controller is polled.) Once I get some dev boards working the first thing I'll check is if the bot responds the same as a real controller (and what options make that happen.)
Finally got a dev board up and running with count_errors.nes running.
The results are promising, with only 4 different start up states, so it seems to be deterministic (at least after a decently long power cycle.)
I also determined that the TAStm32 responds correctly to the DMC glitched polling with the --overread option used.
NESHawk currently does not match any of the 4 options, as expected since no DMC games work. But now I very clearly know what I'm looking for, should only be a matter of time.
If anyone is interested here is a video where I turn the NES on and off for about 30 minutes with test ROm used:
Link to video
Joined: 1/24/2018
Posts: 304
Location: Stafford, NY
Alyosha wrote:
NESHawk currently does not match any of the 4 options, as expected since no DMC games work. But now I very clearly know what I'm looking for, should only be a matter of time.
So once the DMC games work would NESHawk be close to 100% emulation of an actual console?
c-square wrote:
Yes, standard runs are needed and very appreciated here too
Dylon Stejakoski wrote:
Me and the boys starting over our games of choice for the infinityieth time in a row because of just-found optimizations
^ Why I don't have any submissions despite being on the forums for years now...
NESHawk currently does not match any of the 4 options, as expected since no DMC games work. But now I very clearly know what I'm looking for, should only be a matter of time.
So once the DMC games work would NESHawk be close to 100% emulation of an actual console?
Pretty much yes. It's the last major step. Although I should qualify that as saying it's only true for consoles similar to mine, which is pretty common but might not apply to top loaders.
Currently though I'm only able to match about half of the behavior seen in that test ROM, so something still is not exactly right.
Making slow progress on DMC stuff, most of the pieces seem to be correct now, but timing is still off somewhere in some subtle way. It's hard to tell where exactly, might need some new more detailed tests.
Some games are starting to work correctly though. I made some small tests of Ninja Turtles and Tiny Toons, and they now display the same behaviour as console.
Another Interesting example is Time Lord, which uses the DMC channel as kind of a back up IRQ source.
Here is a video demonstrating that you can get only one cycle of mushroom collecting with no backtracking, saving several seconds over the published run. As you can see in the video though, it desyncs before beating the second level, but it's still good to see some real prgoress.
Link to video
After a lot of head scratching, I finally managed to reproduce exact results for the count_errors tests.
As it turns out, the way to actually get this correct is an undocumented behavior!
When a DMC DMA happens, the address bus changes so that the DMC unit can read a sample value. The controller glitch occurs when the DMA happens on a controller read cycle. The controller shift register sees the address bus change to the DMA address and then back again, resulting in double clocking of the controller.
However, if the DMA address happens to have the same bits set as the controller register (I think it is (DMA ADDR & 0x401F) == 0x4016 but am still narrowing it down) then there will not be an extra clock.
I guess in hind sight this kind of makes sense, but still it's pretty neat to discover a new behavior on a system as well studied as the NES.
Getting really close to correct DMC emulation now.
As it turns out, the way to actually get this correct is an undocumented behavior!
When a DMC DMA happens, the address bus changes so that the DMC unit can read a sample value. The controller glitch occurs when the DMA happens on a controller read cycle. The controller shift register sees the address bus change to the DMA address and then back again, resulting in double clocking of the controller.
However, if the DMA address happens to have the same bits set as the controller register (I think it is (DMA ADDR & 0x401F) == 0x4016 but am still narrowing it down) then there will not be an extra clock.
I guess in hind sight this kind of makes sense, but still it's pretty neat to discover a new behavior on a system as well studied as the NES.
Getting really close to correct DMC emulation now.
