Post by Alyosha

Posted: 12/21/2020 1:37 AM
(Edited: 12/29/2020 1:27 AM)

Quote

Alyosha

He/Him

Editor, Emulator Coder, Expert player (3821)

Joined: 11/30/2014
Posts: 2829
Location: US

~~http://tasvideos.org/userfiles/info/68236736685619749~~ Here is a completed resync for oracle of seasons. Unfortunately the last boss desynced (RNG was good but behaviour was different) so I had to redo it at the cost of 90 frames, but everything else is as the original run, and it's right at the end of the run, so maybe it can still be fixed and won't really break anything else (except maybe the second form.) I made up a ROM that sets all WRAM to 0xFF. I then tried the run on console after I ran it. It still desynced in the same way as before, so maybe there is something more substantial then bad WRAM start up at play here. I didn't do a hot swap so I guess it's still possible it could have decayed in the 3 seconds it took me to swap carts and apply power again, not sure. But anyway it's something to keep in mind. I think I'll clean up the clearing ROM to execute from VRAM when it's finished, then maybe hot swapping will be a safer prospect. I think I'll take a break from Zelda for now though and work on something else for a bit, maybe some more work on HDMA edge cases. That resyncing process was mind numbing. I'm almost through my backlog of console verified runs now, so it's maybe also time to start thinking about where GB/C console verification should go from here. It's probably time for a more refined focus then just whatever i can get my hands on, but I'm not really sure how to do that. If anyone has any input please post it.

Posted: 12/23/2020 1:32 AM

Quote

Alyosha

He/Him

Editor, Emulator Coder, Expert player (3821)

Joined: 11/30/2014
Posts: 2829
Location: US

I made a test run of Gensan 1 in dev build which used 0xFF as initial HRAM. I then used my clearing cart that writes all 0xFF to console then hot swapped the Gensan cart and reset the Game Cube to see if it would sync. It did not. In fact it consistently desynced in the same spot about half way through the run. Both Gambatte and GBHawk agreed (cycle exact) that the run should have synced past the point it desynced, and testing indicated that the desync was the result of a different initial HRAM state then 0xFF. I tested this several times. It desynced in the same spot every time. So I think I can conclude pretty confidently that clearing HRAM to 0xFF does not hold through a reset. Actually, the reset seems to remove power from the GBP for a fairly long time, so if 0xFF is not the default unpowered state, it's not surprising that it doesn't work even with a hot swap. I then changed the run to use 0 instead and retested the hot swap. This worked right away. The run synced to the end of the game, which has never happened before with Gensan 1. So, at least for HRAM, I am setting initial state to 0. I'll do some more testing with other games that use uninitialized WRAM, maybe the same thing holds true there as well and 0 was the right choice to begin with. EDIT: looks like even 0 might still not result in 100% sync, so far I'm out 3/4.

Posted: 12/25/2020 12:41 AM

Quote

Alyosha

He/Him

Editor, Emulator Coder, Expert player (3821)

Joined: 11/30/2014
Posts: 2829
Location: US

I resynced oracle of ages and seasons with initial RAM all 0's (but SRAm still 0xFF.) Ages synced fine, it even synced when I forogt to clear the RAM, so I guess it's not that sensitive to initial state. This time though Seasons also synced. Well, up to the last boss which I have to redo again since it broke again in the new resync. So I'm pretty confident that 0's in RAM is a good clean configuration for GBA mode runs that encounter uninitialized RAM. I'll be updating runs and input files as I get them sorted out.

Posted: 12/25/2020 12:50 AM

Quote

CasualPokePlayer

Emulator Coder, Judge, Experienced player (729)

Joined: 2/26/2020
Posts: 781
Location: California

If we're just choosing all 0s for uninit WRAM, there probably not much of a need to actually do any hotswapping for initializing RAM. As I've noted before, entering the GBA bios will 0 out all of the GBC's WRAM (I haven't checked HRAM, although I have doubts it would touch that). This should be a big note when looking into uninit WRAM, as hotswapping has a chance to assert the RESET pin (and no cart inserted = GBA bios), which will usually invalidate research regarding this. Also on the notion that resetting will affect RAM, from my testing it appears that it the small amount of time power is cut isn't actually enough to cause significant decay. Usually whatever RAM state is currently there will hold, and occasionally a bit might decay, but even this isn't too likely to happen.

Posted: 12/25/2020 1:18 AM

