Note that with GBI you can just eliminate the GBP detection entirely (it's a configurable option), or alternatively plugging in something to the link port will prevent serial communication from taking place (this is what RTA runners do IIRC).
By "same chip as in Pokemon" do you mean you checked by unscrewing your own cartridge? Flash 1MB chips come from potentially 2 different manufacturers, Sanyo and Macronix (the latter being more common iirc?). The Pokemon RTA community has noted Sanyo chips apparently are much faster than Macronix chips.
Flash ID checking would end up taking differing amounts of time depending on flash ID returned, so that could be useful for letting the user select it regardless.
cycle = -1232 * 65
#cycle = 0
with open("GBItimestamps.txt", "w") as f:
for line in inputs:
sline = line.decode().rstrip()
if sline[0] == "|":
data = sline[:-1]
data = data[1:]
#data = data[25:]
if data != lastInput:
if cycle < 0:
f.write(f"{0:08X} {convert_frame(data):04X}\n")
else:
#sometimes need a -1 here, depends on timing of inputs per game
f.write(f"{cycle//4096:08X} {convert_frame(data):04X}\n")
lastInput = data
cycle += CYCLES_PER_FRAMEI 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)
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.
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).