SAM Instruction Timings

Introduction

This page describes memory and I/O contention on the SAM Coupé. Contention adds wait states to the execution of some CPU instructions, reducing the potential speed of running code. Knowledge of it is important for raster-level display effects, and general code optimisation.

Rules

Contention delays affect:

• Memory accesses to internal 512K RAM.
• I/O accesses to ASIC ports (F8-FF).

ALL other accesses are uncontended, meaning no waits for ROM or External RAM.

Delays

The size of the delay (if any) depends on the type of access and what the ASIC is doing at the time:

• In the border areas internal RAM accesses are limited to 1 cycle in every 4.
• Over the main screen internal RAM accesses are limited to 1 cycle in every 8.
• I/O accesses to ASIC ports are always limited to 1 cycle in every 8.
• If the display is disabled the entire screen is treated as border.
• In mode 1 alternating columns of 8 cells also have screen rules applied. See the mode 1 article for details.

Depending on where code/data is located and the I/O ports used the same Z80 instruction will take a different length of time to execute. The table below aims to show timings for the most common situations.

Alignment

Memory and I/O accesses occur at different positions within a machine cycle. Even though screen and I/O port accesses are both limted to 1 in 8 cycles, each will add a different number of wait states from the same starting position.

In cases where there is a single contended access during instruction execution, the overall timings will become aligned to the end of the contention region. Repeats of the same instruction will benefit from reduced contention, and in some cases no additional contention. This is most often seen with code running in external RAM (no opcode fetch contention) that accesses internal RAM or a contended I/O port. This is probably best seen with repeated blocks of LDI/OUTI instructions, which remain 16T even if writing to a contended destination.

The table won’t help with instructions that span regions with different contention rules, though the timing will be between the two values. The SimCoupe debugger is better used for this, and for general code/timing analysis.

Test Setup

The timings below were generated programmatically using the same CPU core and contention rules as SimCoupe v1.2.5.

To ensure a representative timing value, each instruction is run twice with the same starting environment (contention rules and RAM/register values). The first run is from a fixed point in the appropriate contention region, and the second run uses this ending cycle position as its start point. The time for the second run is taken as the instruction time.

The first run is purely for starting alignment, to avoid unwanted bias. It also ensures that the timing is representative for repeats of the same instruction, which is important for unrolled blocks of LDI/OUTI.

Timings

The columns headers below show pairs of Code/Data locations (Internal or External RAM), plus whether the raster is over Border or Screen. For ROM cases use the Ext column since they’re both uncontended.

When multiple values are given (e.g. 24/19), they represent the taken/not-taken timings for conditional instructions, or the loop/no-loop case for block repeat instructions such as LDIR.

Values in brackets represent the time for contended ASIC ports (F8-FF).

Undocumented instructions are shown in italics.

Hover over the timing values to see what contributes to the total time. WAIT MREQ and WAIT IORQ show memory and I/O contention delays, respectively.

LDD/LDI/LDDR/LDIR

With these copy instructions the source (HL) and destination (DE) locations may be in different contention regions. Rather than complicate the table above, the table below shows the timings for just these mismatched cases.