Hi, sorry — I've collected notes from miscellaneous sources and am curious as to whether I've understood what I'm reading. Is the below an accurate summary of the timing behaviour of an Enterprise 64?

In PAL there are 283.7516 colour cycles per line. An Enterprise outputs slightly longer lines than spec, each one being exactly 284 colour cycles long. So it outputs 283.7516/284 * 15625 = 15611.3336268 lines per second.

In each of those lines there are 171 RAM access windows. Two out of every three are occupied by Nick. So only one out of three is available for the Z80.

The Z80 is ordinarily clocked by a separate crystal at 4Mhz. If it wants to access RAM, or a Nick IO port, it has to be aligned to the next available access window. This is performed by stopping the clock. The clock will always be stopped for an exact number of 4Mhz clock transitions, i.e. half cycles.

So, as awkward as it turns out to be, I make that 121303809/363520000 RAM access windows per Z80 clock transition. So it is very nearly true that three clock transitions, or 1.5 cycles, is the length of an access window, but not quite. It's actually slightly less — more like 1.498.

In addition to this there is a WAIT generator, which can be disabled, enabled only for M1 cycles, or enabled for all memory access cycles. When enabled it will pad the relevant cycles out by holding WAIT for a single 4Mhz cycle.

Dave accesses don't require alignment to an access window, ROM accesses don't require alignment. On an Enterprise 128, accesses to the additional 64kb don't require alignment, and neither does access to the contents of any RAM expansions. It's only the 64kb of RAM that Nick can access that require arbitration.

So then Nick has bandwidth for two-thirds of 171 bytes per line = 114 bytes, which break down as LPB fetch for 16 bytes, graphics fetching as defined, then six bytes to effect RAM refresh.

I have to admit to not yet knowing whether the mode line is fetched afresh every scan line or whether Nick just does busy work in the more common case when a mode line is longer than a single scan, but either way the slots don't become available for the Z80 or for anything else.

No, the crystal is a 8Mhz, this is the System Clock, also used by the Dave chip, and WD177x chip on the EXDOS card.
The Nick made the clock division for the Z80, including the clock stretching.

Oh, well that was just poor phrasing. I should more correctly have written "The Z80 is ordinarily clocked at 4Mhz, by a separate crystal"; I just meant that the timing of VRAM access slots and the Z80 clock are not derived from a common source. So there's no clean integer relationship between the two. Unlike other machines of the same era where most things are divisions of the same clock.

It is in the Dave chip. And it is only valid when non video memory accessed.

That I didn't know. But presumably it's RAM-only? Not ROM?

...
You can see: every second Z80 windows missed.
On the third picture you can see what happen, if CPU running on 6MHz: every Z80 windows used.

Cool. I had also assumed a full RAS for every Nick access — no attempt at paged mode — based on the video modes. Hence the assumption that it's 171 equal-sized access slots per line, rather than e.g. [RAS, CAS, CAS], [RAS, CAS]. It looks like that was a correct guess.

Follow-up query: are Z80 refresh cycles are completely ignored? Even if I have a refresh address that prima facie points to VRAM, that won't cause a false positive on clock stretching? Is the Z80's refresh cycle the one that keeps non-VRAM stable?