TASVideos

Posted: 2/16/2021 4:28 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

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

You should only need 'Odyssey 2 Bios' to run it. Something very strange is happening in TAStudio. When it loads a state the first CPU variable gets corrupted for unknown reasons. The weird thing is that when I change the order in which things are saved, the corruption goes away. quicksave states made outside of TAStudio never get corrupted. I briefly tried to debug what is happening, without success. As far as I can tell every variable that needs to be in there is in there, so I think it's a TAStudio issue somehow. I won't be able to look that deeply into it for a bit. O2Hawk existed in 2.5.2 in basically the same form as in 2.6 and there is no corruption there though, so try 2.5.2 for now.

Posted: 2/15/2021 6:59 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

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

yeah looks like a savestate issue, I'll look into it.

Posted: 1/31/2021 8:54 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
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/28/2021 7:16 PM

Post subject: Console Verification R & D

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

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

I am making this thread for discussion about console verification research and development, what is currently happening and what is needed for advancement. Here is my synopsis of the current state of console verification (that I am aware of) for various systems and what next steps might be needed to move things forward. I won't go into detail for disc based systems, as likely the first step for a lot of those is replacing disc drives with something deterministic. NES: I think many more NES games can be console verified with current technology. I think the limitation right now is in understanding power on characterization. Improvement here just needs the time investment to do the many tests that it takes to understand the details. I had started doing this with true a few years back but didn't get anything concrete. Admittedly there probably aren't many runs left that would motivate that kind of investment, maybe Punch Out? SNES: My understanding is that the clock of the SPC700 is one of the major obstacles to verifying more games. Also the version of BSNES used in both lsnes and BizHawk is pretty outdated, but I'm not sure how much would actually be gained from updating it. Even sorting out these things, I'm not sure how well the various expansion chips are emulated, which many of the more noteworthy SNES games use. The SA1 memory access timing test still fails in the most recent higan, but I don't think it's known if passing it is even required for verificaiton of e.g. Super Mario RPG. It's probably a long road ahead for SNES. GB/C: I'm pretty confident most games can be verified with GBI. Even when they fail, the pipeline is mature enough that problems can be tracked down quickly. However all of this only applies to relatively standard TASes. Pokemon Yellow ACE for example requires subframe inputs at a higher resolution then GBI can supply. A new replay device would be needed for that. There may be a couple linked play TASes worth verifying that might need some new replay device work as well, and other edge cases like Kirby Tilt 'n Tumble. GBA: Probably some more games can be verified, maybe with some manual adjustment like in SMB3, I think there just needs to be more trials. Beyond that though it is still early days for console accurate GBA timing in many cases, especially ppu, so games requiring careful timing are unlikely to work. But how many of those are there? Currently there isn't enough data to tell, really just need to throw more runs at GBI. N64: Similar to GBA, probably there are more games like Mario 64 and Mario Kart 64 that will work even with current emulation (mupen) that just need to be tried to find out. However it's well known for notable games such as Goldeneye that current emulation is not close enough to console to work. New emulator needed. CEN64 is the closest but even that doesn't do things like cache emulation carefully yet. The huge performance cost perfect memory timings would bring though would make TASing full games tedious, maybe there is a 'good enough' middle ground. Genesis: Not much work has been done with Genesis recently, so it's hard to characterize. Probably Gensplusgx is good enough for many/most games. Again, more trials are needed to see. DS: Not sure how much previous success with Brain Age carries over to other games. Maybe Melon DS in BizHawk can spur more development, but it's still early. Other older cartridge based systems: Need someone interested to put in the ground work, likely not much interest though. Overall I would say that currently many more runs can be verified with current technology, but probably not the ones that would be the most high profile / important. In most cases the hardware side (replay devices) is way ahead of the software (emulation) side. Even where emulation is strong though (NES), the verification pipeline is not nearly as mature as it could be, so more fine tuning is needed. I'm going to try to put more work into NES / SNES later this year, hopefully the success with GB/C can be reproduced. Anyone have any other thoughts? Am I missing anything?

Posted: 1/26/2021 10:48 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

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

Link to video Here is a console verification of the most recent file.

Posted: 1/19/2021 10:21 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

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

bihan wrote:

Where should I start if I want to learn to help develop emulators? I'm very much a beginner; I've examined and written some Lua code and have taken some Computer Science courses in college (university) and learned some basic Python, C++, and Java.

BizHawk has a lot of beginner friendly issues right now, you can probably find something there that fits your interests whatever they may be. If you want to get a sense of what it takes to develop the backend stuff, maybe try your hand at solving some of the NESHawk mapper issues that popped up recently. If you prefer front end stuff, there are some simple feature requests that should be doable without going into the more nebulous regions of BizHawk. I also had limited programming experience when I started working on BizHawk, and just kind of jumping in and fixing stuff worked for me.

Posted: 1/19/2021 10:13 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

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

Very impressive and unexpected find, and it looks so smooth too, nice work. Hopefully it can make it's way to console too.

Posted: 1/18/2021 8:35 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

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

Yeah runs with equal length frames true are pretty likely to desync. I don't think there is anything that can be done about it. Games that turn off the screen enough will eventually line up frame boundaries with input reading, and then the rounding in GBI will occasionally put the input on the wrong side. GBHawk also uses equel length frames, but avoids this by only changing input at the start of vblank, and games aren't likely to be reading input at that time since there are higher priority things to do. This is also why equal length frames false does work, since it tries to start new frames on vblank start. Maybe the text description for that setting should be changed to reflect this limitation (but really it is a limitation of the verification device so I don't know.)

Posted: 1/17/2021 7:59 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

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

Cool i was hoping a TAS of this game would get done. I started looking into it but it seemed too complicated, but looks like you did a good job in it. Yes vote.

Posted: 1/17/2021 4:46 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
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/16/2021 2:34 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

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

This is a known issue, it has already been fixed in the dev build.

Posted: 1/15/2021 5:54 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
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/15/2021 1:49 PM
(Edited: 1/15/2021 10:34 PM)

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
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/14/2021 2:45 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
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/13/2021 3:43 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
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:42 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
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/12/2021 2:36 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

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

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

Posted: 1/9/2021 9:16 PM
(Edited: 3/21/2021 10:56 PM)

Quote

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/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.

Posted: 1/8/2021 10:16 PM

Quote

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/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/5/2021 4:07 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
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.

Posted: 1/2/2021 6:54 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
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: 12/31/2020 12:49 AM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
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: 12/29/2020 8:59 PM

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
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.

Posted: 12/28/2020 10:48 PM

Post subject: Re: requesting console verification

Quote

Alyosha

He/Him

Editor, Experienced Forum User, Published Author, Expert player (3536)

Joined: 11/30/2014
Posts: 2733
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?

Posted: 12/26/2020 12:03 AM

Quote

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/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.

Posts for Alyosha