Posts for Alyosha


Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Samsara wrote:
Uh, false alarm, I was able to resync the run near perfectly to standard BSNES while also improving the pipe room. I've updated the submission file and text to account for this. Judgement may continue.
Is there a desync in the v115 core? If so please report the details here: https://github.com/TASVideos/BizHawk/issues/2754
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Bigbass wrote:
Alyosha wrote:
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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
TiKevin83 wrote:
I implemented 41 TAS verifications as a test suite for Gambatte Speedrun, the goal being to note any deficiencies outstanding in Gambatte Speedrun and to encourage TAS verification as part of an emulator's automated test procedures in general. https://tikevin83.github.io/gsr-automation-site/
That's pretty cool! Clever to feed back in the GBI inputs. I wonder what happened to Oddworld II though? Any idea where it started breaking? EDIT: looks like the movie still works in dev build (after adjusting for the new power up timing.)
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
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
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
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,
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
http://tasvideos.org/userfiles/info/72385648792277409 Here is a console verified run that will work in dev build or 2.6.3 when it is released. It gets all the items in the right places, but I didn't put much effort into manipulation after that point so it ended up slower then the published run by ~100 frames. So, if anyone wants to use this to get a faster run that can be console verified feel free. EDIT: I found an improvement and submitted a new run.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
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
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Patashu wrote:
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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I did some investigating of power on timing using the numerous playback attempts of Roger Rabbit I recorded. As it turns out it wasn't that hard to nail down exactly what the valid power on states were. In the following results, ofst is the offset from cycle zero, scanline 0 where the ppu starts that the cpu starts executing cycles, vbl is the state of the vbl flag at power on, and even_odd is the parity of the frame (one cycle skipped every other frame for NTSC consoles.) ofst = -1, vbl = true, even_odd = false; gives no match to console. ofst = -2, vbl = true, even_odd = false; gives exact match to console. Gives correct items. ofst = -3, vbl = true, even_odd = false; gives exact match to console. ofst = -4, vbl = true, even_odd = false; gives exact match to console. ofst = -5, vbl = true, even_odd = false; gives exact match to console. ofst = -6, vbl = true, even_odd = false; gives no match to console. ofst = -1, vbl = true, even_odd = true; gives no match to console. ofst = -2, vbl = true, even_odd = true; gives no match to console. Gives correct items. ofst = -3, vbl = true, even_odd = true; gives no match to console. ofst = -4, vbl = true, even_odd = true; gives no match to console. ofst = -5, vbl = true, even_odd = true; gives no match to console. ofst = -5, vbl = false, even_odd = true; gives no match to console. ofst = -4, vbl = false, even_odd = true; gives no match to console. ofst = -3, vbl = false, even_odd = true; gives no match to console. ofst = -2, vbl = false, even_odd = true; gives no match to console. ofst = -1, vbl = false, even_odd = true; gives no match to console. ofst = -5, vbl = false, even_odd = false; gives no match to console. ofst = -4, vbl = false, even_odd = false; gives no match to console. ofst = -3, vbl = false, even_odd = false; gives no match to console. ofst = -2, vbl = false, even_odd = false; gives no match to console. ofst = -1, vbl = false, even_odd = false; gives no match to console. ofst = 0, vbl = false, even_odd = false; gives no match to console. The results are pretty definitive. No valid states result from even_odd being true or from VBL being false. The documentation says that VBl is expected to be on some of the time, but I couldn't find any cases where it was off that matched playback. I originally expected valid ofst values clustered around 0, but I guess the CPU takes an extra cycle to reset, so -3 is the next most likely one, which is what we see here. values of -5 and -2 are possible but of low probability. (Mesen appears to match -5 in 0.9.9.) I then tested nightshade, and got a syncing run using -2, but only with very low probability ~1/20 or less. Testing with -3 resulted in a desync, not sure why, maybe something to do with MMC3 clocking. -4 did result in a syncing run though with much higher probability (worked on the third try.) A run of Donkey Kong on the -4 setting also synced to console. So with all of that, it seems very likely that the new startup state will be ofst = -4, vbl = true, and even_odd = false. I'm going to get complete runs of Nightshade and Roger Rabbit tested on these setting, and then try Battletoads, if everything works I will update NESHawk settings in master.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Game: Who Framed Roger Rabbit Emulator: BizHawk: NESHawk, local build with new startup state Console Verification Device: TAStm32 Movie:http://tasvideos.org/userfiles/info/72277515094486081 Description of Desync: Enemies are not in the correct locations after game start Research: Items do (occasionally, ~1/10 chance) appear in the right place on console. I have confirmed this by stopping playback and then manually checking the locations they should be in, but the enemies are in the wrong place, in a seemingly deterministic fashion. Un-initialized RAM is not the cause as I played the movie several times with random power up RAM state with no desyncs. This is curious as getting the right item locations requires accuracy to the ppu level already, but for some reason after that it doesn't work. I have looked at some trace logs, and the only interesting thing happening is that the game starts to use sprite zero hit once gameplay starts, after item location is chosen, maybe this hints at something wrong with sprite zero hit, but it passes all the relevent tests so I don't know. I tried the same movie on Mesen 0.9.9 but it desyncs in a different way, also not observed on console. Possible Next Steps: The game also encounters the OAM address glitch, but resets $2003 properly. Not emulating it all does not cause a desync anyway. Never the less thinking what might be wrong with sprite zero hit seems like the most likely way forward. Status: Open. Closed. resolution: Testing of power on state revealed the correct settings that give the observed enemy positions and correct item locations.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I updated NESHawk's timing of the oninputpoll event to match actual polling and made an appropriate dump script, so now I can test games that do more then one poll per frame. http://tasvideos.org/userfiles/info/72268404788366985 With this I was able to verify Balloon Fight: Link to video I also verified the all items run of Bionic Commando as well (although that run is outdated as it doesn't use the skips in the last level.) I'll get some videos up later today and organize .r08 files.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
CasualPokePlayer wrote:
So by chance you can effectively enter into several different "odd modes" for the NES. At least for GB/C that can only happen for GBC and that's with multiple speed switches...
Essentially yes, it makes tracking down emulation issues especially difficult, because if you have a run that desyncs in 3 different ways, how do you know which one is the emulation issue and which ones are from the wrong alignment? This is why I have anchored NESHawk to a particular run of Battletoads that was shown to work on console for so long, changing it without a lot of evidence that a different state would be better was just too risky. Anyway, I figured out what is wrong with Bionic Commando, incompatible lag definition between emulator and replay device, and having fixed that it now works. I'll be streaming the results a bit later if anyone is interested. I also updated the dump script for NESHawk which works better with the new Frame-increments-after-emulation rule. http://tasvideos.org/userfiles/info/72231161716346055 Unfortunately a lot of runs I try use uninitialized RAM, so progress is pretty slow on actually verifying new things, eventually I'll need to make a RAM clearing cart, there's a lot to do.
Post subject: TASes effected by uninitialized RAM
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I am encountering a large number of runs in my NES testing that rely in some way on uninitialized RAM, so I thought I would make a thread for such runs here so the knowledge that they need special RAM clearing for further testing is written down. [717] NES Monopoly "4 CPUs" by FractalFusion in 01:07.67 [4104] NES Monopoly by adelikat in 00:29.53 [2847] NES Rad Racer by FatRatKnight in 20:32.89 [2120] NES Silver Surfer by Skaad & HardCoreMangeur in 29:45.41 [4349] NES Marble Madness by Aglar & LeKukie in 02:42.07 I don't have a good way to do RAM clearing right now, but hopefully I'll be able to come back to these eventually.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Bigbass wrote:
Alyosha wrote:
Donkey Kong syncs with minor adjustments to the current run, but only with 1/4 probability due to start up variability.
Curious, what is the variability from? Uninitialized RAM affecting something?
I mean this hardware effect: http://forums.nesdev.com/viewtopic.php?t=6186 For games requiring careful timing, that use most ppu features, this basically gives them a 1/4 chance of working from power on. Also there is probably some additional variability of the ppu and cpu seeing the end of reset at slightly different times. If you look earlier in this thread, you can see some results from True when running the read2004.nes test rom on hardware. He got more then 4 different values, meaning something else is giving some timing variability. I think this is what is keeping Nightshade from working (or possibly working but with very low probability.) Almost all NES test roms test relative timing between events, so we don't know very much about absolute timing from power on. I'm not even entirely sure the test rom suite is internally consistent in always relying on the same power up alignment. NES is far messier then GB/C in this sense. Mesen 0.9.9 emulates the alignment variability (options->emulation->advanced-> randomize power on/reset cpu/ppu alignment) if you are interested in tinkering with it. Link to video
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Mixed results in testing today. Donkey Kong syncs with minor adjustments to the current run, but only with 1/4 probability due to start up variability. T&C surf designs syncs with the OAM glitch implemented properly. Silver Surfer needs RAM cleared, I think it would work with that, but doesn't with just hard resets. Nightshade doesn't work, not sure why, but it's MMC3 so might be related to that. Bionic Commando desyncs in the same spot as described by Bigbass, very strange as nothing of note appears to be happening at that point.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Got my TAStm32 board working and am streaming some Donkey Kong TAS verification attempts now. Current NESHawk settings resulted in no syncs. Mesen 0.9.8 settings also resulted in no syncs. Currently trying alternate settings that work for SMB3 glitch run, with some success.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
please try the dev build, I think this issue is fixed already: https://ci.appveyor.com/project/zeromus/bizhawk-udexo/builds/39575136/artifacts
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Please remove me from this and the other Princess Rescue submission, my contribution is insignificant, no need for name clutter.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Started doing some preliminary work. I confirmed that the OAM glitch occurs on console and that if I implement it in NESHawk I can match sync with Mesen 0.9.8. I found several other games that encounter the new OAM glitch, apparently it's not too uncommon to turn off the screen during rendering. They reset $2003 with manual writes though, so are unaffected. Looked at Monopoly, confirmed it uses uninitialized RAM, but is otherwise not too timing sensitive, those runs should work on console with RAM cleared to 0.