Posts for Alyosha

Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (3840)
Joined: 11/30/2014
Posts: 2845
Location: US
CoolHandMike wrote:
Looks like a small improvement, but what was improved? The submission description is rather barebones here. Is there a time stamp for improvement(s)?
There's nothing in particular to point to. The entire run consists of manipulating points as fast as possible. This one is faster overall, but individual sections may be faster / slower.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (3840)
Joined: 11/30/2014
Posts: 2845
Location: US
Noxxa wrote:
My understanding was that you would complete 1-1 normally (there's no possible way the Birdo skip saves any time there, as you have to go the long way around the stage back in order to activate it). Then in 1-2, go to Birdo's room to load the exit to 1-3 on screen 3, and then backtrack to the cave where you ladder glitch on screen 3 (probably doable using a bomb) to skip to 1-3 and have the Mouser skip active. This would save ~15 seconds on the Birdo fight+level transition and ~13 seconds on the Mouser skip. The problem is that backtracking to the cave ladder would either require some way to clip into the blocks from the back entrance, or going the long way around, getting the key in the vase, and entering the cave from the front. If you have to do all that, it's probably slower overall.
I don't think you can take the upper cave to get to 1-1 Birdo though, as that leads to a softlock when using the ladder in 1-2 as in the video. So you have to go the long way around. But either way, yeah it seems you need to somehow clip in from the upper cave door in 1-2 for it to save time. Getting the key takes too long.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (3840)
Joined: 11/30/2014
Posts: 2845
Location: US
MESHUGGAH wrote:
Is this TAS uses the shenanigans explained in this video? Link to video I made a YouTube comment with the chapters. Here's also the list: 0:00 Introduction to room transition mechanics 0:41 How room transitions work 1:18 Level layout and transition objects 1:36 The level exit table explained 4:12 Examples of door and vine transitions 5:05 Positioning mechanics in transitions 9:14 Using glitches to warp between levels 11:58 Skipping Birdo in level 1-1 13:19 Manipulating transitions in level 1-2 15:40 Boss skipping and the desync mechanism 16:15 How level variables are managed 17:23 End of level algorithm flowchart 21:14 Full flowchart 22:30 Alternative wrong warp methods and conclusion 23:30 Shoutouts and level format decoding
From the current warps run thread. It looks like for this to work at all. you have to take the long route to the first Birdo. This probably costs ~5 seconds. But then screen 1 never has a level transition loaded, so if I'm understanding things right, the ladder in 1-2 would then lead to the start of the game. It then takes ~ 12 seconds to reach the potion and glitch to 1-3. Alternatively you can take a bit of a detour to load the lower cave in 1-1 as in the video. Both these options probably take the same amount of time overall. So let's say ~15 seconds are needed to in travel time. This mean you have ~13 seconds to get to the ladder in 1-2 from the Birdo room. Definitely not possible if you need to get the key in the vase. Some kind of clip would be needed to use the other door to get to the cave for this to save time.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (3840)
Joined: 11/30/2014
Posts: 2845
Location: US
https://tasvideos.org/UserFiles/Info/638729375391421612 Trying to clean up my old files, I tried to do some more work on SMB2 warpless to implement the mouser star kill. I got up to 5-3 with minimal time loss but now I'm stuck on a bob-omb pick up. An albatoss is higher than in the current run and things don't line up right. Killing the mouser with the star has some knock on effects on things that carry over between levels, I've been able to work around most of them, I only lost a few frames in 5-2 due to it, and fry guy mercifully worked out ok. Currently I don't understand why the albatoss is spawning at a different height, it's not using the same addresses as other things I'm aware of. If anyone can figure out how to pick up that bob-omb please let me know.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (3840)
Joined: 11/30/2014
Posts: 2845
Location: US
Woah, I won TASer of the year, thank you voters! I'm glad other people are enjoying the console verification work as much as I am. It's an extreme grind, but I still think the results are cool every time I see a new TAS working on console. More challenges lay ahead, let's go!
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (3840)
Joined: 11/30/2014
Posts: 2845
Location: US
Spikestuff wrote:
You're better off making a new one from scratch, and I'll show you why. I have input that I've been sitting on since October 2023. So you know how Freddy crashes into that wall? I get there at 19352 frames compared to the 19365 frames. Now it's a worse final time overall, cause I was having issues at those stupid bonuses, which is why I didn't submit mine in the year and a bit. My vote is No. Work on a new movie, do not reprise Logan's input. Alternatively. Nab my now public input and use that instead.
Yeah, the RNG manip on the bonuses is quite painful. If someone is able to use your file as a base and still get a better time then this one, they can have it.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (3840)
Joined: 11/30/2014
Posts: 2845
Location: US
I've been doing some work to clean up some loose ends of NES verifications as kind of prep work to working on SNES. One of the things that always stumped me was why PaperBoy requires sending 3 blank polls to the bot to get it to sync instead of the usual 1. Well I coincidentally encountered the same problem with Karate Champ, and decided to try to figure it out. It turns out that it's just an uninitialized RAM issue. For both games, if you start RAM with all FF, they end up in a state where they ignore the first frame of controller reading (and since both use DMC, that is 2 polls, hence why I need to send the bot 3.) Starting up with all 0 gives the expected behavior. So it seems my console has enough bits set consistently in RAM at power on to encounter the first case in both games, though I haven't bothered checking exactly which addresses are the culprit. So, that solves that mystery, not sure why I never checked that before, it should have been the first thing I tried. Anyway, the biggest remaining desync mystery is Batman, which works easily using frame based approach but I never got to work with poll based.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (3840)
Joined: 11/30/2014
Posts: 2845
Location: US
I finally got a dev board, this one: ( https://shop.insidegadgets.com/product/gba-32mb-512kbit-flash-save-flash-cart/ ) to test flash save timing. This was opened as an issue as GBAHawk fails test 002 of the flash save tests from here: https://github.com/jsmolka/gba-tests . However the test writes and then immediately reads from Flash, without giving time for the write to process. I asked JSMolka about this, who confirmed that the test itself was only ever tested against a EZ flash and not original hardware. So, I got the dev board to check, and indeed test 002 fails on hardware (the board has an sst39vf512 which is accurate to original carts.) I'll revise the test so that test 002 takes a reasonable amount of time and see if that version passes on the dev board as well. That will confirm it is indeed a timing issue. EDIT: With further testing updating all tests to wait for an expected time for writes to occur, the save fails on hardware on test 6 (I wasn't giving it long enough, with enough time to write all tests pass.) This is a good example of why testing on correct hardware is important.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (3840)
Joined: 11/30/2014
Posts: 2845
Location: US
Cool! Lots of unexpected stuff showcased here.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (3840)
Joined: 11/30/2014
Posts: 2845
Location: US
This was another successful year in console verification. We ended the year with 433 current TASes verified, a bit short of the 450 I was hoping for but oh well. Probably the biggest verification this year was SMB Bad Apple, thought it did require a bit of trickery, it was still amazing to see. NES hardware research still continues into 2025, and there are still a few mystery desyncs left out there, but it's hard to ask for much more from the NES. At the start of the year I predicted GBA verification would reach maturity on the level of GB and NES, and that was pretty accurate. I was able to verify Minish Cap, Mega Man Zero, Metroid, and DKC amongst others. A huge amount of time went into hardware research to make this happen, but looking back that time was spent on relatively few actual missing details. I guess this is the Pareto principle in action. Nearly all of this research was directly driven by desyncing TASes as well, which shows how well this approach works for finding hardware quirks, and also how hard it is to correctly guess what to look for and account for every detail. For the last few desyncs I was hacking savestates into games to track down the exact instruction desyncs happen on simply because I had no idea how else to proceed. There is a lot of research left to do for the GBA, but probably for console verification what I have is good enough for most cases. And that's about it for console verification directly. Of course 2024 also saw the downfall of Switch emulators, the continued rise of LibTAS, and other general changes in the emulation landscape that might have tangential effects for console verification. I expect things to more or less stall in 2025, there's just too much left to do for any newer consoles. For my part I intend to make a new SNES emulator and also revisit some NES failures.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (3840)
Joined: 11/30/2014
Posts: 2845
Location: US
Hâlian wrote:
A new GBA emulator with a focus on hyperaccuracy? Hell yeah. I actually found out about this by checking the Emulation General Wiki's article on GBA accuracy tests, since a friend of mine is working on a Fire Emblem 8 hack and the community's guide to hacking on the decomp suggests using Nocash, which dates it. (Also, hi. I'm surprised I didn't already have an account here.)
Hi! For game / hack development, nocash has a lot of good tools. For Fire Emblem in particular, it does rely on open bus emulation to be accurately emulated for console accurate enemy movement near the bottom of the screen as I've detailed in a previous post. Not sure if nocash has this or not. If you want something more modern and accurate for game / hack development you might also consider Mesen, which has a relatively new GBA core and a lot of cool tools. GBAHawk is research and TAS focused, so admittedly has limited dev tools. This post reminds me that I should add some more info to the Github page instead of just the one line ReadMe I've had since the start.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (3840)
Joined: 11/30/2014
Posts: 2845
Location: US
By mGBA suite I mean this one: https://github.com/mgba-emu/suite which has many many tests in one ROM, testing many aspects of the GBA. More generally, there are many suites of GBA tests scattered around. Some of them are represented here: https://emulation.gametechwiki.com/index.php/GBA_Tests but there are others. By running them manually I assume you mean as opposed to some automated process, then yes. I'm also aware that my documentation of any of this is poor to non-existent, but there's always just too much to do.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (3840)
Joined: 11/30/2014
Posts: 2845
Location: US
I've been pretty busy lately, but I'm still trying to make progress where I can. Recently I became aware of some relatively new tests: https://github.com/hades-emu/Hades-Tests Turns out GBAHawk was failing several of them, but for relatively simple reasons. I fixed those up (but one of them fails on hardware, dma latch test 4, so that one will remain failing, I opened an issue about it.) Also recently many new tests were added to the mGBA test suite, mainly focused on the serial port. I fail most of those for some reason, I think for them to work I need to have a link cable plugged in but not connected to a second GBA, maybe, I haven't had time to look into any of the details. Serial port is still low priority (its good enough for pokemon coop diploma, and that's probably one of the only use cases), so I'll kick that can down the road. More interestingly, there is a ppu background display test that fails. I thought I had that pretty well nailed down so I was pretty surprised it wasn't quite right. Anyway always more to do.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (3840)
Joined: 11/30/2014
Posts: 2845
Location: US
CDRomatron wrote:
Was not sure, so I've gone through and checked. I've tried clearing the save ram on both, copying the cart save to GBAHawk, copying the GBAHawk save to the cart, and 0xFF the whole save on both, neither seem to change the seed I reach the minigame at.
Interesting. Can you send me the movie file and the time stamps you use?
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (3840)
Joined: 11/30/2014
Posts: 2845
Location: US
CDRomatron wrote:
Thanks for the quick response and suggestion. I've so far tried setting it to 10000, 20000, and 32000, none of which seem to change the frame it arrives at as the RNG is the same across all three. It's just the option titled "EEPROM Offset"? (I've been changing it manually in the SyncSettings.json to get to the point where I can test it.)
Does your movie start from cleared cart RAM? If so, do you clear cart RAM on your cartridge to 0xFF before replaying on console? Yeah the EEPROM Offset is the only setting you should need to change.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (3840)
Joined: 11/30/2014
Posts: 2845
Location: US
CDRomatron wrote:
Hi, was recommended coming along here from Discord. I'm trying to start on a little project to do some learning. A big goal for me was being able to run the TAS on console, since I had all the hardware I would need to run through GBI. The game is Spyro Fusion, saves with EEPROM. I've been using GBAHawk 2.2.0, and have verified that my dumps match what they should be in terms of the bios and game. The game rarely advances RNG, which makes manipulation trivial in most instances, except for a singular minigame that appears approx. 3 mins into gameplay. The RNG function uses the current frame count to seed it when starting the minigame, so I need to know what frame I've entered the minigame. On GBAHawk, I've seen the value I get, and the starting position of the enemy (which gives me an idea of where I am). On console, the same inputs give me a different starting position. After playing around on GBAHawk, it appears like the console is entering 4 frames later than emulator. My suspicion at the moment is due to the game doing occasional auto-saves with EEPROM. I understand that there is a sync option for tuning, which might solve my problem. But I'm unsure where to start with it (as the range is ~64k possible options). Does anyone have any suggestions based on the situation? Thanks in advance.
I would start around 10000. Unfortunately EEPROM timings vary widely, it's a bit of a process to tune them.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (3840)
Joined: 11/30/2014
Posts: 2845
Location: US
It may be possible to significantly improve the run in the future when subframe resets become possible.
If you are interested, subframe resetting is available in GBAHawk, though I haven't tested it in a while, but I'm pretty sure it's in working order.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (3840)
Joined: 11/30/2014
Posts: 2845
Location: US
GoddessMaria wrote:
Do you need an authentic Emerald or LeafGreen cart to do testing?
Well as long as the run doesn't save I don't need it, the run should work for any cart as long as no saves or autosaves happen. But otherwise yes I would need one (I don't have one and I'm not willing to pay ~$200 for one to buy it myself, what's with these crazy prices?) Although with 2.2.0, people can tune runs to their personal carts, so there isn't a need for me in particular to do it, and I think emulation is otherwise accurate enough for a new run to sync on console (of course, testing as you go is recommended.) Pokemon is probably the last run of interest for console verification, so I'm willing to help in whatever way is needed for it to happen. Side note: I heard back from Epilogue and they say Mario Kart save loading will be supported in an upcoming software patch, so eventually that one will be done too.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (3840)
Joined: 11/30/2014
Posts: 2845
Location: US
With GBAHawk 2.2.0 released, I added check marks to DKC 2 and Super Metroid GBA. At the moment there are no remaining runs to check for games that I have carts for, so, I guess that's all for now.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (3840)
Joined: 11/30/2014
Posts: 2845
Location: US
GBAHawk 2.2.0 is released, with implementation of Flash chip type selection and manual timings. This also includes the accuracy improvements for DKC 2 and Super Metroid GBA. Next thing to work on is GBP detection / emulation, which is disabled in this release, but all the wiring is done, I just need to understand the commands. Aside from that the only major upgrade I want to make is finishing implementing the LDM^ glitch. Just bug fixing after that.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (3840)
Joined: 11/30/2014
Posts: 2845
Location: US
No luck resyncing Gunstar Super Heroes or Lady Sia to GBAHawk.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (3840)
Joined: 11/30/2014
Posts: 2845
Location: US
Not sure about emerald, but on saphire the order goes : timer start Flash chip check halt is sued on copyright screen So, as long as RNG isn't used before the copyright screen, the chip check shouldn't matter if it takes less than a frame. And it seems the check doesn't do much more than check the ID, so halt should be able to sync everything up. At least in Sapphire
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (3840)
Joined: 11/30/2014
Posts: 2845
Location: US
CasualPokePlayer wrote:
Makes more sense. Starting at 225 means it takes 163 scanlines to get to the second frame, 65 scanlines less than the typical 228 total scanlines. I would assume me offsetting by an entire frame more just worked due to how Pokemon polls inputs (once at the start of the main loop, which normally at the beginning of vblank).
Correct. And even though timing tests give 65, I do occasionally have to apply -1 to the GBI inputs if inputs are being polled really close to the start of vblank, so maybe there is a slight offset to when GBi applies inputs and the original -83776 is closer to the precise value that should be used.
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (3840)
Joined: 11/30/2014
Posts: 2845
Location: US
CasualPokePlayer wrote:
That still doesn't make much sense? Startup timing tests indicate that input would be polled sooner on console than emulator? Is it GBI somehow being late with its internal timestamp tracking? (by ~20 PWM frames???) Keep in mind by "1 frame back" I meant I just set the starting cycle from 0 to -CYCLES_PER_FRAME.
Based on my testing, the first frame after power up is shorter. A test called music4.gba, show that the ppu must start either at scanline 161 or 225 (GBAHawk starts at 225, which is where the 65 comes from.) With this timestamps for GBI line up (roughly) with vblank boundaries, which is noticeable when testing games that sample input close to the start of vblank. I imagine this was noticed by whoever put -83776 in the original script as well (1232*65 = 80080 which is pretty close.)
Alyosha
He/Him
Editor, Emulator Coder, Experienced Forum User, Published Author, Expert player (3840)
Joined: 11/30/2014
Posts: 2845
Location: US
CasualPokePlayer wrote:
I already had the cycles per frame add set to the end of the movie. The subtraction of the frame is after that change. (in fact, you have some weird -1232 * 65 offset already? Which doesn't make much sense)
Interesting, well I'll eventually get to Pokemon but I doubt it got the right RNG by chance. That value comes from start up timing tests. Similar to how the tas.bot script has cycle = -83776.