In the right hands I'm sure someone could use the lightpen to achieve stable mid-line splits. The VDC-spilt I use in my test programs currently have about a 1 or 2 character jitter which I could live with for the results I was after. Obviously this jitter would need to be totally removed for any respectable demo.
The VDC draws approximately 2 characters/ cpu cycle (VICII slow mode). The challenge is getting a CPU that is not in sync and is running almost half the speed than the VDC (assuming 8 dot clocks/VDC cycle) to time the updating of VDC registers with a 1 character width precision. I doubt the VICII in fast mode would offer much help because clock stretching during the update of IO registers, and the VICII DRAM refresh cycles does not allow the cpu to run consistently at the faster speed. Maybe Z80 could help or some multiline trickery by reading the lightpen multiple times...
I think the main problem you have is you have to wait for the VDC to say its ready, before you can write to a register, this makes cycle perfect timing impossible. The VIC-II stretching is no different to 1mhz mode so I don't see that as being a hindrance, in fact you could use it as a way to eat the 1 cycle "slide" that a nop could give, if you hit the odd, it will stretch to the even, if you get even you just write. The question would be does the VDC allow you to write to registers during display fetches? Does it have 2 internal buses, so it can set its RAM bus to fetch data, while it pushes data into its registers?
The Z80 won't avoid the VIC DRAM refresh, the VIC still does refresh the RAM during Z80 operations, otherwise the RAM would decay. The Z80 also completes the current instruction before honoring a interrupt.
Saying it's impossible is a big call. You only really need to check for busy flag after you've executed a memory transfer via the VDC registers. Have you tried the vdc split using lightpen? It wasn't it's primary purpose but it demonstrates that you can have reasonable control where on the line you update a VDC register. c-128.freeforums.net/thread/600/vdc-raster-split
reasonable sure, but we are talking about cycle perfect right? On my code, I switched to the "you don't need to check the register every time" and watched my code break So I would love to hear the conditions you don't need to check for ready flag when writing registers as it will speed up my 128 version even more
Sorry, that was too broad a comment. Once you know exactly where the VDC is with it's internal operations with drawing etc, and understand how the busy flag works, then you don't always need to check the busy flag. In general you should check the busy flag unless you are confident the VDC is no longer busy. An example where a program fails on real hardware and Z64K because the busy state of the VDC is not respected is discussed here ==>c128-vdc-emd.prg from the VICE test repository.
My abovementioned VDC raster split test program has a busy flag test that shows the time the VDC is transferring memory and doing other internal operations. There is bit of a discussion in the VDC raster split thread on the observed behaviour of the busy flag. It's something I plan on revisiting to improve my understanding.
What is always helpful to improve our understanding of how the VDC works is to get programs that work in emulators but fails on real hardware or vice versa. I'm always on the lookout for programs that break emulation like VDC101 did.
What we need to do is make a test board that hooks up to a Pi, and then me manually runs its clocks a lot slower, so we can snoop its address bus, and the output lines and hit its port registers every clock, and build a nice map of what how it reacts and what it fetches when. I just hope the chip doesn't need or rely upon the input clock being 16Mhz and can say handle it at 2mhz or so. But knowing how many corners this chip maker took he probably does rely upon the input clock being X for something internally.