I'm seriously thinking about just throwing away the existing HSYNC circuitry, and switching from a character-column-based system to a pixel-addressed counter arrangement.

There are several events that need to happen along any given axis of a display:

With the 8563/8568 VDCs, these events are encoded in a variety of registers which, frankly, make no sense and makes for hardware which is significantly more complicated than it needs to be.  It has taken me several weeks worth of study and a corresponding amount of experimentation with emulators to finally understand how to implement a compatible HSYNC generator, and to figure out how horizontal scrolling would work.

I've been trying to figure out a corresponding theory of operation for the VSYNC generator, but to no avail.  It seems to defy any rational explanation.  Despite the registers seeming to indicate they are common circuits under the hood, it turns out that there's enough minute edge- and special-cases that differ between HSYNC and VSYNC generation that they each would require their own formal specification.

I'm not sure I want to go down this rabbit hole.

It is especially weird that the VDC has separate registers for controlling blanking along the X-axis, but not on the Y-axis.

Contrast this with my CGIA concept, which I'd intended for use with the Kestrel-3 project.  It uses pixel/line up-counters and magnitude comparators to trigger events.  Horizontal control circuitry always works in units of pixels.  Vertical control circuitry always works in units of raster lines.  Both have a similar set of registers.  No exceptions, and thus, no strange surprises.  Plus, this approach directly supports features like raster interrupts, which are notably absent on the original VDC.

The other criticism I have of the VDC approach is its extreme reliance upon down-counters for almost everything, key word being "almost."  In both X- and Y-axes, there are separate down-counters for specific purposes (e.g., to control the horizontal display enable, for example), but up-counters for other purposes (e.g., vertical smooth scroll depends upon a down-counter, but knowing which raster line to fetch for character font data depends on a corresponding up-counter that holds the same information.)  This is incredibly wasteful of resources, to say nothing of how confusing it is to keep the design in your head.

In conclusion, although I'm satisfied that I've been able to figure out HSYNC behavior, I'm simply not able to crack the VSYNC behavior nut.  I've spent weeks on this problem, but haven't gotten any further than defining how the display is generated without support for vertical smooth scrolling or the vertical total adjust.  Without a coherent method of generating HSYNC and VSYNC, we can't get a stable display.  For this reason, I'm deeply inclined to change the programming interface for the VDC-II away from VDC-style CRT control and replacing it wholesale with CGIA-style CRT control instead.

I really, really wanted to maintain backward compatibility with the VDC on this particular aspect.  But, I see that is proving to be more expensive in terms of my time than I had hoped.  Perhaps some external contributor can provide a compatible hardware definition in the future.  For now, I think going with the CGIA CRT controls is the right choice for me.