So... I ended up using the system friendly way by reading the ex_EClockFrequency from execbase for the clock and reading gb_current_tot_cclks and gb_current_tot_rows from gfxbase to get the number of rows and cycles per row.

Now the next issue appeared. To get from these to the actual numbers I need, I would have to know:
- is the screen interlaced?
- is the screen NTSC and are the long lines enabled?

I think that if the screen is interlaced, we have gb_current_tot_rows+1 rows every even frame and gb_current_tot_rows rows every odd frame, while if we aren't, we have gb_current_tot_rows+1 for every frame.

I think that if the screen isn't NTSC or if the long lines are disabled, we need to add 1 to gb_current_tot_cclks to get the number of clocks, and if we have a long lines NTSC, we need to add 1 to gb_current_tot_cclks every even scanline and 3 to gb_current_tot_cclks every odd scanline.

If any of those assumptions are incorrect, please correct me. Also, the hardware register with the info I need is read only and I couldn't find that info in execbase or gfxbase so far. Anyone knows where I can get that info?

Honestly... it is not possible unless you have reliable external frequency source not linked with system clock - proper NTSC and proper PAL are using different system clock and Horizontal timing is different - Vblank is not valid source.

After while i have idea - perhaps interrupt from floppy INDEX signal can be used to distinguish between NTSC and PAL machines (timer counting ticks between interrupts, after some averaging it could be OK especially if floppy will be without disk inside).