Posts for Alyosha

Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3572)
Joined: 11/30/2014
Posts: 2744
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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3572)
Joined: 11/30/2014
Posts: 2744
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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Awesome, and I see that this also resolved the console verification issue for Avenging Spirit, so a 2 for 1.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3572)
Joined: 11/30/2014
Posts: 2744
Location: US
http://tasvideos.org/userfiles/info/68677201607586094 Here is a partial resync of Xtreme 2 that works in the current GBHawk build. It beats Flame Mammoth and starts the next level. I console verified this movie up to beating Flame mammoth, so if a complete run ever gets redone it should work on console as well. Compared to the original VBA movie, there is a lot more lag, so things are slightly slower overall. Also here is a resynced verification movie for completeness: http://tasvideos.org/userfiles/info/68657981202423899 In terms of strategy I think staying as Zero would be faster overall but only if there is quick way to kill the mini boss in Launch Octopus' stage.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3572)
Joined: 11/30/2014
Posts: 2744
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.)
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3572)
Joined: 11/30/2014
Posts: 2744
Location: US
It's been a while since I posted here, as my time has gone almost exclusively to GBHawk, but I do work on things occasionally in the background (most of which just get deleted as they don't amount to anything, but whatever.) Most recently though, I finally made a basic C++ version of NESHawk: It's a stripped down and simplified version, mostly just to see how fast it would go out of the box. This is about 100 fps faster then C# NESHawk, but still not really comparable to Mesen which is up around 400. It could definitely be optimized to take advantage of C++ with pointer trickery and such a bit more, as well as some more general optimizations, but I also left out the mapper system (it only does nrom) so probably these things would roughly cancel out. So while I think the test was worth the time to do, this won't be a production core. The whole NESHawk ecosystem is too big to port over and would be a huge time sink for not even double the speed. It does give me a good test bed to work with though, so I'll be tinkering with things over time, especially the CPU, for optimization. Hopefully it will be sort of a launching point for a SNES core. Let's see how things go.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3572)
Joined: 11/30/2014
Posts: 2744
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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3572)
Joined: 11/30/2014
Posts: 2744
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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Interesting, this is one I actually can look into, I'll be doing so in the next week or two. Uninitialized HRAM aside, I find it strange for such a slow paced, fairly standard looking game to encounter a desync, will be interesting to see what the problem is. EDIT: I researched The Humans in this post: http://tasvideos.org/forum/viewtopic.php?p=502659#502659 I'm confident it is input latch error in the the dump script and not emulation related. I think this one can be closed.
Post subject: Re: requesting console verification
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3572)
Joined: 11/30/2014
Posts: 2744
Location: US
ThunderAxe31 wrote:
Hi there. It was brought to my attention that there is a graphical quirk on emulator that seems to be less severe on real hardware. For that reason, I'd like to see a console verification of a Castlevania Aventure TAS, preferably the GB version. This movie file should work for the purpose: submission #6834 Specifically, I'd like to check if we get the same horizontal lines that start appearing from minute 14:57 onward of the following video: https://www.twitch.tv/videos/848116999?t=00h14m57s
"blue"-print run on definitive version I see that in the twitch video you posted, what does it mean?
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3572)
Joined: 11/30/2014
Posts: 2744
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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Cool trick. Discoveries like this that are relatively simple yet no one ever thought to try always makes me wonder what other stuff is still out there to be found. Yes vote.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3572)
Joined: 11/30/2014
Posts: 2744
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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3572)
Joined: 11/30/2014
Posts: 2744
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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3572)
Joined: 11/30/2014
Posts: 2744
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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I'll be showing the Oracle of Ages run tonight at 10 pm eastern time at alyosha_tas if anyone is interested. I also uploaded the RAM clearing program to the github repo. It will set all WRAM and HRAM to 0xFF and then turn off the screen and execute an infinite loop in VRAM. I'm going to try a hot swap test of games that have previously failed due to uninitialized RAM in the next couple of days. Gensan 1 will probably be first on the list, and Race Days as well. I'm hopeful this method will eliminate problems with uninitialized RAM and allow some more runs to be verified.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3572)
Joined: 11/30/2014
Posts: 2744
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.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I tried working on Seasons again. The initial desync was due to me improperly clearing SRAM, so I closed out the post in the de-verified thread about that one. I also got by the RNG desync that was stopping me before. The bad news is that the run deterministically (or at least the 2 times I tried) desyncs on console about half way through (~190000 frames in.) I tried changing WRAM initial state to reproduce this, I can get runs that desync at about ~100000 frames in, but not this exact desync. I would still guess some initial RAM value is causing the problem, but I don't want to spend forever figuring out exactly which one. I'll probably finish resyncing a run that at least will work in 2.5.3, even though it won't work on console, then move on, there's too much other stuff to do. I'll be streaming again at alyosha_tas at 10 pm eastern time tonight. Runs will be Oddworld 2, Kwirk, Super Mario Bros Deluxe (any% and You vs Boo) I don't think I ever posted the resynced Oddworld 2 run, it's still in gambatte just now it works in 2.4.2 and doesn't use equal length frames: http://tasvideos.org/userfiles/info/67165593974849577
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I'll be doing another stream at alyosha_tas today at 10:30 eastern time. Runs will be Men in Black the Series, Spirou Robot Invasion, and Megaman Extreme. Also I updated the movie file in the opening post for oracle of ages to work in the dev build. Now it is consistent with console when writing 0xFF to SRAM. I'll try Oracle of Seasons again over the weekend, but I'm pretty sure the new initial WRAM state should solve the consistency problems there as well.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3572)
Joined: 11/30/2014
Posts: 2744
Location: US
CasualPokePlayer wrote:
https://github.com/ISSOtm/gb-bootroms/blob/443d7f057ae06e8d1d76fa8083650cf0be2cd0ae/src/cgb.asm#L297 Or it's set to 1 on this write to FF70 shortly before the end of the bootrom?
Huh, I guess I confused myself somewhere along the way. Anyway, I changed GBHawk to just set initial WRAM to 0xFF in GBA mode, since the game seems to check for 0 which is unlikely in most bytes from that dumped file. This gives sync on console that is now actually consistent with emulator when writing 0 to SRAM. So looks like problem solved there. I'll make a new movie for Ages and a new test for Seasons with writing 0xFF to SRAM now since that has been the standard.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Interesting, so definitely not the pattern like CGB, basically random junk. I'll do some more testing. Also, it seems like RAM bank automatically gets set to 1 on he write to FF50. I was only doing this on GB compatibility mode, but Gambatte seems to be doing it in CGB mode too, that is probably also important.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3572)
Joined: 11/30/2014
Posts: 2744
Location: US
TiKevin83 wrote:
I would be more suspicious that the cart battery isn't holding since it sometimes will work anyway and settle into FFs, but doesn't always work that easily.
I tested the battery on my Ages cart and it holds zeroes when I write zeroes.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Thanks to everyone who watched the test stream / gave helpful advice. Here is a repo of the input timestamp files I used, I'll be adding more as I get more organized: https://github.com/alyosha-tas/GBI_timestamps I'll link this in the opening post too. Also I did some more research on oracle of ages / seasons. Seasons was randomly syncing occasionally despite not properly clearing RAM, so I went back to Ages to see if maybe I missed something. It turns out that when I was verifying ages I was writing 0 to SRAM before playing the game, not 0xFF. Desptie this fact, I played the run on console several times this way and it always synced. In emulator though, 0xFF was written. If I tried writing 0xFF to the game, it now desyncs on console. How can that be? Ages reads several areas of unintialized RAM in order to set start up values. So, it must be that the initial state in GBA mode is different then in a CGB, so that the error in the time spent clearing WRAM cancels out the error in the time spent clearing SRAM when it is 0xFF. As unlikely as this sounds, it's basically the only variable that can change. I tried a few different possible initial RAM states, and indeed there are some possibilities where the difference in cycles executed after initial startup is only a few hundred cycles. So I think we really need a dump of WRAM from a GBP to see what it actually is.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3572)
Joined: 11/30/2014
Posts: 2744
Location: US
I'm going to be doing a test stream of some GB console verificaitons in about an hour (11 pm eastern time) if anyone wants to watch. I'll be doing batman return of the joker, battletoads, and maybe zen intergalactic ninja if things go smoothly. It will be alyosha_tas on twitch.
Alyosha
He/Him
Editor, Experienced Forum User, Published Author, Expert player (3572)
Joined: 11/30/2014
Posts: 2744
Location: US
Unfortunately I was only able to catch a little bit of the event live, but what I saw looked pretty well put together and seemed to be going pretty well (at the time I saw it), so well done to the organizers and tech people for at least getting that far. Probably could have used a few more months of lead time, as putting together TAS content is just slow by nature. I don't really get the other criticism about involving this site more, the opportunity was there to get involved (though apparently some lack of communication caused an issue as above.) But honestly there weren't many posts in the event thread even expressing that much interest, where as event planning needs active people actively doing stuff. Seems reasonable not to keep pumping at a dry well. But also maybe some more lead time in the future can give more people the chance to get involved without being faced with a short deadline right out of the gate, maybe.