On Mon, 31 Jan 2005, Aley Keprt wrote:
> A SimCoupe source code comment says:
> // if we are in the main screen area, or one of the extra MODE
> 1 contended areas:
> // CPU can only access memory 1 out of every 8 T-States
> // else
> // CPU can only access memory 1 out of every 4 T-States
>
> Let's assume we are executing while in ray is in screen mode 4 ("paper"
> area).
>
> For example LD (HL),N is 2 bytes long and writes 1 byte to memory. So it has
> 3 memory accesses in total, what gives the total execution time of 24T when
> screen is drawn.
>
> Note that classic Z80 specs. says 10T for this instruction. So it's a quite
> big difference.
It is indeed. I find it helps to think about this by defining a new time
unit, which (for historical reasons) I call a z-state. A z-state is equal
to a t-state when the screen is off or the raster is in the border area,
but if the screen is on and the raster is in the screen area then one
z-state is equal to two 2 t-states. This gives you a constant measure of
the length of time taken by an instruction, even though the actual time
taken will vary.
Then, the time taken for any instruction (in z-states) is almost always(*)
the time given in the z80 specs (in t-states), rounded up to a multiple of
4.
So a LD (HL),nn is supposed to take 10 t-states; rounded up it takes 12
z-states (that's 24 t-states when the screen is on, 12 t-states when the
screen is off).
The numbers are different from the official figures because the z80 specs
assume a perfect memory system, wheras the Sam's ASIC makes some shortcuts
to keep the circuitry manageable:
* Accesses to internal RAM only occur at multiple of exactly 4 z-states
so all instruction times are rounded up to 4, because even if one
instruction finishes sooner, it takes until the next multiple before the
following instruction can be read.
This doesn't apply to ROM accesses, or accesses to external memory.
* When the screen is on, the ASIC interleaves framebuffer reads with z80
accesses
so the CPU cannot get memory accesses more often than once every 8
t-states. Instruction timings are rounded for the same reasons as above.
(This is for screen MODEs 2,3 and 4; in MODE 1 not even the borders are
always safe).
> Also, Edwin Blink wrote that for sprite drawing I should use the sequence of
> LD (HL),nn
> INC L
> which is 16 T per byte - but how can it be 16T in total when each memory
> access takes 8T?
I think he was only counting timings of when the screen was off. (Or in
z-states).
HTH,
Andrew
(*) The exceptions are instructions like INC HL where the cpu needs to do
extra processing without extra memory accesses. In those cases, the
instruction can take one fewer z-state in the screen area than in the
border area (or, to put it another way, it takes 8 t-states whether the
screen is on or off).
When you absolutely, positively have to execute every instruction in the
entire frame - these are the instructions that you should try to put into
the screen area and not the border.
--
--- Andrew Collier ----
---- http://www.intensity.org.uk/ ---
--
r<2+ T<4* cSEL dMS hEn/CB<BL A4 S+*<++ C$++L/mP W- a-- Vh+seT+ (Cantab) 1.1.4
