Nice, so basically now we are in three possible states after auto-syncing, instead of 300+ possibilities.

I was wondering: What actually does define the parameters of the synchronisation of the computer with the screen, and what can impact it?
- On startup, when booting the machine, are we synced to a know value, or is it impacted by the power circuitry, the tv, random parameters, etc...
- Does pressing the reset button change the synchronisation values?

Great that someone is testing this! If the idea works it would be incredibly useful for making games and demos!

Now a couple of things I don't understand. For the description I understood that after the algorithm, the IRQ would be triggered somewhere between lines 208 and 260, the latter being outside the image area and all of them at the bottom of the screen.

Why the middle screen shows the raster in the middle then? And why the rightmost image shows it so up (I think it is well above line 208)?

And yeah, I know about racing the beam. It means updating the screen top to bottom very carefully to keep behind the raster, and by lines, not by columns. I don't remember why I had some problems when trying it in Oricium, though...

The numbers originally proposed, even if I hadn't mixed up multiplying by 40 and multiplying by 64, were predicated on a 260-line 60Hz frame. It turns out it's 264 lines. So the original arithmetic is based on false accounting, though the premise is still solid: leave a 60Hz attribute visible in a screen location for n cycles, then change it to a 50Hz attribute and any machines that were in the n cycle region of the display prior to that attribute will skip 312-264=48 lines.

So if you have a particular target zone that you want all Orics to be in, you can repeatedly perform that process to shift those that are in the wrong until all are in the right.

Having thought more about the "what offset does startup inherently leave us at?" question, I've come to the conclusion that it doesn't matter. Neither disk nor tape offers a guaranteed loading speed because both are subject to flutter and wow (and, with a tape you don't know how far the user rewound it; with a disk you don't know which track the disk drive was at when power was first applied, so don't know how long the initial seek to track zero took, or what the initial rotation was). So unless your title is on ROM I don't think you could safely do anything with that knowledge.

EDIT:
based on 312 and 264, the following is possibly correct:

Step 1: eliminate all Orics currently in the period without pixels.

write a 60Hz attribute at the start of the first line, leave it up for 88 lines, replace with a 50Hz attribute;

wait a 60Hz frame length;

do the same thing again.

Step 2: collect all Orics in the final 48 lines of the display.

write a 60Hz attribute at the start of line 176, leave it up for 176 lines, replace with a 50Hz attribute;

wait a 60Hz frame length;

do the same a further three times.

Step 3: bounce those Orics in the top half of the final 48 lines into the bottom.

write a 60Hz attribute at the start of the first text line, leave it up for 24 lines, replace with a 50Hz attribute;

wait a 60Hz frame length;

write a 60Hz attribute to same place, leave it up for 288 lines, replace with a 50Hz attribute;

repeat that a further five times.

All Orics should now be in the bottom three lines of the display. Start your VIA interrupt. And you can use ordinary VIA timing methods to move its location if you don't want to be in the lower 24 lines.

As before, typed directly from the top of my thoughts, not checked. Hopefully close to correct. I count 12 instances of "wait a 60Hz frame length", which is 12 waits of 264 lines, plus non-frame waits of (6*288 + 24 + 4*176 + 2*88) = 2632 lines. For a total of 5800 lines. So the whole process should take 371,200 cycles. So it's a blank screen for 40% of a second. I think you'd get away with it.