Currently, UniPCemu uses a half character clock system.
It's basically very simple: neither bits set means each character clock, divide by 2 set only means character clovk divided by 2, divide by 4 set only means character clock divided by 4. Then a special case is made for when both divide by 2 and divide by 4 are set: perform twice per character clock (which is why UniPCemu rendering is based on the half character clock counting).

Now, there's two timers (really dividers) running directly off said half clock (both clocks reset to trigger at the start of each scanline of active display):
- The memory address clock (based on the 'memory address' divisors: CRTC mode control bit 3 and underline location bit 5. This increments the memory address counter when it ticks the divided value.
- The Shift/Load mechanic (after the above, except for the first load on a scanline where it isn't getting an increased memory address counter). This, when it ticks, applies the memory logic(MAP13/14 bits, followed by address wrapping) and loads the latches from that address (ET4000 also the next address(+1) before translation in 16-bit character code text mode). After loading the latches, it uses the current text or graphics mode handling to pick it apart and (using plane 2 if needed) generate 8 pixels font/background status as well as the attribute (and text-mode specific additions) to start clocking out to the attribute controller.

What do people here think really happens on such hardware?
What happens when SLR is increased? UniPCemu just makes it read VRAM and decode less often(or more often, with both bits set), but if the experiments with the shifting registers is to be believed (https://hackaday.io/project/6150-beckman-du-6 … -a-new-vga-mode) it's even more complicated?
Or simply force reloads without reading from VRAM when using division by 2 or 4 cases (but not both set) by instead just rotating (ROL) the latches?
What if this is used in text modes?