I finally figured out Incredibles enough to get it to sync. The game initially turns on gamepad IRQs which makes playback difficult, but it turns them off again after the first input. So I found that having an extra start press while the game title is loading turns off the gamepad IRQs before they cause issues with the rest of the run. The code it runs at the IRQ seems like it is not entirely benign though and messes up sync for the rest of the existing movie file from RetroEdit. GBAHawk 2.0.2 had a bug where the interrupt wasn't firing at all, so the desync seems unavoidable. I resynced what I could manually, the video is below. It seems like, barring anything else being wrong, Incredibles should be console verifiable in GBAHawk 2.0.3.
Link to video
I also decided to test Super Monkey Ball Jr as the run is short and the 3D seemed like a good test of timing. The TAS desyncs very badly, but I got a test run of level 1 going and it made it through that. The game uses EEPROM, but doesn't appear to be too sensitive to timing. Comparing the video to emulator, it looks like the EEPROM is going somewhat faster on console, so the game spends a few extra frames on the title screen, but it doesn't effect the rest of the run:
EDIT: video removed, superceded below.
So good progress. I have a couple more things I want to do before releasing 2.0.3, but now that I finally figured out Incredibles I can start making progress again.
I finished up verifying Wario Land 4. All resyncs were pretty simple. 4/4 runs verified. I'm going to try Metroid Fusion again, then move on to Metroid Zero Mission.
Link to video
I was able to properly verify Metroid Fusion, so that run is verified, finally completing one of my original goals. I am working on 100% as well.
The resync was done using RetroEdit's resyncing tools, which are incredible and saved me hours of effort. They should greatly speed up future verifications where simple adjustment for lag / loading times are all that is needed. EDIT: 100% done as well, cool!
Alright, for my small contribution to this...
I did a test of Pokémon using my Japanese copy of Ruby version to check the integrity of capability with console. I did intentionally choose to go with bad (dry) battery for this as my cart's battery is dead. From power-on up to saving, everything worked without a hitch. Unfortunately, syncing using the exact inputs from the movie broke and led me to manually check and count the frames that the inputs were off from that point and adjust the movie accordingly...
Original movie:
GBMV
Encode (original):
Link to video
After having added 75 frames to the movie, the inputs for soft resetting worked, but then that also had to be tweaked in order to get it resynced. Once the Start input was put back in its correct place, everything else worked correctly as intended.
Console Fixed movie:
GBMV
Encode:
Link to video
Cool! How many such soft resets would there be in a complete run? 75 frames is an inexplicably long time, not sure what's causing that, but I guess it's manageable as long as it's consistent.
The quest to find the bug that was keeping Shrek 2 from being console verified is over! Today I found that it was a rather simple issue with timing of the case where a DMA pauses an already running DMA of lower priority. This also fixes the desync with Metroid Zero Mission.
Link to video
With that, I have no TASes known to desync due to emulator accuracy issues. I have to do some work to verify the fix in all edge cases, but it fixes the two desyncs and doesn't break any existing TAS, so it seems solid. At the same time I also redid part of the DMA loop, which gave a ~5% speed up due to skipping a lot of steps when no DMA is running. It's not much but I'll take every fps I can get.
Once I have everything tested and verified good I'll release v2.1.0. Now that Shrek 2 is no longer stuck in the back of my mind I can focus on the long list of relatively less important edge cases like undefined / implementation defined cpu behavior, running DMA in decrement mode in ROM region, running FIFO DMAs very close together, etc.
I also tried to verify Donkey Kong Country but the EEPROM timing was way off, no small or even relatively large change to the baseline timing could possibly fix it. I'm not sure what I'll do about such cases yet. Maybe just use extra blank frames since saving only happens at the very start and very end of the run, but I'd much rather have something cleaner.
Anyway finally time to test some new runs!
I finished up verifying Metroid Zero Mission runs thanks to RetroEdit's resync script greatly speeding up the process. The new Metroid Fusion Memory Corruption run also worked on console so that was cool. That's all runs of GBA Metroid games verified along with ~50% of associated ROM hack runs, good progress.
Now I will try to fix some runs where RNG doesn't work.
I'm having no success getting any other runs to sync for games I have. Here's a quick summary:
Fire Emblem:desyncs in second stage, doesn't seem fixable fixed in 2.1.1
Fire Emblem Sacred Stones:desyncs about half way through the run in the same fashion as the first game. fixed in 2.1.1
Banjo Kazooie: I can't fix the RNG of the enemies, so damage boosts don't happen.
Rayman Advance: Syncs about half way through with some manual effort, but then breaks. Fixed, new run submitted.
Advance Wars 2: Seems like it might sync in emulator but desyncs in a strange way on console, the game polls input in a weird way.
Mario vs. Donkey Kong: See below
Turok Evolution: bad enemy RNG in first stage.
Mega Man Battle network 2: Bad encounter RNG
So yeah, definitely hitting a road block in terms of resyncs.
I did manage to console verify the Donkey Kong Country 101% run though:
Link to video
It turns out I had a wrong EEPROM setting which was preventing sync at the start. After that I needed to adjust timing of EEPROM writes to be about 10% faster than the GBA Tek baseline to get it to sync.
GBAHawk version 2.1.1 will have a sync setting to account for this. Eventually I'll add a similar setting for Flash, but that is more complicated so just EEPROM for now.
Some time ago RetroEdit sent me a resync of Donkey Kong Country 2, but I don't currently have a cart to test it, seems like it should work though.
https://tasvideos.org/UserFiles/Info/638446788869509673
With a bit better understanding of how the lag resync script works, I was able to get a good resync of Mario Vs Donkey Kong. Unfortunately it doesn't work on console because the save time is just way too long on my cart. As far as I can tell it's like 50% longer than the stated maximum on the data sheet, which is causing sync issues.
My cart uses the same Flash chip as Sonic Advance, so I'm not sure why the timings are so different, but perhaps after 20 years this is just what you get.
Link to video
With some considerable effort I was able to get Fire Emblem to work on console after all!
I should get the Sacred Stones run done some time this week as well.
Here is a video and movie file for a complete test run of Super Monkey Ball Jr. Master stages. It is console verified, but quite a bit slower than the published run (which doesn't sync at all.) I had previously tested one level but wanted to follow up with at least a complete test run since I was previously unable to get the skip in level 4 to work.
Link to videohttps://tasvideos.org/UserFiles/Info/638464781749776967
I won't be working on a complete new run, at least not any time soon, a working test run was my goal and that's good enough for me.
Link to video
Here is a test run of the first level of Megaman and Bass GBA. This game uses the other variety of EEPROM (8kb while the other games I tested use 512b.) As it turns out my cart has very different timings compared to the other 2 EEPROM verifications I did so far. Those were -9000 or so on the cycle timing offset while this one is +28000. This value seems pretty stable at least.
Right now the only other 8kb cart I have is Ty 2, so I'll have to go back and check the timings of that one more carefully to see what kind of agreement I get.
I recorded a small TAS of Duke Nukem Advance: User movie #638491602391815310
The game features unusual usage of hardware. The sound chip participates in calculation and doesn't play music during the gameplay. Besides, the framerate is uncapped.
So I think it will be a good accuracy test for GBAHawk, if you have the game around.
TASing is like making a film: only the best takes are shown in the final movie.
I recorded a small TAS of Duke Nukem Advance: User movie #638491602391815310
The game features unusual usage of hardware. The sound chip participates in calculation and doesn't play music during the gameplay. Besides, the framerate is uncapped.
So I think it will be a good accuracy test for GBAHawk, if you have the game around.
Woah that's really interesting!
I don't have a cart right now, but I'll be sure to get one when I can and give this a try, thanks!
It turns out sparky's SNES run can be almost directly used in the GBA version with some file editing. Having done so I managed to get past Cold Man and verified that the zip glitches also work on the GBA version. I didn't keep track of RNG so I eventually ran out of Ice Wall, but I console verified up to where I got in Astro Man's stage:
Link to video
Cold Man didn't have the same RNG so I had to redo part of the fight, and there are some small changes needed where the screen being slightly smaller led to some desyncs in hitting enemies, but other then that and fixing some minor desyncs the inputs are sparky's. Pretty convenient that the port matches so closely.
I'm not sure if I'll work through all the necessary RNG manipulation to get the complete run to sync, it would be funny if a SNES run got verified on a GBA first though.
