Input latency is probably going to be important if button interrupts are used. I am not sure which games use this though, if any. It's not necessarily important on gameboy.
It is very likely emulation quality is not there yet. To determine if input timing is an issue, inject your own delay and determine if the results are deterministic.
From what I read, button interrupts are usually used to wake the GBA out of stop mode, so that's probably not the issue.
Looking at vba-m's code, the inputs are set right at the beginning of VBlank. I changed the code to set button inputs in the middle, as so:
This helped with dropped inputs, but the replay still doesn't play out correctly. On the first stage Mario always jumps too soon. I doubled the length of each button press and he jumps too late.
I'll post the videos of that if anyone is interested, but I'm gonna assume its emulation at this point.
I have received two GBAs and some Spongebob games from someone who wants to remain anonymous; thanks! I can try verifying games as long as there is some way to detect input poll or screen update on the hardware, will need to look for that. Hopefully someone has already done the work.
I've been working on my GBA project recently (the YouTube posted earlier is an earlier try at it). You can detect a VBlank off the SPS pin.
I've been having issues with that approach though -- inputs are either being dropped or not recognized, and I'm not sure if it's due to my setup or just differences between emulation and the real hardware. My inputs should be tied to a single frame, as you can see here:
Last signal is the SPS pin that I'm keying off of, which has the expected frequency of 59.73 Hz. GBA buttons are active low. There is some latency on the order of 50 uS, but I don't think that's the problem.
The game I'm testing against is Super Mario Advance 2. As far as I can tell, there's no standardized way of polling buttons for the GBA (and buttons can actually drive interrupts), so I'm not 100% certain that setting a button for a single frame actually does work for it/other games.
For most handhelds, it would require modification to force contact closure on the contacts, and a sync source to sync with the device. This is possible on most handhelds.
I'm trying my hand at making a GBA bot, but the input syncing is definitely my sticking point at the moment. How would you suggest doing it?
My current strategy is to just set the inputs for an approximate vblank cycle, since I don't think there's any way to get a pulse as you'd have in a console's controller. The timings seem to be too difficult though, setting it close to a vblank (16.7 ms based on a 16.8 MHz (2^24 Hz) CPU and 280,896 cycles/vblank) leads to dropped inputs. Setting it higher shows that it works, but obviously leads to immediate desyncing.
Edit: Oh, the LCD pinout has a VSYNC pin, that should give me what I need. Not sure why I didn't start looking there!
This helped with dropped inputs, but the replay still doesn't play out correctly. On the first stage Mario always jumps too soon. I doubled the length of each button press and he jumps too late.
I'll post the videos of that if anyone is interested, but I'm gonna assume its emulation at this point.
Last signal is the SPS pin that I'm keying off of, which has the expected frequency of 59.73 Hz. GBA buttons are active low. There is some latency on the order of 50 uS, but I don't think that's the problem.
The game I'm testing against is Super Mario Advance 2. As far as I can tell, there's no standardized way of polling buttons for the GBA (and buttons can actually drive interrupts), so I'm not 100% certain that setting a button for a single frame actually does work for it/other games.