ZX Next Dev Guide
ZX Next Dev Guide
ZX Next Dev Guide
Tomaž Kragelj
ZX Spectrum Next Assembler Developer Guide
Tomaž Kragelj
15 September 2021
REVISIONS
2021-09-15
2021-07-16
i
Chapter 1
Introduction
1
CHAPTER 1. INTRODUCTION
2
CHAPTER 1. INTRODUCTION
3
CHAPTER 1. INTRODUCTION
Jan
http://www.myquest.nl/z80undocumented/
Email [email protected]
Twitter @janwilmans
Interested in emulation for a long time, but a few years after Sean started writing this document,
I have also started writing my own MSX emulator in 2003 and I’ve used this document quite
a lot. Now (2005) the Z80 emulation is nearing perfection, I decided to add what extra I have
learned and comments various people have sent to Sean, to this document.
I have restyled the document (although very little) to fit my personal needs and I have checked
a lot of things that were already in here.
Sean
http://www.msxnet.org/
Ever since I first started working on an MSX emulator, I’ve been very interested in getting
the emulation absolutely correct - including the undocumented features. Not just to make sure
that all games work, but also to make sure that if a program crashes, it crashes exactly the
same way if running on an emulator as on the real thing. Only then is perfection achieved.
I set about collecting information. I found pieces of information on the Internet, but not
everything there is to know. So I tried to fill in the gaps, the results of which I put on my
website. Various people have helped since then; this is the result of all those efforts and to my
knowledge, this document is the most complete.
4
CHAPTER 1. INTRODUCTION
1.5 ChangeLog
15 September 2021 Corrections and updates based on community comments - with special
thanks to Peter Ped Helcmanovsky. Restructured and updated many ZX Next chapters:
added sample code to ports, completely restructured memory map and paging, added
new palette chapter including 9-bit palette handling, updated ULA with shadow screen
info and added Next extended keyboard description. Other than that couple of cosmetic
changes: redesigned title, copyright pages etc. Also, many behind the scenes improvements
like splitting previous huge single LATEX file into multiple per-chapter/section. This is
not only more manageable but can also compile much faster.
16 July 2021 Added ZX Spectrum Next information and instructions and restructured text
for better maintainability and readability.
18 September 2005 Corrected a textual typo in the R register and memory refresh section,
thanks to David Aubespin. Corrected the contradiction in the DAA section saying the NF
flag was both affected and unchanged :) thanks to Dan Meir. Added an error in official
documentation about the way Interrupt Mode 2 works, thanks to Aaldert Dekker.
15 June 2005 Corrected improper notation of JP x,nn mnemonics in opcode list, thanks to
Laurens Holst. Corrected a mistake in the INI, INIR, IND, INDR section and documented
a mistake in official Z80 documentation concerning Interrupt Mode 2, thanks to Boris
Donko. Thanks to Aaldert Dekker for his ideas, for verifying many assumptions and for
writing instruction exercisers for various instruction groups.
18 May 2005 Added an alphabetical list of instructions for easy reference and corrected
an error in the 16-bit arithmetic section, SBC HL,nn sets the NF flag just like other
subtraction instructions, thanks to Fredrik Olssen for pointing that out.
4 April 2005 I (Jan [email protected]) will be maintaining this document from this version on. I
restyled the document to fix the page numbering issues, corrected an error in the I/O
Block Instructions section, added graphics for the RLD and RRD instructions and corrected
the spelling in several places.
20 November 2003 Again, thanks to Ramsoft, added PV flag to OUTI, INI and friends.
Minor fix to DAA tables, other minor fixes.
13 November 2003 Thanks to Ramsoft, add the correct tables for the DAA instruction (section
??). Minor corrections & typos, thanks to Jim Battle, David Sutherland and most of all
Fred Limouzin.
September 2001 Previous documents I had written were in plain text and Microsoft Word,
which I now find very embarrassing, so I decided to combine them all and use LATEX.
Apart from a full re-write, the only changed information is “Power on defaults” (section
??) and the algorithm for the CF and HF flags for OTIR and friends (section ??).
5
CHAPTER 1. INTRODUCTION
6
Chapter 2
Zilog Z80
7
OVERVIEW
2.1 Overview
In 1969 Intel was approached by a Japanese company called Busicom to produce chips for
Busicom’s electronic desktop calculator. Intel suggested that the calculator should be built
around a single-chip generalized computing engine and thus was born the first microprocessor
- the 4004. Although it was based on ideas from a much larger mainframe and mini-computers
the 4004 was cut down to fit onto a 16-pin chip, the largest that was available at the time, so
that its data bus and address bus were each only 4-bits wide.
Intel went on to improve the design and produced the 4040 (an improved 4-bit design) the 8008
(the first 8-bit microprocessor) and then in 1974 the 8080. This last one turned out to be a
very useful and popular design and was used in the first home computer, the Altair 8800, and
CP/M.
In 1975 Federico Faggin who had worked at Intel on the 4004 and its successors left the company
and joined forces with Masatoshi Shima to form Zilog. At their new company, Faggin and Shima
designed a microprocessor that was compatible with Intel’s 8080 (it ran all 78 instructions of
the 8080 in almost the same way that Intel’s chip did)1 but had many more abilities (an extra
120 instructions, many more registers, simplified connection to hardware). Thus was born the
mighty Z80, and thus was the empire forged!
The original Z80 was first released in July 1976, coincidentally Jan was born in the very same
month. Since then newer versions have appeared with much of the same architecture but
running at higher speeds. The original Z80 ran with a clock rate of 2.5MHz, the Z80A runs at
4MHz, the Z80B at 6MHz and the Z80H at 8Mhz.
Many companies produced machines based around Zilog’s improved chip during the 1970s and
80’s and because the chip could run 8080 code without needing any changes to the code the
perfect choice of the operating system was CP/M.
Also, Zilog has created a Z280, an enhanced version of the Zilog Z80 with a 16-bit architecture,
introduced in July 1987. It added an MMU to expand addressing to 16Mb, features for
multitasking, a 256-byte cache, and a huge number of new opcodes (giving a total of over
2000!). Its internal clock runs at 2 or 4 times the external clock (e.g. a 16MHz CPU with a
4MHz bus.
The Z380 CPU incorporates advanced architectural while maintaining Z80/Z180 object code
compatibility. The Z380 CPU is an enhanced version of the Z80 CPU. The Z80 instruction
set has been retained, adding a full complement of 16-bit arithmetic and logical operations,
multiply and divide, a complete set of register-to-register loads and exchanges, plus 32-bit load
and exchange, and 32-bit arithmetic operations for address calculations.
The addressing modes of the Z80 have been enhanced with Stack pointer relative loads and
stores, 16-bit and 24-bit indexed offsets and more flexible indirect register addressing. All of
the addressing modes allow access to the entire 32-bit addressing space.
1
Thanks to Jim Battle ([email protected]): the 8080 always puts the parity in the PF flag; VF does
not exist and the timing is different. Possibly there are other differences.
8
CHAPTER 2. ZILOG Z80
2.1.2 Registers
2.1.3 Flags
The conventional way of denoting the flags is with one letter, “C” for the carry flag for example.
It could be confused with the C register, so I’ve chosen to use the “CF” notation for flags (except
“P” which uses “PV” notation due to having dual-purpose, either as parity or overflow). And
for YF and XF the same notation is used in MAME2 .
bit 7 6 5 4 3 2 1 0
flag SF ZF YF HF XF PF NF CF
SF Set if the 2-complement value is negative; simply a copy of the most significant bit.
HF The half-carry of an addition/subtraction (from bit 3 to 4). Needed for BCD correction
with DAA.
PV This flag can either be the parity of the result (PF), or the 2-complement signed overflow
(VF): set if 2-complement value doesn’t fit in the register.
NF Shows whether the last operation was an addition (0) or a subtraction (1). This information
is needed for DAA.3
CF The carry flag, set if there was a carry after the most significant bit.
2
http://www.mame.net/
3
Wouldn’t it be better to have separate instructions for DAA after addition and subtraction, like the 80x86
has instead of sacrificing a bit in the flag register?
9
OVERVIEW
This section might be relevant even if you don’t do anything with hardware; it might give you
insight into how the Z80 operates. Besides, it took me hours to draw this.
A11 1 40 A10
A12 2 39 A9
A13 3 38 A8
A14 4 37 A7
A15 5 36 A6
CLK 6 35 A5
D4 7 34 A4
D3 8 33 A3
D5 9 32 A2
D6 10 31 A1
5V Z80 CPU A0
11 30
D2 12 29 GND
D7 13 28 RFSH
D0 14 27 M1
D1 15 26 RESET
INT 16 25 BUSREQ
NMI 17 24 WAIT
HALT 18 23 BUSACK
MREQ 19 22 WR
IORQ 20 21 RD
A15 A0 Address bus (output, active high, 3-state). This bus is used for accessing the memory
and for I/O ports. During the refresh cycle the IR register is put on this bus.
BUSACK Bus Acknowledge (output, active low). Bus Acknowledge indicates to the requesting
device that the CPU address bus, data bus, and control signals MREQ, IORQ, RD and WR have
been entered into their high-impedance states. The external device now control these lines.
BUSREQ Bus Request (input, active low). Bus Request has a higher priority than NMI and is
always recognised at the end of the current machine cycle. BUSREQ forces the CPU address
bus, data bus and control signals MREQ, IORQ, RD and WR to go to a high-impedance state
so that other devices can control these lines. BUSREQ is normally wired-OR and requires
an external pullup for these applications. Extended BUSREQ periods due to extensive DMA
operations can prevent the CPU from refreshing dynamic RAMs.
D7 D0 Data Bus (input/output, active low, 3-state). Used for data exchanges with memory,
I/O and interrupts.
HALT Halt State (output, active low). Indicates that the CPU has executed a HALT instruction
and is waiting for either a maskable or nonmaskable interrupt (with the mask enabled) before
operation can resume. While halted, the CPU stops increasing the PC so the instruction is
re-executed, to maintain memory refresh.
INT Interrupt Request (input, active low). Interrupt Request is generated by I/O devices. The
CPU honours a request at the end of the current instruction if IFF1 is set. INT is normally
wired-OR and requires an external pullup for these applications.
IORQ Input/Output Request (output, active low, 3-state). Indicates that the address bus holds
a valid I/O address for an I/O read or write operation. IORQ is also generated concurrently
10
CHAPTER 2. ZILOG Z80
with M1 during an interrupt acknowledge cycle to indicate that an interrupt response vector
can be placed on the databus.
M1 Machine Cycle One (output, active low). M1, together with MREQ, indicates that the current
machine cycle is the opcode fetch cycle of an instruction execution. M1, together with IORQ,
indicates an interrupt acknowledge cycle.
MREQ Memory Request (output, active low, 3-state). Indicates that the address holds a valid
address for a memory read or write cycle operations.
NMI Non-Maskable Interrupt (input, negative edge-triggered). NMI has a higher priority than
INT. NMI is always recognised at the end of an instruction, independent of the status of the
interrupt flip-flops and automatically forces the CPU to restart at location $0066.
RD Read (output, active low, 3-state). Indicates that the CPU wants to read data from memory
or an I/O device. The addressed I/O device or memory should use this signal to place data
onto the data bus.
RESET Reset (input, active low). Initializes the CPU as follows: it resets the interrupt flip-flops,
clears the PC and IR registers, and set the interrupt mode to 0. During reset time, the
address bus and data bus go to a high-impedance state, and all control output signals go to
the inactive state. Note that RESET must be active for a minimum of three full clock cycles
before the reset operation is complete. Note that Matt found that SP and AF are set to
$FFFF.
RFSH Refresh (output, active low). RFSH, together with MREQ, indicates that the IR registers
are on the address bus (note that only the lower 7 bits are useful) and can be used for the
refresh of dynamic memories.
WAIT Wait (input, active low). Indicates to the CPU that the addressed memory or I/O device
are not ready for data transfer. The CPU continues to enter a wait state as long as this
signal is active. Note that during this period memory is not refreshed.
WR Write (output, active low, 3-state). Indicates that the CPU wants to write data to memory
or an I/O device. The addressed I/O device or memory should use this signal to store the
data on the data bus.
Matt4 has done some excellent research on this. He found that AF and SP are always set to
$FFFF after a reset, and all other registers are undefined (different depending on how long the
CPU has been powered off, different for different Z80 chips). Of course, the PC should be set to
0 after a reset, and so should the IFF1 and IFF2 flags (otherwise strange things could happen).
Also since the Z80 is 8080 compatible, the interrupt mode is probably 0.
Probably the best way to simulate this in an emulator is to set PC, IFF1, IFF2, IM to 0 and set
all other registers to $FFFF.
4
[email protected]
11
UNDOCUMENTED OPCODES
An opcode with a CB prefix is a rotate, shift or bit test/set/reset instruction. A few instructions
are missing from the official list, for example SLL (Shift Logical Left). It works like SLA, for
one exception: it sets bit 0 (SLA resets it).
CB30 SLL B
CB31 SLL C
CB32 SLL D
CB33 SLL E
CB34 SLL H
CB35 SLL L
CB36 SLL (HL)
CB37 SLL A
In general, the instruction following the DD prefix is executed as is, but if the HL register is
supposed to be used the IX register is used instead. Here are the rules:
Any usage of HL is treated as an access to IX (except EX DE,HL and EXX and the ED
prefixed instructions that use HL).
Any access to (HL) is changed to (IX+d), where “d” is a signed displacement byte placed
after the main opcode - except JP (HL), which isn’t indirect anyway. The mnemonic
should be JP HL.
Any access to H is treated as an access to IXh (the high byte of IX) except if (IX+d) is
used as well.
Any access to L is treated as an access to IXl (the low byte of IX) except if (IX+d) is
used as well.
A DD prefix before a CB selects a completely different instruction set, see section ??.
12
CHAPTER 2. ZILOG Z80
Some examples:
This prefix has the same effect as the DD prefix, though IY is used instead of IX. Note LD IXL,
IYH is not possible: only IX or IY is accessed in one instruction, never both.
There are a number of undocumented EDxx instructions, of which most are duplicates of
documented instructions. Any instruction not listed here has no effect (same as 2 NOPs). **
indicates undocumented instruction:
ED40 IN B, (C) ED50 IN D, (C)
ED41 OUT (C), B ED51 OUT (C), D
ED42 SBC HL, BC ED52 SBC HL, DE
ED43 LD (nn), BC ED53 LD (nn), DE
ED44 NEG ED54 NEG**
ED45 RETN ED55 RETN**
ED46 IM 0 ED56 IM 1
ED47 LD I, A ED57 LD A, I
ED48 IN C, (C) ED58 IN E, (C)
ED49 OUT (C), C ED59 OUT (C), E
ED4A ADC HL, BC ED5A ADC HL, DE
ED4B LD BC, (nn) ED5B LD DE, (nn)
ED4C NEG** ED5C NEG**
ED4D RETI ED5D RETN**
ED4E IM 0** ED5E IM 2
ED4F LD R, A ED5F LD A, R
13
UNDOCUMENTED OPCODES
All the RETI/RETN instructions are the same, all like the RETN instruction. So they all, including
RETI, copy IFF2 to IFF1. See section ?? for more information on RETI and RETN and IM x.
The undocumented DDCB instructions store the result (if any) of the operation in one of the
seven all-purpose registers. Which one depends on the lower 3 bits of the last byte of the opcode
(not operand, so not the offset).
000 B 100 H
001 C 101 L
010 D 110 (none: documented opcode)
011 E 111 A
5
[email protected]
14
CHAPTER 2. ZILOG Z80
The documented DDCB0106 is RLC (IX+$01). So, clear the lower three bits (DDCB0100) and
something is done to register B. The result of the RLC (which is stored in (IX+$01)) is now also
stored in register B. Effectively, it does the following:
LD B, (IX+$01)
RLC B
LD (IX+$01), B
So you get double value for money. The result is stored in B and (IX+$01). The most common
notation is: RLC (IX+$01), B
I’ve once seen this notation:
RLC (IX+$01)
LD B, (IX+$01)
That’s not correct: B contains the rotated value, even if (IX+$01) points to ROM. The DDCB
SET and RES instructions do the same thing as the shift/rotate instructions:
So for example with the last instruction, the value of (IX+$10) with bit 0 set is also stored in
register A.
The DDCB BIT instructions do not store any value; they merely test a bit. That’s why the
undocumented DDCB BIT instructions are no different from the official ones:
15
UNDOCUMENTED EFFECTS
This part may be of some interest to emulator coders. Here we define what happens if strange
sequences of prefixes appear in the instruction cycle of the Z80.
If CB or ED is encountered, that byte plus the next make up an instruction. FD or DD should be
seen as prefix setting a flag which says “use IX or IY instead of HL”, and not an instruction.
In a large sequence of DD and FD bytes, it is the last one that counts. Also any other byte (or
instruction) resets this flag.
FD DD 00 21 00 10 NOP NOP NOP LD HL, $1000
BIT n,r behaves much like AND r,2n with the result thrown away, and CF flag unaffected.
Compare BIT 7,A with AND $80: flag YF and XF are reset, SF is set if bit 7 was actually set;
ZF is set if the result was 0 (bit was reset), and PV is effectively set if ZF is set (the result of
the AND leaves either no bits set (PV set - parity even) or one bit set (PV reset - parity odd).
So the rules for the flags are:
CF flag Unchanged.
This is where things start to get strange. With the BIT n,(IX+d) instructions, the flags behave
just like the BIT n,r instruction, except for YF and XF. These are not copied from the result
but from something completely different, namely bit 5 and 3 of the high byte of IX+d (so IX
plus the displacement).
16
CHAPTER 2. ZILOG Z80
Things get more bizarre with the BIT n,(HL) instruction. Again, except for YF and XF, the
flags are the same. YF and XF are copied from some sort of internal register. This register
is related to 16-bit additions. Most instructions do not change this register. Unfortunately, I
haven’t tested all instructions yet, but here is the list so far:
ADD HL, xx Use high byte of HL, ie. H before the addition.
LD r, (IX+d) Use high byte of the resulting address IX+d.
JR d Use high byte target address of the jump.
LD r, r’ Doesn’t change this register.
Any help here would be most appreciated!
The LDI/LDIR/LDD/LDDR instructions affect the flags in a strange way. At every iteration, a
byte is copied. Take that byte and add the value of register A to it. Call that value n. Now,
the flags are:
And now for CPI/CPIR/CPD/CPDR. These instructions compare a series of bytes in memory to
register A. Effectively, it can be said they perform CP (HL) at every iteration. The result of that
comparison sets the HF flag, which is important for the next step. Take the value of register
A, subtract the value of the memory address, and finally subtract the value of HF flag, which
is set or reset by the hypothetical CP (HL). So, n=A-(HL)-HF.
CF flag Unchanged.
17
UNDOCUMENTED EFFECTS
These are the most bizarre instructions, as far as the flags are concerned. Ramsoft found all of
the flags. The “out” instructions behave differently than the “in” instructions, which doesn’t
make the CPU very symmetrical.
First of all, all instructions affect the following flags:
NF flag A copy of bit 7 of the value read from or written to an I/O port.
And now the for OUTI/OTIR/OUTD/OTDR instructions. Take the state of the L after the increment
or decrement of HL; add the value written to the I/O port; call that k for now. If k ¡ 255,
then the CF and HF flags are set. The PV flag is set like the parity of k bitwise and’ed with
7, bitwise xor’ed with B.
INI/INIR/IND/INDR use the C register instead of the L register. There is a catch though,
because not the value of C is used, but C + 1 if it’s INI/INIR or C - 1 if it’s IND/INDR. So,
first of all INI/INIR:
Officially the Z80 has an 8-bit I/O port address space. When using the I/O ports, the 16
address lines are used. And in fact, the high 8 bits do have some value, so you can use 65536
ports after all. IN r, (C), OUT (C), r, and the block I/O instructions actually place the
entire BC register on the address bus. Similarly IN A, (n) and OUT (n), A put A 256 + n
on the address bus.
The INI, INIR, IND and INDR instructions use BC before decrementing B, and the OUTI, OTIR,
OUTD and OTDR instructions use BC after decrementing.
18
CHAPTER 2. ZILOG Z80
The repeated block instructions simply decrement the PC by two so the instruction is simply
re-executed. So interrupts can occur during block instructions. So, LDIR is simply LDI + if BC
is not 0, decrement PC by 2.
The 16-bit additions are a bit more complicated than the 8-bit ones. Since the Z80 is an 8-bit
CPU, 16-bit additions are done in two stages: first, the lower bytes are added, then the two
higher bytes. The SF, YF, HF, XF flags are affected by the second (high) 8-bit addition. ZF
is set if the whole 16-bit result is 0.
This instruction is useful when you’re using BCD values. After addition or subtraction, DAA
corrects the value back to BCD again. Note that it uses the CF flag, so it cannot be used after
INC and DEC.
Stefano Donati from Ramsoft6 has found the tables which describe the DAA operation. The
input is the A register and the CF, NF, HF flags. The result is as follows:
Depending on the NF flag, the “diff”
from this table must be added (NF is
reset) or subtracted (NF is set) to A: CF flag is affected: NF flag is affected:
SF, YF, XF are copies of bit 7, 5, 3 of the result respectively; ZF is set according to the result
and NF is always unchanged.
6
http://www.ramsoft.bbk.org/
19
INTERRUPTS
2.4 Interrupts
There are two types of interrupts, maskable and non-maskable. The maskable type is ignored if
IFF1 is reset. Non-maskable interrupts (NMI) will are always accepted, and they have a higher
priority, so if both are requested at the same time, the NMI will be accepted first.
For the interrupts, the following things are important: interrupt Mode (set with the IM 0, IM
1, IM 2 instructions), the interrupt flip-flops (IFF1 and IFF2), and the I register. When a
maskable interrupt is accepted, the external device can put a value on the data bus.
Both types of interrupts increase the R register by one when accepted.
When an NMI is accepted, IFF1 is reset. At the end of the routine, IFF1 must be restored (so
the running program is not affected). That’s why IFF2 is there; to keep a copy of IFF1.
An NMI is accepted when the NMI pin on the Z80 is made low (edge-triggered). The Z80
responds to the change of the line from +5 to 0 - so the interrupt line doesn’t have a state,
it’s just a pulse. When this happens, a call is done to address $0066 and IFF1 is reset so the
routine isn’t bothered by maskable interrupts. The routine should end with an RETN (RETurn
from Nmi) which is just a usual RET but also copies IFF2 to IFF1, so the IFFs are the same as
before the interrupt.
You can check whether interrupts were disabled or not during an NMI by using the LD A,I or
LD A,R instruction. These instructions copy IFF2 to the PV flag.
Accepting an NMI costs 11 t-states.
If the INT line is low and IFF1 is set, a maskable interrupt is accepted - whether or not the
last interrupt routine has finished. That’s why you should not enable interrupts during such a
routine, and make sure that the device that generated it has put the INT line up again before
ending the routine. So unlike NMI interrupts, the interrupt line has a state; it’s not a pulse.
When an interrupt is accepted, both IFF1 and IFF2 are cleared, preventing another interrupt
from occurring which would end up as an infinite loop (and overflowing the stack). What
happens next depends on the Interrupt Mode.
A device can place a value on the data bus when the interrupt is accepted. Some computer
systems do not utilize this feature, and this value ends up being $FF.
Interrupt Mode 0 This is the 8080 compatibility mode. The instruction on the bus is
executed (usually an RST instruction, but it can be anything). I register is not used.
Assuming it’s a RST instruction, accepting this takes 13 t-states.
Interrupt Mode 1 This is the 8080 compatibility mode. The instruction on the bus is
20
CHAPTER 2. ZILOG Z80
executed (usually an RST instruction, but it can be anything). I register is not used.
Assuming it’s a RST instruction, accepting this takes 13 t-states.
Interrupt Mode 2 A call is made to the address read from memory. What address is read
from is calculated as follows: pI registerq 256 pvalue on busq. Zilog’s user manual
states (very convincingly) that the least significant bit of the address is always 0, so they
calculate the address that is read from as: pI registerq 256 pvalue on bus ^ $FEq. I
have tested this and it’s not correct. Of course, a word (two bytes) is read, making the
address where the call is made to. In this way, you can have a vector table for interrupts.
Accepting this interrupt type costs 19 t-states.
At the end of a maskable interrupt, the interrupts should be enabled again. You can assume
that was the state of the IFFs because otherwise the interrupt wasn’t accepted. So, an interrupt
routine always ends with an EI and a RET (RETI according to the official documentation, more
about that later):
1 InterruptRoutine:
2 ...
3 EI
4 RETI or RET
Note a fact about EI: a maskable interrupt isn’t accepted directly after it, so the next opportunity
for an interrupt is after the RETI. This is very useful; if the INT line is still low, an interrupt is
accepted again. If this happens a lot and the interrupt is generated before the RETI, the stack
could overflow (since the routine would be called again and again). But this property of EI
prevents this.
DI is not necessary at the start of the interrupt routine: the interrupt flip-flops are cleared
when accepting the interrupt.
You can use RET instead of RETI, depending on the hardware setup. RETI is only useful if you
have something like a Z80 PIO to support daisy-chaining: queuing interrupts. The PIO can
detect that the routine has ended by the opcode of RETI, and let another device generate an
interrupt. That is why I called all the undocumented EDxx RET instructions RETN: All of them
operate alike, the only difference of RETI is its specific opcode which the Z80 PIO recognises.
21
INTERRUPTS
If you’re working with a Z80 system without NMIs (like the MSX), you can forget all about
the two separate IFFs; since an NMI isn’t ever generated, the two will always be the same.
Some documentation says that when an NMI is accepted, IFF1 is first copied into IFF2 before
IFF1 is cleared. If this is true, the state of IFF2 is lost after a nested NMI, which is undesirable.
Have tested this in the following way: make sure the Z80 is in EI mode, generate an NMI. In
the NMI routine, wait for another NMI before executing RETN. In the second NMI IFF2 was
still set, so IFF1 is not copied to IFF2 when accepting an NMI.
Another interesting fact: I was trying to figure out whether the undocumented ED RET instructions
were RETN or RETI. I tested this by putting the machine in EI mode, wait for an NMI and end
with one of the ED RET instructions. Then execute a HALT instruction. If IFF1 was not restored,
the machine would hang but this did not happen with any of the instructions, including the
documented RETI!
Since every interrupt routine must end with EI followed by RETI officially, It does not matter
that RETI copies IFF2 into IFF1; both are set anyway.
The HALT instruction halts the Z80; it does not increase the PC so that the instruction is
re-executed until a maskable or non-maskable interrupt is accepted. Only then does the Z80
increase the PC again and continues with the next instruction. During the HALT state, the
HALT line is set. The PC is increased before the interrupt routine is called.
During the execution of instructions, interrupts won’t be accepted. Only between instructions.
This is also true for prefixed instructions.
Directly after an EI or DI instruction, interrupts aren’t accepted. They’re accepted again after
the instruction after the EI (RET in the following example). So for example, look at this MSX2
routine that reads a scanline from the keyboard:
1 LD C, A
2 DI
3 IN A, ($0AA)
4 AND $0F0
5 ADD A, C
6 OUT ($0AA), A
7 EI
8 IN A, ($0A9)
9 RET
You can assume that there never is an interrupt after the EI, before the IN A,($0A9) - which
would be a problem because the MSX interrupt routine reads the keyboard too.
22
CHAPTER 2. ZILOG Z80
Using this feature of EI, it is possible to check whether it is true that interrupts are never
accepted during instructions:
1 DI
2 make sure interrupt is active
3 EI
4 insert instruction to test
5 InterruptRoutine:
6 store PC where interrupt was accepted
7 RET
And yes, for all instructions, including the prefixed ones, interrupts are never accepted during
an instruction. Only after the tested instruction. Remember that block instructions simply
re-execute themselves (by decreasing the PC with 2) so an interrupt is accepted after each
iteration.
Another predictable test: at the “insert instruction to test” insert a large sequence of EI
instructions. Of course, during the execution of the EI instructions, no interrupts are accepted.
But now for the interesting stuff. ED or CB make up instructions, so interrupts are accepted
after them. But DD and FD are prefixes, which only slightly affects the next opcode. If you test
a large sequence of DDs or FDs, the same happens as with the EI instruction: no interrupts are
accepted during the execution of these sequences.
This makes sense if you think of DD and FD as a prefix that sets the “use IX instead of HL” or
“use IY instead of HL” flag. If an interrupt was accepted after DD or FD, this flag information
would be lost, and:
DD 21 00 00 LD IX, 0
could be interpreted as a simple LD HL,0 if the interrupt was after the last DD. Which never
happens, so the implementation is correct. Although I haven’t tested this, as I imagine the
same holds for NMI interrupts.
Also see section ?? for details on handling interrupts on ZX Spectrum Next.
23
TIMING AND R REGISTER
During every first machine cycle (beginning of instruction or part of it - prefixes have their own
M1 two), the memory refresh cycle is issued. The whole IR register is put on the address bus,
and the RFSH pin is lowered. It’s unclear whether the Z80 increases the R register before or
after putting IR on the bus.
The R register is increased at every first machine cycle (M1). Bit 7 of the register is never
changed by this; only the lower 7 bits are included in the addition. So bit 7 stays the same,
but it can be changed using the LD R,A instruction.
Instructions without a prefix increase R by one. Instructions with an ED, CB, DD, FD prefix,
increase R by two, and so do the DDCBxxxx and FDCBxxxx instructions (weird enough). Just
a stray DD or FD increases the R by one. LD A,R and LD R,A access the R register after it is
increased by the instruction itself.
Remember that block instructions simply decrement the PC with two, so the instructions are
re-executed. So LDIR increases R by BC 2 (note that in the case of BC = 0, R is increased by
$10000 2, effectively 0).
Accepting a maskable or non-maskable interrupt increases the R by one.
After a hardware reset, or after power on, the R register is reset to 0.
That should cover all there is to say about the R register. It is often used in programs for a
random value, which is good but of course not truly random.
24
CHAPTER 2. ZILOG Z80
The flag affection summary table shows that LDI/LDIR/LDD/LDDR instructions leave the
SF and ZF in an undefined state. This is not correct; the SF and ZF flags are unaffected.
Similarly, the same table shows that CPI/CPIR/CPD/CPDR leave the SF and HF flags in an
undefined state. Not true, they are affected as defined elsewhere in the documentation.
Also, the table says about INI/OUTD/etc “Z=0 if B ¡ 0 otherwise Z=0”; of course the
latter should be Z=1.
When an NMI is accepted, the IFF1 isn’t copied to IFF2. Only IFF1 is reset.
In the 8-bit Load Group, the last two bits of the second byte of the LD r,(IX + d)
opcode should be 10 and not 01.
In the 16-bit Arithmetic Group, bit 6 of the second byte of the ADD IX,pp opcode should
be 0, not 1.
IN x,(C) resets the HF flag, it never sets it. Some documentation states it is set
according to the result of the operation; this is impossible since no arithmetic is done
in this instruction.
Note: In zilog’s own z80cpu um.pdf document, there are a lot of errors, some are very confusing,
so I’ll mention the ones I have found here:
Page 21, figure 2 says “the Alternative Register Set contains 2 B’ registers”; this should
of course be B’ and C’.
Page 26, figure 16 shows very convincingly that “the least significant bit of the address
to read for Interrupt Mode 2 is always 0”. I have tested this and it is not correct, it can
also be 1, in my test case the bus contained $FF and the address that was read did not
end in $FE but was $FF.
25
Chapter 3
ZX Spectrum Next
With modern I/O ports, increased CPU speeds, more memory, better graphics, hardware sprites
and tiles, to mention just the most obvious, ZX Spectrum Next is an exciting platform for the
retro programmer.
27
PORTS
3.1 Ports
28
CHAPTER 3. ZX SPECTRUM NEXT
29
PORTS
Specific features of the Next are controlled via these register numbers, accessed via TBBlue
Register Select $243B1 and TBBlue Register Access $253B2 , or via the NEXTREG instruction.
RW Port Description
R- $0 Identifies TBBlue board type. Should always be 10 on Next
R- $1 Identifies core (FPGA image) version
RW $2 Identifies type of last reset. Can be written to force reset
RW $3 Identifies timing and machine type
-W $4 In config mode, allows RAM to be mapped to ROM area
RW $5 Sets joystick mode, video frequency and Scandoubler
RW $6 Enables CPU Speed key, DivMMC, Multiface, Mouse and AY audio
RW $7 Sets CPU Speed, reads actual speed
RW $8 ABC/ACB Stereo, Internal Speaker, SpecDrum, Timex Video Modes, Turbo
Sound Next, RAM contention and (un)lock 128k paging (see ??)
RW $9 Sets scanlines, AY mono output, sprite-id lockstep, resets DivMMC mapram and
disables HDMI audio (see ??)
RW $0A Mouse buttons and DPI config
R- $0E Identifies core (FPGA image) version (sub minor number)
RW $10 Used within the Anti-brick system
RW $11 Sets video output timing variant
RW $12 Sets the bank number where Layer 2 video memory begins (see ??)
RW $13 Sets the bank number where the Layer 2 shadow screen begins
RW $14 Sets the transparent colour for Layer 2, ULA and LoRes pixel data
RW $15 Enables/disables sprites and Lores Layer, and chooses priority of sprites and Layer
2 (see ??)
RW $16 Sets X pixel offset used for drawing Layer 2 graphics on the screen (see ??)
RW $17 Sets Y offset used when drawing Layer 2 graphics on the screen (see ??)
RW $18 Sets and reads clip-window for Layer 2 (see ??)
RW $19 Sets and reads clip-window for Sprites (see ??)
RW $1A Sets and reads clip-window for ULA/LoRes layer
RW $1B Sets and reads clip-window for Tilemap (see ??)
RW $1C Controls (resets) the clip-window registers indices (see ??)
R- $1E Holds the MSB of the raster line currently being drawn
R- $1F Holds the eight LSBs of the raster line currently being drawn
1
https://wiki.specnext.dev/TBBlue Register Select
2
https://wiki.specnext.dev/TBBlue Register Access
30
CHAPTER 3. ZX SPECTRUM NEXT
RW Port Description
RW $22 Controls the timing of raster interrupts and the ULA frame interrupt
RW $23 Holds the eight LSBs of the line on which a raster interrupt should occur
RW $26 Pixel X offset (0-255) to use when drawing ULA Layer
RW $27 Pixel Y offset (0-191) to use when drawing ULA Layer
RW $28 PS/2 Keymap address MSB, read (pending) first byte of palette colour
-W $29 PS/2 Keymap address LSB
-W $2A High data to PS/2 Keymap (MSB of data in bit 0)
-W $2B Low eight LSBs of PS/2 Keymap data
RW $2C DAC B mirror, read current I2S left MSB
RW $2D SpecDrum port 0xDF / DAC A+D mirror, read current I2S LSB
RW $2E DAC C mirror, read current I2S right MSB
RW $2F Sets the pixel offset (two high bits) used for drawing Tilemap graphics on the
screen (see ??)
RW $30 Sets the pixel offset (eight low bits) used for drawing Tilemap graphics on the
screen (see ??)
RW $31 Sets the pixel offset used for drawing Tilemap graphics on the screen (see ??)
RW $32 Pixel X offset (0-255) to use when drawing LoRes Layer
RW $33 Pixel Y offset (0-191) to use when drawing LoRes Layer
RW $34 Selects sprite index 0-127 to be affected by writes to other Sprite ports (and
mirrors) (see ??)
-W $35 Writes directly into byte 1 of Sprite Attribute Upload $xx57 (see ??)
-W $36 Writes directly into byte 2 of Sprite Attribute Upload $xx57 (see ??)
-W $37 Writes directly into byte 3 of Sprite Attribute Upload $xx57 (see ??)
-W $38 Writes directly into byte 4 of Sprite Attribute Upload $xx57 (see ??)
-W $39 Writes directly into byte 5 of Sprite Attribute Upload $xx57 (see ??)
RW $40 Chooses a palette element (index) to manipulate with (see ??)
RW $41 Use to set/read 8-bit colours of the ULANext palette (see ??)
RW $42 Specifies mask to extract ink colour from attribute cell value in ULANext mode
RW $43 Enables or disables Enhanced ULA interpretation of attribute values and toggles
active palette (see ??)
RW $44 Sets 9-bit (2-byte) colours of the Enhanced ULA palette, or to read second byte
of colour (see ??)
31
PORTS
RW Port Description
RW $4A 8-bit colour to be used when all layers contain transparent pixel (see ??)
RW $4B Index of transparent colour in sprite palette (see ??)
RW $4C Index of transparent colour in Tilemap palette (see ??)
RW $50 Selects the 8k-bank stored in 8k-slot 0 (see ??)
RW $51 Selects the 8k-bank stored in 8k-slot 1 (see ??)
RW $52 Selects the 8k-bank stored in 8k-slot 2 (see ??)
RW $53 Selects the 8k-bank stored in 8k-slot 3 (see ??)
RW $54 Selects the 8k-bank stored in 8k-slot 4 (see ??)
RW $55 Selects the 8k-bank stored in 8k-slot 5 (see ??)
RW $56 Selects the 8k-bank stored in 8k-slot 6 (see ??)
RW $57 Selects the 8k-bank stored in 8k-slot 7 (see ??)
-W $60 Used to upload code to the Copper
RW $61 Holds low byte of Copper control bits
RW $62 Holds high byte of Copper control flags
-W $63 Used to upload code to the Copper
RW $64 Offset numbering of raster lines in copper/interrupt/active register
RW $68 Disable ULA, controls ULA mixing/blending, enable ULA+ (see ??)
RW $69 Layer2, ULA shadow, Timex $FF port
RW $6A LoRes Radastan mode
RW $6B Controls Tilemap mode (see ??)
RW $6C Default tile attribute for 8-bit only maps (see ??)
RW $6E Base address of the 40x32 or 80x32 tile map (see ??)
RW $6F Base address of the tiles’ graphics (see ??)
RW $70 Layer 2 resolution, palette offset (see ??)
RW $71 Sets pixel offset for drawing Layer 2 graphics on the screen (see ??)
-W $75 Same as Attribute 0 Register $35 plus increments $34 (see ??)
-W $76 Same as Attribute 1 Register $36 plus increments $34 (see ??)
-W $77 Same as Attribute 2 Register $37 plus increments $34 (see ??)
-W $78 Same as Attribute 3 Register $38 plus increments $34 (see ??)
-W $79 Same as Attribute 4 Register $39 plus increments $34 (see ??)
32
CHAPTER 3. ZX SPECTRUM NEXT
RW Port Description
RW $7F 8-bit storage for user
RW $80 Expansion bus enable/config
RW $81 Expansion bus controls
RW $82 Enabling internal ports decoding bits 0-7 register
RW $83 Enabling internal ports decoding bits 8-15 register
RW $84 Enabling internal ports decoding bits 16-23 register
RW $85 Enabling internal ports decoding bits 24-31 register
RW $86 When expansion bus is enabled: internal ports decoding mask bits 0-7
RW $87 When expansion bus is enabled: internal ports decoding mask bits 8-15
RW $88 When expansion bus is enabled: internal ports decoding mask bits 16-23
RW $89 When expansion bus is enabled: internal ports decoding mask bits 24-31
RW $8A Monitoring internal I/O or adding external keyboard
RW $8C Enable alternate ROM or lock 48k ROM
RW $8E Control classic Spectrum memory mapping
RW $90-93 Enables GPIO pins output
RW $98-9B GPIO pins mapped to Next Register
RW $A0 Enable Pi peripherals: UART, Pi hats, I2C, SPI
RW $A2 Pi I2S controls
RW $A3 Pi I2S clock divide in master mode
RW $A8 ESP WiFi GPIO output
RW $A9 ESP WiFi GPIO read/write
R- $B0 Read Next keyboard compound keys separately (see ??)
R- $B1 Read Next keyboard compound keys separately (see ??)
RW $B2 DivMMC trap configuration
RW $B4 DivMMC trap configuration
-W $FF Turns debug LEDs on and off on TBBlue implementations that have them
33
PORTS
When writing to one of the lower 256 ports, OUT (n),A instruction is used. For example to
write the value of 43 to peripheral device mapped to port $15:
1 LD A, 43 ; we want to write 43
2 OUT ($15), A ; writes value of A to port $15
To write using full 16-bit address, OUT (C),r instruction is used instead. Example of writing
a byte to serial port using UART TX $133B:
1 LD A, 42 ; we want to write 42
2 LD BC, $133B ; we want to write to port $133B
3 OUT (C), A
The difference between the two speed-wise is tangible: first example requires only 18 t-states
(7+11) while second 29 (7+10+12).
Reading also uses the same approach as on original Spectrums - for the lower 256 ports IN
A,(n) is used. For example reading a byte from port $15:
Note how the accumulator A is cleared before accessing the port. With IN A,(n), the 16-bit
address is composed from A forming high byte and n low byte.
Let’s see how we can use this for reading from 16-bit ports - we have two options: we can either
use IN A,(n) or IN r,(C). Example of both, reading a byte from serial port:
Both have the same result. The difference speed-wise is 22 t-states (10+12) vs 18 (7+11). Not
by a lot, but it may add up if used frequently. However, the intent of the first code is clearer
as the port address is provided in full instead of being split between two instructions.
This example nicely demonstrates a common dilemma when programming: frequently we can
have readable but not as optimal code, or vice versa. But I also thought this was worth pointing
out to avoid possible confusion in case you will encounter different ways in someone else’s code.
34
CHAPTER 3. ZX SPECTRUM NEXT
Writing values to Next/TBBlue registers occurs through TBBlue Register Select $243B and
TBBlue Register Access $253B ports. It’s composed from 2 steps: first we select the register
via write to port $243B, then write the value through port $253B. For example writing value
of 5 to port $16:
5 LD A, 5 ; write 5 5 LD A, 5 ; write 5
6 LD BC, $253B ; to port $254B 6 INC B ; to port $253B
7 OUT (C), A 7 OUT (C), A
Quite involving, isn’t it? Speed-wise, first example requires 58 t-states ((7+10+12)2) and
second 6 t-states less: 52 ((7+10+12)+(7+4+12)).
The second code relies on the fact that the only difference between two port addresses is the
high byte ($24 vs $25). So given we already assigned $243B to BC, we can simply increment
B to get $253B. Again, the intent of the first example is clearer. And again, I thought it was
worth pointing out in case you will encounter both approaches and wonder...
However, we can do better. Much better, in fact, using Next NEXTREG instruction, which allows
direct writes to given registers. So above examples could simply be changed to either:
The first example requires 24 t-states (7+17) while second 20. So less than half of that of
traditional approach. In fact, using NEXTREG is the preferred method of writing to Next registers!
Reading values from Next/TBBlue registers also occurs through $243B and $253B ports. Similar
to write, read is also composed from 2 steps: first select the register with port $243B, then read
the value from port $253B. For example reading a byte from port $B0:
35
MEMORY MAP AND PAGING
Due to its 16-bit address bus, Next can only address 216 = 65.536 bytes or 64K of memory at
a time. To get access to all available memory, it’s divided into smaller chunks called “banks”.
Next supports two interchangeable memory management models. One is inherited from the
original Spectrum 128K, +2, +3 series and Pentagon clones and uses 16K banks. The other
is unique to Next and uses 8K banks. Hence, addressable 64K is also divided into 16K or 8K
“slots” into which banks are swapped in and out3 .
Banks are selected by their number - first bank is 0, second 1 and so on. If you ever worked
with arrays, banks and their numbers work the same as array data and indexes. Both 16K and
8K banks start with number 0 at the same address. So if 16K bank n is selected, then the two
corresponding 8K bank numbers would be n 2 and n 2 1.
After startup, addressable 64K space is mapped like this:
Slots Banks
Address Description
16K 8K 16K 8K
$0000-$1FFF 0 0 ROM ROM ROM, R/W redirect by L2, IRQ, NMI
$2000-$3FFF 1 ROM ROM, R/W redirect by Layer 2
$4000-$5FFF 1 2 5 10 Normal/shadow ULA screen, Tilemap
$6000-$7FFF 3 11 ULA extended attribute/graphics, Tilemap
$8000-$9FFF 2 4 2 4 Free RAM
$A000-$BFFF 5 5 Free RAM
$C000-$DFFF 3 6 0 0 Free RAM
$E000-$FFFF 7 1 Free RAM
36
CHAPTER 3. ZX SPECTRUM NEXT
Banks
Description
16K 8K
2 4-5 Standard RAM. Initially mapped to $8000-$BFFF
3 6-7 Standard RAM, contended on 128, may be used by EsxDOS, RAM disk on
NextZXOS
4 8-9 Standard RAM, contended on +2/+3, RAM disk on NextZXOS
5 10-11 ULA Screen, contended except on Pentagon, cannot be used by NextBASIC
commands. Initially mapped to $4000-$7FFF
6 12-13 Standard RAM, contended on +2/+3, RAM disk on NextZXOS
7 14-15 ULA Shadow Screen, contended except on Pentagon, NextZXOS Workspace,
cannot be used by NextBASIC commands
8 16-17 Next RAM, Default Layer 2, NextZXOS screen and extra data, cannot be
used by NextBASIC commands
9-10 18-21 Next RAM, Rest of default Layer 2
11-13 22-27 Next RAM, Default Layer 2 Shadow Screen
As hinted before, not all available memory is addressable by programs. The first 256K is always
reserved for ROMs and firmware. Hence bank 0 starts at absolute address $40000:
16K bank 8K bank Size Absolute Address Description
- - 64K $000000-$00FFFF ZX Spectrum ROM
- - 16K $010000-$013FFF EsxDOS ROM
Unexpanded Next
16K bank 20 to slot 3 and writing 10 bytes to memory $C000 (start of 16K slot 3), we’re
effectively writing to absolute memory $90000-$90009 ($40000 + 20 16384)
8K bank 30 to slot 5 and writing 10 bytes to memory $A000 (start of 8K slot 5), we’re
effectively writing to absolute memory $7C000-$7C009 ($40000 + 30 8192)
37
MEMORY MAP AND PAGING
As mentioned, Next inherits the memory management models from the Spectrum 128K/+2/+3
models and Pentagon clones. It’s unlikely you will use these modes for Next programs, as Next
own model is much simpler to use. They are still briefly described here though in case you will
encounter them in older programs. All legacy models use 16K slots and banks.
128K Mode
Slot 0 1 2 3
Start $0000 $4000 $8000 $C000
End $3FFF $7FFF $BFFF $FFFF
Ò Ò
ROM 0-1 BANK 0-7 on 128K
BANK 0-127 on Next
Allows selecting:
16K ROM to be visible in the bottom 16K slot (0) from 2 possible banks
16K RAM to be visible in the top 16K slot (3) from 8 possible banks (128 banks on Next)
Registers involved:
Memory Paging Control $7FFD bit 4 selects ROM bank for slot 0
Memory Paging Control $7FFD bits 2-0 select one of 8 RAM banks for slot 3
Next Memory Bank Select $DFFD bits 3-0 are added as MSB to 2-0 from $7FFD to form
128 banks for slot 3 (Next specific)
If you are using the standard interrupt handler or OS routines, then any time you write to
Memory Paging Control $7FFD you should also store the value at $5B5C.
+3 Normal Mode
Slot 0 1 2 3
Start $0000 $4000 $8000 $C000
End $3FFF $7FFF $BFFF $FFFF
Ò Ò
ROM 0-3 BANK 0-7 on 128K
BANK 0-127 on Next
Allows selecting:
16K ROM to be visible in the bottom 16K slot (0) from 4 possible banks
16K RAM to be visible in the top 16K slot (3) from 8 possible banks (128 banks on Next)
Registers involved:
38
CHAPTER 3. ZX SPECTRUM NEXT
Plus 3 Memory Paging Control $1FFD bit 2 as LSB for selecting ROM bank for slot 0
Memory Paging Control $7FFD bit 4 forms MSB for selecting ROM bank for slot 0
Memory Paging Control $7FFD bits 2-0 select one of 8 RAM banks for slot 3
Next Memory Bank Select $DFFD bits 3-0 are added as MSB to 2-0 from $7FFD to form
128 banks for slot 3 (Next specific)
If you are using the standard interrupt handler or OS routines, then any time you write to Plus
3 Memory Paging Control $1FFD you should also store the same value at $5B67 and every
time your write to Memory Paging Control $7FFD you should also store the value at $5B5C.
+3 All-RAM Mode
Slot 0 1 2 3
Start $0000 $4000 $8000 $C000
End $3FFF $7FFF $BFFF $FFFF
Ò Ò Ò Ò
00 = BANK 0 BANK 1 BANK 2 BANK 3
01 = BANK 4 BANK 5 BANK 6 BANK 7
10 = BANK 4 BANK 5 BANK 6 BANK 3
Ó
11 = BANK 4 BANK 7 BANK 6 BANK 3
Lo bit = bit 1 from $1DDF
Hi bit = bit 2 from $1DDF
Also called “Special Mode” or “CP/M Mode”. Allows selecting all 4 slots from limited selection
of banks as shown in the table above.
Registers involved:
Plus 3 Memory Paging Control $1FFD bit 0 enables All-RAM (if 1) or normal mode (0)
Plus 3 Memory Paging Control $1FFD bits 2-1 select memory configuration
If you are using the standard interrupt handler or OS routines, then any time you write to Plus
3 Memory Paging Control $1FFD you should also store the same value at $5B67.
Next also supports paging implementation from Pentagon spectrums. It’s unlikely you will ever
use it on Next, so just mentioning for completness sake. You can find more information on
Next Dev Wiki4 or internet if interested.
4
https://wiki.specnext.dev/Next Memory Bank Select
39
MEMORY MAP AND PAGING
Next MMU based paging mode is much more flexible in that it allows mapping 8K banks into
any 8K slot of memory available to the CPU. It’s also the simplest to use - a single instruction
assigning bank number to desired MMU slot register.
In this mode, 64K memory accessible to the CPU is divided into 8 slots called MMU0 through
MMU7, as shown in the diagram below. Physical memory is thus divided into 96 (or 224 on
expanded Next) 8K banks. This is the only mode that allows paging in all memory from 2048K
extended Next.
16K Slot 0 1 2 3
8K Slot 0 1 2 3 4 5 6 7
Start $0000 $2000 $4000 $6000 $8000 $A000 $C000 $E000
End $1FFF $3FFF $5FFF $7FFF $9FFF $BFFF $DFFF $FFFF
Ò Ò Ò Ò Ò Ò Ò Ò
BANK BANK BANK BANK BANK BANK BANK BANK
0-255 0-255 0-255 0-255 0-255 0-255 0-255 0-255
Bank selection is set via Next registers:
While not absolutely required, it’s good practice to store original slot values and then restore
before exiting program or returning from subroutines.
Example of writing 10 bytes (00 01 02 03 04 05 06 07 08 09) to 8K bank 30 swapped in
to slot 5. As mentioned before, this will effectively write to absolute memory $7C000-$7C009:
40
CHAPTER 3. ZX SPECTRUM NEXT
Note: Memory Management Slot 0 bank $50 and Memory Management Slot 1 bank $51
have extra “functionality”: ROM can be automatically paged in if otherwise nonexistent 8K
page $FF is set. Low or high 8K ROM bank is automatically determined based on which 8K
slot is used. This may be useful if temporarily paging RAM into the bottom 16K region and
then wanting to restore back to ROM.
As mentioned, legacy and Next paging modes are interchangeable. Changing banks in one will
be reflected in the other. The most recent change always has priority. Again, keep in mind
that legacy modes use 16K banks, therefore single bank change will affect 2 8K banks.
ROM is usually mapped to the bottom 16K slot, addresses $0000-$3FFF. This area can only be
remapped using +3 All-RAM or Next MMU-based mode. Beware though that some programs
may expect to find ROM routines at fixed addresses between $0000 and $3FFF. And if default
interrupt mode (IM 1) is set, Z80 will jump PC to $0038 expecting to find interrupt handler
there.
ULA
ULA always reads content from 16K bank 5. This is mapped to 16K slot 1 by default, addresses
$4000-$7FFF. ULA will always use bank 5, regardless of which bank is mapped to slot 1, or
which slot bank 5 is mapped to (or if it is mapped into any slot at all).
You can redirect ULA to read from 16K bank 7 instead (the “shadow” screen), using bit 3 of
Memory Paging Control $7FFD. However, you still need to map bank 7 into one of the slots
if you want to read or write to it (that’s 8K banks 14 and 15 if using MMU for paging). Read
more in ULA chapter, section ??.
Layer 2 Paging
The bottom 16K slot can be set for write-only access for Layer 2. This can be handy as this
slot is typically mapped to ROM and thus useless to write to. There are also other Layer 2
related combinations available, read more in Layer 2 chapter, section ??
41
MEMORY MAP AND PAGING
Bit Effect
7-3 Unused, use 0
2 In normal mode high bit of ROM selection. With low bit from bit 4 of $7FFD:
00 ROM0 = 128K editor and menu system
01 ROM1 = 128K syntax checker
10 ROM2 = +3DOS
11 ROM3 = 48K BASIC
In special mode: high bit of memory configuration number
1 In special mode: low bit of memory configuration number
0 Paging mode: 0 = normal, 1 = special
Bit Effect
7-6 Extra two bits for 16K RAM bank if in Pentagon 512K/1024K mode (see Next
Memory Bank Select $DFFD)
5 1 locks pages; cannot be unlocked until next reset on regular ZX128)
4 128K: ROM select (0 = 128K editor, 1 = 48K BASIC)
+2/+3: low bit of ROM select (see +3 Memory Paging Control $1FFD above)
3 ULA layer shadow screen toggle (0 = bank 5, 1 = bank 7)
2-0 Bank number for slot 4 ($C000)
Bit Effect
7 1 to set Pentagon 512K/1024K mode
3-0 Most significant bits of the 16K RAM bank selected in Memory Paging Control $7FFD
Bit Effect
7-0 Selects 8K bank stored in corresponding 8K slot
42
CHAPTER 3. ZX SPECTRUM NEXT
Bit Effect
7 Access to bit 0 of Next Memory Bank Select $DFFD
6-4 Access to bits 2-0 of Memory Paging Control $7FFD
3 Read will always return 1
Write 1 to change RAM bank, 0 for no change to MMU6,7, $7FFD and $DFFD
2 0 for normal paging mode, 1 for special all-RAM mode
1 Access to bit 2 of +3 Memory Paging Control $1FFD
0 If bit 2 = 0 (normal mode): bit 4 of Memory Paging Control $7FFD
If bit 2 = 1 (special mode): bit 1 of +3 Memory Paging Control $1FFD
Acts as a shortcut for reading and writing +3 Memory Paging Control $1FFD, Memory
Paging Control $7FFD and Next Memory Bank Select $DFFD all at once. Mainly to simplify
classic Spectrum memory mapping. Though, as mentioned, Next specific programs should
prefer MMU based memory mapping.
43
PALETTE
3.3 Palette
Next greatly enhances ZX Spectrum video capabilities by offering several new ways to draw
graphics on a screen. We’ll see how to program each in later chapters, but let’s check common
behaviour first - colour management.
To draw a pixel on a screen, we need to set its colour as data in memory. There are different
approaches to how this data is defined. Next shares implementation to other 8-bit computers
of the era - all possible colours are stored together in a palette, as an array of RGB values,
and each pixel is simply an index into this array. This approach requires less memory and
allows creating efficient effects such as fade to/from black, transitions from day to night, water
animations etc.
Contrary to most computers of the era that only had predefined palettes, Next allows changing
all colours. Furthermore, each layer has not one but two palettes, each of which can be changed
independently. Of course, only one of two can be active at any given time for each mode. The
other can be initialized with alternate colours and can be quickly activated to achieve colour
animation effects. Active palette is set with Enhanced ULA Control Register $43 for ULA,
Layer 2 and Sprites and Tilemap Control Register $6B for Tilemap.
Data for each pixel for most layers and modes is 1 byte long, meaning each palette can have
up to 256 colours.
All palettes are initialized with default colours, so they are usable out of the box. But it’s also
possible to change individual colours. Regardless of the palette, the procedure to read or write
colours is:
1. Enhanced ULA Control Register $43 selects palette which colours you want to edit
2. Palette Index Register $40 selects colour index that will be read or written
3. Palette Value Register $41 or Enhanced ULA Palette Extension $44 reads or writes
data for selected colour
When writing colours, we can chose to automatically increment colour indexes after each write.
Bit 7 of Enhanced ULA Control Register $43 is used for that purpose. This works the same
for both write registers ($41 and $44). Colour RGB values can either be 8-bit RRRGGGBB, or
9-bit RRRGGGBBB values. Use Palette Value Register $41 for 8-bit and Enhanced ULA Palette
Extension $44 for 9-bit.
Note: Enhanced ULA Control Register $43 has two roles when working with palettes - it
selects the active palette for display (out of two available - only for ULA, Layer 2 and Sprites)
and selects palette for editing (for all layers, including Tilemap). Therefore care needs to be
taken when updating colour entries to avoid accidentally changing the active palette for display
44
CHAPTER 3. ZX SPECTRUM NEXT
at the same time. Depending on our program, we may first need to read the value and then only
change bits affecting the palette for editing to ensure the rest of the data remains unaffected.
8-bit colours are stored as RRRGGGBB values with 3 bits per red and green and 2 bits per blue
component. Each colour is therefore stored as a single byte. Palette Value Register $41 is
used to read or write the value.
Here’s a reusable subroutine for copying B number of colours stored as a contiguous block in
memory addressed by HL register, starting at the currently selected colour index:
1 Copy8BitPalette:
2 LD A, (HL) ; Load RRRGGGBB into A
3 INC HL ; Increment to next colour entry
4 NEXTREG $41, A ; Send colour data to Next HW
5 DJNZ Copy8BitPalette ; Repeat until B=0
With 9 bits per colour, each RGB component uses full 3 bits, thus greatly increasing the
available colour gamut. However, each colour needs 2 bytes in memory instead of 1. To read or
write we use Enhanced ULA Palette Extension $44 register instead of $41. It works similarly
to $41 except that each colour requires two writes: first one stores RRRGGGBB part and second
least significant bit of blue component. Subroutine for copying 9-bit colours:
1 Copy9BitPalette:
2 LD A, (HL) ; Load RRRGGGBB into A
3 INC HL ; Increment to next byte
4 NEXTREG $44, A ; Send colour data to Next HW
5 LD A, (HL) ; Load LSB of B into A
6 INC HL ; Increment to next colour entry
7 NEXTREG $44, A ; Send colour data to Next HW and increment index
8 DJNZ Copy9BitPalette ; Repeat until B=0
Note: subroutine requires that colours are stored in 2 bytes with first containing RRRGGGBB part
and second least significant bit of blue. Which is how typically drawing programs store a 9-bit
palette anyways. The calling subroutine is exactly the same as for the 8-bit colours above.
45
PALETTE
Bit Effect
7-0 Reads or writes palette colour index to be manipulated
Writing an index 0-255 associates it with colour set through Palette Value Register $41
or Enhanced ULA Palette Extension $44 of currently selected pallette in Enhanced ULA
Control Register $43. Write also resets value of Enhanced ULA Palette Extension $44 so
next write will occur for first colour of the palette.
While Tilemap, Layer 2 and Sprites palettes use all 256 distinct colours (with some caveats, as
described in specific chapters), ULA modes work like this:
Classic ULA
Index Colours
0-7 Ink
8-15 Bright ink
16-23 Paper
24-31 Bright paper
Border is taken from paper colours.
ULA+
Index Colours
0-64 Ink
Paper and border are taken from Transparency Colour Fallback Register $4A.
46
CHAPTER 3. ZX SPECTRUM NEXT
Bit Effect
7-0 Reads or writes 8-bit colour data
Format is:
7 6 5 4 3 2 1 0
R2 R1 R0 G2 G1 G0 B2 B1
Red Green Blue
Least significant bit of blue is set to OR between B2 and B1 .
Writing the value will automatically increment index in Palette Index Register $40, if auto-
increment is enabled in Enhanced ULA Control Register $43. Read doesn’t auto-increment
index.
Bit Effect
7-0 The number for last ink colour entry in the palette. Only used when ULANext mode
is enabled (see Enhanced ULA Control Register $43). Only the following values are
allowed, harware behavior is unpredictable for other values:
1 Ink and paper only use 1 colour each on indices 0 and 128 respectively
3 Ink and paper use 4 colours each, on indices 0-3 and 128-131
7 Ink and paper use 8 colours each, on indices 0-7 and 128-135
15 Ink and paper use 16 colours each, on indices 0-15 and 128-143
31 Ink and paper use 32 colours each, on indices 0-31 and 128-159
63 Ink and paper use 64 colours each, on indices 0-63 and 128-191
127 Ink and paper use 128 colours each, on indices 0-127 and 128-255
255 Enables full-ink colour mode where all indices are ink. In this mode paper and
border are taken from Transparency Colour Fallback Register $4A
Default value is 7 for core 3.0 and later, 15 for older cores.
47
PALETTE
Bit Effect
7 1 to disable palette index auto-increment, 0 to enable
6-4 Selects palette for read or write
000 ULA first palette
100 ULA second palette
001 Layer 2 first palette
101 Layer 2 second palette
010 Sprites first palette
110 Sprites second palette
011 Tilemap first palette
111 Tilemap second palette
3 Selects active Sprites palette (0 = first palette, 1 = second palette)
2 Selects active Layer 2 palette (0 = first palette, 1 = second palette)
1 Selects active ULA palette (0 = first palette, 1 = second palette)
0 Enables ULANext mode if 1 (0 after reset)
Write will also reset the index of Enhanced ULA Palette Extension $44 so next write there
will be considered as first byte of first colour.
Bit Effect
7-0 Reads or writes 9-bit colour definition
Two consequtive writes are needed:
Bit 7 of the second write must be 0 except for Layer 2 palettes where it specifies colour priority.
If set to 1, then the colour will always be on top, above all other layers, regardless of priority
set with Sprite and Layers System Register $15. So if you need exactly the same colour with
priority and non-priority, you will need to set the same data twice, to different indexes, once
with priority bit 1 and then with 0.
After second write palette colour index in Palette Index Register $40 is automatically increment,
if auto-increment is enabled in Enhanced ULA Control Register $43.
Note: reading will always return the second byte of the colour (least significant bit of blue) and
will not auto-increment index. You can read RRRGGGBB part with Palette Value Register $41.
48
CHAPTER 3. ZX SPECTRUM NEXT
Bit Effect
7-0 8-bit colour to be used when all layers contain transparent pixel. Format is RRRGGGBB
This colour is also used for paper and border when ULANext full-ink mode is enabled - see
Enhanced ULA Ink Colour Mask $42.
49
ULA LAYER
ROM RAM
16K 16K 16K 16K
Pixels Attributes (free)
$4000-$57FF $5800-$5AFF $5B00-$7FFF
Each screen pixel is represented by a single bit, meaning 1 byte holds 8 screen pixels. So,
for each line of 256 pixels, 32 bytes are needed. However, for sake of efficiency, the original
Spectrum optimized screen memory layout for speed but made it inconvenient for programming.
Pixel memory is not linear but is instead divided to fill character rows line by line. The
first 32 bytes of memory represent the first line of the first character row, followed by 32
bytes representing the first line of the second character row and so on until the first line of 8
character rows is filled. Then next 32 bytes of screen memory represent the second line of the
first character row, again followed by the second line of the second character row, until all 8
character rows are covered:
Addr. Ln. Ch. Addr. Ln. Ch. Addr. Ln. Ch.
$4000 0 0/0 $4100 1 0/1 $4200 2 0/2
$4020 8 1/0 $4120 9 1/1 $4220 10 1/2
$4040 16 2/0 $4140 17 2/1 $4240 18 2/2
$4060 24 3/0 $4160 25 3/1 $4260 26 3/2
...
$4080 32 4/0 $4180 32 4/1 $4280 33 4/2
$40A0 40 5/0 $41A0 41 5/1 $42A0 42 5/2
$40C0 48 6/0 $41C0 49 6/1 $42C0 50 6/2
$40E0 56 7/0 $41E0 57 7/1 $42E0 58 7/2
Ln. Screen line (0-191) Ch. Character <row>/<line> (0-23/0-7)
But this is not the end of the peculiarities of Spectrum ULA mode. If you attempt to fill the
screen memory byte by byte, you’ll realize the top third of the screen fills in first, then middle
third and lastly bottom third. The reason is, ULA mode divides the screen into 3 banks. Each
bank covers 8 character rows, so 8832 or 2048 bytes:
50
CHAPTER 3. ZX SPECTRUM NEXT
PIXELAD calculates the address of a pixel with coordinates from DE register pair where D
is Y and E is X coordinate and stores the memory location address into HL register pair
for ready consumption
PIXELDN takes the address of a pixel in HL and updates it to point to the same X coordinate
but one screen line down
SETAE takes X coordinate from E register and prepares mask in register A for reading or
writing to ULA screen
Furthermore; each instruction only uses 8 t-states, which is far less than the corresponding Z80
assembly program would require. Somewhat naive program for drawing vertical line write from
the pixel at coordinate (16,32) to (16,50):
8 INC D ; Y=Y+1
9 LD A, D ; copy new Y coordinate to A
10 CP 51 ; are we at 51 already?
11 RET NC ; yes, return
12
51
ULA LAYER
Note: because we’re updating our Y coordinate in D register within the loop, we could also use
PIXELAD instead of PIXELDN in line 13. Both instructions require 8 T states for execution, so
there’s no difference performance-wise.
If we instead wanted to check if the pixel at the given coordinate is set or not, we would use
AND (HL) instead of OR (HL). For example:
Now that we know how to draw individual pixels, it’s time to handle colour. Memory wise, it’s
stored immediately after pixel RAM, at memory locations $5800 - $5AFF. Each byte represents
colour and attributes for 88 pixel block on the screen. Byte contents are as follows:
7 6 5 4 3 2 1 0
F B P2 P1 P0 I2 I1 I0
F B Paper Ink
52
CHAPTER 3. ZX SPECTRUM NEXT
3.4.3 Border
Next inherits Spectrum border colour handling through ULA Control Port $xxFE. The bottom
3 bits are used to specify one of 8 possible colours (see table on the previous page for full list).
Example:
Note: border colour is set the same way regardless of graphics mode used. However, some Layer
2 modes and Tileset may partially or fully cover the border, effectively making it invisible to
the user.
As mentioned, ULA uses 16K bank 5 by default to determine what to show on the screen.
However, it’s possible to change this to bank 7 instead by using bit 3 of Memory Paging
Control $7FFD. Bank 7 mode is called the “shadow” screen. It gives us two separate memory
spaces for rendering ULA data and means for quickly swapping between them. It allows always
drawing into inactive bank and only swapping it in when ready thus help eliminating flicker.
Note: Memory Paging Control $7FFD only controls which of the two possible banks is being
used by ULA, but it doesn’t map the bank into any of the memory slots. This needs to be
done by one of the paging modes as described in the Memory Map and Paging chapter, section
??. Using MMU, we could do something like:
Remember: 16K bank 7 corresponds to 8K banks 14 and 15. And because pixel and attributes
combined fit within single 8K, only single bank needs to be swapped in.
53
ULA LAYER
ZX Spectrum Next also supports several enhanced ULA modes like Timex Sinclair Double
Buffering, Timex Sinclair Hi-Res and Hi-Colour, etc. However, with the presence of Layer 2
and Tilemap modes, it’s unlikely these will be used when programming new software on Next.
Therefore they are not described here. If interested, read more on:
https://wiki.specnext.dev/Video Modes
Bit Effect
7-5 Reserved, use 0
4 EAR output (connected to internal speaker)
3 MIC output (saving to tape via audio jack)
2-0 Border colour
Note: when reading this port with certain high byte values will read keyboard status. See
section ?? for details.
54
CHAPTER 3. ZX SPECTRUM NEXT
55
LAYER 2
3.5 Layer 2
As we saw in the previous section, drawing with ULA graphics is much simplified on Next. But
it can’t eliminate the colour clash. Well, not with ULA mode at least. However, Next brings
a couple of brand new graphic modes to the table, hidden behind a somewhat casual name
“Layer 2”. But don’t let its name deceive you; Layer 2 raises Next graphics capabilities to a
whole new level!
Layer 2 may appear behind or above the ULA layer. It supports different resolutions with every
pixel coloured independently and memory organized sequentially, line by line, pixel by pixel.
Consequently, Layer 2 requires more memory compared to ULA; each mode needs multiple 16K
banks. But of course, Next has far more memory than the original Speccy ever did!
Resolution Colours BPP Memory Organization
256192 256 8 48K, 3 horizontal banks of 64 lines
320256 256 8 80K, 5 vertical banks of 64 columns5
640256 16 4 80K, 5 vertical banks of 128 columns5
3.5.1 Initialization
Drawing on Layer 2 is much simpler than using ULA mode. But in contrast with ULA, which
is always “on”, Layer 2 needs to be explicitly enabled. This is done by setting bit 1 of Layer
2 Access Port $123B.
By default, Layer 2 will use 256192 with 256 colours, supported across all Next core versions.
You can select another resolution with Layer 2 Control Register $70. 320256 and 640256
modes also require setting up clip window correctly with Clip Window Layer 2 Register $18.
3.5.2 Paging
After Layer 2 is enabled, we can start writing into memory banks. As mentioned above, Layer
2 requires 3-5 contiguous 16K banks. While Next initializes default configuration during boot,
it’s nonetheless a good idea to set it up manually to ensure our code will work across all devices.
Layer 2 Ram Page Register $12 selects the bank number where Layer 2 video memory begins.
Note it’s a good idea to store the original bank values so we can restore them afterwards.
All supported modes can be used for paging, as described in section ??, by swapping in bank
numbers to 16K slot at $C000. However, the simplest and most versatile is MMU mode; MMU6
and MMU7 registers correspond to 2 8K slots starting at $C000.
5
Core 3.0.6+ only
56
CHAPTER 3. ZX SPECTRUM NEXT
3.5.3 Drawing
All Layer 2 modes use the same approach when drawing pixels. Each pixel uses one byte (except
640320 where each byte contains data for 2 pixels). The value is simply an index into the
palette entries list. Similar to other layers, Layer 2 also has two palettes, of which only one
can be active at any given time. Enhanced ULA Control Register $43 is used to select active
palette. See Palette chapter ?? for details on how to program palettes.
See specific modes in the following pages for examples of writing pixel data.
3.5.4 Effects
Sprite and Layers System Register $15 can be used to change Layer 2 priority, effectively
moving Layer 2 above or below other layers - see Tilemap chapter, section ?? for details.
We can even be more specific and only prioritize specific colours, so only pixels using those
colours will appear on top while other pixels below other layers. This way we can achieve a
simple depth effect. Per-pixel priority is available when writing a custom palette with Enhanced
ULA Palette Extension $44 (9-bit colours). See description under Palette chapter, section ??
for details on how to program palette.
We can also use both Layer 2 palettes to achieve simple effects. For example, certain colours
can be marked with the priority flag on one palette but not on the other. When swapping
palettes, pixels drawn with these colours would appear on top or below other layers. Another
simple effect using both palettes could be colour animation, though it can’t be very smooth
with only two states.
Global Transparency Register $14 can be used to alter the transparent colour of Layer 2.
This same register also affects ULA, LoRes and 1-bit (“text mode”) tilemap.
Scrolling effects can be achieved by writing pixel offsets to Layer 2 X Offset Register $16,
Layer 2 X Offset MSB Register $71 and Layer 2 Y Offset Register $17.
57
LAYER 2
This mode is the closest to ULA, resolution wise, so is perhaps the simplest to grasp. It’s
also supported across all Next core versions. Pixels are laid out from left to right and top to
bottom. Each pixel uses one byte that represents an 8-bit index into the palette. 3 16K banks
are needed to cover the whole screen, each holding data for 64 lines. Or, if using 8K, 6 banks,
32 lines each. Combined, colour data requires 48K of memory.
Each (x,y) coordinate pair requires 16-bits. If the upper byte is used for Y and lower for the X
coordinate, together they will form exact memory location offset from the top of the first bank.
But to account for bank swapping; for 16K banks, the most significant 2 bits of Y correspond
to bank number and for 8K banks, top 3 bits. The rest of Y + X is memory location within
the bank.
Example of filling the screen with a vertical rainbow:
1 START_16K_BANK EQU 9
2 START_8K_BANK EQU START_16K_BANK*2
3
4 ; Enable Layer 2
5 LD BC, $123B
6 LD A, 2
7 OUT (C), A
8
14 nextY:
15 ; Calculate bank number and swap it in
16 LD A, D ; Copy current Y to A
17 AND %11100000 ; 32100000 (3MSB = bank number)
18 RLCA ; 21000003
58
CHAPTER 3. ZX SPECTRUM NEXT
19 RLCA ; 10000032
20 RLCA ; 00000321
21 ADD A, START_8K_BANK ; A=bank number to swap in
22 NEXTREG $56, A ; Swap bank
23
Worth noting: MMU page 6 (next register $56) covers memory $C000 - $DFFF. As we swap
different 8K banks there, we’re effectively changing 8K banks that are readable and writable
at those memory addresses. That’s why we OR $C0 in line 24; we need to convert zero based
address to $C000 based. See section ?? for details on MMU paging mode.
We don’t have to handle bank swapping on every iteration; once per 32 rows would do for this
example. But the code is more versatile this way and could be easily converted into a reusable
pixel setting routine.
59
LAYER 2
I7 I6 I5 I4 I3 I2 I1 I0
Colour index
Banking Setup:
8K BANK 1
8K BANK 3
8K BANK 5
8K BANK 7
8K BANK 9
16 15 14 13 12-8 7-0
X8 X70 Y
16K X50 Y
255
8K X40 Y
16K bank contains 64 columns
8K bank contains 32 columns
320256 mode is only available on Next core 3.0.6 or later. Pixels are laid out from top to
bottom and left to right. Each pixel uses one byte that represents an 8-bit index into the
palette. To cover the whole screen, 5 16K banks of 64 columns or 10 8K banks of 32 columns
are needed. Together colour data requires 80K of memory.
In contrast with 256192, this mode allows drawing to the whole screen, including border. In
fact, you can think of it as the regular 256192 mode with additional 32 pixel border around
(32 + 256 + 32 = 320 and 32 + 192 + 32 = 256).
Addressing is more complicated though. As we need 9 bits for X and 8 for Y, we can’t address
all screen pixels with single 16-bit register pair. But we can use 16-bit register pair to address
all pixels within each bank. From this perspective, the setup is similar to 256192 mode,
except that X and Y are reversed: if the upper byte is used for X and lower for Y, then most
significant 2 bits of 16-bit register pair represent lower 2 bits of 16K bank number. And for 8K
banks, the most significant 3 bits correspond to the lower 3 bits of 8K bank number. In either
case, the most significant bit of the bank number arrives from the 9th bit of the X coordinate
(X8 in the table above). The rest of the X + Y is memory location within the bank.
To use this mode, we must explicitly select it with Layer 2 Control Register $70. We must
also not forget to set clip window correctly with Clip Window Layer 2 Register $18 and Clip/
Window Control Register $1C, as demonstrated in example below:
1 START_16K_BANK EQU 9
2 START_8K_BANK EQU START_16K_BANK*2
3
60
CHAPTER 3. ZX SPECTRUM NEXT
10
11 ; Enable Layer 2
12 LD BC, $123B
13 LD A, 2
14 OUT (C), A
15
61
LAYER 2
I3 I2 I1 I0 I3 I2 I1 I0
Colour 1 Colour 2
Banking Setup:
8K BANK 1
8K BANK 3
8K BANK 5
8K BANK 7
8K BANK 9
16 15 14 13 12-8 7-0
X8 2 X70 2 Y
16K X50 2 Y
255
8K X40 2 Y
16K bank contains 128 columns
8K bank contains 64 columns
640256 mode is very similar to 320256, except that each byte represents 2 colours instead
of 1. It’s also available on Next core 3.0.6 or later only. Pixels are laid out from top to bottom
and left to right. Each pixel takes 4 bits, so each byte contains data for 2 pixels. To cover the
whole screen, 5 16K banks of 128 columns or 10 8K banks of 64 columns are needed. Together
colour data requires 80K of memory. Similar to 320256, this mode also covers the whole
screen, including the border.
Addressing wise, this mode is the same as 230256. Using 16-bit register pair we can’t address
all pixels on the screen, but we can address all pixels within each bank. Again, assuming upper
byte of 16-bit register pair is used for X and lower for Y and using 9th bit of X coordinate (bit
X8 in the table above) as the most significant bit of bank number, then most significant 2 bits
of 16-bit register pair represent lower 2 bits of 16K bank number. And for 8K banks, the most
significant 3 bits correspond to the lower 3 bits of 8K bank number. The rest of the X + Y is
memory location within the bank. Don’t forget: each colour byte represents 2 screen pixels, so
the memory X coordinate (as described above) needs to be multiplied by 2 to convert to screen
X coordinate.
To use this mode, we must explicitly select it with Layer 2 Control Register $70. We must
also not forget to set clip window correctly with Clip Window Layer 2 Register $18 and Clip/
Window Control Register $1C, as demonstrated in example below:
1 START_16K_BANK EQU 9
2 START_8K_BANK EQU START_16K_BANK*2
3
62
CHAPTER 3. ZX SPECTRUM NEXT
11 ; Enable Layer 2
12 LD BC, $123B
13 LD A, 2
14 OUT (C), A
15
63
LAYER 2
Bit Effect
7-6 Video RAM bank select
00 First 16K of layer 2 in the bottom 16K
01 Second 16K of layer 2 in the bottom 16K
10 Third 16K of layer 2 in the bottom 16K
11 First 48K of layer 2 in the bottom 48K (core 3.0+)
5 Reserved, use 0
4 0 (see below)
3 Use Shadow Layer 2 for paging
0 Map Layer 2 RAM Page Register $12
1 Map Layer 2 RAM Shadow Page $13
Bit Effect
7 Reserved, must be 0
6-0 Starting 16K bank of Layer 2
Default 256192 mode requires 3 16K banks while new, 320256 and 640256 modes require
5 16K banks. Banks need to be contiguous in memory, so here we only specify the first one.
Valid bank numbers are therefore 0 - 45 (109 for 2MB RAM models) for standard mode and 0
- 43 (107 for 2MB RAM models) for new modes.
Note: this register uses 16K bank numbers. If you’re using 8K banks, you have to multiply this
value by 2. For example, 16K bank 9 corresponds to 8K banks 18 and 19.
64
CHAPTER 3. ZX SPECTRUM NEXT
Bit Effect
7-0 Writes or reads X pixel offset used for drawing Layer 2 graphics on the screen.
This can be used for creating scrolling effects. For 320256 and 640256 modes, 9 bits are
required; use Layer 2 X Offset MSB Register $71 to set it up.
Bit Effect
7-0 Writes or reads Y pixel offset used for drawing Layer 2 graphics on the screen.
Valid range is:
256192: 191
320256: 255
640256: 255
Bit Effect
7-0 Reads and writes clip-window coordinates for Layer 2
4 coordinates need to be set: X1, X2, Y1 and Y2. Which coordinate gets set, is determined
by index. As each write to this register will also increment index, the usual flow is to reset the
index to 0 in Clip Window Control Register $1C, then write all 4 coordinates in succession.
Positions are inclusive. Furthermore, X positions are doubled for 320256 mode, quadrupled
for 640256. Therefore, to view the whole of Layer 2, the values are:
256192 320256 640256
0 X1 position 0 0 0
1 X2 position 255 159 159
2 Y1 position 0 0 0
3 Y2 position 191 255 255
65
LAYER 2
Write:
Bit Effect
7-4 Reserved, must be 0
3 1 to reset Tilemap clip-window register index
2 1 to reset ULA/LoRes clip-window register index
1 1 to reset Sprite clip-window register index
0 1 to reset Layer 2 clip-window register index
Read:
Bit Effect
7-6 Current Tilemap clip-window register index
5-4 Current ULA/LoRes clip-window register index
3-2 Current Sprite clip-window register index
1-0 Current Layer 2 clip-window register index
Bit Effect
7-6 Reserved, must be 0
5-4 Layer 2 resolution (0 after soft reset)
00 256192, 8BPP
01 320256, 8BPP
10 640256, 4BPP
3-0 Palette offset (0 after soft reset)
Bit Effect
7-1 Reserved, must be 0
0 MSB for X pixel offset
This is only used for 320256 and 640256 modes. Together with Layer 2 X Offset Register
$16 full 319 pixels offsets are available. For 640256 only 2 pixel offsets are possible.
66
CHAPTER 3. ZX SPECTRUM NEXT
67
TILEMAP
3.6 Tilemap
Tilemap is fast and effective way of displaying 8x8 pixel blocks on the screen. There are two
possible resolutions available: 40x32 or 80x32 tiles. Tilemap layer overlaps ULA by 32 pixels
on each side. Or in other words, similar to 320x256 and 640x256 modes of Layer 2, tilemap
also covers the whole of the screen, including the border.
Tilemap is defined by 2 data structures: tile definitions and tilemap data itself.
Tiles are 8x8 pixels with each pixel representing an index of the colour from the currently
selected tilemap palette.
Each pixel occupies 4-bits, meaning tiles can use 16 colours. However, as we’ll see in the next
section, it’s possible to specify a 4-bit palette offset for each tile which allows us to reach all
256 colours from the palette.
A maximum of 256 tile definitions are possible, but this can be extended to 512 if needed using
Tilemap Control Register $6B.
All tiles definitions are specified in a contiguous memory block. The offset of tile definitions
memory address relative to the start of bank 5 needs to be specified with Tile Definitions Base
Address Register $6F.
Tilemap data specifies the tile definition index for each of the 40x32 or 80x32 tiles. Each tile
takes 2 bytes:
ULA Mode
Tile Index
X Mirror
Y Mirror
Rotate
Palette Offset 4-bit palette offset for this tile. This allows shifting colours to other 16-colour
“banks” thus allowing us to reach the whole 256 colours from the palette.
X Mirror If 1, this tile will be mirrored in X direction.
Y Mirror If 1, this tile will be mirrored in Y direction.
Rotate If 1, this tile will be rotated 90o clockwise.
ULA Mode If 1, this tile will be rendered on top, if 0 below ULA display. However in
512 tile mode, this is the 8th bit of tile index.
68
CHAPTER 3. ZX SPECTRUM NEXT
However, it’s possible to eliminate attributes byte by setting bit 5 in Tilemap Control Register
$6B. This only leaves an 8-bit tile index. Tileset then only occupies half the memory. But we
lose the option to specify attributes for each tile separately. Instead attributes for all tiles are
taken from Default Tilemap Attribute Register $6C.
The offset of the tilemap data memory address relative to the start of bank 5 needs to be
specified with Tilemap Base Address Register $6E.
The Tilemap layer is closely tied with ULA. Memory wise, it always exists in 16K slot 5.
By default, this page is loaded into 16K slot 1 $4000-$7FFF (examples here will assume this
configuration, if you load into a different slot, you will have to adjust addresses accordingly).
If both ULA and tilemap are used, memory should be arranged to avoid overlap. Given ULA
pixel and attributes memory occupied memory addresses $4000-$5AFF, this leaves $5B00-$7FFF
for tilemap. If we also take into account various system variables that reside on top of ULA
attributes, $6000 should be used for starting address. This leaves us:
40x32 80x32
Bytes per tile 1 2 1 2
Bytes per tileset 1280 2560 2560 5120
Max Tile Definitions 215 175 175 95
We as programmers need to tell hardware where in the memory tilemap and tile definitions are
stored. Tilemap Base Address Register $6E and Tile Definitions Base Address Register
$6F are used for that.
Both addresses are provided as most significant byte of the offset into memory slot 5 (which
starts at $4000). This means we can only store data at multiples of 256 bytes. For example, if
data is stored at $6000, the MSB offset value would be $20 ($6000 - $4000 = $2000).
Generic formula to calculate MSB of the offset is: (Address - $4000) >> 8.
Standard mode: uses bit 0 from tile’s attribute byte to determine if a tile is above or below
ULA. If tilemap uses 2 bytes per tile, we can specify the priority for each tile separately,
otherwise we specify it for all tiles. Transparent pixels are taken into account - if the top
layer is transparent, the bottom one is visible through.
Stencil mode: only used if both, ULA and tileset are enabled. The final pixel is transparent
if both, ULA and tilemap pixels are transparent. Otherwise final pixel is AND of both
colour bits. This mode allows one layer to act as a cut-out for the other.
69
TILEMAP
3.6.5 Examples
Using tilemaps is very simple. The most challenging part in my experience was finding a drawing
program that would export to required formats in full. The best results I have achieved were
with Remy’s Sprite, Tile and Palette editor website6 . Even then, I had to manually tweak
binary files to achieve desired results (single byte per tile).
Regardless of the editor, we need 3 pieces of data: palette, tile definitions and tileset itself. In
this example, they are included as binary files:
1 tilemap:
2 INCBIN "tiles.map"
3 tilemapLength: EQU $- tilemap
4
5 tiles:
6 INCBIN "tiles.spr"
7 tilesLength: EQU $ - tiles
8
9 palette:
10 INCBIN "tiles.pal"
11 paletteLength: EQU $-palette
Above code uses couple neat preprocessing tricks to automatically calculate MSB for tilemap
and tile definitions offsets. The rest is simply setting up desired behaviour using Next registers.
6
https://zx.remysharp.com/sprites/
70
CHAPTER 3. ZX SPECTRUM NEXT
The only remaining piece is to actually copy all the data to expected memory locations:
4 ; Copy palette
5 LD HL, palette ; Address of palette data in memory
6 LD B, 16 ; Copy 16 colours
7 CALL Copy8BitPalette ; Call routine for copying
8
We already know Copy8BitPalette routine from Layer 2 chapter, the other two are straightforward
LDIR loops:
1 CopyTileDefinitions:
2 LD DE, START_OF_TILES
3 LDIR
4 RET
5
6 CopyTileMap40x32:
7 LD BC, 40*32 ; This variant always loads 40x32
8 JR copyTileMap
9
10 CopyTileMap80x32:
11 LD BC, 80*32 ; This variant always loads 80x32
12
13 CopyTileMap:
14 LD DE, START_OF_TILEMAP
15 LDIR
16 RET
71
TILEMAP
Bit Effect
7 1 to enable lo-res layer, 0 disable it
6 1 to flip sprite rendering priority, i.e. sprite 0 is on top (0 after reset)
5 1 to change clipping to “over border” mode (doubling X-axis coordinates of clip window,
0 after reset)
4-2 Layers priority and mixing
000 S L U (Sprites are at top, Layer 2 under, Enhanced ULA at bottom)
001 L S U
010 S U L
011 L U S
100 U S L
101 U L S
110 Core 3.1.1+: (U|T)S(T|U)(B+L) blending layer and Layer 2 combined
Older cores: S(U+L) colours from ULA and L2 added per R/G/B channel
111 Core 3.1.1+: (U|T)S(T|U)(B+L-5) blending layer and Layer 2 combined
Older cores: S(U+L-5) similar as 110, but per R/G/B channel (U+L-5)
110 and 111 modes: colours are clamped to [0,7]
1 1 to enable sprites over border (0 after reset)
0 1 to enable sprite visibility (0 after reset)
Bit Effect
7-0 Reads and writes clip-window coordinates for Tilemap
4 coordinates need to be set: X1, X2, Y1 and Y2. Tilemap will only be visible within these
coordinates. X coordinates are internally doubled for 40x32 or quadrupled for 80x32 mode.
Positions are inclusive. Default values are 0, 159, 0, 255. Origin (0,0) is located 32 pixels to
the top-left of ULA top-left coordinate.
Which coordinate gets set, is determined by index. As each write to this register will also
increment index, the usual flow is to reset the index to 0 in Clip Window Control Register
$1C, then write all 4 coordinates in succession.
72
CHAPTER 3. ZX SPECTRUM NEXT
Bit Effect
7-2 Reserved, use 0
1-0 Most significant bit(s) of X offset
In 40x32 mode, meaningful range is 0-319, for 80x32 0-639. Low 8-bits are stored in Tilemap
Offset X LSB Register $30.
Bit Effect
7-0 X offset for drawing tilemap in pixels
Tilemap X offset in pixels. Meaningful range is 0-319 for 40x32 and 0-639 for 80x32 mode.
To write values larger than 255, Tilemap Offset X MSB Register $2F is used to store MSB.
Bit Effect
7-0 Y offset for drawing tilemap in pixels
Y offset is 0-255.
Bit Effect
7-5 Reserved, must be 0
4-0 Index of transparent colour into tilemap palette
The pixel index from tile definitions is compared before palette offset is applied to the upper 4
bits, so there’s always one index between 0 and 15 that works as transparent colour.
73
TILEMAP
Bit Effect
7 1 to disable ULA output (0 after soft reset)
6-5 (Core 3.1.1+) Blending in SLU modes 6 & 7
00 ULA as blend colour
01 No blending
10 ULA/tilemap as blend colour
11 Tilemap as blend colour
4 (Core 3.1.4+) Cancel entries in 8x5 matrix for extended keys
3 1 to enable ULA+ (0 after soft reset)
2 1 to enable ULA half pixel scroll (0 after soft reset)
1 Reserved, set to 0
0 1 to enable stencil mode when both the ULA and tilemap are enabled.
See Sprite and Layers System Register $15 for different priorities and mixing of ULA, Layer
2 and Sprites.
Bit Effect
7 1 to enable tilemap, 0 disable tilemap
6 1 for 80x32, 0 40x32 mode
5 1 to eliminate attribute byte in tilemap
4 1 for second, 0 for first tilemap palette
3 1 to activate “text mode”1
2 Reserved, set to 0
1 1 to activate 512, 0 for 256 tile mode
0 1 to force tilemap on top of ULA
1
In the text mode, tiles are defined as 1-bit B&W bitmaps, same as original Spectrum UDGs.
Each tile only requires 8 bytes. In this mode, the tilemap attribute byte is also interpreted
differently: bit 0 is still ULA over Tilemap (or 9th bit of tile data index) but the top 7 bits are
extended palette offset (the least significant bit is the value of the pixel itself). In this mode,
transparency is checked against Global Transparency Register $14 colour, not against the
four-bit tilemap colour index.
74
CHAPTER 3. ZX SPECTRUM NEXT
If single byte tilemap mode is selected (bit 5 of Tilemap Control Register $6B set), this register
defines attributes for all tiles.
Bit Effect
7-4 Palette offset
3 1 to mirror tiles in X direction
2 1 to mirror tiles in Y direction
1 1 rotate tiles 90o clockwise
0 In 512 tile mode, bit 8 of tile index
1 for ULA over tilemap, 0 for tilemap over ULA
Bit Effect
7-6 Ignored, set to 0
5-0 Most significant byte of tilemap data offset in bank 5
Bit Effect
7-6 Ignored, set to 0
5-0 Most significant byte of tile definitions offset in bank 5
75
SPRITES
3.7 Sprites
One of the frequently used “my computer is better” arguments from owners and developers of
contemporary systems such as Commodore 64 was hardware supported sprites. To be fair, they
had a point - poor old Speccy had none. But Next finally rectifies this with a sprite system
that far supersedes even later 16-bit era machines such as Amiga. And as we’ll see, it’s really
simple to program too!
Some of the capabilities of Next sprites:
3.7.1 Editing
Before describing how sprites hardware works, it would be beneficial to know how to draw them.
As mentioned, Next comes with a built-in sprite editor. To use it, change to desired folder,
then enter .spredit <filename> in BASIC or command line. The editor is quite capable and
can even be used with a mouse if you have one attached to your Next (or in the emulator).
Alternatively, if you’re developing cross-platform, you can download UDGeed-Next7 or use
Remy’s Sprite, Tile and Palette editor8 . They all share very similar feature sets, so try them
out and decide for yourself.
3.7.2 Patterns
Next sprites have a fixed size of 16x16 pixels. Their display surface is 320x256, overlapping the
ULA by 32 pixels on each side. Or in other words, to draw the sprite fully on-screen, we need
to position it to (32,32) coordinate. And the last coordinate where the sprite is fully visible at
the bottom-right edge is (271,207). This allows sprites to be animated in and out of the visible
area. Sprites can be made visible or invisible when over the border as well as rendered on top
or below Layer 2 and ULA, all specified by Sprite and Layers System Register $15. It’s also
possible to further restrict sprite visibility within provided clip window using Clip Window
Sprites Register $19.
7
http://zxbasic.uk/files/UDGeedNext-current.rar
8
https://zx.remysharp.com/sprites/
76
CHAPTER 3. ZX SPECTRUM NEXT
Sprite patterns (or pixel data) are stored in Next FPGA internal 16K memory. As mentioned,
sprites are always 16x16 pixels but can be 8-bit or 4-bit.
8-bit sprites use full 8-bits to specify colour, so each pixel can be of any of 256 colours
from the sprite palette of which one acts as transparent. Hence each sprite occupies 256
bytes of memory and 64 sprites can be stored.
4-bit sprites use only 4-bits for colour, so each pixel can only choose from 16 colours, one
of which is reserved for transparency. However this allows us to store 2 colours per byte,
so these sprites take half the memory of 8-bit ones: 128 bytes each, meaning 128 sprites
can be stored in available memory.
3.7.3 Palette
Each sprite can specify its own palette offset. This allows sprites to share image data but use
different colours. 4 bits are used for palette offset, therefore the final colour index within the
current sprite palette (as defined by Enhanced ULA Control Register $43) is determined
using the following formula:
Pn is palette offset bit, Sn sprite colour index bit and Cn final colour index.
Transparent colour is defined with Sprites Transparency Index Register $4B.
77
SPRITES
Anchor Sprites
These are “normal” 16x16 pixel sprites, as described in previous sections. They act as standalone
sprites.
The reason they are called “anchors” is because multiple sprites can be grouped together to
form larger sprites. In such case “anchor” acts as a parent and all its “relative” sprites are tied
to it. In order to combine sprites, anchor needs to be defined first, immediately followed by all
its relative sprites. The group ends with the next anchor sprite which can either be another
standalone sprite, or an anchor for another sprite group. For example, if sprite 5 is setup as
an anchor, its relative sprites must be followed at 6, 7, 8... until another sprite that’s setup as
“anchor”.
There are 2 types of relative sprites: composite and unified sprites.
Visibility Rotation
X X & Y mirroring
Y X & Y scaling
Palette offset
Pattern number
4 or 8-bit pattern
Relative sprites only have 8-bits for X and Y coordinates (ninth bits are used for other purposes).
But as the name suggests, these coordinates are relative to their parent anchor sprite so they
are usually positioned close by. When the anchor sprite is moved to a different position on the
screen, all its relatives are also moved by the same amount.
Visibility of relative sprites is determined as AND between anchor visibility and relative sprite
visibility. This way individual relative sprites can be made invisible independently from their
anchor, but if the anchor is invisible, then all its relative sprites will also be invisible.
Relative sprites inherit 4 or 8-bit setup from their anchor. They can’t use a different type but
can use a different palette offset than its anchor.
It’s also possible to tie relative sprite’s pattern number to act as an offset on top of its anchor’s
pattern number and thus easily animate the whole sprite group simply by changing the anchor’s
pattern number.
78
CHAPTER 3. ZX SPECTRUM NEXT
Unified relative sprites are an extension of the composite type. Everything described above
applies here as well.
The main difference is the hardware will automatically adjust relative sprites X, Y, rotation,
mirroring and scaling attributes according to changes in anchor. So relatives will rotate, mirror
and scale around the anchor as if it was a single larger sprite.
3.7.5 Attributes
Attributes are 4 or 5 bytes that define where and how the sprite is drawn. The data can be set
either by selecting sprite index with Sprite Status/Slot Select $303B and then continuously
sending bytes to Sprite Attribute Upload $xx57 (which automatically increments sprite index
after all data for single sprite is transferred) or by calling individual direct access Next registers
$35-$39 or their auto-increment variants $75-$79. See registers section for a description of
individual bytes:
3.7.6 Examples
Reading about sprites may seem complicated, but in practice, it’s quite simple. The following
pages include sample code for working with sprites. To preserve space, only partial code
demonstrating relevant parts is included. You can find full source code on GitHub https:
//github.com/tomaz/zx-next-dev-guide.
79
SPRITES
Before we can use sprites, we need to load their data into FPGA memory. This example
introduces a generic routine that uses DMA9 to copy from given memory to FPGA. Don’t
worry if it seems like magic - it’s implemented as a reusable routine, just copy it to your
project. Routine requires 3 parameters:
1 LoadSprites:
2 LD BC, $303B ; Prepare port for sprite index
3 OUT (C), A ; Load index of first sprite
4 LD (.dmaSource), HL ; Copy sprite sheet address from HL
5 LD (.dmaLength), BC ; Copy length in bytes from BC
6 LD HL, .dmaCode ; Setup source for OTIR
7 LD B, .dmaCodeLength ; Setup length for OTIR
8 LD C, $6B ; Setup DMA port
9 OTIR ; Invoke DMA code
10 RET
11 .dmaCode:
12 DB %10000011 ; Disable DMA
13 DB %01111101 ; WR0 transfer mode, A->B, write adress + block length
14 .dmaSource:
15 DW 0 ; WR0 port A, source address
16 .dmaLength:
17 DW 0 ; WR0 block length in bytes
18 DB %01010100 ; WR1 read A, increment, to memory, bitmaks
19 DB %00000010 ; WR1 cycle port A length
20 DB %01101000 ; WR2 write B, port B address fixed, B is IO
21 DB %00000010 ; WR2 cycle length B
22 DB %10101101 ; WR4 continuous mode, write destination address
23 DW $5B ; Sprite image port $xx5B
24 DB %10000010 ; WR5 restart on end of block
25 DB %11001111 ; WR6 load
26 DB %10000111 ; WR6 enable DMA
27 .dmaCodeLength: EQU $-.dmaCode
Perhaps worth noting: routine uses a technique called “self-modifying code”. As the name
suggests, this means that the program modifies itself in RAM. In this case it modifies 2 addresses
“marked” by .dmaSource and .dmaLength labels. But it’s also possible to modify opcodes (in
this case NOPs are frequently used as placeholders). Either way, careful planning is required to
avoid writing over undesired parts.
And secondly, note the use of a dot in front of some labels. Many assemblers allow this notation
for local labels, only “visible” to code between 2 normal labels (without dot prefix).
9
https://wiki.specnext.dev/DMA
80
CHAPTER 3. ZX SPECTRUM NEXT
Loading Sprites
Using loadSprites routine is very simple. This example assumes you’ve edited sprites with
one of the editors and saved them as sprites.spr file in the same folder as the assembler code:
6 sprites:
7 INCBIN "sprites.spr" ; Sprite sheets file
Enabling Sprites
After sprites are loaded into FPGA memory, we need to enable them:
Displaying a Sprite
Sprites are now loaded into FPGA memory, they are enabled, so we can start displaying them.
This example displays the same sprite pattern twice, as two separate sprites:
81
SPRITES
Even handling combined sprites is much simpler in practice than in theory! This example
combines 4 sprites into a single one using unified relative sprites. Note use of “inc” register $79
which auto-increments sprite index for next sprite:
Because we use combined sprite, we only need to update the anchor to change all its relatives.
And because we set it up as unified relative sprites, even rotation, mirroring and scaling is
inherited as if it was a single sprite!
82
CHAPTER 3. ZX SPECTRUM NEXT
Write: sets active sprite attribute and pattern slot index used by Sprite Attribute Upload
$xx57 and Sprite Pattern Upload $xx5B.
Bit Effect
7 Set to 1 to offset reads and writes by 128 bytes
6-0 0-63 for pattern slots and 0-127 for attribute slots
Read: returns sprite status information
Bit Effect
7-2 Reserved
1 1 if sprite renderer was not able to render all sprites; read will reset to 0
0 1 when collision between any 2 sprites occurred; read will reset to 0
Uploads the attributes for the currently selected sprite slot. Attributes require 4 or 5 bytes.
After all bytes are sent, the sprite index slot automatically increments. See the following Next
registers that directly set the value for specific bytes:
Uploads sprite pattern data. 256 bytes are needed for each sprite. For 8-bit sprites, each
pattern slot contains a single sprite. For 4-bit sprites, it contains 2 128 byte sprites. After 256
bytes are sent, the target pattern slot is auto-incremented.
Bit Effect
7-0 Next byte of pattern data for current sprite
83
SPRITES
Bit Effect
7 1 to enable AY2 “mono” output (A+B+C is sent to both R and L channels, makes it
a bit louder than stereo mode)
6 1 to enable AY1 “mono” output, 0 default
5 1 to enable AY0 “mono” output (0 after hard reset)
4 1 to lockstep Sprite port-mirror Index Register $34 and Sprite Status/Slot Select
$303B
3 1 to reset mapram bit in DivMMC
2 1 to silence HDMI audio (0 after hard reset) (since core 3.0.5)
1-0 Scanlines weight (0 after hard reset)
Core 3.1.1+ Older cores
00 Scanlines off Scalines off
01 Scanlines 50% Scanlines 75%
10 Scanlines 50% Scanlines 25%
11 Scanlines 25% Scanlines 12.5%
Bit Effect
7-0 Reads or writes clip-window coordinates for Sprites
4 coordinates need to be set: X1, X2, Y1 and Y2. Sprites will only be visible within these
coordinates. Positions are inclusive. Default values are 0, 255, 0, 191. Origin (0,0) is located
32 pixels to the top-left of ULA top-left coordinate.
Which coordinate gets set, is determined by index. As each write to this register will also
increment index, the usual flow is to reset the index to 0 with Clip Window Control Register
$1C, then write all 4 coordinates in succession.
When “over border” mode is enabled (bit 1 of Sprite and Layers System Register $15), X
coordinates are doubled internally.
If sprite id lockstep in Peripheral 4 Register $09 is enabled, write to this registers has same
effect as writing to Sprite Status/Slot Select $303B.
84
CHAPTER 3. ZX SPECTRUM NEXT
Bit Effect
7 Set to 1 to offset reads and writes by 128 bytes
6-0 0-63 for pattern slots and 0-127 for attribute slots
Bit Effect
7-0 Low 8 bits of X position
Bit Effect
7-0 Low 8 bits of Y position
Bit Effect
7-4 Palette offset
3 1 to enable X mirroring, 0 to disable
2 1 to enable Y mirroring, 0 to disable
1 1 to rotate sprite 90o clockwise, 0 to disable
0 Anchor sprite: most significant bit of X coordinate
Relative sprite: 1 to add anchor palette offset, 0 to use independent palette offset
Bit Effect
7 1 to make sprite visible, 0 to hide it
6 1 to enable optional byte 4, 0 to disable it
5-0 Pattern index 0-63 (7th, MSB for 4-bit sprites is configured with byte 4)
85
SPRITES
86
CHAPTER 3. ZX SPECTRUM NEXT
Bit Effect
7-0 Sets index of transparent colour inside sprites palette.
For 4-bit sprites, low 4 bits of this register are used.
This set of registers work the same as their non-inc counterpart in $35-$39; writes byte 0-4 of
Sprite attributes for currently selected sprite, except $7X variants also increment Sprite Port-
Mirror Index Register $34 after write. When batch updating multiple sprites, typically the
first sprite is selected explicitly, then $3X registers are used until the last write, which occurs
through $7X register. This way we’ll also increment the sprite index for the next iteration.
87
SOUND
3.8 Sound
Next inherits the same 3 AY-3-8912 chips setup as used in 128K Spectrums. This allows us to
reuse many of the pre-existing applications and routines to play sound effects and music.
AY chip has 3 sound channels, called A, B and C. Combined with 3 chips, this allows us to
produce 9 channel music. Programming wise, each of the 3 chips needs to be selected first
via Turbo Sound Next Control $FFFD register. Afterwards, we can set various parameters
through Peripheral 3 Register $08 and Peripheral 4 Register $09.
AY chip is controlled by 14 internal registers. To program them, we first need to select the
register with Turbo Sound Next Control $FFFD and then write the value with Sound Chip
Register Write $BFFD.
Several applications can produce sounds or music compatible with the AY chip. For sounds,
Shiru’s AYFX Player10 can be used. This program also includes a Z80 native player that can
directly load and play sound effects. Alternatively, Remy’s AY audio generator website11 can
produce exactly the same results and is fully compatible with AYFX Player.
A different way of playing sounds is to convert the WAV file into 1, 2 or 4-bit per sample sound
with the ChibiWave application. Sounds take a bit more memory this way but are much easier
to create. You can find the application, as well as tutorial and playback source code on Chibi
Akumas website12 . While there, definitely check other tutorials too - they’re all high quality
and available as both, written posts and YouTube videos.
For creating music there are also several options. NextDAW13 is native composer that runs on
ZX Spectrum Next itself. Or if you prefer cross-platform, Arkos Tracker14 or Vortex Tracker15
should do the job. All include “drivers”; Z80 code you can include in your program that can
load and play created music.
10
https://shiru.untergrund.net/software.shtml#old
11
https://zx.remysharp.com/audio/
12
https://www.chibiakumas.com/z80/platform4.php#LessonP35
13
https://nextdaw.biasillo.com/
14
https://www.julien-nevo.com/arkostracker/
15
https://bulba.untergrund.net/vortex e.htm
88
CHAPTER 3. ZX SPECTRUM NEXT
3.8.3 Examples
Before we can start playing sounds, we need to enable the sound hardware. While this is usually
enabled by default, it’s nonetheless a good idea to ensure our program will always run under
the same conditions.
Programming AY consists of writing various values to its registers. As mentioned, this is a two-
step process: first select register number, then write the value. Multiple writes are required
for each tone to set period, volume etc. To make it simpler, I created a subroutine. It takes 2
parameters: A for register number (0-13) and D with value to write.
1 WriteDToAYReg:
2 ; Select desired register
3 LD BC, $FFFD
4 OUT (C), A
5
11 RET
Companion code on GitHub includes expanded code as well as a simple player that plays
multiple tones in sequence. For the purposes of this book, I used Remy’s AY audio generator
website to load one of the example effects, then manually copied raw values into the source
code. Laborious process to say the least - this is not how effects should be handled in real life.
But I wanted to learn and demonstrate how to program AY chip, not how to use ready-made
drivers to play effects or music. Furthermore, my “player” blocks the main loop; ideally, sound
effects and music would play on the interrupt handler. This could be a nice homework for the
reader - example in section ?? should give you an idea of how to achieve this - happy coding!
89
SOUND
When bit 7 is 1:
Bit Effect
7 1
6 1 to enable left audio
5 1 to enable right audio
4-2 Must be 1
1-0 Selects active chip:
00 Unused
01 AY3
10 AY2
11 AY1
When bit 7 is 0:
Bit Effect
7 0
6-0 Selects given AY register number for read or write from active sound chip
Bit Effect
7-0 Writes given value to currently selected register:
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
A tone 0 0 0 0 A tone high
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
B tone 0 0 0 0 B tone high
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
C tone 0 0 0 0 C tone high
90
CHAPTER 3. ZX SPECTRUM NEXT
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
0 0 0 Noise Period 0 0 C B A C B A
0 0 Noise Tone
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
0 0 0 0 A Volume 0 0 0 0 B Volume
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Envelope bits 7-0 Envelope bits 15-8
13 - Envelope shape
7 6 5 4 3 2 1 0
0 0 0 0 C At Al H
H “Hold”
1 envelope generator performs 1 cycle then holds the end value
0 cycles continuously
Al “Alternate”
If “hold” set
1 the value held is initial value
0 the value held is the final value
If “hold” not set
1 envelope generator alters direction after each cycle
0 resets after each cycle
At “Attack”
1 the generator counts up
0 the generator counts down
C “Continue”
1 “hold” is followed
0 the envelope generator performs one cycle then drops volume to 0 and
stays there, overriding “hold”
91
SOUND
Bit Effect
7 1 to enable CPU speed mode key ”F8”, 0 to disable (1 after soft reset)
6 Core 3.1.2+: Divert BEEP-only to internal speaker (0 after hard reset)
Pre core 3.1.2: DMA mode, 0 zxnDMA, 1 Z80 DMA (0 after hard reset)
5 Core 2.0+: 1 to enable ”F3” key (50/60 Hz switch) (1 after soft reset)
Pre core 2.0: ”Enable Lightpen”
4 1 to enable DivMMC automap and DivMMC NMI by DRIVE button (0 after hard
reset)
3 1 to enable multiface NMI by M1 button (0 after hard reset)
2 1 to set primary device to mouse in PS/2 mode, 0 to set to keyboard
1-0 Audio chip mode:
00 YM
01 AY
10 Disabled
11 Core 3.0+: Hold all AY in reset
Bit Effect
7 1 unlock / 0 lock port $7FFD paging
6 1 to disable RAM and I/O port contention (0 after soft reset)
5 AY stereo mode (0 = ABC, 1 = ACB) (0 after hard reset)
4 Enable internal speaker (1 after hard reset)
3 Enable 8-bit DACs (A,B,C,D) (0 after hard reset)
2 Enable port $FF Timex video mode read (0 after hard reset)
1 Enable Turbosound (currently selected AY is frozen when disabled) (0 after hard reset)
0 Implement Issue 2 keyboard (port $FE reads as early ZX boards) (0 after hard reset)
92
CHAPTER 3. ZX SPECTRUM NEXT
93
KEYBOARD
3.9 Keyboard
Next inherits ZX Spectrum keyboard handling, so all legacy programs will work out of the box.
Additionally, it allows reading the status of extended keys.
ZX Spectrum uses 85 matrix for reading keyboard status. This means 40 distinct keys can be
represented. The keyboard is read from ULA Control Port $xxFE with particular high bytes.
There are 8 possible bytes, each will return the status of 5 associated keys. If a key is pressed,
the corresponding bit is set to 0 and vice versa.
Example for checking if P or I is pressed:
As mentioned in Ports chapter, section ??, we can slightly improve performance if we replace
first two lines with:
1 LD A, $DF
2 IN ($FE)
Reading the port in first example requires 22 t-states (10+12) vs. 18 (7+11). The difference is
small, but it can add up as typically keyboard is read multiple times per frame.
The first program is more understandable at a glance - the port address is given as a whole 16-
bit value, as usually provided in the documentation. The second program splits it into 2 8-bit
values, so intent may not be immediately apparent. Of course, one learns the patterns with
experience, but it nonetheless demonstrates the compromise between readability and speed.
Next uses larger 87 matrix for keyboard, with 10 additional keys. By default, hardware is
translating keys from extra two columns into the existing 85 set. But you can turn this off
with bit 4 of ULA Control Register $68. Extra keys can be read separately via Extended
Keys 0 Register $B0 and Extended Keys 1 Register $B1.
94
CHAPTER 3. ZX SPECTRUM NEXT
Bits are reversed: if a key is pressed, the corresponding bit is 0, if a key is not pressed, bit is 1.
Note: when written to, ULA Control Port $xxFE is used to set border colour and audio devices.
See description under ULA chapter, section ?? for details.
95
INTERRUPTS ON NEXT
Mode 2: similar to IM 1 in frequency and handling, but uses vector table to jump to
interrupt program instead of executing hard code ROM routine thus allowing the user to
set their own interrupt handler.
Paging out ROM (as described in section ??) and replace it with RAM page with custom
interrupt routine at address $0038
You can also adjust timing of the interrupts with Next/TBBlue Feature Control Registers $22
and $23.
96
CHAPTER 3. ZX SPECTRUM NEXT
1 DI
2
7 LD A, H
8 LD I, A ; I=high byte of vector table
9
16
Based on http://codersbucket.blogspot.com/2015/04/interrupts-on-zx-spectrum-what-are.html
97
Chapter 4
Instructions at a Glance
This chapter presents all instructions at a glance for quick info and to easily compare them
when choosing the most optimal combination for the task at hand. Instructions are grouped
into logical sections based on the area they operate on.
99
Instruction Execution
Flags
Effects
Notes
YF and XF flags are not represented in the tables; they’re irrelevant from the programmer point
of view. They usually contain a copy of bit 5 and 3 of the accumulator A, but special cases are
described.
I used 4 sources for comparing effects: Z80 undocumented1 , Programming the Z80 third
edition2 , Zilog Z80 manual3 and Next Dev Wiki4 . Where different and I couldn’t verify, I
opted for variant that matches most sources with slightly greater precedence for Next Dev
Wiki side.
1
http://www.myquest.nl/z80undocumented/
2
http://www.z80.info/zaks.html
3
https://www.zilog.com/docs/z80/um0080.pdf
4
https://wiki.specnext.dev/Extended Z80 instruction set
100
CHAPTER 4. INSTRUCTIONS AT A GLANCE
Ù Ù Ù Ù
A 111
ADD A,n A ÐA+n VF 0 11 000 110 C6 2B 2 7
n ..
ADD A,(HL) AÐA+(HL) Ù Ù Ù VF 0 Ù 10 000 110 86 1B 2 7
ADD A,(IX+d) AÐA+(IX+d) Ù Ù Ù VF 0 Ù 11 011 101 DD 3B 5 19
p
B
p
000
10 000 110 86 C 001
d .. D 010
E 011
ADD A,(IY+d) A ÐA+(IY+d) Ù Ù Ù VF 0 Ù 11 111 101 FD 3B 5 19 IXh 100
10 000 110 86 IXl 101
A 111
d ..
Ò
ADC A,s 2
AÐA+s+CF Ù Ù Ù VF 0 Ù .. 001 ...
SUB s 2
AÐA-s Ù Ù Ù VF 1 Ù .. 010 ...
q
B
q
000
SBC A,s2 AÐA-s-CF Ù Ù Ù VF 1 Ù .. 011 ... C
D
001
010
AND s 2
AÐA^s Ù Ù 1 PF 0 0 .. 100 ... E
IYh
011
100
XOR s 2
AÐAYs Ù Ù 0 PF 0 0 .. 101 ... IYl 101
Ù Ù
A 111
OR s 2
AÐA_s 0 PF 0 0 .. 110 ...
CP s1,2 A-s Ù Ù Ù VF 1 Ù .. 111 ...
101
CHAPTER 4. INSTRUCTIONS AT A GLANCE
102
CHAPTER 4. INSTRUCTIONS AT A GLANCE
Ð(HL)
A 111
LD r,(HL) r - - - - - - 01 r 110 .. 1B 2 7
LD r,(IX+d) rÐ(IX+d) - - - - - - 11 011 101 DD 3B 5 19 q q
q’ q’
01 r 110 ..
B 000
d .. C 001
LD r,(IY+d) r Ð(IY+d) - - - - - - 11 111 101 FD 3B 5 19 D
E
010
011
01 r 110 .. IYh 100
d .. IYl 101
Ðr
A 111
LD (HL),r (HL) - - - - - - 01 110 r .. 1B 2 7
LD (IX+d),r (IX+d)Ðr - - - - - - 11 011 101 DD 3B 5 19
01 110 r ..
d ..
LD (IY+d),r (IY+d) Ðr - - - - - - 11 111 101 FD 3B 5 19
01 110 r ..
d ..
LD (HL),n (HL) Ðn - - - - - - 00 110 110 36 2B 3 10
n ..
LD (IX+d),n (IX+d) Ðn - - - - - - 11 011 101 DD 4B 5 19
00 110 110 36
d ..
n ..
LD (IY+d),n (IY+d) Ðn - - - - - - 11 111 101 FD 4B 5 19
00 110 110 36
d ..
n ..
LD A,(BC) AÐ(BC) - - - - - - 00 001 010 0A 1B 2 7
LD A,(DE) AÐ(DE) - - - - - - 00 011 01 1A 1B 2 7
LD A,(nm) AÐ(nm) - - - - - - 00 111 010 3A 3B 4 13
m ..
n ..
(continued on next page)
103
CHAPTER 4. INSTRUCTIONS AT A GLANCE
IM 04 - - - - - - 11 101 101 ED 2B 2 8
01 000 110 46
IM 14 - - - - - - 11 101 101 ED 2B 2 8
01 010 110 56
IM 24 - - - - - - 11 101 101 ED 2B 2 8
01 011 110 5E
Notes: 1 YF and XF are copied from register A
2 Documentation says original value of CF is copied to HF, but my tests show that HF remains unchanged
3 No interrupts are accepted directly after EI or DI
4 This instruction has other undocumented opcodes
104
CHAPTER 4. INSTRUCTIONS AT A GLANCE
00 100 001 21
m ..
n ..
LD IY,nm IX Ðnm - - - - - - 11 111 101 FD 4B 4 14
00 100 001 21
m ..
n ..
LD HL,(nm) H Ð(nm+1) - - - - - - 00 101 010 2A 3B 5 16
L Ð(nm) m ..
n ..
LD rr,(nm) rrh Ð(nm+1) - - - - - - 11 101 101 ED 4B 6 20
rrl Ð(nm) 01 rr1 011 ..
m ..
n ..
LD IX,(nm) IXh Ð(nm+1) - - - - - - 11 011 101 DD 4B 6 20
IXl Ð(nm) 00 101 010 2A
m ..
n ..
LD IY,(nm) IYh Ð(nm+1) - - - - - - 11 111 101 FD 4B 6 20
IYl Ð(nn) 00 101 010 2A
n ..
n ..
LD (nm),HL (nn+1) H Ð - - - - - - 00 100 010 22 3B 5 16
(nm) LÐ m ..
n ..
LD (nm),rr (nm+1) Ðrrh - - - - - - 11 101 101 ED 4B 6 20
(nm) Ðrrl 01 rr0 011 ..
m ..
n ..
LD (nm),IX (nm+1) IXhÐ - - - - - - 11 011 101 DD 4B 6 20
Ð
(nm) IXl 00 100 010 22
m ..
n ..
LD (nm),IY (nm+1) IYhÐ - - - - - - 11 111 101 FD 4B 6 20
Ð
(nm) IYl 00 100 010 22
m ..
n ..
LD SP,HL SPÐHL - - - - - - 11 111 001 F9 1B 1 6
LD SP,IX SPÐIX - - - - - - 11 011 101 DD 2B 2 10
11 111 001 F9
LD SP,IY SP ÐIY - - - - - - 11 111 101 FD 2B 2 10
11 111 001 F9
105
CHAPTER 4. INSTRUCTIONS AT A GLANCE
4.6 Stack
Symbolic Flags Opcode
Mnemonic Operation SF ZF HF PV NF CF 76 543 210 Hex B Mc Ts Comments
POP pp pph Ð(SP+1) - - - - - - 11 pp0 001 .. 1B 3 10 pp pp
Ð
ppl (SP) BC 00
Ð
SP SP+2
DE 01
HL 10
POP AF AÐ(SP+1) Ù1 Ù1 Ù1 Ù1 Ù1 Ù1 11 110 001 F1 1B 3 10
FÐ(SP)
SPÐSP+2
Notes: 1 Flags set directly to low 8-bits of the value from stack SP
4.7 Exchange
106
CHAPTER 4. INSTRUCTIONS AT A GLANCE
Ð1
4 100
SET b,r rb - - - - - - 11 001 011 CB 2B 2 8 5 101
11 b r .. 6 110
pHLqb Ð1
7 111
SET b,(HL) - - - - - - 11 001 011 CB 2B 4 15
11 b 110 ..
SET b,(IX+d) pIX d qb Ð1 - - - - - - 11 011 101 DD 4B 6 23
11 001 011 CB
d ..
11 b 110 ..
SET b,(IY+d) pIY d qb Ð1 - - - - - - 11 111 101 FD 4B 6 23
11 001 011 CB
d ..
11 b 110 ..
SET b,(IX+d),r Ð
r (IX+d) - - - - - - 11 011 101 DD 4B 6 23
Ð
rb 1 11 001 011 CB
(IX+d) r Ð d ..
11 b r ..
SET b,(IY+d),r Ð
r (IY+d) - - - - - - 11 111 101 FD 4B 6 23
Ð
rb 1 11 001 011 CB
(IY+d) Ðr d ..
11 b r ..
Ò
RES b,m 3
mb Ð0 - - - - - - 10 ... ...
Notes: 1 See section ?? for complete description
2 Instruction has other undocumented opcodes
3 m is one of r, (HL), (IX+d), (IY+d). To form RES instruction, replace 11 with 10 . Ts also the same
107
CHAPTER 4. INSTRUCTIONS AT A GLANCE
both. Some assemblers will allow SLL as equivalent, but unfortunately some will assemble it as SLI, so it’s best avoiding
108
CHAPTER 4. INSTRUCTIONS AT A GLANCE
4.10 Jump
ÐIY
M 111
JP (IY) PC - - - - - - 11 111 101 FD 2B 2 8
11 101 001 E9
p pp
JP c,nm if c=true: JP nm - - - - - - 11 c 010 .. 3B 3 10 NZ 00
m .. Z 01
n .. NC 10
C 11
JR e PCÐPC+e - - - - - - 00 011 000 18 2B 3 12
e-2 ..
JR p,e if p=true: JR e - - - - - - 00 1pp 000 .. 2B 2 7 if p=false
e-2 .. 3 12 if p=true
DJNZ e Ð
B B-1 - - - - - - 00 010 000 10 2B 2 8 if B=0
if B 0: JR e e-2 .. 3 13 if B0
109
CHAPTER 4. INSTRUCTIONS AT A GLANCE
110
CHAPTER 4. INSTRUCTIONS AT A GLANCE
111
CHAPTER 4. INSTRUCTIONS AT A GLANCE
4.13 Input
IND Ð
(HL) (BC)
5
4
5
5 1 - 11 101 101 ED 2B 4 16
Ð
HL HL-1 10 101 010 AA
Ð
B B-1
4.14 Output
Ðr
C 001
OUT (C),r (BC) - - - - - - 11 101 101 ED 2B 3 12 D 010
01 r 001 .. E 011
Ð0
H 100
OUT (C),0 (BC) - - - - - - 11 101 101 ED 2B 3 12 L 101
01 110 001 71 A 111
OUTI Ð
B B-1
2
1
2
2 1 - 11 101 101 ED 2B 4 16
Ð
(BC) (HL) 10 100 011 A3
Ð
HL HL+1
112
CHAPTER 4. INSTRUCTIONS AT A GLANCE
LDWS Ð
(DE) (HL) Ù Ù Ù VF2 0 - 11 101 101 ED 2B 4 16
INC L 10 100 101 A5
INC D
113
CHAPTER 4. INSTRUCTIONS AT A GLANCE
PIXELDN ^
if (HL $700) $700 - - - - - - 11 101 101 ED 3B 2 8
Ð
HL HL+256 10 010 011 93
^
else if (HL $E0) $E0
Ð ^
HL HL $F8FF+$20
else
ÐHL^$F81F+$800
HL
114
CHAPTER 4. INSTRUCTIONS AT A GLANCE
4.16 Alphabetical
115
CHAPTER 4. INSTRUCTIONS AT A GLANCE
CALL nm Ð
(SP-1) PCh - - - - - - 11 001 101 CD 3B 5 17
Ð
(SP-2) PCl m ..
Ð
SP SP-2 n ..
Ð
PC nm
CP r A-r Ù Ù Ù VF 1 Ù 10 111 r .. 1B 1 4
CP n A-n Ù Ù Ù VF 1 Ù 11 111 110 FE 2B 2 7
n ..
CP (HL) A-(HL) Ù Ù Ù VF 1 Ù 10 111 110 BE 1B 2 7
CP (IX+d) A-(IX+d) Ù Ù Ù VF 1 Ù 11 011 101 DD 3B 5 19
10 111 110 BE
d ..
CP (IY+d) A-(IY+d) Ù Ù Ù VF 1 Ù 11 111 101 FD 3B 5 19
10 111 110 BE
d ..
116
CHAPTER 4. INSTRUCTIONS AT A GLANCE
117
CHAPTER 4. INSTRUCTIONS AT A GLANCE
IM 04 - - - - - - 11 101 101 ED 2B 2 8
01 000 110 46
IM 14 - - - - - - 11 101 101 ED 2B 2 8
01 010 110 56
IM 24 - - - - - - 11 101 101 ED 2B 2 8
01 011 110 5E
IN A,(n) Ð(n)
A - - - - - - 11 011 011 DB 2B 3 11
n ..
IN r,(C) Ð(BC)
r Ù Ù 0 PF 0 - 11 101 101 ED 2B 3 12
01 r 000 ..
IN (C) (BC) Ù Ù 0 PF 0 - 11 101 101 ED 2B 3 12
01 110 000 70
IND Ð
(HL) (BC)
1 - 11 101 101 ED 2B 4 16
Ð
HL HL-1 10 101 010 AA
BÐB-1
118
CHAPTER 4. INSTRUCTIONS AT A GLANCE
LD r,r’ rÐr’ - - - - - - 01 r r’ .. 1B 1 4
LD r,n rÐn - - - - - - 00 r 110 .. 2B 2 7
n ..
LD r,(HL) rÐ(HL) - - - - - - 01 r 110 .. 1B 2 7
LD r,(IX+d) rÐ(IX+d) - - - - - - 11 011 101 DD 3B 5 19
01 r 110 ..
d ..
LD r,(IY+d) Ð(IY+d)
r - - - - - - 11 111 101 FD 3B 5 19
01 r 110 ..
d ..
LD (HL),r (HL)Ðr - - - - - - 01 110 r .. 1B 2 7
LD (IX+d),r (IX+d)Ðr - - - - - - 11 011 101 DD 3B 5 19
01 110 r ..
d ..
LD (IY+d),r (IY+d) Ðr - - - - - - 11 111 101 FD 3B 5 19
01 110 r ..
d ..
LD (HL),n (HL) Ðn - - - - - - 00 110 110 36 2B 3 10
n ..
LD (IX+d),n (IX+d) Ðn - - - - - - 11 011 101 DD 4B 5 19
00 110 110 36
d ..
n ..
LD (IY+d),n (IY+d) Ðn - - - - - - 11 111 101 FD 4B 5 19
00 110 110 36
d ..
n ..
LD (BC),A (BC)ÐA - - - - - - 00 000 010 02 1B 2 7
LD (DE),A (DE)ÐA - - - - - - 00 010 010 12 1B 2 7
LD (nm),A (nm)ÐA - - - - - - 00 110 010 32 3B 4 13
m ..
n ..
119
CHAPTER 4. INSTRUCTIONS AT A GLANCE
120
CHAPTER 4. INSTRUCTIONS AT A GLANCE
LDD Ð
(DE) (HL) - - 0
0 - 11 101 101 ED 2B 4 16
Ð
DE DE-1 10 101 000 A8
Ð
HL HL-1
BCÐBC-1
LDWSZX Ð
(DE) (HL) Ù Ù Ù VF 0 - 11 101 101 ED 2B 4 16
INC L 10 100 101 A5
INC D
121
CHAPTER 4. INSTRUCTIONS AT A GLANCE
OR r AÐA_r Ù Ù 0 PF 0 0 10 110 r .. 1B 1 4
OR n AÐA_n Ù Ù 0 PF 0 0 11 110 110 F6 2B 2 7
n ..
OR (HL) AÐA_(HL) Ù Ù 0 PF 0 0 10 110 110 B6 1B 2 7
OR (IX+d) AÐA_(IX+d) Ù Ù 0 PF 0 0 11 011 101 DD 3B 5 19
10 110 110 B6
d ..
OR (IY+d) ÐA_(IY+d)
A Ù Ù 0 PF 0 0 11 111 101 FD 3B 5 19
10 110 110 B6
d ..
122
CHAPTER 4. INSTRUCTIONS AT A GLANCE
PIXELDNZX ^
if (HL $700) $700 - - - - - - 11 101 101 ED 3B 2 8
Ð
HL HL+256 10 010 011 93
else if (HL $E0) $E0^
Ð ^
HL HL $F8FF+$20
else
Ð ^
HL HL $F81F+$800
POP rr Ð
rrh (SP+1) - - - - - - 11 rr0 001 .. 1B 3 10
Ð
rrl (SP)
Ð
SP SP+2
123
CHAPTER 4. INSTRUCTIONS AT A GLANCE
RL r CF Ð0
7 Ù Ù 0 PF 0 Ù 11 001 011 CB 2B 2 8
00 010 r ..
RL (HL) CF Ð0
7 Ù Ù 0 PF 0 Ù 11 001 011 CB 2B 4 15
00 010 110 16
RL (IX+d) CF Ð0
7 Ù Ù 0 PF 0 Ù 11 011 101 DD 4B 6 23
11 001 011 CB
d ..
00 010 110 16
RL (IY+d) CF Ð0
7 Ù Ù 0 PF 0 Ù 11 111 101 FD 4B 6 23
11 001 011 CB
d ..
00 010 110 16
RLA CF Ð0
7 - - 0 - 0 Ù 00 010 111 17 1B 1 4
124
CHAPTER 4. INSTRUCTIONS AT A GLANCE
125
CHAPTER 4. INSTRUCTIONS AT A GLANCE
126
CHAPTER 4. INSTRUCTIONS AT A GLANCE
SRL r 0 Ñ0
7 CF Ù Ù 0 PF 0 Ù 11 001 011 CB 2B 2 8
00 111 r ..
SRL (HL) 0 Ñ0
7 CF Ù Ù 0 PF 0 Ù 11 001 011 CB 2B 4 15
00 111 110 3E
SRL (IX+d) 0 Ñ0
7 CF Ù Ù 0 PF 0 Ù 11 011 101 DD 4B 6 23
11 001 011 CB
d ..
00 111 110 3E
SRL (IY+d) 0 Ñ0
7 CF Ù Ù 0 PF 0 Ù 11 111 101 FD 4B 6 23
11 001 011 CB
d ..
00 111 110 3E
TEST n ^
A n Ù Ù Ù PF ? Ù 11 101 101 ED 3B 3 11
00 100 111 27
127
CHAPTER 4. INSTRUCTIONS AT A GLANCE
128
Chapter 5
Instructions up Close
The following pages describe all instructions in detail. Alphabetical order is used as much as
possible, but some deviations were made to better fit to pages. Each instruction includes:
Mnemonic
Symbolic operation for quick info on what instruction does
All variants (where applicable)
Description with further details
Effects on flags
Timing table with machine cycles, T states and time required for execution on different
CPU speeds
Where possible, multiple variants of same instruction are grouped together and where multiple
timings are possible, timing table is sorted from quickest to slowest.
129
Abbreviations
Effects
0 Flag is set to 0
1 Flag is set to 1
Ù Flag is modified according to operation
- Flag is not affected
? Effect on flag is unpredictable
Special case, see notes below effects table
PV P/V flag is used as overflow
PV P/V flag is used as parity
PV PV is undefined or indicates other result
130
CHAPTER 5. INSTRUCTIONS UP CLOSE
Similar to ADC except carry flag is not used in calculation: adds operand s or
contents of the memory location addressed by s to destination d. Result is
then stored to destination d.
In case of ZX Next Extended instructions for adding A to 16-bit register pair,
A is zero extended to 16-bits.
131
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
8-bit Ù Ù Ù Ù 0 Ù
16-bit - - Ù - 0 Ù
16-bit HF is set by carry from bit 11 (half
carry in high byte)
Timing Mc Ts 3.5MHz 7MHz 14MHz 28MHz
A,r 1 4 1,1µs 0,57µs 0,29µs 0,14µs
A,n 2 7 2,0µs 1,00µs 0,50µs 0,25µs
A,(HL) 2 7 2,0µs 1,00µs 0,50µs 0,25µs
rr,AZX 2 8 2,3µs 1,14µs 0,57µs 0,29µs
HL,rr 3 11 3,1µs 1,57µs 0,79µs 0,39µs
IX,rr 4 15 4,3µs 2,14µs 1,07µs 0,54µs
IY,rr 4 15 4,3µs 2,14µs 1,07µs 0,54µs
rr,nnZX 4 16 4,6µs 2,29µs 1,14µs 0,57µs
A,(IX+d) 5 19 5,4µs 2,71µs 1,36µs 0,68µs
A,(IY+d) 5 19 5,4µs 2,71µs 1,36µs 0,68µs
Performs bitwise AND between accumulator A and the given operand. The
result is then stored back to the accumulator. Individual bits are AND’ed
like this:
A s Result
0 0 0
0 1 0
1 0 0
1 1 1
Effects SF ZF HF PV NF CF
Ù Ù 1 Ù 0 0
132
CHAPTER 5. INSTRUCTIONS UP CLOSE
133
CHAPTER 5. INSTRUCTIONS UP CLOSE
134
CHAPTER 5. INSTRUCTIONS UP CLOSE
135
CHAPTER 5. INSTRUCTIONS UP CLOSE
CP s ComPare
A-s
CP A CP E CP (HL) CP IXH**
CP B CP H CP (IX+d) CP IXL**
CP C CP L CP (IY+d) CP IYH**
CP D CP n CP IYL**
Effects SF ZF HF PV NF CF
Ù Ù Ù Ù 1 Ù
Timing Mc Ts 3.5MHz 7MHz 14MHz 28MHz
r 1 4 1,1µs 0,57µs 0,29µs 0,14µs
n 2 7 2,0µs 1,00µs 0,50µs 0,25µs
(HL) 2 7 2,0µs 1,00µs 0,50µs 0,25µs
(IX+d) 5 19 5,4µs 2,71µs 1,36µs 0,68µs
(IY+d) 5 19 5,4µs 2,71µs 1,36µs 0,68µs
Note: CPL is alphabetically after CPD, CPDR, CPI and CPIR, but is placed here to
avoid empty space and to allow CPxx instructions to be presented together
136
CHAPTER 5. INSTRUCTIONS UP CLOSE
137
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
Ù
Ù
1 -
ZF set if A=(HL) before HL is incremented,
reset otherwise
PV set if BC0 after execution, rest
otherwise
Timing Mc Ts 3.5MHz 7MHz 14MHz 28MHz
BC=0 or A=(HL) 4 16 4,6µs 2,29µs 1,14µs 0,57µs
BC0 and A(HL) 5 21 6,0µs 3,00µs 1,50µs 0,75µs
138
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
Ù Ù Ù Ù - Ù
CF set if second addition was required
Timing Mc Ts 3.5MHz 7MHz 14MHz 28MHz
1 4 1,1µs 0,57µs 0,29µs 0,14µs
DEC s DECrement
sÐs-1
8-bit 8-bit 16-bit
DEC A DEC (HL) DEC BC
DEC B DEC (IX+d) DEC DE
DEC C DEC (IY+d) DEC HL
DEC D DEC IXH** DEC IX
DEC E DEC IXL** DEC IY
DEC H DEC IYH** DEC SP
DEC L DEC IYL**
139
CHAPTER 5. INSTRUCTIONS UP CLOSE
DI Disable Interrupts
IFF1Ð0
IFF2Ð0
Disables all maskable interrupts (mode 1 and 2). Interrupts are disabled
after execution of the instruction following DI. See sections ?? and ?? for
more details on interrupts.
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
EI Enable Interrupts
IFF1Ð1
IFF2Ð1
Enables maskable interrupts (mode 1 and 2). Interrupts are enabled after
execution of the instruction following EI; typically RETI or RETN. See sections
?? and ?? for more details on interrupts.
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
140
CHAPTER 5. INSTRUCTIONS UP CLOSE
Exchanges contents of two register pairs or register pair and last value pushed
to stack. For example:
BEFORE AFTER
Reg Value
HL $ABCD $3412
SP $0B00 $0B00
Mem Value Ñ EX (SP),HL Ñ
$0B00 $12 $CD
$0B01 $34 $AB
Effects SF ZF HF PV NF CF
No effect - - - - - -
EX AF,AF’
EX AF,AF’ sets flags directly from the
value of F’
Timing Mc Ts 3.5MHz 7MHz 14MHz 28MHz
rr,rr 1 4 1,1µs 0,57µs 0,29µs 0,14µs
(SP),HL 5 19 5,4µs 2,71µs 1,36µs 0,68µs
(SP),IX 6 23 6,6µs 3,29µs 1,64µs 0,82µs
(SP),IY 6 23 6,6µs 3,29µs 1,64µs 0,82µs
141
CHAPTER 5. INSTRUCTIONS UP CLOSE
HALT HALT
Suspends CPU and executes NOPs (to continue memory refresh cycles) until
the next interrupt or reset. This effectively creates a delay. You can chain
HALTs. But make sure that there will be an interrupt, otherwise HALT will
run forever.
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
IM n Interrupt Mode
IM 0
IM 1
IM 2
Sets the interrupt mode. All 3 interrupts are maskable, meaning they can be
disabled using DI instruction. See sections ?? and ?? for details and example.
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
142
CHAPTER 5. INSTRUCTIONS UP CLOSE
So these two have the same result (though, as mentioned in section ??, variant
on the right is slightly faster, 18 vs 22 T states):
1 LD BC, $DFFE 1 LD A, $DF
2 IN A, (C) 2 IN A, ($FE)
Effects SF ZF HF PV NF CF
IN r,(C) Ù Ù 0 Ù 0 -
IN A,(n) (no effect) - - - - - -
Note: IN (C) (or its alternative form IN F,(C)) variant performs an input, but
does not store the result, only sets the flags.
Note: some assemblers also allow (BC) to be used instead of (C).
143
CHAPTER 5. INSTRUCTIONS UP CLOSE
INC s INCrement
sÐs+1
8-bit 8-bit 16-bit
INC A INC (HL) INC BC
INC B INC (IX+d) INC DE
INC C INC (IY+d) INC HL
INC D INC IXH** INC IX
INC E INC IXL** INC IY
INC H INC IYH** INC SP
INC L INC IYL**
144
CHAPTER 5. INSTRUCTIONS UP CLOSE
145
CHAPTER 5. INSTRUCTIONS UP CLOSE
146
CHAPTER 5. INSTRUCTIONS UP CLOSE
JP nn JumP
PCÐnn
JP nn JP (IX)
JP (HL) JP (IY)
JP (C)ZX JumP
PCÐPC^$C000+IN(C)<<6
Sets bottom 14 bits of current program counter PC* to value read from I/O
port: PC[13-0] = (IN (C) << 6). Can be used to execute code block read
from a disk stream.
* “CurrentPC” is address of the next instruction after JP (C); PC was already
advanced after fetching JP (C) instruction from memory. If JP (C) instruction is
147
CHAPTER 5. INSTRUCTIONS UP CLOSE
located at the very end of 16K memory block ($..FE or $..FF address), then new
PC value will land into following 16K block.
Effects SF ZF HF PV NF CF
? ? ? ? ? ?
JR e Jump Relative
PCÐPC+e
Unconditionally performs relative jump. Offset e is added to the value of
program counter PC as signed value to allow jumps forward and backward.
Offset is added to PC after JR instruction is read (aka PC+2), so offset is in
the range of -126 to 129. Assembler automatically subtracts 2 from offset
value e to generate opcode.
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
148
CHAPTER 5. INSTRUCTIONS UP CLOSE
LD d,s LoaD
dÐs
Loads source s into destination d. The following combinations are allowed
(source s is represented horizontally, destination d vertically):
A B C D E H L I R IXH IXL IYH IYL BC DE HL SP IX IY (BC) (DE) (HL) (IX+d) (IY+d) n nn (nn)
A
B
C
D
E
H
L
I
R
IXH
IXL
IYH
IYL
BC
DE
HL
SP
IX
IY
(BC)
(DE)
(HL)
(IX+d)
(IY+d)
(nn)
149
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
LD A,I and LD A,R Ù Ù 0 IFF2 0 -
Other variants - - - - - -
150
CHAPTER 5. INSTRUCTIONS UP CLOSE
151
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
- - 0 0 0 -
Note: the source data are read only from single 256B (aligned) block of memory,
because only L is incremented, not HL pair.
Note: LDWS is alphabetically after LDPIRX, but is placed here to avoid empty space
and to allow Next extended LDxx instructions to be presented together
152
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
153
CHAPTER 5. INSTRUCTIONS UP CLOSE
154
CHAPTER 5. INSTRUCTIONS UP CLOSE
A 7654 3210
Note: Older core versions also supported MIRROR DE, but this was removed.
NEG NEGate
AÐ-A
Negates contents of the accumulator A and stores result back to A.
Effects SF ZF HF PV NF CF
Ù Ù Ù Ù 1 Ù
Timing Mc Ts 3.5MHz 7MHz 14MHz 28MHz
2 8 2,3µs 1,14µs 0,57µs 0,29µs
Directly sets the Next Feature Control Registers without going through ports
TBBlue Register Select $243B and TBBlue Register Access $253B. See
section ?? for ports list.
155
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
NOP No OPeration
Does nothing for 4 cycles.
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
OR s bitwise OR
AÐA_s
OR A OR E OR (HL) OR IXH**
OR B OR H OR (IX+d) OR IXL**
OR C OR L OR (IY+d) OR IYH**
OR D OR n OR IYL**
Effects SF ZF HF PV NF CF
Ù Ù 0 Ù 0 0
156
CHAPTER 5. INSTRUCTIONS UP CLOSE
157
CHAPTER 5. INSTRUCTIONS UP CLOSE
Writes the value of operand s to the port at address d. Port addresses are
always 16-bit values defined like this:
Address Bits
Variant 15-8 7-0
OUT (n),A A n
OUT (C),r B C
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
Note: on the Next FPGA OUT (C),0 variant outputs 0 to the port at address BC,
but some Z80 chips may output different value like $FF, so it is not recommended
to use OUT (C),0 if you want to reuse your code on original ZX Spectrum also.
158
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
1 -
SF, HF and PV are destroyed on Next, for
other Z80 computers see ??
ZF set if B=0 after decrement, reset
otherwise
Timing Mc Ts 3.5MHz 7MHz 14MHz 28MHz
4 16 4,6µs 2,29µs 1,14µs 0,57µs
159
CHAPTER 5. INSTRUCTIONS UP CLOSE
Copies 2 bytes from stack pointer SP into contents of the given register pair
ss and increments SP by 2.
Effects SF ZF HF PV NF CF
No effect - - - - - -
POP AF Ù Ù Ù Ù Ù Ù
POP AF flags set directly to low 8-bits of
the value from SP
Timing Mc Ts 3.5MHz 7MHz 14MHz 28MHz
rr 3 10 2,9µs 1,43µs 0,71µs 0,36µs
IX 4 14 4,0µs 2,00µs 1,00µs 0,50µs
IY 4 14 4,0µs 2,00µs 1,00µs 0,50µs
160
CHAPTER 5. INSTRUCTIONS UP CLOSE
Copies contents of a register pair to the top of the stack pointer SP, then
decrements SP by 2. Next extended PUSH nn also allows pushing immediate
16-bit value.
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
161
CHAPTER 5. INSTRUCTIONS UP CLOSE
162
CHAPTER 5. INSTRUCTIONS UP CLOSE
RL s Rotate Left
CF 7 Ð0
s
RL A RL (IX+d),A** RL (IY+d),A**
RL B RL (IX+d),B** RL (IY+d),B**
RL C RL (IX+d),C** RL (IY+d),C**
RL D RL (IX+d),D** RL (IY+d),D**
RL E RL (IX+d),E** RL (IY+d),E**
RL H RL (IX+d),H** RL (IY+d),H**
RL L RL (IX+d),L** RL (IY+d),L**
RL (HL)
RL (IX+d)
RL (IY+d)
Performs 9-bit left rotation of the value of the operand s or memory addressed
by s through the carry flag CF so that contents of CF are moved to bit 0 and
bit 7 to CF. Result is then stored back to s.
Effects SF ZF HF PV NF CF
Ù Ù 0 Ù 0 Ù
Timing Mc Ts 3.5MHz 7MHz 14MHz 28MHz
r 2 8 2,3µs 1,14µs 0,57µs 0,29µs
(HL) 4 15 4,3µs 2,14µs 1,07µs 0,54µs
(IX+d) 6 23 6,6µs 3,29µs 1,64µs 0,82µs
(IY+d) 6 23 6,6µs 3,29µs 1,64µs 0,82µs
163
CHAPTER 5. INSTRUCTIONS UP CLOSE
CF Ð0
7
A
Performs RL A, but twice faster and preserves SF and ZF.
Effects SF ZF HF PV NF CF
- - 0 - 0 Ù
Timing Mc Ts 3.5MHz 7MHz 14MHz 28MHz
1 4 1,1µs 0,57µs 0,29µs 0,14µs
CF 7Ð0
s
RLC A RLC (IX+d),A** RLC (IY+d),A**
RLC B RLC (IX+d),B** RLC (IY+d),B**
RLC C RLC (IX+d),C** RLC (IY+d),C**
RLC D RLC (IX+d),D** RLC (IY+d),D**
RLC E RLC (IX+d),E** RLC (IY+d),E**
RLC H RLC (IX+d),H** RLC (IY+d),H**
RLC L RLC (IX+d),L** RLC (IY+d),L**
RLC (HL)
RLC (IX+d)
RLC (IY+d)
Performs 8-bit rotation to the left. Bit 7 is moved to carry flag CF as well as
to bit 0. Result is then stored back to s.
Note: undocumented variants work slightly differently:
RLC r,(IX+d): RLC r,(IY+d):
rÐ(IX+d) rÐ(IY+d)
RLC r RLC r
(IX+d)Ðr (IY+d)Ðr
Effects SF ZF HF PV NF CF
Ù Ù 0 Ù 0 Ù
Timing Mc Ts 3.5MHz 7MHz 14MHz 28MHz
r 2 8 2,3µs 1,14µs 0,57µs 0,29µs
(HL) 4 15 4,3µs 2,14µs 1,07µs 0,54µs
(IX+d) 6 23 6,6µs 3,29µs 1,64µs 0,82µs
(IY+d) 6 23 6,6µs 3,29µs 1,64µs 0,82µs
164
CHAPTER 5. INSTRUCTIONS UP CLOSE
CF Ð0
7
A
Performs RLC A, but twice faster and preserves SF and ZF.
Effects SF ZF HF PV NF CF
- - 0 - 0 Ù
Timing Mc Ts 3.5MHz 7MHz 14MHz 28MHz
1 4 1,1µs 0,57µs 0,29µs 0,14µs
7
(HL)
8
10
(HL)
11 digits = $-number ;(2)
Effects SF ZF HF PV NF CF
Ù Ù 0 Ù 0 -
Note: instruction doesn’t assume any format of the data; it simply rotates nibbles.
So while it’s most frequently associated with BCD numbers, it can be used for
shifting hexadecimal values (in which case it would represent multiplication by 16)
or any other content.
165
CHAPTER 5. INSTRUCTIONS UP CLOSE
RR s Rotate Right
7 Ñ0 CF
s
RR A RR (IX+d),A** RR (IY+d),A**
RR B RR (IX+d),B** RR (IY+d),B**
RR C RR (IX+d),C** RR (IY+d),C**
RR D RR (IX+d),D** RR (IY+d),D**
RR E RR (IX+d),E** RR (IY+d),E**
RR H RR (IX+d),H** RR (IY+d),H**
RR L RR (IX+d),L** RR (IY+d),L**
RR (HL)
RR (IX+d)
RR (IY+d)
7 Ñ0 CF
A
Performs RR A, but twice faster and preserves SF and ZF.
Effects SF ZF HF PV NF CF
- - 0 - 0 Ù
Timing Mc Ts 3.5MHz 7MHz 14MHz 28MHz
1 4 1,1µs 0,57µs 0,29µs 0,14µs
166
CHAPTER 5. INSTRUCTIONS UP CLOSE
7 Ñ0 CF
s
RRC A RRC (IX+d),A** RRC (IY+d),A**
RRC B RRC (IX+d),B** RRC (IY+d),B**
RRC C RRC (IX+d),C** RRC (IY+d),C**
RRC D RRC (IX+d),D** RRC (IY+d),D**
RRC E RRC (IX+d),E** RRC (IY+d),E**
RRC H RRC (IX+d),H** RRC (IY+d),H**
RRC L RRC (IX+d),L** RRC (IY+d),L**
RRC (HL)
RRC (IX+d)
RRC (IY+d)
7 Ñ0 CF
A
Performs RRC A, but twice faster and preserves SF and ZF.
Effects SF ZF HF PV NF CF
- - 0 - 0 Ù
Timing Mc Ts 3.5MHz 7MHz 14MHz 28MHz
1 4 1,1µs 0,57µs 0,29µs 0,14µs
Similar to RLD (page ??) except rotation is to the right. If used with BCD
values, this operation effectively divides 3-digit BCD number by 10 and stores
167
CHAPTER 5. INSTRUCTIONS UP CLOSE
1 DivideBy10: Progression
2 LD HL, number ; number=0123 line number A B
3 LD B, digits ; number of repeats
2-4 0123 0 2
4 XOR A ; reset "carry" Ó
t
(HL)
5 lp: RRD ; divide by 10
6 INC HL ; next 2 digits
5-7 0023 1 1
DJNZ lp ; number=0012, A=3 ÷
t
7
(HL)
8
t
10
(HL)
11 digits = $-number ;(2)
Effects SF ZF HF PV NF CF
Ù Ù 0 Ù 0 -
RST n ReSTart
(SP-1)ÐPCh
(SP-2)ÐPCl
SPÐSP-2
PCÐn
RST $00 RST $20
RST $08 RST $28
RST $10 RST $30
RST $18 RST $38
Restarts at the zero page address s. Only above addresses are possible, all
in page 0 of the memory, therefore the most significant byte of the program
counter PC is loaded with $00. The instruction may be used as a fast response
to an interrupt.
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
168
CHAPTER 5. INSTRUCTIONS UP CLOSE
169
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
170
CHAPTER 5. INSTRUCTIONS UP CLOSE
171
CHAPTER 5. INSTRUCTIONS UP CLOSE
Note: most assemblers will accept both variants: SLI or SL1, but some may only
accept one or the other, while some may expect SLL instead.
172
CHAPTER 5. INSTRUCTIONS UP CLOSE
173
CHAPTER 5. INSTRUCTIONS UP CLOSE
SUB s SUBtract
AÐA-s
SUB A SUB n SUB IXH**
SUB B SUB (HL) SUB IXL**
SUB C SUB (IX+d) SUB IYH**
SUB D SUB (IY+d) SUB IYL**
SUB E
SUB H
SUB L
A 7654 3210
Effects SF ZF HF PV NF CF
Ù Ù Ù Ù ? Ù
Timing Mc Ts 3.5MHz 7MHz 14MHz 28MHz
3 11 3,1µs 1,57µs 0,79µs 0,39µs
174
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
Ù Ù 0 Ù 0 0
175
CHAPTER 5. INSTRUCTIONS UP CLOSE
176
Appendix A
**
Instructions marked with are undocumented.
ZX
Instructions marked with are ZX Spectrum Next extended.
177
APPENDIX A. INSTRUCTIONS SORTED BY MNEMONIC
178
APPENDIX A. INSTRUCTIONS SORTED BY MNEMONIC
CP A BF IM 1 ED56 LD (HL),A 77
CP B B8 IM 2** ED7E LD (HL),B 70
CP C B9 IM 2 ED5E LD (HL),C 71
CP D BA IN A,(C) ED78 LD (HL),D 72
CP E BB IN A,(n) DB n LD (HL),E 73
CP H BC IN B,(C) ED40 LD (HL),H 74
CP L BD IN C,(C) ED48 LD (HL),L 75
CP n FE n IN D,(C) ED50 LD (HL),n 36 n
CP (HL) BE IN E,(C) ED58 LD (IX+d),A DD77 d
CP (IX+d) DDBE d IN F,(C)** ED70 LD (IX+d),B DD70 d
CP (IY+d) FDBE d IN H,(C) ED60 LD (IX+d),C DD71 d
CP IXH** DDBC IN L,(C) ED68 LD (IX+d),D DD72 d
CP IXL** DDBD IN (C)** ED70 LD (IX+d),E DD73 d
CP IYH** FDBC INC (HL) 34 LD (IX+d),H DD74 d
CP IYL** FDBD INC (IX+d) DD34 d LD (IX+d),L DD75 d
CPDR EDB9 INC (IY+d) FD34 d LD (IX+d),n DD36 d n
CPD EDA9 INC A 3C LD (IY+d),A FD77 d
CPIR EDB1 INC B 04 LD (IY+d),B FD70 d
CPI EDA1 INC C 0C LD (IY+d),C FD71 d
CPL 2F INC D 14 LD (IY+d),D FD72 d
DAA 27 INC E 1C LD (IY+d),E FD73 d
DEC (HL) 35 INC H 24 LD (IY+d),H FD74 d
DEC (IX+d) DD35 d INC L 2C LD (IY+d),L FD75 d
DEC (IY+d) FD35 d INC BC 03 LD (IY+d),n FD36 d n
DEC A 3D INC DE 13 LD (nm),A 32 m n
DEC B 05 INC HL 23 LD (nm),BC ED43 m n
DEC C 0D INC IX DD23 LD (nm),DE ED53 m n
DEC D 15 INC IXH** DD24 LD (nm),HL 22 m n
DEC E 1D INC IXL** DD2C LD (nm),HL ED63 m n
DEC H 25 INC IY FD23 LD (nm),IX DD22 m n
DEC L 2D INC IYH** FD24 LD (nm),IY FD22 m n
DEC BC 0B INC IYL** FD2C LD (nm),SP ED73 m n
DEC DE 1B INC SP 33 LD A,A 7F
DEC HL 2B INDR EDBA LD A,B 78
DEC IX DD2B IND EDAA LD A,C 79
DEC IXH** DD25 INIR EDB2 LD A,D 7A
DEC IXL** DD2D INI EDA2 LD A,E 7B
DEC IY FD2B JP (C)ZX ED98 LD A,H 7C
DEC IYH** FD25 JP (HL) E9 LD A,I ED57
DEC IYL** FD2D JP (IX) DDE9 LD A,L 7D
DEC SP 3B JP (IY) FDE9 LD A,R ED5F
DI F3 JP nm C3 m n LD A,n 3E n
DJNZ (PC+e) 10 e JP C,nm DA m n LD A,(BC) 0A
EI FB JP M,nm FA m n LD A,(DE) 1A
EX (SP),HL E3 JP NC,nm D2 m n LD A,(HL) 7E
EX (SP),IX DDE3 JP NZ,nm C2 m n LD A,(IX+d) DD7E d
EX (SP),IY FDE3 JP P,nm F2 m n LD A,(IY+d) FD7E d
EX AF,AF’ 08 JP PE,nm EA m n LD A,(nm) 3A m n
EX DE,HL EB JP PO,nm E2 m n LD A,IXH** DD7C
EXX D9 JP Z,nm CA m n LD A,IXL** DD7D
HALT 76 JR e 18 e LD A,IYH** FD7C
IM 0** ED4E JR C,e 38 e LD A,IYL** FD7D
IM 0** ED66 JR NC,e 30 e LD B,A 47
IM 0** ED6E JR NZ,e 20 e LD B,B 40
IM 0 ED46 JR Z,e 28 e LD B,C 41
IM 1** ED76 LD (BC),A 02 LD B,D 42
LD (DE),A 12 LD B,E 43
179
APPENDIX A. INSTRUCTIONS SORTED BY MNEMONIC
180
APPENDIX A. INSTRUCTIONS SORTED BY MNEMONIC
181
APPENDIX A. INSTRUCTIONS SORTED BY MNEMONIC
182
APPENDIX A. INSTRUCTIONS SORTED BY MNEMONIC
183
APPENDIX A. INSTRUCTIONS SORTED BY MNEMONIC
184
APPENDIX A. INSTRUCTIONS SORTED BY MNEMONIC
185
APPENDIX A. INSTRUCTIONS SORTED BY MNEMONIC
186
Appendix B
**
Instructions marked with are undocumented.
ZX
Instructions marked with are ZX Spectrum Next extended.
187
APPENDIX B. INSTRUCTIONS SORTED BY OPCODE
188
APPENDIX B. INSTRUCTIONS SORTED BY OPCODE
189
APPENDIX B. INSTRUCTIONS SORTED BY OPCODE
190
APPENDIX B. INSTRUCTIONS SORTED BY OPCODE
191
APPENDIX B. INSTRUCTIONS SORTED BY OPCODE
192
APPENDIX B. INSTRUCTIONS SORTED BY OPCODE
193
APPENDIX B. INSTRUCTIONS SORTED BY OPCODE
194
APPENDIX B. INSTRUCTIONS SORTED BY OPCODE
195
APPENDIX B. INSTRUCTIONS SORTED BY OPCODE
196
Appendix C
Bibliography
[2] YAZE (Yet Another Z80 Emulator). This is a CPM emulator by Frank Cringle. It emulates
almost every undocumented flag, very good emulator. Also includes a very good instruction
exerciser and is released under the GPL.
ftp://ftp.ping.de/pub/misc/emulators/yaze-1.10.tar.gz
Note: the instruction exerciser zexdoc/zexall does not test I/O instructions and not all
normal instructions (for instance LD A,(IX+n) is tested, but not with different values of n,
just n=1, values above 128 (LD A,(IX-n) are not tested) but it still gives a pretty good idea
of how well a simulated Z80 works.
[3] Z80 Family Official Support Page by Thomas Scherrer. Very good – your one-stop Z80 page.
http://www.geocities.com/SiliconValley/Peaks/3938/z80 home.htm
[5] Gerton Lunter’s Spectrum emulator (Z80). In the package there is a file TECHINFO.DOC,
which contains a lot of interesting information. Note that the current version can only be
unpacked in Windows.
ftp://ftp.void.jump.org/pub/sinclair/emulators/pc/dos/z80-400.zip
[6] Mostek Z80 Programming Manual – a very good reference to the Z80.
197
APPENDIX C. BIBLIOGRAPHY
198
Appendix D
Preamble
The purpose of this License is to make a manual, textbook, or other written document “free” in the
sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without
modifying it, either commercially or non-commercially. Secondarily, this License preserves for the
author and publisher a way to get credit for their work, while not being considered responsible for
modifications made by others.
This License is a kind of “copyleft”, which means that derivative works of the document must
themselves be free in the same sense. It complements the GNU General Public License, which is
a copyleft license designed for free software.
We have designed this License in order to use it for manuals for free software, because free software
needs free documentation: a free program should come with manuals providing the same freedoms that
the software does. But this License is not limited to software manuals; it can be used for any textual
work, regardless of subject matter or whether it is published as a printed book. We recommend this
License principally for works whose purpose is instruction or reference.
199
APPENDIX D. GNU FREE DOCUMENTATION LICENSE
either copied verbatim, or with modifications and/or translated into another language.
A “Secondary Section” is a named appendix or a front-matter section of the Document that deals
exclusively with the relationship of the publishers or authors of the Document to the Document’s
overall subject (or to related matters) and contains nothing that could fall directly within that overall
subject. (For example, if the Document is in part a textbook of mathematics, a Secondary Section
may not explain any mathematics.) The relationship could be a matter of historical connection with
the subject or with related matters, or of legal, commercial, philosophical, ethical or political position
regarding them.
The “Invariant Sections” are certain Secondary Sections whose titles are designated, as being those of
Invariant Sections, in the notice that says that the Document is released under this License.
The “Cover Texts” are certain short passages of text that are listed, as Front-Cover Texts or Back-
Cover Texts, in the notice that says that the Document is released under this License.
A “Transparent” copy of the Document means a machine-readable copy, represented in a format whose
specification is available to the general public, whose contents can be viewed and edited directly and
straightforwardly with generic text editors or (for images composed of pixels) generic paint programs
or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters
or for automatic translation to a variety of formats suitable for input to text formatters. A copy made
in an otherwise Transparent file format whose mark-up has been designed to thwart or discourage
subsequent modification by readers is not Transparent. A copy that is not “Transparent” is called
“Opaque”.
Examples of suitable formats for Transparent copies include plain ASCII without mark-up, Texinfo
input format, LATEX input format, SGML or XML using a publicly available DTD, and standard-
conforming simple HTML designed for human modification. Opaque formats include PostScript, PDF,
proprietary formats that can be read and edited only by proprietary word processors, SGML or XML
for which the DTD and/or processing tools are not generally available, and the machine-generated
HTML produced by some word processors for output purposes only.
The “Title Page” means, for a printed book, the title page itself, plus such following pages as are
needed to hold, legibly, the material this License requires to appear in the title page. For works in
formats which do not have any title page as such, “Title Page” means the text near the most prominent
appearance of the work’s title, preceding the beginning of the body of the text.
200
APPENDIX D. GNU FREE DOCUMENTATION LICENSE
D.4 Modifications
You may copy and distribute a Modified Version of the Document under the conditions of sections
2 and 3 above, provided that you release the Modified Version under precisely this License, with the
Modified Version filling the role of the Document, thus licensing distribution and modification of the
Modified Version to whoever possesses a copy of it. In addition, you must do these things in the
Modified Version:
Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and
from those of previous versions (which should, if there were any, be listed in the History section
of the Document). You may use the same title as a previous version if the original publisher of
that version gives permission.
List on the Title Page, as authors, one or more persons or entities responsible for authorship of
the modifications in the Modified Version, together with at least five of the principal authors of
the Document (all of its principal authors, if it has less than five).
State on the Title page the name of the publisher of the Modified Version, as the publisher.
Add an appropriate copyright notice for your modifications adjacent to the other copyright
notices.
201
APPENDIX D. GNU FREE DOCUMENTATION LICENSE
Include, immediately after the copyright notices, a license notice giving the public permission to
use the Modified Version under the terms of this License, in the form shown in the Addendum
below.
Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given
in the Document’s license notice.
Preserve the section entitled “History”, and its title, and add to it an item stating at least
the title, year, new authors, and publisher of the Modified Version as given on the Title Page.
If there is no section entitled “History” in the Document, create one stating the title, year,
authors, and publisher of the Document as given on its Title Page, then add an item describing
the Modified Version as stated in the previous sentence.
Preserve the network location, if any, given in the Document for public access to a Transparent
copy of the Document, and likewise the network locations given in the Document for previous
versions it was based on. These may be placed in the “History” section. You may omit a
network location for a work that was published at least four years before the Document itself,
or if the original publisher of the version it refers to gives permission.
In any section entitled “Acknowledgements” or “Dedications”, preserve the section’s title, and
preserve in the section all the substance and tone of each of the contributor acknowledgements
and/or dedications given therein.
Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles.
Section numbers or the equivalent are not considered part of the section titles.
Delete any section entitled “Endorsements”. Such a section may not be included in the Modified
Version.
Do not retitle any existing section as “Endorsements” or to conflict in title with any Invariant
Section.
If the Modified Version includes new front-matter sections or appendices that qualify as Secondary
Sections and contain no material copied from the Document, you may at your option designate some
or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the
Modified Version’s license notice. These titles must be distinct from any other section titles.
You may add a section entitled “Endorsements”, provided it contains nothing but endorsements of
your Modified Version by various parties – for example, statements of peer review or that the text has
been approved by an organization as the authoritative definition of a standard.
You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as
a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of
Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by)
any one entity. If the Document already includes a cover text for the same cover, previously added by
you or by arrangement made by the same entity you are acting on behalf of, you may not add another;
but you may replace the old one, on explicit permission from the previous publisher that added the
old one.
The author(s) and publisher(s) of the Document do not by this License give permission to use their
names for publicity for or to assert or imply endorsement of any Modified Version.
202
APPENDIX D. GNU FREE DOCUMENTATION LICENSE
D.8 Translation
Translation is considered a kind of modification, so you may distribute translations of the Document
under the terms of section 4. Replacing Invariant Sections with translations requires special permission
203
APPENDIX D. GNU FREE DOCUMENTATION LICENSE
from their copyright holders, but you may include translations of some or all Invariant Sections in
addition to the original versions of these Invariant Sections. You may include a translation of this
License provided that you also include the original English version of this License. In case of a
disagreement between the translation and the original English version of this License, the original
English version will prevail.
D.9 Termination
You may not copy, modify, sublicense, or distribute the Document except as expressly provided for
under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void,
and will automatically terminate your rights under this License. However, parties who have received
copies, or rights, from you under this License will not have their licenses terminated so long as such
parties remain in full compliance.
204