GBC input timing

[12341231214]

I modded a GBC to be able to control it from a computer using an Arduino and now I'm trying to be able to record and playback gameplay. I'm currently using the pad labeled SPS on the board as a measure of time since it seems to run at a steady 60ish Hz but when playing back a recording it seems to get out of sync very easily.

So I was wondering if there would be a better place to get my timing from, possibly some kind of input latch like a NES controller has if that exists somewhere on a GBC?

Thanks.

[calima]

GBC does not have autoread like SNES. Games may read input at any time they wish, and as many times a frame they wish. It sounds like this is your issue, and when you supply input too late, the game applies it one frame later.

I don't think there is any "latch" hw signal, but I'm not 100% sure.

[12341231214]

Well that's unfortunate, it still happens even with a hardcoded sequence of inputs so maybe an Arduino just isn't fast enough.
Thanks for the info.

[lidnariq]

On the original Game boy, there's a signal that the code must toggle in order to scan the joypad.

Unfortunately for you, they got rid of it on the Game Boy Color, and there's just 8 digital inputs instead.

[tepples]

Earlier Game Boy systems (Game Boy, Super Game Boy, and Game Boy pocket) have a 2x4-key matrix that the program scans using two output lines (P14 and P15). Does Game Boy Color still output P14 on the SD line of the Game Link connector?

[12341231214]

Does Game Boy Color still output P14 on the SD line of the Game Link connector?

Seems like it doesn't, all of the link connector pins are either always high or always low during normal gameplay.

[SonoSooS]

If this is still relevant, and/or someone attempting to need this information, I'll leave it here.


Yeah, the LCD signals don't correspond well to what the game software sees.
But luckily for us, we can still *derive* some of the information.

I don't have exact timings for hardware signals and software correspondance, but it should be possible to narrow it down with some testing.

You'll need:

• LP - seems like this is the closest thing we get to an OAM scan interrupt, which happens right as LY increments. Otherwise the function of this pin is to latch the colors shifted in to the column driver outputs, like a huge serial-to-parallel shift register.
• CLS - "basically HSync", shifts the line driver down by one line
• SPS - "basically VSync", when held low, enables shifting an active line into the line driver when CLS pulses
• REVC (optional) - "alternative HSync", toggles its state on every line (so the display panel ends up with net zero charge over time), and should also be different every time SPS "pulses", creating virtual even/odd frame signal (although I did not measure this, but this is how I drive the LCD myself)

The hardest part, is that these signals change independently of eachother (in the timing sense), so you *will* need some logic to reconstruct where the Game Boy LY could be at.

I think this might be your best bet:

• Pin change interrupt on LP, high edge means that LY has incremented.
  • Could be gated to certain CLS pin change interrupt conditions, to reduce interrupt spam.
• Pin change interrupt on SPS, *high edge*, to know when "VSync has finished", to reset internal counters. SPS is active low, but doing it this way makes our recovery logic much simpler.
• Pin change interrupt on CLS, low edge, to know when "HSync" is about to begin soon.
  • This pin change interrupt should not do a lot, as the LP pin change interrupt happens shortly after.
  • I did not measure this one on hardware, but considering how sensitive the LCD is to timing when I drive it myself, it should be happening somewhere around mode3(draw)-->mode0("HBlank") transition, but should have definitely no connection between the two to maintain correct display colors, as lines with longer mode3 interval would flicker more, and/or have wrong color curves otherwise.

Having LCD off pin timings is uh... up to the reader, I'm afraid.
REVC might be needed in that case.

I hope this helps enough, though.

Source of my information:

• Some publically available DMG display timings. I did not save any links, but it is possible to find them again.
  • Be aware though, that display timings on GBC are somewhat different!
• Driving the CGB display myself through the cartridge port using an RP2040 running Micropython.

Earlier Game Boy systems (Game Boy, Super Game Boy, and Game Boy pocket) have a 2x4-key matrix that the program scans using two output lines (P14 and P15). Does Game Boy Color still output P14 on the SD line of the Game Link connector?

It's an input with (internal?) pull-up that appears in [rRP].4, and only works on Game Boy Color.
On GBA, SD is hard-driven high, so it doesn't seem to work at all there.