Quote

Alyosha

He/Him

Editor, Emulator Coder, Expert player (3821)

Joined: 11/30/2014
Posts: 2829
Location: US

Yeah that should work nicely for cases of only uninitialized WRAM. I haven't tried Gensan 1 with just loading GBA bios, but I'll try in the next few days to check since it uses HRAM. If nothing else, it's pretty clear that 0xFF is not stable while 0 is, at least in my testing, very stable, so I think just clarifying that is already worth the time it took me to test everything.

Posted: 12/26/2020 12:03 AM

Quote

Alyosha

He/Him

Editor, Emulator Coder, Expert player (3821)

Joined: 11/30/2014
Posts: 2829
Location: US

http://tasvideos.org/userfiles/info/68344555483336459 Here is an updated version of oracle of seasons, console verified. The last boss fight is different, and slower, as again the original did not work. I'll be streaming the verification tomorrow at 10 pm eastern at alyosha_tas. Having console verified versions of both Ages and Seasons is more then what I expected to get done before the new year, so that's good. I'll work on a proper run of Gensan 1 and then probably go back to accuracy improvements, there is still some low hanging fruit in audio emulation and a few other places. I don't want to mess with too many other crazy edge case stuff before 2.5.3 so I can be confident about stability. Not sure where I'll look next for console verification, possibly Pocket Bomberman. Mega Man Xtreme 2 would also be a good candidate, but not sure I have the will to go through an RNG nightmare.

Posted: 12/31/2020 12:49 AM

Quote

Alyosha

He/Him

Editor, Emulator Coder, Expert player (3821)

Joined: 11/30/2014
Posts: 2829
Location: US

I implemented enough of the LCDC bit 4 write behaviour glitch documented here: https://github.com/mattcurrie/mealybug-tearoom-tests/blob/master/the-comprehensive-game-boy-ppu-documentation.md to pass the gbc-acid-hell test ( https://github.com/mattcurrie/cgb-acid-hell ) This only covers half of the glitch (the reset part) and correctly fixing the other half will require a major rewrite of sprite evaluation. I planned to do this eventually anyway, as it will be necessary for another test that changes the double sized sprite bit while rendering, so this is just another motivating factor. Actually that test suite covers a lot of ppu edge case behaviours that GBHawk doesn't implement, pretty neat. I also tried a test of letting the GBA bios run and then playing Oracle of Seasons but it desynced. I might try a few more times later, or with a shorter run that uses uninitialized WRAM, but for now it seems like hot swap is the most stable for me. I also verified a test TAS of Gensan 1, so no more surprises there.

Posted: 1/2/2021 6:54 PM

Quote

Alyosha

He/Him

Editor, Emulator Coder, Expert player (3821)

Joined: 11/30/2014
Posts: 2829
Location: US

I researched the desync in The Humans TAS. GBHawk agrees with Gambatte in execution after I adjusted the initial HRAM state to match Gambatte. I believe the problem here is the same as Mortal Kombat. After level completion the game just continuously polls input. This happens at too fine a resolution for GBI to accurately account for. I believe the solution is to adjust the dump script to add about one scanline worth of delay to the latch timing. This should put the latch time more comfortably into the VBlank region, where the constant polling isn't happening, and should hopefully fix the problem. I'll do some testing with this assumption and report back with results. EDIT: with a hot swap after clearing HRAM to match Gambatte and a change in input latch offest from 485376 to 486376 in the script the run synced just fine. This is about 4 scanlines worth of time. It probably doesn't need to be that much, it's just what I tested with. I would say that the value of 485376 does need some fine tuning, in my experience it latches input just a bit too early, but I'm not sure what the right value would be. But anyway I'm calling this one closed, I'm confident after looking at the logs that this is the correct fix to the problem.

Posted: 1/8/2021 10:16 PM

Quote

Alyosha

He/Him

Editor, Emulator Coder, Expert player (3821)

Joined: 11/30/2014
Posts: 2829
Location: US

http://tasvideos.org/userfiles/info/68655947775585338 A final piece of follow up regarding uninitialized RAM. I made a test run of Race Days that beats 2 tracks. This was previously the worst desyncing game as it behaved differently on each test. But, with the hot swap after setting RAM to zero it works just fine. So that's the last testing I will do specifically for uninitialized RAM. 0's in all onboard RAM and 0xFF in all SRAM will be what I stick with going forward for GBA mode (which has been the case all along.)

