Hi,
sorry — I've searched the various archives of the mailing list and
just confused myself. So...
In Mode 4, with the display switched on, is it accurate to say that:
1) the RAM gets a clock of 384 cycles/scanline
2) the display runs with a constant 312 scanlines/frame
3) for all but 192 of the scanlines, the CPU may access RAM on every
fourth cycle
4) on the 192 scanlines with pixels on them, the CPU may access RAM
every fourth cycle in the border, every eighth cycle during the display
5) pixels are generated for 256 cycles
6) so, on a scanline with pixels, you get 256 cycles in which you are
allowed 32 memory accesses, and 128 cycles in which you are allowed a
further 32 memory accesses
So, e.g. if the following programs are executed from RAM then:
ex de, hl
add hl, hl
add hl, hl
ex de, hl
(all 1 byte opcodes, native z80 timings of 4 cycles for ex de, hl; 11
cycles for add hl, hl)
Takes 48 cycles (on the 6 Mhz bus) if executed in its entirety while
pixels are being drawn, 32 cycles if executed in its entirety while
pixels are not being drawn. The functionally equivalent:
sla e
rl d
sla e
rl d
(all 2 byte opcodes, with a z80 native timing of 8 cycles each)
Takes 64 cycles if executed in its entirety while pixels are being
drawn, 32 cycles if executed in its entirety while pixels are not
being drawn?
Has anyone drawn up a neat table of all the opcodes with cycle counts
computed as weighted probabilities of their timings if executed
entirely in pixels and if executed entirely outside?
