you can race the beam, I've written many demos that use this. On the original Apple II you have to do something called "vapor lock" or "reading the floating bus" where you draw a pattern to memory scanned by the video circuitry, then read an unmapped memory address and you get a "ghost" of the last value read by the video circuitry due to capacitance on the bus. You can then find the beam location, but from then on you have to cycle-count everything. Sather describes this in his book.

Don Lancaster had a software-only method for syncing to the video scan, called the Vaporlock. Which is a play on "genlock", which TV production systems called their hardware to sync to the scan for doing overlays.

Don's technique relied on the fact that the video hardware in the II line scanned memory that was outside the video frame. He put magic values in those extra bytes for each scan line, and his software could detect where the beam was on each line. (I've probably messed up the explanation; it's from memory of 40 years ago...)

The great thing is that you could mix video modes within a single scan line, allowing you to put text on the left edge of a HIRES graph. The downside is that the Apple can't do anything else, because his code is running in an exact timing loop to stay synced.

There were other solutions, but those were all hardware-based.

No, and there was no (easy) way to detect the vertical retrace. For a lot more on that topic have a look at the Apple II mouse card, they needed to synchronise with the video and did work out a software based way of doing it, but the final product added hardware to make it possible.