ZX Next Dev Guide r3
ZX Next Dev Guide r3
Tomaž Kragelj
Z80 Undocumented by
Jan Wilmans
Sean Young
ZX Spectrum Next Assembly Developer Guide
Tomaž Kragelj
15 July 2022
REVISIONS
2022-07-15
2022-11-11
2021-07-16
1 Introduction 1
1.1 Where to get this document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Companion Source Code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.3 Background, Contact & Feedback . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Z80 Undocumented . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.5 ChangeLog . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Zilog Z80 7
2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1 History of the Z80 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2 Pin Descriptions [7] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.1.3 Power on Defaults . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.1.4 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.1.5 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2 Undocumented Opcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.1 CB Prefix [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.2 DD Prefix [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.2.3 ED Prefix [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.2.4 FD Prefix [5] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.5 DDCB Prefix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2.6 FDCB Prefixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.7 Combinations of Prefixes . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Undocumented Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3.1 BIT Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
i
2.3.2 Memory Block Instructions [1] . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.3 I/O Block Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.4 16 Bit I/O ports . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.5 Block Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.6 16 Bit Additions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.3.7 DAA Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4 Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.1 Non-Maskable Interrupts (NMI) . . . . . . . . . . . . . . . . . . . . . . . 19
2.4.2 Maskable Interrupts (INT) . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2.4.3 Things Affecting the Interrupt Flip-Flops . . . . . . . . . . . . . . . . . . 21
2.4.4 HALT Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
2.4.5 Where interrupts are accepted . . . . . . . . . . . . . . . . . . . . . . . . 22
2.5 Timing and R register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.5.1 R register and memory refresh . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6 Errors in Official Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3 ZX Spectrum Next 25
3.1 Ports and Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.1 Mapped Spectrum Ports . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.1.2 Next/TBBlue Feature Control Registers . . . . . . . . . . . . . . . . . . 29
3.1.3 Accessing Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2 Memory Map and Paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.1 Banks and Slots . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.2 Default Bank Traits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.2.3 Memory Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.2.4 Legacy Paging Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2.5 Next MMU Paging Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.2.6 Interaction Between Paging Modes . . . . . . . . . . . . . . . . . . . . . 40
3.2.7 Paging Mode Ports and Registers . . . . . . . . . . . . . . . . . . . . . . 41
3.3 DMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.3.1 Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
ii
3.3.2 Registers at a Glance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.3.3 WR0 - Direction, Operation, Port A Configuration . . . . . . . . . . . . 45
3.3.4 WR1 - Port A Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.3.5 WR2 - Port B Configuration . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.3.6 WR3 - Activation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.3.7 WR4 - Port B, Timing, Interrupt Control . . . . . . . . . . . . . . . . . . 51
3.3.8 WR5 - Ready, Stop Configuration . . . . . . . . . . . . . . . . . . . . . . 52
3.3.9 WR6 - Command Register . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.3.10 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.3.11 Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
3.3.12 DMA Ports and Registers . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.4 Palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.4.1 Palette Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.4.2 Palette Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.4.3 8 Bit Colours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.4.4 9 Bit Colours . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.4.5 Palette Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.5 ULA Layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.5.1 Pixel Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.5.2 Attributes Memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.5.3 Border . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.5.4 Shadow Screen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.5.5 Enhanced ULA Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.5.6 ULA Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.6 Layer 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.6.1 Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.6.2 Paging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.6.3 Drawing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.6.4 Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
3.6.5 256192 256 Colour Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.6.6 320256 256 Colour Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 77
iii
3.6.7 640256 16 Colour Mode . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.6.8 Layer 2 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.7 Tilemap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.7.1 Tile Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.7.2 Tilemap Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
3.7.3 Memory Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.7.4 Combining ULA and Tilemap . . . . . . . . . . . . . . . . . . . . . . . . 86
3.7.5 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
3.7.6 Tilemap Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
3.8 Sprites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
3.8.1 Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
3.8.2 Patterns . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
3.8.3 Palette . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3.8.4 Combined Sprites . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
3.8.5 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
3.8.6 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
3.8.7 Sprite Ports and Registers . . . . . . . . . . . . . . . . . . . . . . . . . . 100
3.9 Copper . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
3.9.1 Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
3.9.2 Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
3.9.3 Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
3.9.4 Copper Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
3.10 Sound . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
3.10.1 AY Chip Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
3.10.2 Editing and Players . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
3.10.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
3.10.4 Sound Ports and Registers . . . . . . . . . . . . . . . . . . . . . . . . . . 113
3.11 Keyboard . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
3.11.1 Legacy Keyboard Status . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
3.11.2 Next Extended Keys . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
3.11.3 Keyboard Ports and Registers . . . . . . . . . . . . . . . . . . . . . . . . 118
iv
3.12 Interrupts on Next . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
3.12.1 Interrupt Mode 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
3.12.2 Interrupt Mode 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
3.12.3 Hardware Interrupt Mode 2 . . . . . . . . . . . . . . . . . . . . . . . . . 123
3.12.4 Interrupt Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
v
5.9 BSRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
5.10 BSRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
5.11 BSRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
5.12 CCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
5.13 CP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
5.14 CPD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
5.15 CPDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
5.16 CPI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
5.17 CPIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
5.18 DAA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
5.19 CPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
5.20 DEC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
5.21 DI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
5.22 DJNZ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
5.23 EI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
5.24 EX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
5.25 EXX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
5.26 HALT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
5.27 IM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
5.28 IN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
5.29 INC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
5.30 IND . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
5.31 INDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
5.32 INI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
5.33 INIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
5.34 JP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
5.35 JP c,nn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
5.36 JP (C) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
5.37 JR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
5.38 JR c,n . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
5.39 LD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
vi
5.40 LDD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
5.41 LDDX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
5.42 LDI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
5.43 LDIX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
5.44 LDWS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
5.45 LDDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
5.46 LDDRX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
5.47 LDIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
5.48 LDIRX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
5.49 LDPIRX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
5.50 MUL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
5.51 NEG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
5.52 NEXTREG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
5.53 NOP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
5.54 OR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
5.55 OTDR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
5.56 OTIR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
5.57 OUTD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
5.58 OUTI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
5.59 OUT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
5.60 OUTINB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
5.61 PIXELAD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
5.62 PIXELDN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
5.63 POP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
5.64 PUSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
5.65 RES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
5.66 RET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
5.67 RET c . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
5.68 RETI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
5.69 RETN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
5.70 RL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
vii
5.71 RLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
5.72 RLC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
5.73 RLCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
5.74 RR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
5.75 RRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
5.76 RRC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
5.77 RLD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
5.78 RRCA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
5.79 RRD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
5.80 RST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
5.81 SCF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 195
5.82 SET . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
5.83 SETAE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
5.84 SLA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
5.85 SLL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
5.86 SLI / SL1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
5.87 SRA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
5.88 SRL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
5.89 SBC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
5.90 SUB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
5.91 SWAPNIB . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
5.92 TEST . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
5.93 XOR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
C Bibliography 225
viii
Chapter 1
Introduction
1
CHAPTER 1. INTRODUCTION
2
CHAPTER 1. INTRODUCTION
3
CHAPTER 1. INTRODUCTION
Jan
http://www.myquest.nl/z80undocumented/
Email jw AT dds DOT nl
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 July 2022 Corrections, updates and improvements. Main focus on making instruction up
close chapter more useful. Each instruction now includes description of effects on flags
and where makes sense, includes additional description or code examples.
11 November 2021 Corrections and updates based on community comments - with special
thanks to Peter Ped Helcmanovsky and Alvin Albrecht. 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, DMA, Copper and Hardware
IM2 sections. Other than some 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 jw AT dds DOT nl) 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
2.3.7, page 19). 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
2.1.3, page 10) and the algorithm for the CF and HF flags for OTIR and friends (section
2.3.3, page 17).
5
CHAPTER 1. INTRODUCTION
6
Chapter 2
Zilog Z80
2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.2 Undocumented Opcodes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.3 Undocumented Effects . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.5 Timing and R register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.6 Errors in Official Documentation . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7
CHAPTER 2. ZILOG Z80
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 (frustum AT pacbell DOT net): 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
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
9
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.
Matt2 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.
2
redflame AT xmission DOT com
10
CHAPTER 2. ZILOG Z80
2.1.4 Registers
2.1.5 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 MAME3 .
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.4
CF The carry flag, set if there was a carry after the most significant bit.
3
http://www.mame.net/
4
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?
11
CHAPTER 2. ZILOG Z80
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).
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 2.2.5,
page 14.
Some examples:
12
CHAPTER 2. ZILOG Z80
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
CHAPTER 2. ZILOG Z80
All the RETI/RETN instructions are the same, all like the RETN instruction. So they all, including
RETI, copy IFF2 to IFF1. See section 2.4.3, page 21 for more information on RETI and RETN
and IM x.
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.
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
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:
1 LD B, (IX+$01)
2 RLC B
3 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:
1 RLC (IX+$01)
2 LD B, (IX+$01)
That’s not correct: B contains the rotated value, even if (IX+$01) points to ROM.
5
gerton AT math.rug DOT nl
14
CHAPTER 2. ZILOG Z80
The DDCB SET and RES instructions do the same thing as the shift/rotate instructions:
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
15
CHAPTER 2. ZILOG Z80
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).
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!
16
CHAPTER 2. ZILOG Z80
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.
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.
17
CHAPTER 2. ZILOG Z80
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.
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.
18
CHAPTER 2. ZILOG Z80
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: HF 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.
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
6
http://www.ramsoft.bbk.org/
19
CHAPTER 2. ZILOG Z80
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 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
20
CHAPTER 2. ZILOG Z80
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
CHAPTER 2. ZILOG Z80
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, ($AA)
4 AND $F0
5 ADD A, C
6 OUT ($AA), A
7 EI
8 IN A, ($A9)
9 RET
You can assume that there never is an interrupt after the EI, before the IN A,($A9) - which
would be a problem because the MSX interrupt routine reads the keyboard too.
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.
22
CHAPTER 2. ZILOG Z80
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 3.12, page 119 for details on handling interrupts on ZX Spectrum Next.
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.
23
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.
24
Chapter 3
ZX Spectrum Next
25
With increased CPU speeds, more memory, better graphics, hardware sprites and tiles, to
mention just some of the most obvious, ZX Spectrum Next is an exciting platform for the retro
programmer.
This chapter represents the bulk of the book. Each topic is discussed in its own section. While
the sections are laid out in order - later sections sometimes rely on, or refer to the topics
discussed earlier, there’s no need to go through them in an orderly fashion. Each section should
be quite usable by itself as well. All topics discussed elsewhere are referenced, so you can quickly
jump there if needed. If using PDF you can click on the section number to go straight to
it. With a printed book though, turning the pages gives you a chance to land on something
unrelated, but equally interesting, thus learning something new almost by accident.
One more thing worth mentioning, before leaving you on to explore, are ports and Next registers.
You will find the full list in the next section. But that’s just a list with a couple of examples on
how to read and write them. Still, many ports and registers are described in detail at the end
of the sections in which they are first mentioned. Those registers that are relevant for multiple
topics are described in the first section they are mentioned in, and then referenced from other
sections. Additionally, each port and register that’s described in detail, has the reference to
that section in the list on the following pages as a convenience. I thought for a while about how
to approach this. One way would be to describe the ports and references in a single section,
together with their list, and then only reference them elsewhere. But ultimately decided on the
format described above for two reasons: descriptions are not comprehensive, only relevant ports
and registers have this “honour”. And secondly, I wanted to keep all relevant material as close
together as possible.
26
CHAPTER 3. ZX SPECTRUM NEXT
27
CHAPTER 3. ZX SPECTRUM NEXT
28
CHAPTER 3. ZX SPECTRUM NEXT
Specific features of the Next are controlled via these register numbers, accessed through ports
TBBlue Register Select $243B and TBBlue Register Access $253B (see page 34 for details).
All registers can also be written to directly with 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 (see section
3.10.4, page 115)
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 section 3.10.4, page
115)
RW $9 Sets scanlines, AY mono output, sprite-id lockstep, resets DivMMC mapram and
disables HDMI audio (see section 3.8.7, page 101)
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 (see section 3.3.12, page 60)
RW $12 Sets the bank number where Layer 2 video memory begins (see section 3.6.8, page
81)
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 section 3.7.6, page 89)
RW $16 Sets X pixel offset used for drawing Layer 2 graphics on the screen (see section
3.6.8, page 82)
RW $17 Sets Y offset used when drawing Layer 2 graphics on the screen (see section 3.6.8,
page 83)
RW $18 Sets and reads clip-window for Layer 2 (see section 3.6.8, page 83)
RW $19 Sets and reads clip-window for Sprites (see section 3.8.7, page 101)
RW $1A Sets and reads clip-window for ULA/LoRes layer
RW $1B Sets and reads clip-window for Tilemap (see section 3.7.6, page 89)
RW $1C Controls (resets) the clip-window registers indices (see section 3.6.8, page 83)
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
29
CHAPTER 3. ZX SPECTRUM NEXT
RW Port Description
RW $22 Controls the timing of raster interrupts and the ULA frame interrupt (see section
3.12.4, page 125)
RW $23 Holds the eight LSBs of the line on which a raster interrupt should occur (see
section 3.12.4, page 125)
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 section 3.7.6, page 90)
RW $30 Sets the pixel offset (eight low bits) used for drawing Tilemap graphics on the
screen (see section 3.7.6, page 90)
RW $31 Sets the pixel offset used for drawing Tilemap graphics on the screen (see section
3.7.6, page 90)
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 section 3.8.7, page 101)
-W $35 Writes directly into byte 1 of port $xx57 (see section 3.8.7, page 102)
-W $36 Writes directly into byte 2 of port $xx57 (see section 3.8.7, page 102)
-W $37 Writes directly into byte 3 of port $xx57 (see section 3.8.7, page 102)
-W $38 Writes directly into byte 4 of port $xx57 (see section 3.8.7, page 102)
-W $39 Writes directly into byte 5 of port $xx57 (see section 3.8.7, page 103)
RW $40 Chooses a palette element (index) to manipulate with (see section 3.4.5, page 63)
RW $41 Use to set/read 8-bit colours of the ULANext palette (see section 3.4.5, page 64)
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 section 3.4.5, page 65)
RW $44 Sets 9-bit (2-byte) colours of the Enhanced ULA palette, or to read second byte
of colour (see section 3.4.5, page 65)
30
CHAPTER 3. ZX SPECTRUM NEXT
RW Port Description
RW $4A 8-bit colour to be used when all layers contain transparent pixel (see section 3.4.5,
page 66)
RW $4B Index of transparent colour in sprite palette (see section 3.8.7, page 104)
RW $4C Index of transparent colour in Tilemap palette (see section 3.7.6, page 90)
RW $50 Selects the 8k-bank stored in 8k-slot 0 (see section 3.2.7, page 42)
RW $51 Selects the 8k-bank stored in 8k-slot 1 (see section 3.2.7, page 42)
RW $52 Selects the 8k-bank stored in 8k-slot 2 (see section 3.2.7, page 42)
RW $53 Selects the 8k-bank stored in 8k-slot 3 (see section 3.2.7, page 42)
RW $54 Selects the 8k-bank stored in 8k-slot 4 (see section 3.2.7, page 42)
RW $55 Selects the 8k-bank stored in 8k-slot 5 (see section 3.2.7, page 42)
RW $56 Selects the 8k-bank stored in 8k-slot 6 (see section 3.2.7, page 42)
RW $57 Selects the 8k-bank stored in 8k-slot 7 (see section 3.2.7, page 42)
-W $60 Used to upload code to the Copper (see section 3.9.4, page 109)
RW $61 Holds low byte of Copper control bits (see section 3.9.4, page 109)
RW $62 Holds high byte of Copper control flags (see section 3.9.4, page 109)
-W $63 Used to upload code to the Copper in 16-bit chunks (see section 3.9.4, page 109)
RW $64 Offset numbering of raster lines in copper/interrupt/active register (see section
3.12.4, page 125)
RW $68 Disable ULA, controls ULA mixing/blending, enable ULA+ (see section 3.7.6,
page 91)
RW $69 Layer2, ULA shadow, Timex $FF port (see section 3.6.8, page 84)
RW $6A LoRes Radastan mode
RW $6B Controls Tilemap mode (see section 3.7.6, page 91)
RW $6C Default tile attribute for 8-bit only maps (see section 3.7.6, page 92)
RW $6E Base address of the 40x32 or 80x32 tile map (see section 3.7.6, page 92)
RW $6F Base address of the tiles’ graphics (see section 3.7.6, page 92)
RW $70 Layer 2 resolution, palette offset (see section 3.6.8, page 84)
RW $71 Sets pixel offset for drawing Layer 2 graphics on the screen (see section 3.9.4, page
109)
-W $75 Same as register $35 plus increments $34 (see section 3.8.7, page 104)
-W $76 Same as register $36 plus increments $34 (see section 3.8.7, page 104)
-W $77 Same as register $37 plus increments $34 (see section 3.8.7, page 104)
-W $78 Same as register $38 plus increments $34 (see section 3.8.7, page 104)
-W $79 Same as register $39 plus increments $34 (see section 3.8.7, page 104)
RW $7F 8-bit storage for user
RW $80 Expansion bus enable/config
RW $81 Expansion bus controls
31
CHAPTER 3. ZX SPECTRUM NEXT
RW Port Description
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 section 3.11.3, page 118)
R- $B1 Read Next keyboard compound keys separately (see section 3.11.3, page 118)
RW $B2 DivMMC trap configuration
RW $B4 DivMMC trap configuration
RW $C0 Interrupt Control (see section 3.12.4, page 126)
RW $C2 NMI Return Address LSB (see section 3.12.4, page 126)
RW $C3 NMI Return Address MSB (see section 3.12.4, page 126)
RW $C4 Interrupt Enable 0 (see section 3.12.4, page 126)
RW $C5 Interrupt Enable 1 (see section 3.12.4, page 126)
RW $C6 Interrupt Enable 2 (see section 3.12.4, page 127)
RW $C8 Interrupt Status 0 (see section 3.12.4, page 127)
RW $C9 Interrupt Status 1 (see section 3.12.4, page 127)
RW $CA Interrupt Status 2 (see section 3.12.4, page 128)
RW $CC DMA Interrupt Enable 0 (see section 3.12.4, page 128)
RW $CD DMA Interrupt Enable 1 (see section 3.12.4, page 128)
RW $CE DMA Interrupt Enable 2 (see section 3.12.4, page 129)
-W $FF Turns debug LEDs on and off on TBBlue implementations that have them
32
CHAPTER 3. ZX SPECTRUM NEXT
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.
33
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 Next register $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 Next registers. So above examples could simply be changed to either:
The first example requires 24 t-states (7+17) while the second 20. So less than half compared
to using ports. 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 Next register $B0:
34
CHAPTER 3. ZX SPECTRUM NEXT
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”1 .
Next supports two interchangeable memory management models. One is inherited from the
original Spectrums and 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 out. In a way, slots are like windows into available memory.
Banks are selected by their number - the 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
35
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)
36
CHAPTER 3. ZX SPECTRUM NEXT
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)
Ports 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)
See page 41 for details on ports $7FFD and $DFFD. 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)
37
CHAPTER 3. ZX SPECTRUM NEXT
Ports involved:
+3 Memory Paging Control $1FFD bit 2 as LSB selects ROM bank for slot 0
Memory Paging Control $7FFD bit 4 forms MSB 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)
See page 41 for details on ports $1FFD, $7FFD and $DFFD. If you are using the standard interrupt
handler or OS routines, then any time you write to +3 Memory Paging Control $1FFD you
should also store the same value at $5B67 and any 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.
Ports involved:
+3 Memory Paging Control $1FFD bit 0 enables All-RAM (if 1) or normal mode (0)
+3 Memory Paging Control $1FFD bits 2-1 select memory configuration
See page 41 for details on port $1FFD. If you are using the standard interrupt handler or OS
routines, then any time you write to +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 Wiki2 or internet if interested.
2
https://wiki.specnext.dev/Next_Memory_Bank_Select
38
CHAPTER 3. ZX SPECTRUM NEXT
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. This is the only mode that allows paging in all
2048K on extended Next. It’s also the simplest to use - a single NEXTREG 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.
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 (see page 42 for details):
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:
39
CHAPTER 3. ZX SPECTRUM NEXT
Note: registers Memory Management Slot 0 Bank $50 and Memory Management Slot 1
Bank $51 (page 42) 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 expect to find interrupt handler at the address $0038.
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”, used for double-
buffering), using bit 3 of Memory Paging Control $7FFD (page 41). 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 3.5, page 67.
Layer 2 Paging
Layer 2 uses specific ports and registers that are can be used to change memory mapping. For
example, the bottom 16K slot can be set for write and read access. Layer 2 also supports a
double-buffering scheme of its own. Though any other mapping mode discussed here can be
used as well. See Layer 2 chapter, section 3.6, page 73 for more details.
40
CHAPTER 3. ZX SPECTRUM NEXT
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 below)
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
41
CHAPTER 3. ZX SPECTRUM NEXT
Bit Effect
7-0 Selects 8K bank stored in corresponding 8K slot
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.
42
CHAPTER 3. ZX SPECTRUM NEXT
3.3 DMA
The ZX Spectrum Next DMA (zxnDMA) is a single channel direct memory access device that
implements a subset of the Z80 DMA functionality. The subset is large enough to be compatible
with common uses of the similar Datagear interface available for standard ZX Spectrums but
without the idiosyncracies and requirements on the order of commands.
zxnDMA defines two “ports”, called “A” and “B” (port is just a word used for referring to both,
source and destination). Either one can be used as a source, the other as the destination. They
can be memory location or I/O port, auto-increment, auto-decrement or stay fixed. zxnDMA
can operate in continuous or burst mode and implements a special feature that can force each
byte transfer to take a fixed amount of time, which can be used to deliver sampled audio.
3.3.1 Programming
Since core 3.1.2, zxnDMA is mapped to zxnDMA Port $xx6B and legacy Zilog DMA to MB02
DMA Port $xx0B (see page 60 for details).
Similar to Z80 DMA, zxnDMA also has 7 write registers named WR0-WR6. Some of the bits are
used to identify a register, while the rest represent the payload (x in the table below):
43
CHAPTER 3. ZX SPECTRUM NEXT
DMA Mode
WR1 0 0 Do not use!
0 1 Continuous Mode
7 6 5 4 3 2 1 0 1 0 Burst Mode
Base Register Byte
0 1 0 0 1 1 Do not use!
44
CHAPTER 3. ZX SPECTRUM NEXT
WR0 specifies the direction of the transfer, the length of the data that will be transferred and
port A address. Base register byte can be followed by up to four parameter bytes:
7 6 5 4 3 2 1 0
Base Register Byte
0
Operation
0 0 Do not use! (Reserved for WR1 and WR2)
3 =1
4 =1
0 1 Transfer
5 =1
6 =1
Transfer Direction
0 Port BÑA
1 Port AÑB
PARAMETERS
Bits 1-0: The combination of these two bits defines the type of operation the DMA program
Operation will use. While all four combinations are listed, zxnDMA only supports one at
the moment - 01:
00 Don’t use, it conflicts with WR1 and WR2.
01 Transfer; this is the only supported operation on zxnDMA.
10 Not recommended for compatibility reasons: at the moment 10 behaves
exactly like 01 (transfer) on zxnDMA, but on Z80 it’s “search” instead. So
there is a possibility this will change in future cores.
11 Similar to 10; at the moment it behaves like 01 (transfer) on zxnDMA, but
on Z80 it’s “search/transfer”. Again, this may change in future cores.
Bit 2: Provides the destination of the data transfer:
Transfer 0 Port B is source, port A destination.
Direction
1 Port A is source, port B destination.
Either port can act as source, while the other becomes the destination.
Bits 4-3: Regardless of whether port A acts as a source or destination, we have to define
Port A its source address. To do so, set both bits to 1. The address is then entered
Starting
immediately after this byte. The address is interpreted either as memory or I/O
Address
port, based on the configuration from WR1.
Bits 6-5: All DMA operations must have a length defined. Therefore this parameter is
Transfer also required - set both bits to 1. The length is a 16-bit value and needs to be
Length entered at the end of the data for WR0 register.
45
CHAPTER 3. ZX SPECTRUM NEXT
If bit 3 of the base register byte is set, then LSB of port A starting address is expected as the
first parameter after the base. If bit 4 is set, then MSB byte is expected. If both bits are set,
then LSB needs to be written first, followed by MSB. This is in fact the most common setup
because port A starting address is required for each DMA operation. And since little-endian
format is used, the value forming the 16-bit starting address of port A can be written directly.
For example:
Whether the address represents a memory location or I/O port is defined with WR1.
Transfer Length
Setting bit 5 of the base register byte is associated with LSB of transfer length and bit 6 with
MSB. If both bits are set, which is the usual case, then LSB is written first, followed by MSB.
Again, 16-bit length can be written directly in this case, as shown above with port A starting
address.
Notes
Since all parameters in WR0 are important for DMA transfer, they are typically always included.
The configuration would most often look something like this:
Usually, the address and length are provided dynamically, and frequently “self-modifying code”
approach is used to fill this data on the fly. We’ll discuss this in the example section later on.
46
CHAPTER 3. ZX SPECTRUM NEXT
This is where we provide details about port A. Base register byte may be followed by one
parameter, if bit 6 of the base byte is set:
7 6 5 4 3 2 1 0
Base Register Byte
0 1 0 0
Port A Source
6 =1
0 Port A is Memory
1 Port A is I/O
Port A Address Handling
REGISTER
7 6 5 4 3 2 1 0
+1 byte Port A Timing
0 0 0 0 0 0
Bit 3: Specifies the type of the address for port A (the address is written with WR0):
Port A Source
0 Port A address is memory location.
1 Port A address is I/O port.
Bits 5-4: The combination of these two bits determines how port A address will be handled
Port A after each byte is transferred:
Address
Handling 00 Address is decremented after byte is transferred.
01 Address is incremented after byte is transferred.
10 The address remains fixed at its starting value. This is typically used when
port A is an I/O port; all bytes are sent to the same port in this case.
11 The same as 10, address is fixed.
In case of decrementing or incrementing, the first byte is read from or written
to the starting address for port A from WR0, then decrementing or incrementing
begins for the second and subsequent bytes.
Bit 6: If bit 6 is set, the next byte written to the DMA after WR1 base register byte is
Port A used to define port A variable timing. If bit 6 is 0, standard Z80 timing for read
Timing and write cycles is used.
47
CHAPTER 3. ZX SPECTRUM NEXT
Port A Timing
This byte is expected if bit 6 of the base register byte is set. Only bits 1 and 0 are used, the
rest must be set to 0.
Bits 1-0: Specifies variable timing configuration for port A that allows shortening the
Port A length of port A read or write cycles:
Timing
00 Cycle length is 4.
01 Cycle length is 3.
10 Cycle length is 2.
11 Do not use!
The cycle lengths are intended to selectively slow down read or write cycles for
hardware that can’t operate at the DMA full speed.
In contrast with Z80 DMA, zxnDMA doesn’t support half-cycle timing for control signals.
48
CHAPTER 3. ZX SPECTRUM NEXT
This register is similar to WR1 except it sets the configuration for port B. If bit 6 is set, base
register byte needs to be followed by one parameter. And the configuration of this parameter
may in turn require one more parameter byte to be appended.
7 6 5 4 3 2 1 0
Base Register Byte
0 0 0 0
Port B source
6 =1
0 Port B is Memory
1 Port B is I/O
Port B Address Handling
REGISTER
7 6 5 4 3 2 1 0
+1 byte Port B Timing
0 0 0 0 0
5 =1
Bit 3: Specifies the type of the address for port B (the address is written with WR4):
Port B
0 Port B address is memory location.
Source
1 Port B address is I/O port.
Bits 5-4: The combination of the two bits determines how port B address will be handled
Port B after each byte is transferred:
Address
Handling 00 Address is decremented after byte is transferred.
01 Address is incremented after byte is transferred.
10 The address remains fixed at its starting value. This is typically used when
port B is an I/O port; all bytes are sent to the same port in this case.
11 The same as 10, address is fixed.
In case of decrementing or incrementing, the first byte is read from or written
to the starting address for port B from WR4, then decrementing or incrementing
begins for the second and subsequent bytes.
Bit 6: If bit 6 is set, the next byte written to the DMA after WR2 base register byte is
Port B used to define port B variable timing. If bit 6 is 0, standard Z80 timing for read
Timing
and write cycles is used.
49
CHAPTER 3. ZX SPECTRUM NEXT
Port B Timing
This byte is expected if bit 6 of the base register byte is set. Only bits 5, 1 and 0 are used, the
rest must be set to 0.
Bits 1-0: Specifies variable timing configuration for port A that allows shortening the
Port A length of port A read or write cycles:
Timing
00 Cycle length is 4.
01 Cycle length is 3.
10 Cycle length is 2.
11 Do not use!
The cycle lengths are intended to selectively slow down read or write cycles for
hardware that can’t operate at the DMA full speed.
Bit 5: If set, then additional byte is expected with prescalar value used for fixed time
Enable transfers. See below for details.
Prescalar
In contrast with Z80 DMA, zxnDMA doesn’t support half-cycle timing for control signals.
This byte is expected if bit 5 of “Port B Timing” is set. This is a feature of zxnDMA not present
in Z80. If non-zero value is written, a delay will be inserted after each byte is transferred. The
delay is calculated so that the total amount of time for each byte, including time required for
actual transfer, is determined by the prescalar value.
To calculate prescalar value, use formula: prescalar 875kHz {rate where rate is desired
frequency. For example to have a constant rate of 16kHz, prescalar needs to be set to 55
(calculation gives 54.6875 which needs to be rounded). The constant 875kHz is assumed for
28MHz system clock. But exact system clock depends on video timing selected by user (HDMI,
VGA). The actual value should therefore be adjusted according to exact frequency as described
with Video Timing $11 (page 60).
Fixed time transfer works in continuous and burst mode (see WR4). In burst mode, DMA will
give up any waiting time to the CPU so it can run while DMA is idle.
50
CHAPTER 3. ZX SPECTRUM NEXT
Activation
0 DMA Disabled
1 DMA Enabled
Bit 6: If set, DMA will be enabled, otherwise disabled. DMA should be enabled only
Enable after all other bytes are written.
DMA
Note: while enabling/disabling through WR3 works on Next, it’s recommended to
use WR6 instead.
Another register where zxnDMA uses only a small portion of functionality from Z80 DMA:
7 6 5 4 3 2 1 0
Base Register Byte
1 0 0 1
2 =1
3 =1
DMA Mode
REGISTER
Bits 3-2: Similar to bits 4-3 of WR0, these two bits indicate that port B address will follow.
Port B Bit 3 enables LSB and bit 2 MSB of the address. Each byte can be enabled
Starting separately, though most commonly, both are used. The address is interpreted
Address
either as memory or I/O port, based on the configuration from WR2.
Bits 6-5: Specifes operating mode for DMA:
DMA Mode
00 Not recommended for compatibility reasons: at the moment 00 behaves
exactly like 01 (continuous mode) on zxnDMA, but on Z80 it’s “byte” mode.
So there is a possibility this will change in future cores.
51
CHAPTER 3. ZX SPECTRUM NEXT
01 Continuous mode. When the CPU starts DMA, it will run to completion
without allowing the CPU to run. The CPU will only execute the next
instruction after DMA completes.
10 Burst mode. In this mode, DMA will let the CPU run if either port is not
ready. With zxnDMA, this condition can only occur when operating in
fixed time transfer mode, as described with WR2.
11 Do not use!
This works exactly the same as port A starting address in bits 4-3 of WR0, but for port B. Bit 3
of base register enables LSB and bit 4 MSB of the port B address. If both are set, then LSB is
written before MSB. As port B address is also required for each DMA operation, both bytes are
usually provided. And because the 16-bit value uses little-endian notation, it can be written
directly. For example:
Whether the address represents memory or I/O port is defined with WR2.
7 6 5 4 3 2 1 0
Base Register Byte
1 0 0 0 1 0
Ready Configuration
0 CE only
1 CE and WAIT multiplexed
Stop Configuration
0 Stop on End of Block
1 Auto Restart on End of Block
Bit 4: 0 CE/WAIT line functions only as chip enable line, allowing CPU to read and
Ready write control and status bytes when DMA is not owning the bus.
Configuration
1 This mode is implemented but currently not used in zxnDMA. This mode
has an external device using the DMA’s CE pin to insert wait states during
the DMA’s transfer.
Bit 5: Specifies what happens when DMA reaches the end of the block:
Stop
Configuration 0 DMA stops once the end of the block is reached.
1 DMA will auto repeat at the end of the block.
52
CHAPTER 3. ZX SPECTRUM NEXT
This register is the most complex, but usually only a small subset of functionality is needed:
7 6 5 4 3 2 1 0
Base Register Byte
1 1 1
Command
0 0 0 0 1 $87 Enable DMA
0 0 0 0 0 $83 Disable DMA
0 0 0 1 0 $8B Reinitialize Status Byte
0 1 0 0 1 $A7 Initialize Read Sequence
0 1 1 0 0 $B3 Force Ready (irrelevant for zxnDMA)
0 1 1 1 0 $BB Read Mask Follows (see below)
0 1 1 1 1 $BF Read Status Byte
1 0 0 0 0 $C3 Reset
$C7
REGISTER
7 6 5 4 3 2 1 0
+1 byte Read Mask
1
READ FROM DMA I/O PORT
Status
Byte Counter LSB (MSB in core 3.0.5 - bug)
Byte Counter MSB (LSB in core 3.0.5 - bug)
Port A Address LSB
Port A Address MSB
Port B Address LSB
Port B Address MSB
WR6 uses a slightly different configuration than other registers. Bits 7, 1 and 0 are always set
while bits 6-2 are used together to specify the command to execute. Only a subset of possbible
bit combinations are implemented. Some of the most relevant ones:
Enable DMA This should be written as the last command of the DMA program to start
executing.
Disable DMA It’s recommended to use this command at the start to ensure the whole program
will be written before executing.
Load This is required for DMA to copy port A and B addresses into its internal
pointers. Usually, this is used just before Enable DMA.
53
CHAPTER 3. ZX SPECTRUM NEXT
Read Mask This is not one of the frequently used commands, but it’s mentioned because
it works differently: instead of indicating parameter bytes that will follow the
register as part of the DMA program, it specifies which bytes will be read from
the DMA port in the “future”. See below for more details.
Read Mask
This parameter provides a bit mask that defines which bytes will be read from DMA. While
read mask parameter byte has to be written immediately after base register byte, as any other
parameter, reading happens separately as I/O read from the DMA port.
Bit 0: Indicates that the status byte will be read from the DMA I/O port. Status byte
Status has the following format: 00E1101T where:
E is 0 if the total block length was transferred at least once, 1 otherwise.
T is 0 if no byte transferred yet, 1 if at least one byte was transferred.
Bits 1-2: Indicates that the 16-bit number of bytes transferred so far will be read from
Byte Counter the DMA I/O port. Bit 1 indicates read for LSB and bit 2 for MSB of the value
(note: core 3.0.5 has a bug that reverses the bytes, so bit 1 indicates read for
MSB and bit 2 for LSB).
Bits 3-4: Indicates that the current internal 16-bit port A address will be read from the
Port A I/O port. Bit 3 indicates LSB and bit 4 MSB of the value will be read. Usually
Address the address it read as the whole 16-bit value, so both bits are set.
Bits 5-6: Similar to bits 3-4 above; indicates that the current internal 16-bit port B address
Port B will be read from the I/O port. Bit 3 indicates LSB and bit 4 MSB of the value
Address
will be read.
Registers can be read via an I/O read from the DMA port $6B after setting the read mask.
Register values are the current internal DMA values. Or in other words: the values that will be
used for the next transfer operation. Once the end of the read mask is reached, further reads
loop around to the first one.
3.3.10 Examples
DMA is another subject that may sound quite complicated when attempting to explain, but is
really quite straighforward in practice. As you’ll see in the following pages, most programs can
use the same pattern with only slight changes. You can also find use of DMA to transfer data
in various projects in companion code, for example sprites and copper.
54
CHAPTER 3. ZX SPECTRUM NEXT
Source is at memory address $C000, destination $D000, size 2048 bytes. We’ll use port A as
source, B as destination.
1 CopyMemory:
2 LD HL, .dmaProgram ; HL = pointer to DMA program
3 LD B, .dmaProgramSize; B = size of the code
4 LD C, $6B ; C = $6B (zxnDMA port)
5 OTIR ; upload DMA program
6 RET
7
8 .dmaProgram:
9 DB %1’00000’11 ; WR6 - disable DMA
10
The code includes both, the routine that copies the program into DMA memory and the program
itself.
Copy routine relies on OTIR to upload the program to DMA memory through port $xx6B. OTIR
does all the heavy lifting for us - continuously copies bytes until B becomes 0. Perhaps worth
noting: .dmaProgramSize is used to establish the length of the program that will be sent. This
way we can safely add or remove instructions and it will continue to work (as long as the size
stays within 256 bytes).
The program itself, lines 9-25, should be self-explanatory. But we’ll go through it anyway since
this is how most DMA programs look like:
Line 9 uses WR6 with bits 6-2 set to %00000 which corresponds to command “Disable
DMA”. It’s good practice to disable DMA before uploading the rest of the program.
Next comes WR0 register in line 11; from least to most significant:
– Bits 1-0 have the value %01, so “transfer” operation will be used. On zxnDMA this
is the only allowed combination anyway.
55
CHAPTER 3. ZX SPECTRUM NEXT
12 DB $00
13 DB $C0 ; $C000
14 DB $00
15 DB $08 ; $0800 (=2048)
Line 15 specifies the configuration for port A with WR1 and line 17 for port B with WR2.
Both use the same:
– Bit 3 is 0 meaning port is memory.
– Bits 5-4 are %01 so address will increment after each byte.
– Bit 6 is 0 so we use default cycle length.
Next comes WR4 in line 19 with which we specify additional configuration for port B:
– Bits 3-2 are set, therefore both bytes of port B address are expected after the register.
– Bits 6-5 are %01 therefore DMA will run the program in continuous mode.
16-bit port B starting address follows in line 20.
Line 22 has WR5 register with bit 4 and 5 reset. Bit 4 tells DMA to use CE only and bit 5
to stop at the end of the block, after all bytes are transferred.
Line 24 uses WR6 with bits 6-2 set to %10011 which tells DMA to load source and destination
addresses into its own internal pointers. This command must always be included before
the end of the program, otherwise DMA internal pointers may point to old values.
And finally, once everything is configured, line 25 includes another WR6 with bits 6-2 set
to %00001. This corresponds to “Enable DMA”. After encountering this command, DMA
will start running the program.
Note the use of apostrophes to delimit bits. This is special syntax for binary values, sjasmplus
will strip them out, so %1’00000’11 will become %10000011 for example. I used it to emphasize
individual bits and bit groups. You can use whichever you prefer though.
Perhaps one more thing: the dot in front of .dmaProgram and .dmaProgramSize labels makes
them private within last “normal” label (CopyMemory in our case). This is nice if your editor
supports code completion; it will not offer these labels outside this scope.
56
CHAPTER 3. ZX SPECTRUM NEXT
Source is at memory address $9000, destination is port $5B, size 16384 bytes. We’ll use port A
as source, B as destination.
1 CopyMemory:
2 LD HL, .dmaProgram ; HL = pointer to DMA program
3 LD B, .dmaProgramSize; B = size of the code
4 LD C, $6B ; C = $6B (zxnDMA port)
5 OTIR ; upload DMA program
6 RET
7
8 .dmaProgram:
9 DB %1’00000’11 ; WR6 - disable DMA
10
Apart from the obvious differences - source and destination addresses and size in lines 12, 13
and 20, the program is almost the same as before.
The only other difference is port B setup in line 17. Because we’re sending the bytes to an I/O
port, which exists on a specific address and doesn’t change, we need to tweak WR2 register data:
Bit 3 is now set to indicate port B is an I/O port.
Bits 5-4 are %10 to indicate port B address is fixed.
With this change, port B address will remain fixed at the given value of $5B throughout the
whole transfer, while port A address will be incremented after each byte.
While the result is quite different, the two programs share a lot of similarities. Even more so if
we want to use this program multiple times, for transferring data to the same port but from
another memory address or of a different size. As it stands now, we’d have to repeat the above
program, only replace port A source and transfer length in lines 12-13.
Well, we can use a neat trick to have a reusable DMA program and pass in the address and
length as parameters! And it’s right on the next page for easy comparison.
57
CHAPTER 3. ZX SPECTRUM NEXT
The routine gets the address of the source memory through HL and length in BC register pair:
1 CopyMemory:
2 LD (.dmaPortAAddress), HL ; modify program with actual address
3 LD (.dmaTransferLength), BC ; modify program with actual length
4
11 .dmaProgram:
12 DB %1’00000’11 ; WR6 - disable DMA
13
DMA program is exactly the same, except for the two WR0 parameters.
The labels in lines 15 and 17 are the first part of the puzzle. They are used to get the exact
memory address of the first byte of the 16-bit value declared with DW 0. Lines 2 and 3 are
where the magic happens. We take the address from the labels and load the value from the
corresponding register pair over it.
That’s all there is to it. This is one of the most frequent implementations of DMA routines, you
likely saw it in various code listings.
The technique is called “self-modifying code”, for obvious reasons: we are modifying the program
loaded into memory. It’s a useful trick to keep in our bag, and this is just one of the simplest
implementations. However, we should take care - it’s very easy to modify wrong parts which
can lead to all sorts of issues. So use with care!
58
CHAPTER 3. ZX SPECTRUM NEXT
3.3.11 Miscellaneous
Operating Speed
When zxnDMA controls the bus (when transfer is in progress), Z80 can’t respond to interrupts.
Here’s detailed explanation from Next Dev Wiki4 :
On the Z80, the NMI interrupt is edge triggered so if an NMI occurs the fact that it
occurred is stored internally in the Z80 so that it will respond when it is woken up.
On the other hand, maskable interrupts are level triggered. That is, the Z80 must
be active to regularly sample the INT line to determine if a maskable interrupt is
occurring. On the Spectrum and the ZX Next, the ULA (and line interrupt) are only
asserted for a fixed amount of time, 30 cycles at 3.5MHz. If the DMA is executing
a transfer while the interrupt is asserted, the CPU will not be able to see this and it
will most likely miss the interrupt.
However, when operating in burst mode, with large enough prescalar, the CPU will be able to
respond to interrupts.
It’s also possible to allow or prevent specific interrupters from interrupting DMA using Next
specific Hardware IM2 mode. This is configured with Next registers DMA Interrupt Enable 0
$CC, DMA Interrupt Enable 1 $CD and DMA Interrupt Enable 2 $CE (pages 128-129). See
section 3.12, page 119 for more details on interrupts.
3
https://wiki.specnext.dev/DMA#Operating_speed
4
https://wiki.specnext.dev/DMA#The_DMA_and_Interrupts
59
CHAPTER 3. ZX SPECTRUM NEXT
Core 3.1.2+: Always in Zilog DMA mode for uploading legacy DMA programs. For zxnDMA,
use zxnDMA Port $xx6B.
Older cores: this port is not supported, set bit 6 of Peripheral 2 $06 (page 115) and use
zxnDMA Port $xx6B.
Core 3.1.2+: Always in zxnDMA mode. For legacy Zilog DMA, use MB02 DMA Port $xx0B.
Older cores: this port behaves either in zxnDMA or legacy Zilog DMA mode based on bit 6 of
Peripheral 2 $06 (page 115): if bit 6 is 0, zxnDMA mode is enabled, otherwise Zilog DMA.
Peripheral 2 $06
See description under Sound, section 3.10.4, page 115.
Bit Effect
7-3 Reserved, must be 0
2-0 Video signal timing variant
000 clk28=28000000 Base VGA timing
001 clk28=28571429 VGA setting 1
010 clk28=29464286 VGA setting 2
011 clk28=30000000 VGA setting 3
100 clk28=31000000 VGA setting 4
101 clk28=32000000 VGA setting 5
110 clk28=33000000 VGA setting 6
111 clk28=27000000 HDMI
60
CHAPTER 3. ZX SPECTRUM NEXT
3.4 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. Next shares
implementation to other contemporary 8-bit computers - 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.
Each graphics mode or 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 $43 (page 65) for ULA, Layer 2 and Sprites
and Tilemap Control $6B (page 91) for Tilemap.
Next palettes have 256 colours. All are initialized with default values, so they are usable out of
the box. But it’s also possible to change every colour. Regardless of the palette, the procedure
to read or write colours is:
1. Enhanced ULA Control $43 (page 65) selects palette which colours you want to edit
2. Palette Index $40 (page 63) selects colour index that will be read or written
3. Palette Value $41 (page 64) or Enhanced ULA Palette Extension $44 (page 65) 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 $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 $41 for 8-bit and Enhanced ULA Palette Extension
$44 for 9-bit.
Note: Enhanced ULA Control $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 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.
61
CHAPTER 3. ZX SPECTRUM NEXT
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 $41 (page 64) 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
1 NEXTREG $43, %00010000 ; Auto increment, Layer 2 first palette for read/write
2 NEXTREG $40, 0 ; Start copying into index 0
3 LD HL, palette ; Address to copy RRRGGGBB values from
4 LD B, 255 ; Copy 255 colours
5 CALL Copy8BitPalette
Note: we could also use DMA to transfer all the bytes. I won’t show it here, but feel free to
implement it as an excercise - see section 3.3 for details on programming the DMA.
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 (page 65) 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 remaining byte with LSB of B component 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 code for calling this subroutine is exactly the same as for the 8-bit colours
above.
62
CHAPTER 3. ZX SPECTRUM NEXT
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 $41 or Enhanced
ULA Palette Extension $44 (page 65) of currently selected pallette in Enhanced ULA Control
$43 (page 65). Write also resets value of Enhanced ULA Palette Extension $44 (page 65) 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 $4A (page 66).
63
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 $40, if auto-increment is
enabled in Enhanced ULA Control $43 (page 65). 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 $43 (page 65)). 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 $4A (page 66)
Default value is 7 for core 3.0 and later, 15 for older cores.
64
CHAPTER 3. ZX SPECTRUM NEXT
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 $15 (page 89). 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 the second write palette colour index in Palette Index $40 (page 63) is automatically
increment, if auto-increment is enabled in Enhanced ULA Control $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 $41 (page 64).
65
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 (page 64).
66
CHAPTER 3. ZX SPECTRUM NEXT
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:
67
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
68
CHAPTER 3. ZX SPECTRUM NEXT
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
69
CHAPTER 3. ZX SPECTRUM NEXT
3.5.3 Border
Next inherits Spectrum border colour handling through ULA Control Port Write $xxFE (page
71). 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 (page 41). 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 (page 41) 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 3.2, page 35. 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.
70
CHAPTER 3. ZX SPECTRUM NEXT
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 read with certain high byte values, ULA Control Port Read $xxFE will read
keyboard status. See Keyboard, section 3.11.3, page 118 for details.
71
CHAPTER 3. ZX SPECTRUM NEXT
72
CHAPTER 3. ZX SPECTRUM NEXT
3.6 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.6.1 Initialization
Drawing on Layer 2 is much simpler than ULA. 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 (page 81).
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 $70 (page 84). In this case you will
also have to set up clip window correctly with Clip Window Layer 2 $18 (page 83).
3.6.2 Paging
After Layer 2 is enabled, we can start writing into memory banks. As mentioned, Layer 2
requires 3-5 contiguous 16K banks. Upon boot, Next assigns it 16K banks 8-10. However, that
gets modified by NextZXOS to 9-11 soon afterwards. You can use this configuration, but it’s a
good idea to set it up manually to future proof our programs.
There are two pieces to the “puzzle” of Layer 2 paging: first, we need to tell the hardware which
banks are used. Since banks are always contiguous we only need to write the starting 16K bank
number into Layer 2 RAM Page $12 (page 81). Then we need to swap the banks into one or
more slots to write or read the data. Any supported mode can be used for paging, as described
in section 3.2, page 35. But the recommended and simplest is MMU mode. It’s recommended
to only use 16K banks 9 or greater for Layer 2.
16K slot 3 ($C000-$FFFF, MMU7 and 8) is typically used for Layer 2 banks. But any other
slot will work. You can use MMU registers to swap banks. Alternatively Layer 2 Access Port
$123B (page 81) also allows setting up paging for Layer 2. Either way, make sure paging is reset
before passing control back from Layer 2 handling code.
5
Core 3.0.6+ only
73
CHAPTER 3. ZX SPECTRUM NEXT
Similar to ULA, Layer 2 can also be set up to use a double-buffering scheme. Layer 2 RAM
Shadow Page $13 (page 82) defines starting 16K bank number for “shadow screen” (back
buffer) in this case. This is mainly used when paging is set up through Layer 2 Access Port
$123B (page 81); bit 3 is used to switch configuration between normal and shadow banks. Or
we can use MMU registers instead. If we track shadow banks manually, we don’t have to use
register $13 at all. We still need to assign starting shadow screen bank to register Layer 2
RAM Page $12 (page 81) in order to make it visible on screen.
3.6.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 $43 (page 65) is used to select active
palette. See Palette chapter 3.4, page 61 for details on how to program palettes.
See specific modes in the following pages for examples of writing pixel data.
3.6.4 Effects
Sprite and Layers System $15 (page 89) can be used to change Layer 2 priority, effectively
moving Layer 2 above or below other layers - see Tilemap chapter, section 3.7.6, page 89 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 (page 65) (9-bit colours). See description under Palette chapter,
section 3.4, page 61 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 $14 (page 82) register 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 registers Layer 2 X Offset MSB
$71 (page 84), Layer 2 X Offset $16 (page 82) and Layer 2 Y Offset $17 (page 83).
74
CHAPTER 3. ZX SPECTRUM NEXT
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 = 9
2 START_8K_BANK = 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 (3 MSBs = bank number)
18 RLCA ; 21000003
75
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 to slot 6 ($C000-$DFFF)
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.
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.
You can find fully working example in companion code on GitHub in folder layer2-256x192.
76
CHAPTER 3. ZX SPECTRUM NEXT
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-8 7-0
16 15 14 13 12-8 7-0
X8 X70 Y
255
16K X50 Y
16K bank contains 64 columns 8K X40 Y
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 $70 (page 84). We must
also not forget to set clip window correctly with Clip Window Layer 2 $18 (page 83) and Clip
Window Control $1C (page 83), as demonstrated in example below:
1 START_16K_BANK = 9
2 START_8K_BANK = START_16K_BANK*2
3
4 RESOLUTION_X = 320
5 RESOLUTION_Y = 256
6
7 BANK_8K_SIZE = 8192
8 NUM_BANKS = RESOLUTION_X * RESOLUTION_Y / BANK_8K_SIZE
9 BANK_X = BANK_8K_SIZE / RESOLUTION_Y
77
CHAPTER 3. ZX SPECTRUM NEXT
10
11 ; Enable Layer 2
12 LD BC, $123B
13 LD A, 2
14 OUT (C), A
15
You can find fully working example in companion code on GitHub in folder layer2-320x256.
78
CHAPTER 3. ZX SPECTRUM NEXT
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-8 7-0
16 15 14 13 12-8 7-0
X8 X70 Y
255
16K X50 Y
16K bank contains 128 columns 8K X40 Y
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. Therefore
division by 2 should be used to convert screen coordinate to X for address, multiplication by 2
for the other way around.
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 320256. 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 $70 (page 84). We must
also not forget to set clip window correctly with Clip Window Layer 2 $18 (page 83) and Clip
Window Control $1C (page 83), as demonstrated in example below:
1 START_16K_BANK = 9
2 START_8K_BANK = START_16K_BANK*2
3
4 RESOLUTION_X = 640
5 RESOLUTION_Y = 256
6
7 BANK_8K_SIZE = 8192
79
CHAPTER 3. ZX SPECTRUM NEXT
11 ; Enable Layer 2
12 LD BC, $123B
13 LD A, 2
14 OUT (C), A
15
You can find fully working example in companion code on GitHub in folder layer2-640x256.
80
CHAPTER 3. ZX SPECTRUM NEXT
Bit Effect
7-6 Video RAM bank select
00 First 16K of layer 2 in the bottom 16K slot
01 Second 16K of layer 2 in the bottom 16K slot
10 Third 16K of layer 2 in the bottom 16K slot
11 First 48K of layer 2 in the bottom 48K - 16K slots 0-2 (core 3.0+)
5 Reserved, use 0
4 0 (see below)
3 Use Shadow Layer 2 for paging
0 Map Layer 2 RAM Page $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
81
CHAPTER 3. ZX SPECTRUM NEXT
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.
Changes to this registers are immediately visible on screen.
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.
Bit Effect
7 Reserved, must be 0
6-0 Starting 16K bank of Layer 2 shadow screen
Similar to Layer 2 RAM Page $12 except this register sets up starting 16K bank for Layer 2
shadow screen. The other difference is that changes to this registers are not immediately visible
on screen.
Note: this register doesn’t affect the shadow screen in any way besides when bit 3 is set in
Layer 2 Access Port $123B. We can circumvent it completely if a manual paging scheme is
used to swap banks for reading and writing.
Bit Effect
7-0 Sets index of transparent colour for Layer 2, ULA and LoRes pixel data ($E3 after
reset).
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 $71 (page 84) to set it up.
82
CHAPTER 3. ZX SPECTRUM NEXT
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 $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
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
83
CHAPTER 3. ZX SPECTRUM NEXT
Bit Effect
7 1 to enable Layer 2 (alias for bit 1 in Layer 2 Access Port $123B, page 81)
6 1 to enable ULA shadow display (alias for bit 3 in Memory Paging Control $7FFD,
page 41)
5-0 Alias for bits 5-0 in Timex Sinclair Video Mode Control $xxFF
ULA shadow screen from Bank 7 has higher priority than Timex modes.
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 $16 (page
82) full 319 pixels offsets are available. For 640256 only 2 pixel offsets are possible.
84
CHAPTER 3. ZX SPECTRUM NEXT
3.7 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 $6B (page 91).
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 $6F (page 92).
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.
Tile Index 8-bit tile index within the tile definitions.
85
CHAPTER 3. ZX SPECTRUM NEXT
However, it’s possible to eliminate attributes byte by setting bit 5 in Tilemap Control $6B
(page 91). 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 $6C (page 92).
The offset of the tilemap data memory address relative to the start of bank 5 needs to be
specified with Tilemap Base Address $6E (page 92).
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 $6E and Tile Definitions Base Address $6F registers (page
92) 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.
86
CHAPTER 3. ZX SPECTRUM NEXT
3.7.5 Examples
Using tilemaps is very simple. The most challenging part of my experience was finding a drawing
program that would export to required formats in full. In my experience, Next Graphics6 is
the most feature-complete application for generating data for the Next. It takes images from
your preferred editor and converts them into a format that can be easily consumed by Next
hardware. It supports many different configurations too.
Alternatively, Remy’s Sprite, Tile and Palette editor website7 is the readily available editor and
exporter. However, at the time of this writing, export is limited.
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 = $-tilemap
4
5 tiles:
6 INCBIN "tiles.spr"
7 tilesLength = $-tiles
8
9 palette:
10 INCBIN "tiles.pal"
11 paletteLength = $-palette
1 START_OF_BANK_5 = $4000
2 START_OF_TILEMAP = $6000 ; Just after ULA attributes and system vars
3 START_OF_TILES = $6600 ; Just after 40x32 tilemap
4
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://github.com/infromthecold/Next-Graphics
7
https://zx.remysharp.com/sprites/
87
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 straightfor-
ward 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
You can find fully working example in companion code on GitHub in folder tilemap.
88
CHAPTER 3. ZX SPECTRUM NEXT
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 $1C (page
83), then write all 4 coordinates in succession.
89
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 $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 $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.
90
CHAPTER 3. ZX SPECTRUM NEXT
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 $15 (page 89) 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 $14 (page 82) colour, not against the
four-bit tilemap colour index.
91
CHAPTER 3. ZX SPECTRUM NEXT
If single byte tilemap mode is selected (bit 5 of Tilemap Control $6B), 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
92
CHAPTER 3. ZX SPECTRUM NEXT
3.8 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.8.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, the most feature-complete application for
converting images to sprite data in my experience is Next Graphics8 . It takes images from
your preferred editor and converts them into a format that can be easily consumed by Next
hardware. Other options I found are UDGeed-Next9 or Remy’s Sprite, Tile and Palette editor10 .
In contrast to Next Graphics, the latter two are not just exporters but also editors and share
very similar feature sets. So try them out and decide for yourself.
3.8.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
8
https://github.com/infromthecold/Next-Graphics
9
http://zxbasic.uk/files/UDGeedNext-current.rar
10
https://zx.remysharp.com/sprites/
93
CHAPTER 3. ZX SPECTRUM NEXT
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 $15 (page 89). It’s also
possible to further restrict sprite visibility within provided clip window using Clip Window
Sprites $19 (page 101).
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.8.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 $43 (page 65)) 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 $4B (page 104).
94
CHAPTER 3. ZX SPECTRUM NEXT
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.
95
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.8.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 (details on page 100) 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 ports and
registers section 3.8.7, page 100 for a description of individual bytes:
3.8.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
fully working example in companion code on GitHub in folder sprites. Besides demonstrating
anchor and relative sprites, it also includes some very crude animations as a bonus.
96
CHAPTER 3. ZX SPECTRUM NEXT
Before we can use sprites, we need to load their data into FPGA memory. This example
introduces a generic routine that uses DMA11 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 (.dmaSource), HL ; Copy sprite sheet address from HL
3 LD (.dmaLength), BC ; Copy length in bytes from BC
4 LD BC, $303B ; Prepare port for sprite index
5 OUT (C), A ; Load index of first sprite
6 LD HL, .dmaProgram ; Setup source for OTIR
7 LD B, .dmaProgramLength ; Setup length for OTIR
8 LD C, $6B ; Setup DMA port
9 OTIR ; Invoke DMA code
10 RET
11 .dmaProgram:
12 DB %10000011 ; WR6 - Disable DMA
13 DB %01111101 ; WR0 - append length + port A address, A->B
14 .dmaSource:
15 DW 0 ; WR0 par 1&2 - port A start address
16 .dmaLength:
17 DW 0 ; WR0 par 3&4 - transfer length
18 DB %00010100 ; WR1 - A incr., A=memory
19 DB %00101000 ; WR2 - B fixed, B=I/O
20 DB %10101101 ; WR4 - continuous, append port B address
21 DW $005B ; WR4 par 1&2 - port B address
22 DB %10000010 ; WR5 - stop on end of block, CE only
23 DB %11001111 ; WR6 - load addresses into DMA counters
24 DB %10000111 ; WR6 - enable DMA
25 .dmaProgramLength = $-.dmaProgram
See section 3.3, page 43 for details on how to program the zxnDMA.
11
https://wiki.specnext.dev/DMA
97
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:
98
CHAPTER 3. ZX SPECTRUM NEXT
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!
99
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 (see below).
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
100
CHAPTER 3. ZX SPECTRUM NEXT
Peripheral 4 $09
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 $34 (page 101) and Sprite Status/Slot Select
$303B (page 100)
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 $1C (page
83), then write all 4 coordinates in succession.
When “over border” mode is enabled (bit 1 of Sprite and Layers System $15, page 89), X
coordinates are doubled internally.
If sprite id lockstep in Peripheral 4 $09 (page 101) is enabled, write to this registers has same
effect as writing to Sprite Status/Slot Select $303B (page 100).
101
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)
102
CHAPTER 3. ZX SPECTRUM NEXT
103
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 $34 (page 101) 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.
104
CHAPTER 3. ZX SPECTRUM NEXT
3.9 Copper
Copper stands for “co-processor”. If the name sounds familiar, there’s a reason - it functions
similarly to the Copper from the Commodore Amiga Agnus chip. It allows changing a subset of
Next registers at certain scanline positions, which frees the Z80 processor for other tasks.
Copper uses 2K of dedicated write-only memory for its programs. A program consists of a series
of instructions. Instructions are 16-bits in size, meaning we can store up to 1024 instructions.
Internally, Copper uses a 10-bit program counter (CPC) that by default auto-increments and
wraps around from the last to the first instruction. But we can change this behaviour if needed.
Timing for Copper is 14MHz on core 2.0 and 28MHz on core 3.0. If interested, this document
describes the timing and many other details for core 2.0 in great detail12 .
3.9.1 Instructions
There are only two types of instructions ZX Next Copper understands, but each type has a
special case, so in total, we can say there are four operations:
Op. Bit Pattern Effect Dur.
WAIT 1HHHHHHV VVVVVVVV Wait for raster line V (0-311) and horizontal 1 cycle
position H (0-55)
HALT 11111111 11111111 Special case of WAIT; works as “halt” 1 cycle
MOVE 0RRRRRRR VVVVVVVV Write value V to Next register R 2 cycles
NOOP 00000000 00000000 Special case of MOVE; works as “no operation” 1 cycle
WAIT
105
CHAPTER 3. ZX SPECTRUM NEXT
HALT
MOVE
NOOP
106
CHAPTER 3. ZX SPECTRUM NEXT
3.9.2 Configuration
To load a program, we need to send it, byte by byte, through Copper Data $60 or Copper
Data 16-bit Write $63 registers (page 109). As instructions are 16-bits in size, two writes
are required. The difference between the two registers is that $60 sends bytes immediately
while $63 only after both bytes of an instruction are provided, thus preventing half-written
instructions from executing.
Copper is controlled through 16-bit control word accessible through Copper Control High
Byte $62 and Copper Control Low Byte $61 registers (page 109):
Copper Control High Byte $62 (page 109) Copper Control Low Byte $61 (page 109)
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0
Mode 0 0 0 Index for program upload
Mode can be one of the following:
00 Stops the Copper, CPC keeps its current value. This is useful during program upload, to
prevent Copper from executing incomplete instructions and programs.
01 Resets CPC to 0, then starts Copper. From here on, Copper will start executing the first
instruction in the program and continue until CPC reaches 1023, then wrap around back
to first. However it will stop if HALT instruction is encountered.
10 Starts or resumes Copper from current CPC. Similar to 01, except that CPC is not changed.
Instead, Copper resumes execution from current instruction.
11 Same as 01, but also auto-resets CPC to 0 on vertical blank. In this mode we can use
HALT to mark the end of the program and still repeat it without having to fill-in NOOPs
from the last instruction of our program to the end of Copper 2K memory.
The other value we set is the index for program upload. This is 11-bit value (0-2047) specifying
the byte offset for write commands with Copper Data $60 or Copper Data 16-bit Write $63
registers (page 109). In other words: this is the index for the location into which data will be
uploaded, not the value of the CPC. We can’t change CPC programmatically, apart from resetting
it to 0.
3.9.3 Example
Enough theory, let’s see how it works in practice, Copper program first. It changes palette
colour to green at the top of the screen and then to red in the middle:
1 CopperList:
2 DB $80, 0 ; Wait line 0
3 DB $41, %00011100 ; Set palette entry to green
4 DB $80, 96 ; Wait line 96
5 DB $41, %11100000 ; Set palette entry to red
6 DB $FF, $FF ; HALT
7 CopperListSize = $-CopperList
In case you may be wondering: we should also ensure we update the correct colour with
107
CHAPTER 3. ZX SPECTRUM NEXT
Enhanced ULA Control $43 (page 65) and Palette Index $40 (page 63). But I wanted to
keep the program simple for demonstration purposes.
With Copper program in place, we can upload it to Copper memory. We can use DMA or
directly upload values through Next registers. The code here demonstrates later, but companion
code implements both so you can compare:
Again, this is an overly simplified example. It only works for lists that are less than 256 bytes
long.
The next step is... Well, there is no next step - if we enabled Layer 2 and filled it with the
colour we’re changing in our Copper list, we should see the screen divided into two halves with
top in green and bottom red colour.
Not the most impressive display of Copper capabilities, I give you that. You can find a more
complex example in companion code on GitHub, folder copper with couple additional points of
interest:
Upload routine that supports programs of arbitrary size (within 1024 instructions limit)
Example of upload routine using DMA
Using DMA to fill in Layer 2 banks
Macros that hopefully make Copper programs easier to read and write
Usage of Copper Data $60 (page 109) to dynamically update individual bytes of the
program in memory to achieve couple effects
108
CHAPTER 3. ZX SPECTRUM NEXT
Bit Effect
7-0 Data to upload to Copper memory
The data is written to the index specified with Copper Control Low Byte $61 and Copper
Control High Byte $62 registers. After the write, the index is auto-incremented to the next
memory position. The index wraps to 0 when the last byte of the program memory is written to
position 2047. Since Copper instructions are 16-bits in size, two writes are required to complete
each one.
Bit Effect
7-0 Least significant 8 bits of Copper list index
Bit Effect
7-6 Control mode
00 Stops the Copper, CPC keeps its current value
01 Resets CPC to 0, then starts Copper
10 Starts or resumes Copper from current CPC
11 Same as 01, but also auto-resets CPC to 0 on vertical blank
5-3 Reserved, must be 0
2-0 Most significant 3 bits of Copper list index
When control mode is identical to current one, it’s ignored. This allows change of the upload
index without restarting the program.
Bit Effect
7-0 Data to upload to Copper memory
Similar to Copper Data $60 except that writes are only committed to Copper memory after
two bytes are written. This prevents half-written instructions to be executed.
The first write to this register is for MSB of the Copper instruction or even instruction address
and second write for LSB or odd instruction address.
109
CHAPTER 3. ZX SPECTRUM NEXT
110
CHAPTER 3. ZX SPECTRUM NEXT
3.10 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 (page 113) register. Afterwards, we can set various
parameters through Peripheral 3 $08 (page 115) and Peripheral 4 $09 (page 101) registers.
AY chip is controlled by 14 internal registers. To program them, we first need to select the
register with Turbo Sound Next Control $FFFD (page 113) and then write the value with
Sound Chip Register Write $BFFD (page 113).
Several applications can produce sounds or music compatible with the AY chip. For sounds,
Shiru’s AYFX Player13 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 website14 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 website15 . 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. NextDAW16 is native composer that runs on
ZX Spectrum Next itself. Or if you prefer cross-platform, Arkos Tracker17 or Vortex Tracker18
should do the job. All include “drivers”; Z80 code you can include in your program that can
load and play created music.
13
https://shiru.untergrund.net/software.shtml#old
14
https://zx.remysharp.com/audio/
15
https://www.chibiakumas.com/z80/platform4.php#LessonP35
16
https://nextdaw.biasillo.com/
17
https://www.julien-nevo.com/arkostracker/
18
https://bulba.untergrund.net/vortex_e.htm
111
CHAPTER 3. ZX SPECTRUM NEXT
3.10.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.
1 WriteDToAYReg:
2 ; Select desired register
3 LD BC, $FFFD
4 OUT (C), A
5
11 RET
Companion code on GitHub, folder sound 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 3.12, page 119 should give you an idea of how to
achieve this - happy coding!
112
CHAPTER 3. ZX SPECTRUM NEXT
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
113
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”
114
CHAPTER 3. ZX SPECTRUM NEXT
Peripheral 2 $06
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
Peripheral 3 $08
Bit Effect
7 1 unlock / 0 lock port Memory Paging Control $7FFD (page 41) 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)
Peripheral 4 $09
See description under Sprites, section 3.8.7, page 101.
115
CHAPTER 3. ZX SPECTRUM NEXT
116
CHAPTER 3. ZX SPECTRUM NEXT
3.11 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 Read $xxFE (page 118) 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 3.1.3, page 33, 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 $68 (page 91). Extra keys can be read separately via Extended
Keys 0 $B0 and Extended Keys 1 $B1, details on page 118.
117
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 Write $xxFE is used to set border colour and audio
devices. See ULA Layer, section 3.5.6, page 71 for details.
118
CHAPTER 3. ZX SPECTRUM NEXT
10 .loop:
11 JP .loop ; infinite loop
12 RET ; this is never reached...
13
The first directive tells sjasmplus to generate the code for Next. This will become important
later on. Then we set the program counter to $8000; all subsequent instructions and data will
be assembled starting at this address.
Next, we are paging out ROM in 8K slot 0 with bank 28. We’ll write our interrupt handler
subroutine into this bank later on. Afterwards, we enable Interrupt Mode 1. This is optional;
119
CHAPTER 3. ZX SPECTRUM NEXT
by default, Next will run in this mode already, but being explicit is more future proof. Maybe
another program would change to IM2. Note how we disable interrupts during this setup to
prevent undesired side effects.
The remaining part is simply an infinite loop to prevent the program from exiting. And finally,
we declare our counter variable.
The interrupt subroutine is expected at $0038. There are several ways to achieve this with
sjasmplus. I opted for explicit slot/bank technique so we’re in control of the paging:
5 InterruptHandler:
6 LD HL, counter ; load address of counter var
7 INC (HL) ; increment it
8 EI ; enable interrupts
9 RETI ; return from interrupt
This is where the previously mentioned DEVICE directive comes to play - sjasmplus decides
slot and bank configuration based on it. ZXSPECTRUMNEXT assumes 8K slot and bank size. Lines
1-3 are the key to ensure our interrupt handler will be present on $0038:
SLOT directive tells sjasmplus we want the following section to be loaded into 8K slot 6,
addresses $C000-$DFFF.
Next, we specify 8K bank number to load into the selected slot with PAGE directive.
Subsequent code will be assembled into this bank. This step is optional; default bank
would be used otherwise, 0 in this case (see section 3.2, page 35). Being explicit is more
future proof though. I chose bank 28 but feel free to use others. What’s important is to
use the same bank with NEXTREG instruction when paging out ROM!
Since we selected slot 6, we also need to set the program counter to the corresponding
address - we want the code to be assembled into the selected bank that we will page into
ROM slot 0 at runtime. Because interrupt handler is expected on $0038, we need to start
at $C038 (slot 6 starts at $C000, but this will be loaded into slot 0 at $0000).
Not that hard, right!? It may take a while to wrap the head around those SLOT, PAGE and
ORG directives and addresses, but it’s quite straightforward otherwise. While at it: this same
technique can be used to load assets into specific banks and then page them in during runtime!
You can find the full source code for this example in companion code, folder im1. Feel free to
run it, set breakpoints and see how the counter is being changed.
Note there’s one potentially deal-breaking issue with this approach: since we are paging out
ROM, we can’t use any of its functionality. For example, ROM routines like print text at $203C.
But we can do this with IM2 - read on!
120
CHAPTER 3. ZX SPECTRUM NEXT
Once Interrupt Mode 2 is activated, mode 1 handler at $0038 isn’t called anymore. Instead,
when an interrupt occurs, Z80 performs the following steps:
First, a 16-bit address is formed where the value for the most significant byte is taken
from the I register and the value for the least significant byte from the current value of
the data bus.
Two bytes are read from this address (little endian format is assumed - low byte first,
then high byte); these 2 bytes form another 16-bit address.
It’s this second address that the CPU treats as an interrupt routine and starts executing
from.
Phew, a lot of words and concepts to grasp. But it’s simpler than it sounds - let’s rewrite the
IM1 example, but this time with IM2. The main program first:
Almost the same except for the NEXTREG replaced with SetupInterruptVectors subroutine
call that initializes vector table:
1 SetupInterruptVectors:
2 LD DE, InterruptHandler ; prepare pointer to IM2 routine
121
CHAPTER 3. ZX SPECTRUM NEXT
The subroutine fills in all 128 entries of the vector table with the address of our actual interrupt
routine. The only remaining piece is the declaration of the vector table itself; I chose .ALIGN
256 directive that fills in bytes until 256-byte boundary is reached:
The interrupt handler itself can reside anywhere in the memory. Code-wise it’s the same as for
IM1 mode previously.
So there’s some more work when using IM2 mode, but it leaves ROM untouched so we can rely
on its routines and other functionality. I only demonstrated relevant bits here. You can find a
fully working example in companion code, folder im2 (make sure to read the next section!).
Sharp-eyed readers may be wondering what would happen if the value from the data bus is odd?
Given our IM2 example from above, our interrupt handler happens to be on address $802A.
Therefore the vector table would have the following contents:
$xx00 $xx01 $xx02 $xx03 ... $xxFE $xxFF
$2A $80 $2A $80 ... $2A $80
If the bus value is even, for example 0, 2, 4 etc, then the address of the interrupt handler would
be correctly read as $802A (remember, Z80 is little-endian). But what if the value is odd, 1, 3,
5 etc? In this case, 16-bit interrupt handler address would be wrong - $2A80! During my tests,
this didn’t happen - whether by luck, the data bus always had an even number, or, maybe Z80
reset bit 0 before constructing vector lookup address. But we can’t rely on luck!
In fact, Next Dev Wiki19 recommends that the interrupt handler routine is always placed on an
address where high and low bytes are equal. It’s best to follow this advice to avoid potential
issues. The changes to the code are minimal, so I won’t show it here - it could be a nice exercise
though! Just a tip - to be extra safe, make vector table 257 bytes long in case the data bus has
$FF. You can find a working example in companion code, folder im2safe.
19
https://wiki.specnext.dev/Interrupts
122
CHAPTER 3. ZX SPECTRUM NEXT
In addition to regular IM2, Next also supports a “Hardware IM2” mode. This mode works
similar to legacy IM2 in that we still need to provide vector tables. But it properly implements
the Z80 IM2 scheme with daisy chain priority. So when particular interrupt subroutine is called,
we know exactly which device caused it without having to figure it out as needed in legacy IM2.
Let’s go over the details with an example. First, the initialization:
1 DI ; disable interrupts
2 NEXTREG $C0, (InterruptVectorTable & %11100000) | %00000001
3 NEXTREG $C4, %10000001 ; enable expansion bus INT and ULA interrupts
4 NEXTREG $C5, %00000000 ; disable all CTC channel interrupts
5 NEXTREG $C6, %00000000 ; disable UART interrupts
6
7 LD A, InterruptVectorTable >> 8
8 LD I, A ; I now holds high byte of vector table
9
Line 3 is where hardware IM2 mode is established. The crucial part is Interrupt Control $C0
(page 126) register: firstly, we are supplying the top 3 bits of LSB of the vector table to bits 7-5,
and secondly, we enable IM2 mode by setting bit 0.
Lines 4-6 enable or disable specific interrupters with Interrupt Enable 0 $C4 (page 126),
Interrupt Enable 1 $C5 (page 126) and Interrupt Enable 2 $C6 (page 127).
Lines 8-12 are the same as with legacy IM2 mode - we assign the LSB of the vector table address
to I register. Then we enable IM2 mode and interrupts.
Interrupt vectors table is quite a bit different (in a good way though):
1 .ALIGN 32
2 InterruptVectorTable:
3 DW InterruptHandler ; 0 = line interrupt (highest priority)
4 DW InterruptHandler ; 1 = UART0 Rx
5 DW InterruptHandler ; 2 = UART1 Rx
6 DW InterruptHandler ; 3 = CTC channel 0
7 DW InterruptHandler ; 4 = CTC channel 1
8 DW InterruptHandler ; 5 = CTC channel 2
9 DW InterruptHandler ; 6 = CTC channel 3
10 DW InterruptHandler ; 7 = CTC channel 4
11 DW InterruptHandler ; 8 = CTC channel 5
12 DW InterruptHandler ; 9 = CTC channel 6
13 DW InterruptHandler ; 10 = CTC channel 7
14 DW InterruptHandlerULA ; 11 = ULA
15 DW InterruptHandler ; 12 = UART0 Tx
16 DW InterruptHandler ; 13 = UART1 Tx (lowest priority)
17 DW InterruptHandler
18 DW InterruptHandler
123
CHAPTER 3. ZX SPECTRUM NEXT
As you can see, each interrupter gets its own vector. In the above example, all except ULA
are pointing to the same interrupt routine. Since there are only a handful, we can use a much
clearer declaration with DW <routine address>. This way we don’t need any initialization
code that would fill in the routine address as we used with legacy IM2 mode.
The thing to note: .ALIGN 32 is used to ensure the interrupt table is placed on a 32-byte
boundary; the least significant 5 bits of the address must be 0 (25 32 %100000). This is
important due to how hardware IM2 vector table lookup address is formed during interrupt:
For details and more, see this discussion on Discord20 , highly recommended!
Very special thanks to the folks from Next Discord server: Alvin Albrecht for mentioning21
hardware IM2 mode and @varmfskii whos discussion22 and sample code was the basis for my
exploration into this mode!
20
https://discord.com/channels/556228195767156758/692885312296190102/894284968614854749
21
https://discord.com/channels/556228195767156758/692885312296190102/865955247552462848
22
https://discord.com/channels/556228195767156758/692885353161293895/817807486744526886
124
CHAPTER 3. ZX SPECTRUM NEXT
Bit Effect
7 Read: INT signal (even when Z80N has interrupts disabled) (1 = interrupt is requested)
Write: Reserved, must be 0
6-3 Reserved, must be 0
2 1 disables original ULA interrupt (0 after reset)
1 1 enables Line Interrupt (0 after reset)
0 MSB of interrupt line value (0 after reset)
Line value starts with 0 for the first line of pixels. But the line-interrupt happens already when
the previous line’s pixel area is finished (i.e. the raster-line counter still reads ”previous line” and
not the one programmed for interrupt). The INT signal is raised while display beam horizontal
position is between 256-319 standard pixels, precise timing of interrupt handler execution then
depends on how-quickly/if the Z80 will process the INT signal.
Bit Effect
7-0 LSB of interrupt line value (0 after reset)
On core 3.1.5+ line numbering can be offset by Vertical Video Line Offset $64.
Bit Effect
7-0 Vertical line offset value 0-255 added to Copper, Video Line Interrupt and Active Video
Line readings.
Core 3.1.5+ only.
Normally the ULA’s pixel row 0 aligns with vertical line count 0. With a non-zero offset, the
ULA’s pixel row 0 will align with the vertical line offset. For example, if the offset is 32 then
video line 32 will correspond to the first pixel row in the ULA and video line 0 will align with
the first pixel row of the Tilemap and Sprites (in the top border area).
Since a change in offset takes effect when the ULA reaches row 0, the change can take up to
one frame to occur.
125
CHAPTER 3. ZX SPECTRUM NEXT
Bit Effect
7-5 Programmable portion of IM2 vector
4 Reserved, must be 0
3 1 enables, 0 disabled stackless NMI response
2-1 Reserved, must be 0
0 Maskable interrupt mode: 1 IM2, 0 pulse
If bit 3 is set, the return address pushed during an NMI acknowledge cycle will be written to
NMI Return Address LSB $C2 and NMI Return Address MSB $C3 instead of the memory
(the stack pointer will be decremented). The first RETN after the NMI acknowledge will then take
its return address from the registers instead of memory (the stack pointer will be incremented).
If bit 3 is 0, and in other circumstances (if there is no NMI first), RETN functions normally.
Bit Effect
7-0 LSB or MSB of the return address written during an NMI acknowledge cycle
Bit Effect
7 Expansion bus INT (1 after reset)
6-2 Reserved, must be 0
1 1 enables, 0 disables line interrupt (0 after reset)
0 1 enables, 0 disabled ULA interrupt (1 after reset)
Bit Effect
7 1 enables, 0 disables CTC channel 7 interrupt
6 1 enables, 0 disables CTC channel 6 interrupt
5 1 enables, 0 disables CTC channel 5 interrupt
4 1 enables, 0 disables CTC channel 4 interrupt
3 1 enables, 0 disables CTC channel 3 interrupt
2 1 enables, 0 disables CTC channel 2 interrupt
1 1 enables, 0 disables CTC channel 1 interrupt
0 1 enables, 0 disables CTC channel 0 interrupt
All bits 0 after reset.
126
CHAPTER 3. ZX SPECTRUM NEXT
Bit Effect
7 Reserved, must be 0
6 UART1 Tx empty
5 UART1 Rx half full
4 UART1 Rx available
3 Reserved, must be 0
2 UART0 Tx empty
1 UART0 Rx half full
0 UART0 Rx available
All bits 0 after reset. Rx half full overrides Rx available.
Bit Effect
7-2 Reserved, must be 0
1 Line interrupt
0 ULA interrupt
Read indicates whether the given interrupt was generated in the past. Write with 1 clears given
bit unless in IM2 mode (bit 0 set on Interrupt Control $C0 (page 126)) with interrupts enabled.
Bit Effect
7 CTC channel 7 interrupt
6 CTC channel 6 interrupt
5 CTC channel 5 interrupt
4 CTC channel 4 interrupt
3 CTC channel 3 interrupt
2 CTC channel 2 interrupt
1 CTC channel 1 interrupt
0 CTC channel 0 interrupt
Read indicates whether the given interrupt was generated in the past. Write with 1 clears given
bit unless in IM2 mode (bit 0 set on Interrupt Control $C0, page 126) with interrupts enabled.
127
CHAPTER 3. ZX SPECTRUM NEXT
Bit Effect
7 Reserved, must be 0
6 UART1 Tx empty interrupt
5 UART1 Rx half full interrupt
4 UART1 Rx available interrupt
3 Reserved, must be 0
2 UART0 Tx empty interrupt
1 UART0 Rx half full interrupt
0 UART0 Rx available interrupt
Read indicates whether the given interrupt was generated in the past. Write with 1 clears given
bit unless in IM2 mode (bit 0 set on Interrupt Control $C0, page 126) with interrupts enabled.
Bit Effect
7-2 Reserved, must be 0
1 1 allows, 0 prevents line interrupt from interrupting DMA
0 1 allows, 0 prevents ULA interrupt from interrupting DMA
Bit Effect
7 1 allows, 0 prevents CTC channel 7 interrupt from interrupting DMA
6 1 allows, 0 prevents CTC channel 6 interrupt from interrupting DMA
5 1 allows, 0 prevents CTC channel 5 interrupt from interrupting DMA
4 1 allows, 0 prevents CTC channel 4 interrupt from interrupting DMA
3 1 allows, 0 prevents CTC channel 3 interrupt from interrupting DMA
2 1 allows, 0 prevents CTC channel 2 interrupt from interrupting DMA
1 1 allows, 0 prevents CTC channel 1 interrupt from interrupting DMA
0 1 allows, 0 prevents CTC channel 0 interrupt from interrupting DMA
128
CHAPTER 3. ZX SPECTRUM NEXT
Bit Effect
7 Reserved, must be 0
6 1 allows, 0 prevents UART1 Tx empty from interrupting DMA
5 1 allows, 0 prevents UART1 Rx half full from interrupting DMA
4 1 allows, 0 prevents UART1 Rx available from interrupting DMA
3 Reserved, must be 0
2 1 allows, 0 prevents UART0 Tx empty from interrupting DMA
1 1 allows, 0 prevents UART0 Rx half full from interrupting DMA
0 1 allows, 0 prevents UART0 Rx available from interrupting DMA
129
CHAPTER 3. ZX SPECTRUM NEXT
130
Chapter 4
Instructions at a Glance
131
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.
Instruction Execution
Effects
Notes
YF and XF flags are not represented; they’re irrelevant from the programmer point of view.
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
132
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,s2 AÐA+s+CF Ù Ù Ù VF 0 Ù .. 001 ...
SUB s2 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 s2 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 s 1,2
A-s Ù Ù Ù VF 1 Ù .. 111 ...
133
CHAPTER 4. INSTRUCTIONS AT A GLANCE
134
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)
135
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
136
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
137
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
Symbolic Flags Opcode
Mnemonic Operation SF ZF HF PV NF CF 76 543 210 Hex B Mc Ts Comments
EX AF,AF’ AFØAF’
1
1
1
1
1
1 00 001 000 08 1B 1 4
EX DE,HL DEØHL - - - - - - 11 101 011 EB 1B 1 4
EX (SP),HL HØ(SP+1) - - - - - - 11 100 011 E3 1B 5 19
LØ(SP)
138
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 dqb Ð1 - - - - - - 11 011 101 DD 4B 6 23
11 001 011 CB
d ..
11 b 110 ..
SET b,(IY+d) pIY dqb Ð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,m3 mb Ð0 - - - - - - 10 ... ...
Notes: 1 See section 2.3.1, page 16 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
139
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
140
CHAPTER 4. INSTRUCTIONS AT A GLANCE
4.10 Jump
Symbolic Flags Opcode
Mnemonic Operation SF ZF HF PV NF CF 76 543 210 Hex B Mc Ts Comments
JP nm PCÐnm - - - - - - 11 000 011 C3 3B 3 10 c c
m .. NZ 000
n .. Z 001
NC C10
JP (HL) PCÐHL - - - - - - 11 101 001 E9 1B 1 4 C 011
PCÐIX
PO 100
JP (IX) - - - - - - 11 011 101 DD 2B 2 8 PE 101
11 101 001 E9 P 110
Ð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
141
CHAPTER 4. INSTRUCTIONS AT A GLANCE
142
CHAPTER 4. INSTRUCTIONS AT A GLANCE
143
CHAPTER 4. INSTRUCTIONS AT A GLANCE
4.13 Input
Symbolic Flags Opcode
Mnemonic Operation SF ZF HF PV NF CF 76 543 210 Hex B Mc Ts Comments
IN A,(n)1 AÐ(n) - - - - - - 11 011 011 DB 2B 3 11 r r
n .. B 000
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
Symbolic Flags Opcode
Mnemonic Operation SF ZF HF PV NF CF 76 543 210 Hex B Mc Ts Comments
OUT (n),A (n) ÐA - - - - - - 11 010 011 D3 2B 3 11 r r
n .. B 000
Ð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
OTIR do OUTI
2 1
2
2 1 - 11 101 101 ED 2B 4 16 if B=0
while B>0 10 110 011 B3 5 21 if B0
OUTD BÐB-1
2
1
2
2 1 - 11 101 101 ED 2B 4 16
(BC)Ð(HL) 10 101 011 AB
HLÐHL-1
144
CHAPTER 4. INSTRUCTIONS AT A GLANCE
LDWS Ð
(DE) (HL) Ù Ù Ù VF3 0 - 11 101 101 ED 2B 4 16
INC L 10 100 101 A5
INC D
Notes: 1 CF is undefined, recently discovered, thanks to Peter Ped Helcmanovsky
https://discord.com/channels/556228195767156758/695180116040351795/888099852725133412
2 Core v2+ only
3 PV set to 1 if D was $7F before increment, otherwise 0
145
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ÐHL^$F81F+$800
PUSH nm (SP-2)Ðm - - - - - - 11 101 101 ED 3B 6 23
(SP-1)Ðn 10 001 010 8A
SPÐSP-2 n1 ..
m1 ..
SETAE AÐunsigned($80)>>(E^7) - - - - - - 11 101 101 ED 3B 2 8
10 010 101 95
SWAPNIB A 7654 3210 - - - - - - 11 101 101 ED 2B 2 8
00 100 011 23
TEST n ^
A n Ù Ù 1 PF ? 0 11 101 101 ED 3B 3 11
00 100 111 27
Notes: 1 This is not mistake, nm operand is in fact encoded in big-endian
146
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.
147
Flags
SF Sign Flag is set to twos-complement of the most-significant bit (bit 7) of the result of an
instruction. If the result is positive (bit 7 is 0), SF is set, and if the result is negative (bit 7 is
1), SF is reset. This leaves bits 0-6 to represent the value. Positive numbers range from 0 to
127 and negative from -1 to -128.
ZF Zero Flag depends on whether the result of an instruction is 0. ZF is set if the result if 0
and reset otherwise.
HF Half Carry Flag represents a carry or borrow status between bits 3 and 4 of an 8-bit
arithmetic operation (bits 11 and 12 for 16-bit operations). Set if:
A carry from bit 3 to bit 4 occurs during addition (bit 11 to 12 for 16-bit operations)
A borrow from bit 4 occurs during subtraction (from bit 12 for 16-bit operations)
148
CHAPTER 5. INSTRUCTIONS UP CLOSE
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 P/V is undefined or indicates other result
Abbreviations
149
CHAPTER 5. INSTRUCTIONS UP CLOSE
150
CHAPTER 5. INSTRUCTIONS UP CLOSE
Adds source operand s or contents of the memory location addressed by s and value
of carry flag to destination d. Result is then stored to destination d.
Effects SF ZF HF PV NF CF
8-bit Ù Ù Ù Ù 0 Ù
16-bit Ù Ù Ù Ù 0 Ù
SF set if: result is negative (bit 7 is set)
ZF set if: result is 0
HF set if: carry from bit 3
PV set if: both operands positive and result negative
both operands negative and result positve
CF set if: carry from bit 7
151
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.
ZX Next Extended instructions for adding A to 16-bit register pair, zero extend A
to 16-bits.
Effects SF ZF HF PV NF CF
8-bit Ù Ù Ù Ù 0 Ù
16-bit - - Ù - 0 Ù
SF 8-bit only, set if: result is negative (bit 7 is set)
ZF 8-bit only, set if: result is 0
HF set if: carry from bit 3 (bit 11 for 16-bit)
PV 8-bit only, set if: both operands positive and result negative
both operands negative and result positve
CF set if: carry from bit 7 (bit 15 for 16-bit)
Effects SF ZF HF PV NF CF
ADD rr,AZX - - - - - ?
ADD rr,nnZX - - - - - -
152
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
Ù Ù 1 Ù 0 0
Tests specified bit b (0-7) of the given register s or contents of memory addressed
by s and sets zero flag according to result; if bit was 1, ZF is 0 and vice versa.
Effects SF ZF HF PV NF CF
? Ù 1 ? 0 -
153
CHAPTER 5. INSTRUCTIONS UP CLOSE
BRLC, BSLA, BSRA, BSRF, BSRL See pages 155 and 156
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
154
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 - - - - - -
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
155
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 - - - - - -
Effects SF ZF HF PV NF CF
- -
- 0 Ù
HF Documentation says original value of CF is copied
to HF, however under my tests HF remained un-
changed
CF if CF was 0 it’s now 1 and vice versa
156
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 Ù
HF set if: borrow from bit 4
PV set if: A and s positive and A-s result negative
A and s negative and A-s result positve
Other flags are set like this when A is greater than, equal or less than s:
SF ZF HF PV NF CF
A¡s 0 0 Ù Ù 1 0
As 0 1 Ù Ù 1 0
A s 1 0 Ù Ù 1 1
With this in mind, we can derive the programs for common comparisons:
A=s As
1 CP s 1 CP s
2 JP Z, true ; A=s? 2 JP NZ, true ; A!=s?
3 false: ; A!=s 3 false: ; A=s
4 true: ; A=s 4 true: ; A!=s
A¤s A<s
1 CP s 1 CP s
2 JP M, true ; A<s? 2 JP M, true ; A<s?
3 JP Z, true ; A=s? 3 false: ; A>=s
4 false: ; A>s 4 true: ; A<s
5 true: ; A<=s
A¥s A>s
1 CP s 1 CP s
2 JP M, false ; A<s? 2 JP M, false ; A<s?
3 true: ; A>=s 3 JP Z, false ; A=s?
4 false: ; A<s 4 true: ; A>s
5 false: ; A<=s
Note: the examples use two labels to emphasize both results. But only one is
needed. Furthermore, depending on the actual needs, the programs can also use
157
CHAPTER 5. INSTRUCTIONS UP CLOSE
no label at all. For example, we can use RET instead of JP when used within a
subroutine, and the desired outcome is to return if the condition is not met:
A=s As
1 CP s 1 CP s
2 RET NZ ; A!=s? 2 RET Z ; A=s?
3 ; A=s 3 ; A!=s
A¤s A<s
1 CP s 1 CP s
2 JP M, true ; A<s? 2 RET P ; A>=s?
3 JP Z, true ; A=s? 3 ; A<s
4 RET ; A>s
5 true: ; A<=s
A¥s A>s
1 CP s 1 CP s
2 RET M ; A<s? 2 RET M ; A<s?
3 ; A>=s 3 RET Z ; A=s?
4 ; A>s
Note: some of the comparisons are reversed. And A¤s still requires a label because
the condition is true if either SF or ZF is set.
Note: I opted to use SF for some of the comparisons. It makes more sense to me
this way. But you can just as well use CF instead. As evident from the table on the
previous page, both flags are updated the same way, so you could use JP C or RET
C instead of M and JP NZ or RET NZ instead of P. This is due to CP performing a
subtraction A-s internally. So when s is greater than A, the result of the subtraction
is negative, meaning the sign flag is set. At the same time a borrow is needed, so
the carry is set too. I thought it’s worth mentioning since you may find examples
using the carry flag elsewhere and wonder why.
158
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
Ù Ù Ù
1 -
159
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
Ù Ù Ù
1 -
160
CHAPTER 5. INSTRUCTIONS UP CLOSE
1. The least significant 4 bits of accumulator A (low nibble) are checked first. If
they contain invalid BCD number (greater than 9), or HF is set, the value of
A is adjusted based on the value of NF: if it’s reset, $06 is added to A, if set,
$06 is removed from A.
2. Then 4 most significant bits of accumulator A (high nibble) are checked in a
similar fashion. If they contain invalid BCD number, or CF is set, the value of
A is adjusted: if NF is not set, $60 is added to A, if NF is set, $60 is removed
from A.
3. Finally flags are changed accordingly, as described below.
Effects SF ZF HF PV NF CF
Ù Ù Ù Ù - Ù
SF set if: A is negative (bit 7 is set) after operation
ZF set if: A is 0 after operation
HF depends on: input values of NF, HF and bits 0-3 of A:
NF HF A[3-0] HF
0 * 0-9 0
0 * A-F 1
1 0 * 0
1 1 0-5 1
1 1 6-F 0
PV set if: A has even number of bits set after operation
CF depends on: input values of CF and both nibbles of A:
CF A[7-4] A[3-0] CF
0 0-9 0-9 0
0 0-8 A-F 0
0 9-F A-F 1
0 A-F 0-9 1
1 * * 1
161
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
- - 1 - 1 -
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**
Effects SF ZF HF PV NF CF
8-bit Ù Ù Ù Ù 1 -
16-bit (no effect) - - - - - -
162
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 2.4, page 19 and 3.12, page
119 for more details on interrupts.
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
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 2.4, page 19
and 3.12, page 119 for more details on interrupts.
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
163
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
EX AF,AF’
Other variants no effect - - - - - -
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
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
164
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 2.4, page 19 and 3.12, page 119 for
details and example.
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
165
CHAPTER 5. INSTRUCTIONS UP CLOSE
So these two have the same result (though, as mentioned in section 3.11, page 117,
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)) 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).
166
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**
Effects SF ZF HF PV NF CF
8-bit Ù Ù Ù Ù 0 -
16-bit (no effect) - - - - - -
167
CHAPTER 5. INSTRUCTIONS UP CLOSE
168
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
1 -
Effects SF ZF HF PV NF CF
1
1 -
169
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
1 -
Effects SF ZF HF PV NF CF
1
1 -
170
CHAPTER 5. INSTRUCTIONS UP CLOSE
JP nn JumP
PCÐnn
JP nn JP (IX)
JP (HL) JP (IY)
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
171
CHAPTER 5. INSTRUCTIONS UP CLOSE
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.
* “Current PC” is the address of the next instruction after JP (C); PC was already
advanced after fetching JP (C) instruction from memory. If JP (C) instruction is
located at the very end of 16K memory block ($..FE or $..FF address), then the
new PC value will land into the 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 - - - - - -
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
172
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)
173
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
LD A,I and LD A,R Ù Ù 0 IFF2 0 -
Other variants - - - - - -
174
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
- - 0
0 -
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
Effects SF ZF HF PV NF CF
- - 0
0 -
175
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
Effects SF ZF HF PV NF CF
Ù Ù Ù Ù 0 -
Note: the source data are read from a single 256B (aligned) block of memory,
because only L is incremented, not the whole HL pair.
176
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
- - 0 0 0 -
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
Effects SF ZF HF PV NF CF
- - 0 0 0 -
177
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 - - - - - -
178
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
NEG NEGate
AÐ-A
Negates contents of the accumulator A and stores result back to A. You can also
think of the operation as subtracting the value of A from 0 (AÐ0-A). This way it
might be easier to understand effects on flags.
Effects SF ZF HF PV NF CF
Ù Ù Ù Ù 1 Ù
SF set if: result is negative (bit 7 is set)
ZF set if: result is 0
HF set if: borrow from bit 4
PV set if: A was $80 before operation
CF set if: A was not $00 before operation
Directly sets the Next Feature Control Registers without going through ports
TBBlue Register Select $243B and TBBlue Register Access $253B (page 34).
See section 3.1.2, page 29 for registers list.
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
179
CHAPTER 5. INSTRUCTIONS UP CLOSE
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**
Performs bitwise or between the accumulator A and operand s A s Result
or contents of memory addressed by s. Then stores the result 0 0 0
back to A. Individual bits are OR’ed as shown on the right: 0 1 1
1 0 1
1 1 1
Effects SF ZF HF PV NF CF
Ù Ù 0 Ù 0 0
180
CHAPTER 5. INSTRUCTIONS UP CLOSE
181
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
1 -
Effects SF ZF HF PV NF CF
1 -
182
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.
Effects SF ZF HF PV NF CF
? ? ? ? ? ?
183
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
184
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
POP AF Ù Ù Ù Ù Ù Ù
Other variants no effect - - - - - -
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
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 - - - - - -
185
CHAPTER 5. INSTRUCTIONS UP CLOSE
Resets bit b (0-7) of the given register s or memory location addressed by operand
s.
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
186
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
187
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
188
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 Ù
SF set if: result is negative (bit 7 is set)
ZF set if: result is 0
PV set if: result has even number of bits set
CF set to: bit 7 of the original value
CF 7Ð0
A
Performs RL A, but twice faster and preserves SF, ZF and PV.
Effects SF ZF HF PV NF CF
- - 0 - 0 Ù
CF set to: bit 7 of the original value
189
CHAPTER 5. INSTRUCTIONS UP CLOSE
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 Ù
SF set if: result is negative (bit 7 is set)
ZF set if: result is 0
PV set if: result has even number of bits set
CF set to: bit 7 of the original value
190
CHAPTER 5. INSTRUCTIONS UP CLOSE
CF 7Ð0
A
Performs RLC A, but twice faster and preserves SF, ZF and PV.
Effects SF ZF HF PV NF CF
- - 0 - 0 Ù
CF set to: bit 7 of the original value
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)
Performs 9-bit right rotation of the contents of the operand s or memory addressed
by s through carry flag CF so that contents of CF are moved to bit 7 and bit 0 to
CF. Result is then stored back to s.
Effects SF ZF HF PV NF CF
Ù Ù 0 Ù 0 Ù
SF set if: result is negative (bit 7 is set)
ZF set if: result is 0
PV set if: result has even number of bits set
CF set to: bit 0 of the original value
191
CHAPTER 5. INSTRUCTIONS UP CLOSE
7Ñ0 CF
A
Performs RR A, but twice faster and preserves SF, ZF and PV.
Effects SF ZF HF PV NF CF
- - 0 - 0 Ù
CF set to: bit 0 of the original value
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)
Performs 8-bit rotation of the source s to the right. Bit 0 is moved to CF as well
as to bit 7. Result is then stored back to s.
Effects SF ZF HF PV NF CF
Ù Ù 0 Ù 0 Ù
SF set if: result is negative (bit 7 is set)
ZF set if: result is 0
PV set if: result has even number of bits set
CF set to: bit 0 of the original value
192
CHAPTER 5. INSTRUCTIONS UP CLOSE
Performs leftward 12-bit rotation of 4-bit nibbles where 2 least significant nibbles
are stored in memory location addressed by HL and most significant digit as lower 4
bits of the accumulator A.
If used with BCD numbers: as the shift happens by 1 digit to the left, this effectively
results in multiplication with 10. A acts as a sort of decimal carry in the operation.
Example of multiplying multi-digit BCD number by 10:
t
5 lp: RLD ; multiply by 10 (HL)
6 DEC HL ; prev 2 digits 5-7 0130 2 1
DJNZ lp ; number=1230, A=0 ÷
t
7
(HL)
8
t
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 or any other content.
7Ñ0 CF
A
Performs RRC A, but twice faster and preserves SF, ZF and PV.
Effects SF ZF HF PV NF CF
- - 0 - 0 Ù
CF set to: bit 0 of the original value
193
CHAPTER 5. INSTRUCTIONS UP CLOSE
Similar to RLD except rotation is to the right. If used with BCD values, this
operation effectively divides 3-digit BCD number by 10 and stores remainder in
A. Taking the example from RLD, we can easily convert it to division by 10 simply
by using RRD. Note however we also need to change the order - we start from MSB
now (which is exactly how division would be performed by hand):
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 -
Note: similar to RLD, this instruction also 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 or any other content.
194
CHAPTER 5. INSTRUCTIONS UP CLOSE
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 - - - - - -
Effects SF ZF HF PV NF CF
- - 0 - 0 1
195
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 - - - - - -
196
CHAPTER 5. INSTRUCTIONS UP CLOSE
197
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
Ù Ù 0 Ù 0 Ù
SF set if: result is negative (bit 7 is set)
ZF set if: result is 0
PV set if: result has even number of bits set
CF set to: bit 7 of the original value
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.
198
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
Ù Ù 0 Ù 0 Ù
SF set if: result is negative (bit 7 is set)
ZF set if: result is 0
PV set if: result has even number of bits set
CF set to: bit 0 of the original value
199
CHAPTER 5. INSTRUCTIONS UP CLOSE
200
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
8-bit Ù Ù Ù Ù 1 Ù
16-bit Ù Ù Ù Ù 1 Ù
SF set if: result is negative (bit 7 is set)
ZF set if: result is 0
HF set if: borrow from bit 4 (bit 12 for 16-bit)
PV set if: both operands positive and result negative
both operands negative and result positve
CF set if: borrow from bit 8 (bit 16 for 16-bit)
201
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
202
CHAPTER 5. INSTRUCTIONS UP CLOSE
A 7654 3210
Effects SF ZF HF PV NF CF
No effect on flags - - - - - -
Effects SF ZF HF PV NF CF
Ù Ù 1 Ù ? 0
203
CHAPTER 5. INSTRUCTIONS UP CLOSE
Effects SF ZF HF PV NF CF
Ù Ù 0 Ù 0 0
204
Appendix A
205
APPENDIX A. INSTRUCTIONS SORTED BY MNEMONIC
206
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
207
APPENDIX A. INSTRUCTIONS SORTED BY MNEMONIC
208
APPENDIX A. INSTRUCTIONS SORTED BY MNEMONIC
209
APPENDIX A. INSTRUCTIONS SORTED BY MNEMONIC
210
APPENDIX A. INSTRUCTIONS SORTED BY MNEMONIC
211
APPENDIX A. INSTRUCTIONS SORTED BY MNEMONIC
212
APPENDIX A. INSTRUCTIONS SORTED BY MNEMONIC
213
APPENDIX A. INSTRUCTIONS SORTED BY MNEMONIC
214
Appendix B
**
Instructions marked with are undocumented.
ZX
Instructions marked with are ZX Spectrum Next extended.
215
APPENDIX B. INSTRUCTIONS SORTED BY OPCODE
216
APPENDIX B. INSTRUCTIONS SORTED BY OPCODE
217
APPENDIX B. INSTRUCTIONS SORTED BY OPCODE
218
APPENDIX B. INSTRUCTIONS SORTED BY OPCODE
219
APPENDIX B. INSTRUCTIONS SORTED BY OPCODE
220
APPENDIX B. INSTRUCTIONS SORTED BY OPCODE
221
APPENDIX B. INSTRUCTIONS SORTED BY OPCODE
222
APPENDIX B. INSTRUCTIONS SORTED BY OPCODE
223
APPENDIX B. INSTRUCTIONS SORTED BY OPCODE
224
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.
225
APPENDIX C. BIBLIOGRAPHY
226
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.
227
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.
228
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.
229
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.
230
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
231
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.
232