It's very interesting following your work hlide, unfortunately I have far from enough knowledge about the internal signals to come with any meaningful input.
In your current test compile of PAL EmuZ-700, how many cycles per line is VRAM-accessible?
A while ago MooZ sent me this link:
https://twitter.com/youkan700/status/10 ... 7077280768
Where some guy from Japan have written a program that somehow tests the size of the VRAM access window. I have to admit that I don't really understand exactly how it's working, but playing around with it on my MZ-700 I get a bugfree access window at 82 cycles (and lower) and bugs if I set to to 83 and higher.
So, if 82 cycles/rasterline checks out, I did some quick math and came up with the following:
My test program runs 1000 loops of LDIRs of 1000 bytes. Each LDIR takes 21 cycles, so we are looking at 21 million cycles of VRAM access for it to run (now, this isn't the *exact* truth, since not every cycle of the LDIR 21 cycles actually needs VRAM access, so the first and last of the LDIR instructions that fit into the window may stretch out a bit before and after).
Anyway, if we skip these, we at least get an upper bound on how long it should take.
312 lines * 82 accessible cycles per line * 50 frames per second = 1279200 VRAM accessible cycles per second.
21000000/1279200 = 16.4 seconds.
My manually timed tests shows that it runs a bit below that, which makes sense as I said, LDIR doesn't necessarily get absolutely blocked outside the VRAM-window.