Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I haven't checked my movie for optimality, I just wanted to demonstrate that console sync is possible. Probably someone should at l;east try to improve before it is used for submission.
That being said, I think a movie that is demonstrated to be console accurate should be preferred over one that is demonstrated not to be, it's supposed to be a TAS representing GBA not emulator.
I also don't care about authorship, do whatever makes the most sense, I'm only interested in accuracy.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
ruadath wrote:
do you have the gbmv of the resynced movie? there was some "low hanging fruit" improvements to sonic advance that I did not have time to get working because of lag/sync issues -- maybe we can try again on the more accurate emulator and get lucky
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I was able to resync the baseline Sonic Advance run and console verify it:
Link to video
I had to change some inputs on the ice level boss fight due to different icicles, so it's not the exact same as the original, but still its good to see consistency between both this and the knuckles version.
The previous version of this TAS was verified in its original form, so there is a possibility the original run would work on some other cart, just not my particular one due to different Flash timings.
I'll try the other 3 runs of this game when i get a chance.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
https://tasvideos.org/UserFiles/Info/638358560032196485
Here is a better strategy that wins with only 9 checkers.
Basically, the computer will not let you win in 1 move if you have 3 in a row and an opportunity for 4 in a row the next move, but it will give you a chance to win on your next move if the opportunity doesn't already exist.
It's possible this can also be done with only 8 checkers with a red start, I haven't checked yet, this is the first case I could get working. EDIT: Actually that's not possible since then red would get the connect 4 first, so 9 should checkers should be the minimum.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
This TAS (Tompa's most recent one) does not sync on console. Red blocks after the third black checker. Desyncs the same way on GBAHawk. So far I haven't been able to reproduce a winning condition without a much slower play from red.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
GoddessMaria was able to get good RNG and finish the game, this run finally works on console!
Link to video
It's really cool to see this working on console now, maybe other Flash RAM games have a shot as well.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Dimon12321 wrote:
I wish I could have a similar console testing tool.
How useful would it be for the emulator development to have reverse-engineered TASes (when the input is built blindly and is iteratively loaded and played back on console to see if TAS works alright)?
Not useful for GBA. You have to work through desyncs in order, one at a time. If there is going to be a desync anyway, then you might as well use the emulator to create the TAS which is orders of magnitude faster and easier.
There may be a point where the approach you suggest is the only viable one (and it was already done for the Mario Maker switch demo, so is certainly doable.) I would imagine that consoles up to and including DS and N64, or consoles of similar complexity, can be emulated with cycle accuracy eventually. For those cases it makes sense to develop TASes on emulator. Past that though, who can say, the complexity of modern consoles quickly skyrockets. And, even if an emulator can get games running, the gap between running games and making console verifiable TASes can be very large.
If some one can get a decent workflow for modern-ish cartridge based consoles, like PSP or 3DS, to make TASes on hardware without emulator, it might be the best approach.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I've released GBAHawk v2.0.2 with improvements to Flash RAM, halt, and audio emulation.
Improvements to Flash RAM timing are particularly notable as I was able to get stable sync on Sonic Advance (my copy of it anyway, could vary cart to cart.) This could potentially lead to verification of all 5 runs of that game. Not sure how well this will carry over to other games with Flash RAM, but either way it's much better than what it was.
Improvements to halt emulation finally allow me to pass the halt_cnt tests, and my own halt tests that I made specifically to test the behaviour. Now the only known test failure I have is the 128k boundary test using decreasing DMA. This change did effect sync on Shrek 2 though, this seems to be another case of the line between lag and non-lag being only a small number of cycles, similar to Flintstones, so some small error is happening somewhere. no idea where.
I have one new lead though. The game Incredibles, rise of the Underminer desyncs at the very first start press on console. This is a good candidate for the test ROM injection strategy I used to track down the issue with Flintstones. This will be the next thing I check once I have a big block of time to focus and put things together.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
--video removed: superseded--
I'm able to get stable sync up to the last boss now. For the fourth boss so far I only just hit him as soon as possible, no entertainment value added, just to test for sync. I needed to spend 4 frames waiting on start presses in earlier levels to get this to work this far, which isn't too bad. Unfortunately, robot knuckles was not cooperating and I need to waste 4 additional in level frames on delay to get good RNG.
The only problem now is that I cannot get the last boss to do the hand attack. I delayed many frames, but so far it just doesn't happen. Maybe I need to change movement somehow I don't know.
Assuming that can be figured out, sync seems to be really stable. I opened up my Sonic Advance cart and got the data sheet for the exact Flash RAM used, which really helped nail down timings and emulation accuracy.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
--video removed: superseded--
Making some progress here. Now I get sync past the second boss and a correct save file.
Getting bad RNG on the third boss though, not sure why yet, still working on it.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Thanks to RetroEdit for providing a resync, one of the Warioland 4 runs has now been console verified. Awesome! RetroEdit's resync workflow is a huge advancement and should greatly accelerate console verification of GBA games in the future. Cool stuff happening all around.
Link to video
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
It looks like GBAHawk is not making a correct save file here, which is probably why console verification fails. I'm going to look into this and see if I can get a fix and hopefully get this verified.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
GoddessMaria wrote:
Thanks so much!
So... after floundering about like an idiot, I managed to get my movie to play on console. Unfortunately said movie, Sonic Advance, desynced at the start in Secret Base Zone Act 2 on console. It played back fine on emulator, though, which makes me wonder if there's additional timing differences not being accounted for or cart reading issues.
Link to video
Cool, nice progress!
Comparing your video to the publication video, it looks like the A press to start the level is happening at a different time, probably due to Flash timing. Since the python script doesn't need the movie to sync to create inputs, you could potentially try adding / removing frames in the movie file to get something that works, as was done in the Super Mario Advance 4: SMB3 case. I haven't tested Flash timings at all yet, so this is just a guess.
ViGadeomes wrote:
Hello,
Convert console verified movies made on other GBA emulators to GBAHawk that are then known to sync on console would also be cool at one point to test if they sync on GBAHawk:
The games you listed use Flash for saving, so it's probably not worth converting them yet until I work on timing testing, as the results will probably change in the future. At the moment I'm bogged down with other things, I doubt I'll make significant progress before 2024 comes around.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
GoddessMaria wrote:
I was wondering something... how do you go about converting the movies from GBAHawk to what's expected by console? Do you utilize the same script that is on the TASbot site or something else?
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
EDIT: Video removed, superseded by improvement.
I finished a run of Flintstones that now syncs on console so that is one mystery solved. I haven't had time to properly test all the necessary cases so this won't be a submitted TAS for a while (will be with version 2.0.2 of GBAHawk eventfully.) This was a very interesting example of just how far apart cause and effect of accuracy errors can be, and was also why it took so long to track down.
RetroEdit made a resync of Shrek 2 but it currently desyncs on the next to last level on console. Haven't been able to dig into it very deeply yet but seems it could be an accuracy issue rather than a EEPROM issue. So one mystery solved but another one takes its place.
I tried another EEPROM game Ty 2, but it is extremely sensitive to EEPROM timing so it desynced almost right away. I might put an EEPROM timing parameter into GBAHawk eventually to give more games a chance of syncing, still too early though.
RetroEdit also managed to make a resync of WarioLand 4, so I think that will be next.
Testing continues.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I was able to splice one of my timing test ROMs into Flintstones to try to track down the source of the timing error. With this I could break into the test ROM at any point and compare against console. The resolution of this particular test is 14 cycles, and the reported error was 28 cycles. I narrowed down when the error appeared to one loop of code where nothing interesting seemed to be happening. This also happened to be when audio is turned on.
The game resets audio by turning on the system, then resetting the FIFO unit, then manually writing 8 words to the FIFO buffers to fill them up before enabling auto filling via DMA. The amount of error seemd like the time one FIFO DMA would take, but I had tested pretty thoroughly and nothing seemed off.
Except it seems something was off. It turns out that writing a full 32 bytes to the FIFO seems to actually reset it back to zero. A quick test ROM verified that this seems to be the case and it fixes Flintstones. This is very unexpected. I think I'll have to make a few more tests before committing this fix. On the right track though.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I've released GBAHawk v2.0.1 as a cumulative bug fix / emulation improvement release, it also adds an about tab.
Originally I was going to wait until I fixed Flintstones for this, but right now I'm honestly stumped. The issue is quite simple, a lag frame appears in emulator that doesn't on console. I can see where it is. The game decides what's a lag frame by whether or not the previous frame entered the halt loop. On emulator, this is missed by < 20 cycles, (out of 280896 in a frame.) The problem is the error isn't necessarily in that frame, as FIFO DMAs and a timer interrupt effect the timing, and those are started at the very beginning of the game loading and not changed. So the first thing I need to do is audit the timing of all the initialization code the game does until starting the timers and FIFO DMA, and if that doesn't fix anything I have to audit the timing on the error frame.
So, I'll be doing that in between continuing verification testing on other games, maybe one of the Castlevanias.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I'm starting to make some more involved tests that test interactions amongst system components. The first thing I wanted to do was test an assumption I made a long while ago about how DMA occurs in BIOS. This assumption came about from weird behaviour in 'haltcnt' NBA test ROM that triggers a halt via a DMA started with an SWI. The result on emulator is 3 cycles off from hardware.
My original fix was just guessing that maybe DMA started earlier in BIOS. So I made a test ROM to run the same thing the halt test does but start a timer instead. Results were as expected with normal DMA start time. SO what is the proper fix?
If you assume:
-Halt only stops the cpu on instruction boundaries: you get 3 cycles too few, 2 of them because DMA stops cpu on memory access boundaries, and the boundary here is after the first cycle of branch. So two more cycles (pipeline refill) would occur before the halt.
-Halt immediately stops clocks to the cpu: you get 1 cycle off, the 2 refill cycles that need to run happen after halt instead of before as above.
This is why i assumed the fix I did, because it was the only way I could think to get the extra cycle. So the actual fix, whatever it may be, is more complicated than these 2 options. I have no more guesses what it might be. For now I simply reverted the incorrect fix and I'll just have to take the failure until I can more carefully test what's going on.
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
Thanks to RetroEdit doing some resyncs, I was able to verify DK; King of Swing, pretty cool!
Link to video
In the coming days I will also do 200% and Diddy mode. RetroEdit says these resyncs were very simple, so this probably isn't pushing accuracy very much , but it's still nice to see some success.
I will also return to Metroid Fusion when I get a chance and try to redo the resync so I can give it a check mark, and also look at 100%.
EDIT: 3 for 3 on King of swing verifications, awesome!
Editor, Experienced Forum User, Published Author, Expert player
(3536)
Joined: 11/30/2014
Posts: 2733
Location: US
I FINALLY figured out how to pass the 'cancel-irq-ie.gba' test. It seems that when enabling the timer after it was previously disabled while it has an internal value of 0xFFFF, then an interrupt can occur if they are enabled. I think internally the timer ticks for one cycle before getting reset when it is enabling, which means it is ticking from 0xFFFF to 0 and overflowing, causing the interrupt. I made a simple test ROM that verifies this behaviour on hardware, and it indeed fixes the issue.
So far I only have a rough draft of this fix, I need to think a bit more about how exactly to implement it in a clean way, but at least now the issue is known.
In hindsight this probably could have been found sooner since a very similar thing happens with a reload value of 0xFFFF, which is well known since it's part of the mGBA test suit tests. But, lots of things seem simple in hindsight.
So once that is fixed, the only failing test will be one that does a decrement DMA in ROM area near a 0x20000 boundary. I think I know what to do with this one, but it's messy to implement and needs more testing.
This still doesn't fix Flintstones though. That game turns on the timers right after boot and never touches them again, so couldn't really be a fix anyway. No idea what is happening there.