Posted: 1/12/2021 6:00 AM
(Edited: 1/13/2021 2:35 AM)

Quote

CasualPokePlayer

Emulator Coder, Judge, Experienced player (729)

Joined: 2/26/2020
Posts: 781
Location: California

After doing some tests, I believe the GBA->GBC switch offset is actually correct. The issue is due to string.format always flooring the resulting "cycles", which leads to off by 1 issues. The correct solution is to simply ceiling the "cycles" once all the math is done with it. EDIT: After trying to play back The Humans with this new script, it synced further, but later desynced. Adding 1 audio frames to the script seems to fix this. However, I am skeptical if this is the right choice. It might be possible that the GBA->GBC switch takes in between 948 and 949 audio frames, rather than just 949. Although I am relativity confident it can't be more than 949 audio frames, and this is probably "good enough" for now.

Posted: 1/12/2021 2:36 PM

Quote

Alyosha

He/Him

Editor, Emulator Coder, Expert player (3821)

Joined: 11/30/2014
Posts: 2829
Location: US

Awesome, and I see that this also resolved the console verification issue for Avenging Spirit, so a 2 for 1.

Posted: 1/13/2021 2:43 AM

Quote

CasualPokePlayer

Emulator Coder, Judge, Experienced player (729)

Joined: 2/26/2020
Posts: 781
Location: California

After further testing, I believe the GBA->GBC switch takes exactly 948.84375 audio frames. Thus using 485808 as the new offset should solve console verification issues with input polling (along with applying a ceiling to the final number before sending it to string.format).

Posted: 1/13/2021 3:42 PM

Quote

Alyosha

He/Him

Editor, Emulator Coder, Expert player (3821)

Joined: 11/30/2014
Posts: 2829
Location: US

CasualPokePlayer wrote:

After further testing, I believe the GBA->GBC switch takes exactly 948.84375 audio frames. Thus using 485808 as the new offset should solve console verification issues with input polling (along with applying a ceiling to the final number before sending it to string.format).

I tested Wacky Racers, another very timing sensitive game that didn't work before (sometiems reads input at scanline 143 and sometimes in VBL) with these settings and it worked. Nice work, I think that resolves the input timing issue completely, I will update the GBHawk input dump script accordingly.

Posted: 1/13/2021 3:43 PM

Quote

Alyosha

He/Him

Editor, Emulator Coder, Expert player (3821)

Joined: 11/30/2014
Posts: 2829
Location: US

CasualPokePlayer wrote:

After further testing, I believe the GBA->GBC switch takes exactly 948.84375 audio frames. Thus using 485808 as the new offset should solve console verification issues with input polling (along with applying a ceiling to the final number before sending it to string.format).

I tested Wacky Racers, another very timing sensitive game that didn't work before (sometiems reads input at scanline 143 and sometimes in VBL) with these settings and it worked. Nice work, I think that resolves the input timing issue completely, I will update the GBHawk input dump script accordingly.

Posted: 1/13/2021 4:33 PM

Quote

TiKevin83

He/Him

Ambassador, Moderator, Site Developer, Player (155)

Joined: 3/17/2018
Posts: 358
Location: Holland, MI

I have an updated dump script here that works across gbhawk/subgbhawk/gambatte and splits up movies with hard resets. https://pastebin.com/NbTRNePD

Posted: 1/14/2021 2:45 AM

Quote

Alyosha

He/Him

Editor, Emulator Coder, Expert player (3821)

Joined: 11/30/2014
Posts: 2829
Location: US

TiKevin83 wrote:

I have an updated dump script here that works across gbhawk/subgbhawk/gambatte and splits up movies with hard resets. https://pastebin.com/NbTRNePD

Nice, that's convenient. I just console verified an 8 track test run of Wave Race with the new timings as well. At the risk of sounding over confident, I think maybe there isn't that much left to do here in terms of console verification dev. work, things have really come together. I have Gensan 1 and 2 ready to go for when 2.5.3 is released, and then I'm pretty much caught up on runs.

Posted: 1/15/2021 4:50 AM

Quote

TiKevin83

He/Him

Ambassador, Moderator, Site Developer, Player (155)

Joined: 3/17/2018
Posts: 358
Location: Holland, MI

