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.
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.
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.
Speedrunner who finds something cool once every couple years I guess?
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.
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.)
Speedrunner who finds something cool once every couple years I guess?
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.
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.
Speedrunner who finds something cool once every couple years I guess?
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?
I have resisted doing this in the past, but I just have to admit that I can't continue to finance both console verifications and new hardware research on my own anymore. I keep hoping used game prices will go down, but it never happens, and it's become too hard to justify spending the high prices for games that I might verify once and never look at again.
So, I am now accepting game and hardware donations!
See my homepage for info if you are interested: https://tasvideos.org/HomePages/Alyosha
(And not just GBA, I'll accept anything anyone is interested in seeing verified.)
My idea here is to use donated games / hardware for the day-to-day efforts of testing sync and console verificaitons, so I can focus resources on things for new hardware tools and research (like dev boards and electrical components and such.)
For the record, it cost $75 for a six month lease of the PO Box, so with current game prices even getting as few as 2-3 games could already be worth it.
Feel free to PM me if anyone has any questions. Thanks!
Would you leave some bank account info to accept straight donations too?
I submitted some movies for the purpose of console verification testing, and now I feel a little awkward because the life challenges made me postpone the making of full TAS movies, and I don't know when I will ignore them all for the sake of this thing
TASing is like making a film: only the best takes are shown in the premier.
https://xkcd.com/3246/
Would you leave some bank account info to accept straight donations too?
I submitted some movies for the purpose of console verification testing, and now I feel a little awkward because the life challenges made me postpone the making of full TAS movies, and I don't know when I will ignore them all for the sake of this thing
I don't have anything like that set up at the moment. Maybe I can set up pay pal or gofundme or something, Not sure what the best approach is, I'll look into it.
I had to use very large parameters for flash timing, 1500000 cycles for a sector erase compared to ~350000 I used for Sonic. The chip in SMB3 is the same one as in pokemon, so maybe I need different defaults for those but I can't seem to find a data sheet that is an exact match.
I recently created some tests to measure flash timings: https://github.com/CasualPokePlayer/gba-flash-speed-test
The results obtained from just my own Emerald cart point a really bleak picture. I would expect some wide variation from different carts, but my tests indicate that a single cartridge by itself can have wild variations (enough to even cause frames worth of variation if a game uses a ton of sectors for its save data).
For "erase sector" timings, they vary every time the test is ran, and they even sometimes outright fail to erase a sector in some iterations (i.e. giving you a "timeout" in games, and games would proceed to retry to erase the sector).
For "program" timings, they appear to actually be consistent (and programming 0xFF appears to be faster than non-0xFF even?)
Cool tests!
How are you running them, are you replacing the ROM in your cartridge?
I'm not really surprised at the results, I don't want to go too far down the path of 'this TAS only works on my cart, and only sometimes' but what else can we do? That's reality.
Alright, so as I was trying to do something related to the recent Pokémon Ruby/Sapphire advancements... I decided to give it a go with testing on a live RTC battery.
The result is this:
Link to video
Initially, the movie desync at the starter due to being on a completely different seed as a result of the RTC state being incorrect... as expected. Unsure, I checked for a way to alter the RTC on a cart and found GBA_RTCRead. GBA_RTCRead, as the name says, reads the RTC on select GBA carts (Pokemon RSE and Boktai) and allows modification of the RTC info. So after changing the RTC info to what was used in the movie (gave myself 30 seconds leeway), I was able to get it to successfully sync! Although, the timings of inputs are off when it comes to saving. I made sure to use the Flash chip applicable to my authentic Sapphire v1.0 cart, which used the Sanyo chip, too.
The Pokemon RTA community has been running some tests using Mesen integrated into my own emulator (GSE), namely just doing RTA runs (without saving, since that's non-deterministic) and playing back the results on console. The tests have resulted in some desyncs being discovered. One of them was able to be fixed by cross-referencing GBAHawk (which matched console). However, one of them ends up desyncing the exact same way on GBAHawk, so it appears Mesen and GBAHawk share the exact same inaccuracy (wherever that is).
https://tasvideos.org/UserFiles/Info/639068276894494681
The apparent desync point in this movie shows up at around frame 11892. The trainer ID will be shown, and Mesen and GBAHawk show an ID of 03107, whereas console has an ID of 03072. The trainer ID in this game is set within the name selection screen, using Timer1 (start on entering the name selection screen, and stopped on exiting, although everything you do before the name selection screen can potentially affect results anyways)
I thought Mesen and GBAHawk were at parity, what did you have to change for the first desync?
I don't have Fire Red, but I see that the movie starts from an existing SRAM, do desyncs happen when starting from blank (oxFF) SRAM?
Also I made a few minor accuracy fixes since 2.3.2, so might want to try dev build and see if that has any effect.
I thought Mesen and GBAHawk were at parity, what did you have to change for the first desync?
I don't have Fire Red, but I see that the movie starts from an existing SRAM, do desyncs happen when starting from blank (oxFF) SRAM?
Also I made a few minor accuracy fixes since 2.3.2, so might want to try dev build and see if that has any effect.
The first desync was just caused by serial interrupts occurring (the game likes to touch the serial port on soft reset and clicking New Game as part of some check for the wireless adapter being present or not), I changed Mesen to no longer do any serial interrupts (as they probably would never occur as there is no link cable connected).
The movie is designed for using existing SaveRAM (as RTA runs normally are since that allows for options to be set beforehand), the runner testing the inputs would load up SaveRAM beforehand. This shouldn't be an issue, as reading SaveRAM is perfectly deterministic.
GBAHawk dev builds have the same inaccuracy.
It's not my own cart so I don't have that.
According to the runner anyways it is a 1.0 ROM (you can tell within the copyright screen), so the movie was made using a 1.0 ROM. I have no idea which flash chip it uses, although it is probably the Macronix one as that is the more common chip. Sync doesn't change if you change flash chip types anyways.
Currently I don't have a cart or 1Mb flash dev board, so I have no way of addressing this. Even then I don't have the time to track down a probably very complicated accuracy error. Probably ETA Summer, hopefully someone figures it out before then so I don't have another 40+ hour grind on my hands.
Just to check the basics, are there absolutely no serial interrupts expected ever if there is no link cable connected? Or can serial interrupts occur sometimes in certain cases? Looking at GBAHawk code it appears the answer is maybe the latter?
