In a classic simple 6502 system the setup is usually: the 6502 receives a symmetrical clock signal. It unfailingly tristates the bus during the first half of each cycle, then accesses memory during the second. Therefore RAM that is fast enough to keep up with the 6502 is used at only 50% of its bandwidth. So the other 50% is used for video fetching — the basic pattern is a video fetch during phase 1 (i.e. the first half of a cycle) and then a CPU access during phase 2 (i.e. the second half).
If machines require more bandwidth for video than that implies, the CPU has limited stoppage periods. Of those I'm familiar with, the C64 is a famous example, the Acorn Electron a less-famous example.
So... how much do we know about the Lynx's bus handling?
These things I think are uncontroversial:
- Mikey both contains the CPU and is responsible for the video DMA;
- from the processor's point of view, a page mode memory access costs 4 cycles and a completely random one costs 5;
- Suzy has no bus access unless Mikey cedes it;
- Mikey will then interrupt Suzy as required for video fetch, with a maximum latency from initiating a request to getting access of 40 cycles; and
- a compromise was required "between bigger FIFOs in the Mikey video DMA and reduced performance in Suzy".
From which I can conclude, or guess anyway:
- Mikey grabs data in bursts, implicitly filling itself with a quantity of memory much larger than that which can be fetched in 40 cycles;
- it is unlikely that Mikey interleaves video and processor accesses even when it has full access to the bus, as otherwise there'd be almost no point in spending time on a page mode optimisation for CPU access — it'd rarely be helpful;
- therefore memory bandwidth is probably something like an optimum of 3 cycles for a page mode read, 4 cycles for a random one, as it's hard to imagine the processor core eliminated the 6502's think-then-act rhythm;
- ... which, if true, would also imply that the CPU sees stoppages just like Suzy does, albeit without a 10-cycle request/grant delay.
That being said, there is a mention of "the other pertinent states of the system" in deciding whether to permit something which otherwise definitely could be a paged mode processor access.
Has anybody ever done something simple like run a fixed counting loop against a timer to get a simple estimate of actual processor speed when Suzy isn't involved? Or anything as extreme as hooking up an oscilloscope and trying to map the whole pattern out?