I'm working on making videos of some of the verification movies from Alyosha's repo and ran into a few problems: The Kwirk movie was missing an ending blank input so the final input didn't register, checked the others and Oracle of Seasons and Oddworld Adventures 2 were also missing the final blank input. When I tried to do my own resync of Kwirk, GBHawk did not emulate the lag accurately enough (though surely it will sync fine manually adding the final input). I'm checking that game now in Gambatte to see if the emu inaccuracy issue persists there. Edit: resync to Gambatte worked fine and the final timestamps were slightly ahead of the timestamps Alyosha's repo (probably EFL differences?) - will note the userfile and video on the Kwirk publication.

Posted: 1/15/2021 1:49 PM
(Edited: 1/15/2021 10:34 PM)

Quote

Alyosha

He/Him

Editor, Emulator Coder, Expert player (3821)

Joined: 11/30/2014
Posts: 2829
Location: US

The bk2 files I used for console verification are all linked in the opening post of this thread, they should all work in dev build, I don't think any of them are the same as the publication file. Kwirk and Spirou in particular were originally made on much older builds of GBHawk that emulate frame timing differently and thus required substantial resyncing to work in current builds. EDIT: I compared input from the new dump script to the old one, looks like it's off by quite a bit. I think the problem is that GBHawk needs to use the OnInputPoll event, where as Gambatte just does it at frame boundary, so the new script won't really work for GBHawk in it's current form. (I think I knew that back when I made the GBHawk script but forgot.)

Posted: 1/15/2021 5:11 PM
(Edited: 1/15/2021 5:54 PM)

Quote

TiKevin83

He/Him

Ambassador, Moderator, Site Developer, Player (155)

Joined: 3/17/2018
Posts: 358
Location: Holland, MI

ok, I'll look into that event too, thanks. Is everything ok with those GBI movies other than the missing blank inputs mentioned?

Posted: 1/15/2021 5:54 PM

Quote

Alyosha

He/Him

Editor, Emulator Coder, Expert player (3821)

Joined: 11/30/2014
Posts: 2829
Location: US

Yup they are all the same ones I used in the console verifications. Just be aware that ones that need ram set need the hot swap to work.

Posted: 1/17/2021 4:46 PM

Quote

Alyosha

He/Him

Editor, Emulator Coder, Expert player (3821)

Joined: 11/30/2014
Posts: 2829
Location: US

I console verified the first level of Airaki by Furrtek, a game that purposely tried to be difficult to emulate, with no issues. I also realized that twitch doesn't automatically save your past broadcasts, so none of the verifications I did previously were saved, oops. I'll be recording some of them and uploading to youtube. Hopefully I can have Spirou, Zen, SMB Deluxe, and Mega Man Xtreme up today, and the Oracle games later in the week.

Posted: 1/31/2021 7:10 PM
(Edited: 1/31/2021 9:17 PM)

Quote

CasualPokePlayer

Emulator Coder, Judge, Experienced player (729)

Joined: 2/26/2020
Posts: 781
Location: California

https://github.com/mgba-emu/mgba/issues/2032 Looks like this series proves to still be ass to emulate correctly all the way to the GBC game. I researched this and this happens to be another case where correct open bus implementation is needed, otherwise this game gets stuck in some infinite loop at this point. GBHawk has good enough open bus behavior where this doesn't happen, so ~~any TASes of this game would have to be with GBHawk~~ disregard, TASes can just go use some infinite jump glitch with the hammer, only relevant for casual playthroughs.

Posted: 1/31/2021 8:54 PM

Quote

Alyosha

He/Him

Editor, Emulator Coder, Expert player (3821)

Joined: 11/30/2014
Posts: 2829
Location: US

Thanks for the research, does ThunderAxe31's WIP of this game not encounter this somehow? (It's done in Gambatte, but haven't looked at it myself.) http://tasvideos.org/userfiles/info/67980900883093493

Posted: 1/31/2021 9:14 PM

Quote

CasualPokePlayer

Emulator Coder, Judge, Experienced player (729)

Joined: 2/26/2020
Posts: 781
Location: California

Alyosha wrote:

Thanks for the research, does ThunderAxe31's WIP of this game not encounter this somehow? (It's done in Gambatte, but haven't looked at it myself.) http://tasvideos.org/userfiles/info/67980900883093493

Oh, interesting. Seems like there's some infinite jumping glitch with the hammer or something so doing the puzzle the intended way isn't needed (thus this glitch never comes up).

Forum BizHawk GBHawk

Forum

BizHawk

GBHawk