Emulator Coder, Judge, Experienced player (732)
Joined: 2/26/2020
Posts: 791
Location: California
MESHUGGAH wrote:
https://docs.google.com/spreadsheets/d/13f9KWy35O3qA6uudvNheh7EtDYv8QrgH1_iFtrBbmKU/edit?usp=sharing
The spreadsheet is asking for access. Also, GB subframe stuff is possible to verify to an extent. At least, GBI's resolution for inputs is 256 1MiHz cycles. If it's within that range, it could be verified. Being smaller would end up being tricky and possibly not verifiable. EDIT: Got a userfile of what I believe you saw: http://tasvideos.org/userfiles/info/74082050596796939 Seems to just be a dumb game that does a stupid amount of polling. Nothing fancy really. It's probably not impossible to verify if GBI timings play nice (i.e. luck) but it's ultimately nothing too amazing.
MESHUGGAH
Other
Skilled player (1920)
Joined: 11/14/2009
Posts: 1353
Location: 𝔐𝔞𝔤𝑦𝔞𝔯
CasualPokePlayer wrote:
The spreadsheet is asking for access.
Fixed it. Soon will watch your movie and edit this post. edit: I can't find the bizhawk version you use @ https://ci.appveyor.com/project/zeromus/bizhawk-udexo/history Movie says GIT update_gambatte#ec2baf17a edit2: checked it with https://ci.appveyor.com/project/zeromus/bizhawk-udexo/builds/40714103/artifacts and yes, this is the problematic input polling stuff I'm interested in! edit3: I'm not sure how it supposed to work, but does 0 length is valid? Fastest start seems to be: 0763 --> 3605 A 0764 --> empty 0765 --> 0 S or 28163 S Not yet... okay, thank you for your help! I will have fun with this tomorrow! edit4 probably final: ok looks like you are just another TAS god as you already uploaded the fastest start. The requirement is this: 0763 --> empty non-lag frame 0764 --> press any button 0765 --> 28163 S 0766 --> 2937 empty 0767 --> press S or s or B or A 0893 first non lag frame
PhD in TASing 🎓 speedrun enthusiast ❤🚷🔥 white hat hacker ▓ black box tester ░ censorships and rules...
Emulator Coder, Judge, Experienced player (732)
Joined: 2/26/2020
Posts: 791
Location: California
Right, should of mentioned I was using latest dev on my SGB meme thing. That branch is being put into bizhawk for ??? reasons, don't know why it isn't using the correct version. 0 length is silently turned into 35112 length (full frame), so somewhat invalid I guess. Of course, be wary of timing from frames, frame length is just a suggestion towards Gambatte, it will sometimes overrun the requested length due to the event scheduling that takes place and such. Using the cycle counter (i.e. lua's emu.totalexecutedcycles()) would be the true time so to say.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3827)
Joined: 11/30/2014
Posts: 2834
Location: US
Game: Mega Man X3 (USA) Emulator: BizHawk: 2.8 - BSNES 115 core Console Verification Device: TAStm32 V3 Movie: https://tasvideos.org/UserFiles/Info/637831474705110410 Description of Desync: On emulator, Zero climbs 2 ladders moving towards a vertical climb section. On console, he instead hits an enemy at the base of the first ladder. This appears to be deterministic. Research: Most other desyncs I have encountered on SNES are non-deterministic, so it's unusual to find a deterministic one. Could be a emulation issue, possibly Cx4 chip. Possible Next Steps: There aren't any Cx4 specific tests. Eliminating this as a source of error would probably be the first step. Status: Open
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3827)
Joined: 11/30/2014
Posts: 2834
Location: US
Game: Mega Man X2 (USA) Emulator: BizHawk: 2.8 - BSNES 115 core Console Verification Device: TAStm32 V3 Movie: https://tasvideos.org/UserFiles/Info/637833290115102148 Description of Desync: Initially desyncs because it requires 2 blank frames to get past the title screen (other SNES games require 0.) Then desyncs due to not performing a dash after jumping down into the stage. On emulator X beats the intro stage. Also gets incorrect RNG, does not seem deterministic. Research: NES games also occasionally need extra blanks and I'm pretty sure there it's a bot issue, but what is triggering the polls? Shouldn't desync non-deterministically either way though. Possible Next Steps: Testing with a different bot might help. Status: Open
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3827)
Joined: 11/30/2014
Posts: 2834
Location: US
Game: GBC Pocket Bomberman (Jump mini game) Emulator: BizHawk: 2.8 (GBHawk or Gambatte) Console Verification Device: Gameboy Player with GBI Movie: https://tasvideos.org/UserFiles/Info/637893651321154009 (GBHawk) https://tasvideos.org/UserFiles/Info/637893650773641622 (Gambatte) Description of Desync: Desyncs randomly in stage 2 at the first boss enemy. Research: The game is effected by uninitialized WRAM. The GBA start up state used in the movies does not produce working results on console. Both floor and ceiling settings were used for dumping inputs in both movies without improvement. It seems start up state is inconsistent. Possible Next Steps: A movie with initial WRAM set to 0 and using a RAM clearing cart syncs right away. Previous research seemed to verify that initial WRAM had a consistent start up state but this does not appear to be the case. Could it be something to do with GBI? Status: Open
Emulator Coder, Judge, Experienced player (732)
Joined: 2/26/2020
Posts: 791
Location: California
Alyosha wrote:
Previous research seemed to verify that initial WRAM had a consistent start up state but this does not appear to be the case.
I'm not sure where you got this from. The most that is consistent is the pattern of the startup state between different GBAs (which is more or less inherent based on how the GBA's EWRAM maps over to the GBC's WRAM). This doesn't make the entire state consistent, but it's not completely random. https://www.dropbox.com/s/omunfsd21b2am58/agb_wram_sram_hram_init.gbc?dl=1 Here's a ROM which will initialize all WRAM/SRAM/HRAM to exactly the state Gambatte sets.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3827)
Joined: 11/30/2014
Posts: 2834
Location: US
Well I guess those movies would sync on your (or TIKevin83's) consoles then. Maybe I'll get a better flash cart so I can read out the state of my console and compare.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3827)
Joined: 11/30/2014
Posts: 2834
Location: US
Game: Castlevania III (USA) Emulator: BizHawk: 2.8 - NESHawk Console Verification Device: TAStm32 V3 Movie: https://tasvideos.org/7743S Description of Desync: Randomly spawning enemy spawns differently on console compared to emulator ~ 1.5 minutes into the game. Research: Presumably the error is in MMC5 IRQs, as this game uses MMC5 which has not been tested or updated in some time. Possible Next Steps: Test ROMs needed Status: Open. Closed. resolution: Innacuracy in reading back state of DMC channel caused the desync. Test ROM confirmed correct timing. Additionally, unemulated open bus behaviour caused desync later in the run. This is also fixed. MMC5 IRQ timing also verified.
Alyosha
He/Him
Editor, Emulator Coder, Expert player (3827)
Joined: 11/30/2014
Posts: 2834
Location: US
Game: NES Batman Emulator: BizHawk: 2.8 (NESHawk) Console Verification Device: TAStm32 Movie: https://tasvideos.org/UserFiles/Info/638097680760634038 Description of Desync: Desyncs shortly into stage 2, Batman jumps into the acid. Research: This game uses an MMC3A and DMC channel. There are no other verifications of MMC3A games that require careful timing such as this, (there are others using MMC3A, but don't require careful timing, and there are verificaitons of games ex. SMB3 that require careful timing but use a later MMC variant) so may be related to that revision, but it's not clear why this would be. Possible Next Steps: ??? Status: Open