Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
I've made some good progress on DMC, the basics all work as expected. I made a test run of Ninja turtles where i press pause about a dozen times on frames where a DMC glitch occurs, which has the effect of skipping the pause. This run syncs through all of those pauses on console, but then desyncs on a sub weapon drop. This indicates that probably some edge case behavior is being missed. Tiny Toons similarly syncs through all DMC glitches but then desyncs on the mole boss RNG. These runs also need the behavior I mentioned in the previous post of skipping glitch polls on vertain addresses, confirming that behavior. I think some new test roms need to be made still though, I really need nesdev to be back up and running. One example of something that needs testing is encountered by Time Lord, where the DMC channel is disabled as a DMA is about to be triggered. What happens? It's kind of funny how all the DMC games I try manage to encounter the edgiest edge cases possible. Everything really does need to be perfect to work. So, I'm kind of stuck for now. Might try a few other games just to see what happens. If anyone has any suggestions of games they want to see tried let me know. Sometimes you never know which game will provide the crucial hint to make everything make sense.
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
Since I'm pretty stuck on DMC for now, I decided to try to make a RAM clearing cart and test some games that relied on un-initialized memory. So far results are promising, I was able to verify Monopoly by running the cart, then turning off power and switching. no hot swap was required. Here is a console verification video: Link to video My NES is not the most reliable, so this process can take a couple tries. I'll be doing some more testing and hopefully can get a lot of the previous difficult games verified. One other note, for better or worse this does use the FCEUX RAM state, at least for now. EDIT: Here is the 4 cpu's run as well: Link to video
MESHUGGAH
Other
Skilled player (1884)
Joined: 11/14/2009
Posts: 1349
Location: 𝔐𝔞𝔤𝑦𝔞𝔯
Interesting case. So the TAS syncs on console using FCEUX RAM start pattern but doesn't with the originally used BizHawk RAM start pattern? This means only the output/result of the TAS is verified, while the starting/initial setup used not. I'm not sure if "partial" console verified TASes should also get the console verified tag. Since the TAS itself doesn't syncs only after changing the required RAM pattern.
Alyosha wrote:
My NES is not the most reliable, so this process can take a couple tries.
So after using the clear cart, power off, edit: monopoly cart, power on, the TAS doesn't syncs each time? Are you sure it's about your NES and not an unknown variable/factor somewhere else? Full list of potential factors - your NES as you mentioned, - your RAM clearing/changing cart, - your Monopoly cart, - the time spent between ejecting your ram clear cart and powering on monopoly cart (you should aim for sub 10 seconds. Greatly depends on platforms, obviously the faster you are the better your chances will be. In case you are desperate, you could try https://en.wikipedia.org/wiki/Cold_boot_attack ) (no more edits)
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Bigbass
He/Him
Moderator
Joined: 2/2/2021
Posts: 153
Location: Midwest
It's usually agreed that if a TAS's inputs verify on console at least once, then it is verified. I don't exactly understand how a RAM pattern from a different emulator (assuming the pattern is actually different) would make a TAS verify on console more than the starting emulator. However, I'd consider using a different RAM pattern, no different than any other regular resync. If anything, it's even closer to the original TAS than a resync, as the actual inputs are still identical. Changing the RAM is just changing the state of the console to something that the emulated movie is compatible with. It's also possible to verify TASes for games using uninitialized RAM for RNG, without changing the RAM to match the emulator (albeit, often extremely low chance, but it is possible).
TAS Verifications | Mastodon | Github | Discord: @bigbass
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
Ah, I should have been more clear. BizHawk also uses the FCEUX start up RAM state, I just call it that since it originated from there. There isn't any particular reason to use it though, it's simply a convention. I currently don't have the hardware to check what RAM actually looks like at power on, I can't remember if it's been done in past somewhere either.
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
Link to video So it turns out that Metroid Low % works but needs a unique set up compared to other runs. The game polls input in a very odd way. It polls player 1 input but then polls all over again for player 2. This seems to give the bot some trouble, and causes desyncs when using the usual poll based script. The frame based script however works correctly and without the extra blank input I usually need. After I applied these settings, I did not need to clear RAM for it to work. I also resynced to BizHawk but the non-lag inputs are the same (I think, wasn't keeping too close track.) So that is all of the current Metroid runs verified! The only remaining run of the a game that I have that should work but doesn't (that doesn't use DMC) is Silver Surfer. I'll still be trying it a bit more though. EDIT: Was able to get Silver Surfer working. I had to use a reset since apparently some RAM is decaying too fast while swapping with power off, but using 0 delay and holding reset while swapping from the RAM clear cart worked right away.
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
After some more research, I have updated the power up state of NESHawk again. With this new state, now all available APU tests pass at the same time. This was not the case with the previous state, in particular count_errors_fast gave a result that I never saw on console. Fortunately, the new state also has high compatibility. Most of the previous timing sensitive games work with only minor tweaking of inputs, including Battletoads and Nightshade. Some games will require new movies, Roger Rabbit doesn't work anymore (but that's ok since it was slower anyway by a wide margin.) Excite Bike also doesn't work, but I probably just need to put some more time into that one. I am in the process of updating movie files and .r08 files and will be replacing them in the repo when I get a chance. I did some test runs with Tiny Toons in with the new state, but it desynced at the same point (but in a different way.) So, I still need the last few DMC edge cases working, but at least now everything is consistent. I have reverted the above changes pending further testing, as that state seems to have very low probability and doesn't work with one of the tiny Toons DMC test runs I use.
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
Thanks to Fiskbit and Lidnariq from NesDev, I was able to implement some new findings related to DMC DMA. Now some DMC runs are starting to work for the first time. For example this is the first time ever I have gotten past the third level of Tiny Toons on console: I'm going to try to get a full game run of Tiny Toons working next, then probably Ninja Turtles if that works. This isn't quite the last step for DMC games, as Time Lord still needs some edge cases worked out, but should be getting really close now.
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
After fixing numerous subtle bugs in IRQ/NMI handling, i finally have a run of tiny Toons that makes it to the end of the game on console. The current run is here: http://tasvideos.org/userfiles/info/76487677575343984 Not submittable as a new run in it's current form as it's longer then the published run by a few seconds, and I think with some good luck manipulation it can be a few seconds shorter, but it's a baseline for now. I believe the only remaining issues involve edge cases of disabling the DMC channel, getting really close to correct DMC emulation now. Time Lord can now beat the second level on console due to implementing DMC IRQ delay that surprisingly went untested until now, so making progress there as well.
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
Link to video I console verified a resync of Rollergames. I had some trouble syncing this one to NESHawk so it's slightly different then the original in some places, but the important thing here is that I had not previously used this game in developing NESHawk, so it's a good indicator that I didn't accidentally fine tune emulation simply to the games I was working with. There are some edge cases left that are pretty difficult and will require a rewrite of a big chunk of code, but they shouldn't come up in actual games, so I'll wait for test ROMs to become available to verify the expected behaviour before working on them. For now, progress is blocked not by emulation but by not having any runs that actually sync on the updated core.
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
Link to video Here is a resync of Strider console verified. This one lost about 2 seconds in the resync process due to general difficulties making the inputs work, but I did the best I could. This is a glitchy run, and the original in FCEUX desynced on console right at the first glitchy part, so this is another good data point to check accuracy against.
Bigbass
He/Him
Moderator
Joined: 2/2/2021
Posts: 153
Location: Midwest
In the video description, the bk2 file you provide doesn't seem to match the r08 dump; and I'm not able to get either to work on my console.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
Bigbass wrote:
In the video description, the bk2 file you provide doesn't seem to match the r08 dump; and I'm not able to get either to work on my console.
Are you using the dev build and the poll based dump script? EDIT: also you probably need to use an original cart from power on.
Bigbass
He/Him
Moderator
Joined: 2/2/2021
Posts: 153
Location: Midwest
Alyosha wrote:
Bigbass wrote:
In the video description, the bk2 file you provide doesn't seem to match the r08 dump; and I'm not able to get either to work on my console.
Are you using the dev build and the poll based dump script? EDIT: also you probably need to use an original cart from power on.
I'm using the master branch yes. I'm also using my own dump script which I've been using for every other verification I've made. But regardless, I can see in the bk2 file you provided, that the inputs simply do not match the r08 file's inputs. For example, in the bk2, there is one Start button press near the beginning, whereas the r08 has two Start button presses. There's other inconsistencies later in the run too.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
There are 2 start presses in the .r08 file because the controller is polled 2 times in the same frame. All my verifications (except for Metroid where the bot has issues) are done based on input being polled/latched. If input is latched 3 times in a frame, 3 copies of that input are sent to the .r08 file.
Joined: 4/4/2021
Posts: 7
I'll try to console verify it in the next 2-4 days with the TAStm32. (Sorry if I needed to add a subject. It's been like 10 years since I last used any forum software, so I don't know how to do forum posts anymore)
Bigbass
He/Him
Moderator
Joined: 2/2/2021
Posts: 153
Location: Midwest
Ohhh, so you never use a latch filter. Interesting. (yet another downfall of the r08 format). AFAIK the only time you need to use latch-based inputs like you're doing, is when subframe inputs are required, like for the SMB3 game end glitch TASes. Either way, even when dumping from the bk2 myself, the playback consistently fails at the first glitch (~0:47 of the encode).
TAS Verifications | Mastodon | Github | Discord: @bigbass
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
I don't filter out latches if I can avoid it, it's not how a real controller works and introduces a potential source of error (which games do encounter ex Bionic Commando.) But ill dump by frame and try it later today and see what happens.
Bigbass
He/Him
Moderator
Joined: 2/2/2021
Posts: 153
Location: Midwest
Alyosha wrote:
it's not how a real controller works
Sorta. True that controllers do not just ignore extra latches within a given frame, but TASes that explicitly do not use sub-frame inputs, assume that multiple polls/latches within a given frame, will get the same input repeated for each poll. On replay devices, this is implemented using a latch filter (usually 8ms is used, approx. half a frame). Any subsequent latches after the first, will receive the same data, until the end of the latch filter period.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
I dumped the run with frame based inputs, tried a few times to verify and always failed at first screen glitch. here is the file: https://github.com/alyosha-tas/NES_replay_files/blob/main/strider_f.r08 Tried again with poll based dump, worked first try.
Bigbass
He/Him
Moderator
Joined: 2/2/2021
Posts: 153
Location: Midwest
Alright, after (effectively) disabling the latch filter on my device, I was able to verify this using your poll-based dump. ---- I wanted to know what the difference was. First of all, the polling sequence done by the game is fairly typical. No non-standard polling, or weird clocks, etc. Each frame consists of: Latch, clock*8 player 1, clock*8 player 2, Latch again, clock*8 player 1, clock*8 player 2. Though the time when the polls appear within a frame changed wildly. So I compared your poll-based dump, and my frame-based dump, by incrementing through each set of inputs on a frame by frame basis. Thus your dump should theoretically have two identical sets per frame, which should match the frame-based dump. Based on the analysis here, I found the first difference. I traced this moment back to roughly movie frame #2719. Which is the point where the player performs the first glitch of the run. Using onmemoryread/onmemorywrite in a lua script for memory address 0x4016, I found that on most frames, just as seen on hardware, 2 latches occur as described earlier. But on frames #2715 and #2716 of the emulator, only 1 latch occurs on each. I located where this was happening on hardware, and it turns out that VSYNC occurs after the 1st latch's polling sequence, causing a short delay (~0.5ms) until the 2nd latch occurs, and is why only 1 latch appears on these frames on emu. Trying to change the latch filter to account for this, didn't work, and seemed to consistently change which frames get this collision.. ---- If we think about frames as being wholly separate from each other, then theoretically the frame-based dump should have still worked. The reason it didn't in practice, is because the latch-filter is much too large for this odd case (which happens multiple times throughout the run), and a single value may not be sufficient. To me, this throws into question why some of us even bother using a latch filter at all. Perhaps in the past, it was necessary because emulators weren't accurate enough? Also makes me wonder if using a poll-based dump would allow me to verify TASes that have failed for me in the past.
TAS Verifications | Mastodon | Github | Discord: @bigbass
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
Strider and Bionic Commando are the only current examples, so ~2/150 runs encounter this issue. So yeah maybe a few others encounter this issue that didn't work before, but most failures are probably just inaccurate emulation or uninitialized RAM. Anyway, I only have a few cases left where I both have the game and a syncing run of it to test, so please let me know if any other interesting looking cases pop up because I'll be looking for new / useful things to test.
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
After resyncing to dev build and using my RAM clearing cart, I was able to get Adventures of Tom Sawyer to sync on console. It lost a few frames but is mostly the same: Link to video I am encountering more runs that use both uninitialized RAM and the DMC channel. These runs are probably the most difficult to make work because you need to clear the RAM (which means turning the console on) but the DMC initial state requires the console to be off for at least a few seconds (which will likely undo most of the effect of clearing the RAM.) Very unfortunate. I don't have a good solution for these cases. Maybe changing the RAM chip to one that starts in a known state? Oh well, just another example of how messy real world effects can be.
Alyosha
He/Him
Editor, Expert player (3514)
Joined: 11/30/2014
Posts: 2713
Location: US
Link to video Top Gun. And with that, I am out of runs to try. It's unfortunate that most of the more interesting games have runs that desync pretty badly. I have tried resyncing Mega Man 6, Ninja Turtles 1 and 3, Castlevania 2, and Blaster Master, and they appear to be pretty hopeless, new runs needed. I have a few other games left I could possibly verify if I can get syncing runs for them, but nothing that looks like it would be too interesting or insightful. I'll still try though. I think development is mostly complete here anyway, I'll probably try to find something new to do.
Editor, Player, Publisher (46)
Joined: 10/15/2021
Posts: 366
Has Lunar Pool been attempted for verification yet?