SpecNext Wiki - User contributions [en-gb]

DMA

2024-01-06T15:56:25Z

Intrepidis: Layer2 auto-slowdown was lifted in Core 3.0

== Overview ==
The ZX Spectrum Next DMA (zxnDMA) is a single channel DMA 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 Spectrum computers and compatibles. It also adds a burst mode capability that can deliver audio at programmable sample rates to the DAC device.

== Accessing the zxnDMA ==
<del>The zxnDMA is mapped to a single Read/Write IO Port 0x6B which is the same one used by the Datagear but unlike the Datagear it doesn't also map itself to a second port 0x0B similar to the MB-02 interface.</del>

Since core 3.1.2 the zxnDMA is mapped to {{PortNo|$xx6B}}, and Zilog-DMA mode is mapped to {{PortNo|$xx0B}}.

== Description ==
The normal Z80 DMA (Z8410) chip is a pipelined device and because of that it has numerous off-by-one idiosyncrasies and requirements on the order that certain commands should be carried out. These issues are not duplicated in the zxnDMA. You can continue to program the zxnDMA as if it is were a Z8410 DMA device but it can also be programmed in a simpler manner.

The single channel of the zxnDMA chip consists of two ports named A and B. Transfers can occur in either direction between ports A and B, each port can describe a target in memory or IO, and each can be configured to autoincrement, autodecrement or stay fixed after a byte is transferred.

A special feature of the zxnDMA can force each byte transfer to take a fixed amount of time so that the zxnDMA can be used to deliver sampled audio.

== Modes of Operation ==
The zxnDMA can operate in a z80-DMA compatibility mode.

'''REMOVED in core 3.1.2:''' <del>The z80-DMA compatibility mode is selected by setting bit 6 of nextreg 0x06. In this mode, all transfers involve length+1 bytes which is the same behaviour as the z80-DMA chip. In zxn-DMA mode, the transfer length is exactly the number of bytes programmed. This mode is mainly present to accommodate existing spectrum software that uses the z80-DMA and for cp/m programs that may have a z80-DMA option.</del>

'''Since core 3.1.2:''' the DMA mode is selected by port number, the {{PortNo|$xx6B}} works in zxnDMA mode, {{PortNo|$xx0B}} works in Zilog mode. The bit 6 in {{NextRegNo|$06}} is not DMA related any more and will be reused for something different.

The zxnDMA can also operate in either burst or continuous modes.

Continuous mode means the DMA chip runs to completion without allowing the CPU to run. When the CPU starts the DMA, the DMA operation will complete before the CPU executes its next instruction.

Burst mode nominally means the DMA lets the CPU run if either port is not ready. This condition can't happen in the zxnDMA chip except when operated in the special fixed time transfer mode. In this mode, the zxnDMA will let the CPU run while it waits for the fixed time to expire between bytes transferred.

Note that there is no byte transfer mode as in the Z80 DMA.

== Programming the zxnDMA ==
Like the Z80 DMA chip, the zxnDMA has seven write registers named WR0-WR6 that control the device. Each register WR0-WR6 can have zero or more parameters associated with it.

In a first write to the zxnDMA port, the write value is compared against a bitmask to determine which of the WR0-WR6 is the target. Remaining bits in the written value can contain data as well as a list of associated parameter bits. The parameter bits determine if further writes are expected to deliver parameter values. If there are multiple parameter bits set, the expected order of parameter values written is determined by parameter bit position from right to left (bit 0 through bit 7). Once all parameters are written, the zxnDMA again expects a regular register write selecting WR0-WR6.

The table below describes the registers and the bitmask required to select them on the zxnDMA.

{|
! Register Group
! Register Function Description
! Bitmask
! Notes
|-
| WR0
| Direction, Operation and Port A configuration
| <pre>0XXXXXAA</pre>
| AA must NOT be 00
|-
| WR1
| Port A configuration
| <pre>0XXXX100</pre>
|
|-
| WR2
| Port B configuration
| <pre>0XXXX000</pre>
|
|-
| WR3
| Activation
| <pre>1XXXXX00</pre>
| It’s best to use WR6
|-
| WR4
| Port B, Timing and Interrupt configuration
| <pre>1XXXXX01</pre>
|
|-
| WR5
| Ready and Stop configuration
| <pre>10XXX010</pre>
|
|-
| WR6
| Command Register
| <pre>1XXXXX11</pre>
|
|}

== zxnDMA Registers ==
These are described below following the same convention used by Zilog for its DMA chip:

=== WR0 – Write Register Group 0 ===

<pre>D7 D6 D5 D4 D3 D2 D1 D0 BASE REGISTER BYTE
0 | | | | | | |
| | | | | 0 0 Do not use
| | | | | 0 1 Transfer (Prefer this for Z80 DMA compatibility)
| | | | | 1 0 Do not use (Behaves like Transfer, Search on Z80 DMA)
| | | | |
| | | | | 1 1 Do not use (Behaves like Transfer, Search/Transfer on Z80 DMA)
| | | | |
| | | | 0 = Port B -> Port A (Byte transfer direction)
| | | | 1 = Port A -> Port B
| | | V
D7 D6 D5 D4 D3 D2 D1 D0 PORT A STARTING ADDRESS (LOW BYTE)
| | V
D7 D6 D5 D4 D3 D2 D1 D0 PORT A STARTING ADDRESS (HIGH BYTE)
| V
D7 D6 D5 D4 D3 D2 D1 D0 BLOCK LENGTH (LOW BYTE)
V
D7 D6 D5 D4 D3 D2 D1 D0 BLOCK LENGTH (HIGH BYTE)</pre>

Several registers are accessible from WR0. The first write to WR0 is to the base register byte. Bits D6:D3 are optionally set to indicate that associated registers in this group will be written next. The order the writes come in are from D3 to D6 (right to left). For example, if bits D6 and D3 are set, the next two writes will be directed to PORT A STARTING ADDRESS LOW followed by BLOCK LENGTH HIGH.

=== WR1 – Write Register Group 1 ===

<pre>D7 D6 D5 D4 D3 D2 D1 D0 BASE REGISTER BYTE
0 | | | | 1 0 0
| | | |
| | | 0 = Port A is memory
| | | 1 = Port A is IO
| | |
| 0 0 = Port A address decrements
| 0 1 = Port A address increments
| 1 0 = Port A address is fixed
| 1 1 = Port A address is fixed
|
V
D7 D6 D5 D4 D3 D2 D1 D0 PORT A VARIABLE TIMING BYTE
0 0 0 0 0 0 | |
0 0 = Cycle Length = 4
0 1 = Cycle Length = 3
1 0 = Cycle Length = 2
1 1 = Do not use
</pre>

The cycle length is the number of cycles used in a read or write operation. The first cycle asserts signals and the last cycle releases them. There is no half cycle timing for the control signals.

=== WR2 – Write Register Group 2 ===

<pre>D7 D6 D5 D4 D3 D2 D1 D0 BASE REGISTER BYTE
0 | | | | 0 0 0
| | | |
| | | 0 = Port B is memory
| | | 1 = Port B is IO
| | |
| 0 0 = Port B address decrements
| 0 1 = Port B address increments
| 1 0 = Port B address is fixed
| 1 1 = Port B address is fixed
|
V
D7 D6 D5 D4 D3 D2 D1 D0 PORT B VARIABLE TIMING BYTE
0 0 | 0 0 0 | |
| 0 0 = Cycle Length = 4
| 0 1 = Cycle Length = 3
| 1 0 = Cycle Length = 2
| 1 1 = Do not use
|
V
D7 D6 D5 D4 D3 D2 D1 D0 ZXN PRESCALAR (FIXED TIME TRANSFER)
</pre>
The ZXN PRESCALAR is a feature of the zxnDMA implementation. If non-zero, a delay will be inserted after each byte is transferred such that the total time needed for each transfer is determined by the prescalar. This works in both the continuous mode and the burst mode. If the DMA is operated in burst mode, the DMA will give up any waiting time to the CPU so that the CPU can run while the DMA is idle.

The rate of transfer is given by the formula “Frate = 875kHz / prescalar” or, rearranged, “prescalar = 875kHz / Frate”. The formula is framed in terms of a sample rate (Frate) but Frate can be inverted to set a transfer time for each byte instead. The 875kHz constant is a nominal value assuming a 28MHz system clock; the system clock actually varies from this depending on the video timing selected by the user (HDMI, VGA0-6) so for complete accuracy the constant should be prorated according to documentation for nextreg 0x11.

In a DMA audio setting, selecting a sample rate of 16kHz would mean setting the prescalar value to 55. This sample period is constant across changes in CPU speed.

=== WR3 – Write Register Group 3 ===

<pre>D7 D6 D5 D4 D3 D2 D1 D0 BASE REGISTER BYTE
1 | 0 0 0 0 0 0
|
1 = DMA Enable
</pre>
The Z80 DMA defines more fields but they are ignored by the zxnDMA. The two other registers defined by the Z80 DMA in this group on D4 and D3 are implemented by the zxnDMA but they do nothing.

It is preferred to start the DMA by writing an 'Enable DMA' command to WR6.

=== WR4 – Write Register Group 4 ===

<pre>D7 D6 D5 D4 D3 D2 D1 D0 BASE REGISTER BYTE
1 | | 0 | | 0 1
| | | |
0 0 = Do not use (Behaves like Continuous mode, Byte mode on Z80 DMA)
0 1 = Continuous mode
1 0 = Burst mode
1 1 = Do not use
| |
| V
D7 D6 D5 D4 D3 D2 D1 D0 PORT B STARTING ADDRESS (LOW BYTE)
|
V
D7 D6 D5 D4 D3 D2 D1 D0 PORT B STARTING ADDRESS (HIGH BYTE)
</pre>
The Z80 DMA defines three more registers in this group through D4 that define interrupt behaviour. Interrups and pulse generation are not implemented in the zxnDMA nor are these registers available for writing.

=== WR5 – Write Register Group 5 ===
<pre>D7 D6 D5 D4 D3 D2 D1 D0 BASE REGISTER BYTE
1 0 | | 0 0 1 0
| |
| 0 = /ce only
| 1 = /ce & /wait multiplexed
|
0 = Stop on end of block
1 = Auto restart on end of block
</pre>
The /ce & /wait mode is implemented in the zxnDMA but is not currently used. This mode has an external device using the DMA's /ce pin to insert wait states during the DMA's transfer.

The auto restart feature causes the DMA to automatically reload its source and destination addresses and reset its byte counter to zero to repeat the last transfer when a previous one is finished.

=== WR6 – Command Register ===
<pre>D7 D6 D5 D4 D3 D2 D1 D0 BASE REGISTER BYTE
1 ? ? ? ? ? 1 1
| | | | |
1 0 0 0 0 = 0xC3 = Reset
1 0 0 0 1 = 0xC7 = Reset Port A Timing
1 0 0 1 0 = 0xCB = Reset Port B Timing
0 1 1 0 0 = 0xB3 = Force Ready (irrelevant for zxnDMA)
0 1 1 1 1 = 0xBF = Read Status Byte
0 0 0 1 0 = 0x8B = Reinitialize Status Byte
0 1 0 0 1 = 0xA7 = Initialize Read Sequence
1 0 0 1 1 = 0xCF = Load
1 0 1 0 0 = 0xD3 = Continue
0 0 0 0 1 = 0x87 = Enable DMA
0 0 0 0 0 = 0x83 = Disable DMA
+-- 0 1 1 1 0 = 0xBB = Read Mask Follows
|
D7 D6 D5 D4 D3 D2 D1 D0 READ MASK
0 | | | | | | |
| | | | | | V
D7 D6 D5 D4 D3 D2 D1 D0 Status Byte
| | | | | |
| | | | | V
D7 D6 D5 D4 D3 D2 D1 D0 Byte Counter Low ("High" with core 3.0.5 = bug in core)
| | | | |
| | | | V
D7 D6 D5 D4 D3 D2 D1 D0 Byte Counter High ("Low" with core 3.0.5 = bug in core)
| | | |
| | | V
D7 D6 D5 D4 D3 D2 D1 D0 Port A Address Low
| | |
| | V
D7 D6 D5 D4 D3 D2 D1 D0 Port A Address High
| |
| V
D7 D6 D5 D4 D3 D2 D1 D0 Port B Address Low
|
V
D7 D6 D5 D4 D3 D2 D1 D0 Port B Address High
</pre>
Unimplemented Z80 DMA commands are ignored.

Prior to starting the DMA, a LOAD command must be issued to copy the Port A and Port B addresses into the DMA's internal pointers. Then an 'Enable DMA' command is issued to start the DMA.

The 'Continue' command resets the DMA's byte counter so that a following 'Enable DMA' allows the DMA to repeat the last transfer but using the current internal address pointers. I.e. it continues from where the last copy operation left off.

Registers can be read via an IO read from the DMA port after setting the read mask. (At power up the read mask is set to 0x7f). Register values are the current internal DMA counter values. So 'Port Address A Low' is the lower 8-bits of Port A’s next transfer address. Once the end of the read mask is reached, further reads loop around to the first one.

The format of the DMA status byte is as follows:

<pre>00E1101T</pre>

E is set to 0 if the total block length has been transferred at least once.

T is set to 1 if at least one byte has been transferred.

== Operating speed ==
The zxnDMA operates at the same speed as the CPU, that is 3.5MHz, 7MHz, 14MHz or 28Mhz. This is a contended clock that is modified by the ULA and the auto-slowdown by [[Layer 2|Layer2]] (which only occurred in Next core's 1 and 2, the limitation was lifted in core 3.0).

The (pre-core 3.0) auto-slowdown occurs without user intervention if speed exceeds 7Mhz and the active Layer2 display is being generated (higher speed operation resumes when the active Layer2 display is not generated). Programmers do NOT need to account for speed differences regarding DMA transfers as this happens automatically.

Because of this, the cycle lengths for Ports A and B can be set to their minimum values without ill effects. The cycle lengths specified for Ports A and B are intended to selectively slow down read or write cycles for hardware that cannot operate at the DMA's full speed.

== The DMA and Interrupts ==
The zxnDMA cannot currently generate [[Interrupts|interrupts]].

The other side of this is that while the DMA controls the bus, the Z80 cannot respond to interrupts. 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. In burst mode, with large-enough prescalar value, the CPU will never miss these interrupts, although this may change if multiple channels are implemented.

== Programming examples ==
A simple way to program the DMA is to walk down the list of registers WR0-WR5, sending desired settings to each. Then start the DMA by sending a LOAD command followed by an ENABLE_DMA command to WR6. Once more familiar with the DMA, you will discover that the amount of information sent can be reduced to what changes between transfers.

=== Assembly ===
Short example program to DMA memory to the screen, then DMA a sprite image from memory to sprite RAM, and then showing said sprite scrolling across the screen.

<pre>;------------------------------------------------------------------------------
; sjasmplus extra options to enable Z80N, stricter syntax and Next device
opt --zxnext --syntax=abf : device zxspectrumnext
;------------------------------------------------------------------------------
; DEFINE testing ; uncomment to produce NEX file (instead of DOT)
;------------------------------------------------------------------------------
; DMA (Register 6)
;
;------------------------------------------------------------------------------
;zxnDMA programming example
;------------------------------------------------------------------------------
;(c) Jim Bagley
;------------------------------------------------------------------------------
DMA_RESET equ $c3
DMA_RESET_PORT_A_TIMING equ $c7
DMA_RESET_PORT_B_TIMING equ $cb
DMA_LOAD equ $cf ; %11001111
DMA_CONTINUE equ $d3
DMA_DISABLE_INTERUPTS equ $af
DMA_ENABLE_INTERUPTS equ $ab
DMA_RESET_DISABLE_INTERUPTS equ $a3
DMA_ENABLE_AFTER_RETI equ $b7
DMA_READ_STATUS_BYTE equ $bf
DMA_REINIT_STATUS_BYTE equ $8b
DMA_START_READ_SEQUENCE equ $a7
DMA_FORCE_READY equ $b3
DMA_DISABLE equ $83
DMA_ENABLE equ $87
DMA_WRITE_REGISTER_COMMAND equ $bb
DMA_BURST equ %11001101
DMA_CONTINUOUS equ %10101101
ZXN_DMA_PORT equ $6b
SPRITE_STATUS_SLOT_SELECT equ $303B
SPRITE_IMAGE_PORT equ $5b
SPRITE_INFO_PORT equ $57
;------------------------------------------------------------------------------

IFDEF testing
org $5800
block 32*24, $38 ; default ULA attributes
org $6000
ELSE
org $2000
ENDIF

start
ld hl,$0000
ld de,$4000
ld bc,$800
call TransferDMA ; copy some random data to the screen pointing
; to ROM for now, for the purpose of showing
; how to do a DMA copy.
ld a,0 ; sprite image number we want to update
ld bc,SPRITE_STATUS_SLOT_SELECT
out (c),a ; set the sprite image number
ld bc,1*256 ; number to transfer (1)
ld hl,testsprite ; from
call TransferDMASprite ; transfer to sprite ram

nextreg 21,1 ; turn sprite on. for more info on this check
; out https://www.specnext.com/tbblue-io-port-system/
ld de,0
ld (xpos),de ; set initial X position ( doesn't need it for
; this demo, but if you run the .loop again it
; will continue from where it was
ld a,$20
ld (ypos),a ; set initial Y position

.loop
ld a,0 ; sprite number we want to position
ld bc,SPRITE_STATUS_SLOT_SELECT
out (c),a
ld de,(xpos)
ld hl,(ypos) ; ignores H so doing this rather than
; ld a,(ypos):ld l,a
ld bc,(image) ; not flipped or palette shifted
call SetSprite

halt

ld de,(xpos)
inc de
ld (xpos),de
ld a,d
cp $01
jr nz,.loop ; if high byte of xpos is not 1 (right of
; screen )
ld a,e
cp $20+1
jr nz,.loop ; if low byte is not $21 just off the right of
; the screen, $20 is off screen but as the
; INC DE is just above and not updated sprite
; after it, it needs to be $21
xor a
ret ; return back to basic with OK

xpos dw 0 ; x position
ypos db 0 ; y position
; these next two BITS and IMAGE are swapped
; as bits needs to go into B register
image db 0+$80 ; use image 0 (for the image we transfered)
; +$80 to set the sprite to active
bits db 0 ; not flipped or palette shifted

c1 = %11100000
c2 = %11000000
c3 = %10100000
c4 = %10000000
c5 = %01100000
c6 = %01000000
c7 = %00100000
c8 = %00000000

testsprite
db c1,c1,c1,c1,c1,c1,c1,c1,c1,c1,c1,c1,c1,c1,c1,c1
db c1,c2,c2,c2,c2,c2,c2,c2,c2,c2,c2,c2,c2,c2,c2,c1
db c1,c2,c3,c3,c3,c3,c3,c3,c3,c3,c3,c3,c3,c3,c2,c1
db c1,c2,c3,c4,c4,c4,c4,c4,c4,c4,c4,c4,c4,c3,c2,c1
db c1,c2,c3,c4,c5,c5,c5,c5,c5,c5,c5,c5,c4,c3,c2,c1
db c1,c2,c3,c4,c5,c6,c6,c6,c6,c6,c6,c5,c4,c3,c2,c1
db c1,c2,c3,c4,c5,c6,c7,c7,c7,c7,c6,c5,c4,c3,c2,c1
db c1,c2,c3,c4,c5,c6,c7,c8,c8,c7,c6,c5,c4,c3,c2,c1
db c1,c2,c3,c4,c5,c6,c7,c8,c8,c7,c6,c5,c4,c3,c2,c1
db c1,c2,c3,c4,c5,c6,c7,c7,c7,c7,c6,c5,c4,c3,c2,c1
db c1,c2,c3,c4,c5,c6,c6,c6,c6,c6,c6,c5,c4,c3,c2,c1
db c1,c2,c3,c4,c5,c5,c5,c5,c5,c5,c5,c5,c4,c3,c2,c1
db c1,c2,c3,c4,c4,c4,c4,c4,c4,c4,c4,c4,c4,c3,c2,c1
db c1,c2,c3,c3,c3,c3,c3,c3,c3,c3,c3,c3,c3,c3,c2,c1
db c1,c2,c2,c2,c2,c2,c2,c2,c2,c2,c2,c2,c2,c2,c2,c1
db c1,c1,c1,c1,c1,c1,c1,c1,c1,c1,c1,c1,c1,c1,c1,c1

;-------------------------------------------------
; de = X
; l = Y
; b = bits
; c = sprite image
SetSprite
push bc
ld bc,SPRITE_INFO_PORT
out (c),e ; Xpos
out (c),l ; Ypos
pop hl
ld a,d
and 1
or h
out (c),a
ld a,l:or $80
out (c),a ; image
ret

;--------------------------------
; hl = source
; de = destination
; bc = length
;--------------------------------
TransferDMA
di
ld (DMASource),hl
ld (DMADest),de
ld (DMALength),bc
ld hl,DMACode
ld b,DMACode_Len
ld c,ZXN_DMA_PORT
otir
ei
ret

DMACode db DMA_DISABLE
db %01111101 ; R0-Transfer mode, A -> B, write adress
; + block length
DMASource dw 0 ; R0-Port A, Start address
; (source address)
DMALength dw 0 ; R0-Block length (length in bytes)
db %01010100 ; R1-write A time byte, increment, to
; memory, bitmask
db %00000010 ; 2t
db %01010000 ; R2-write B time byte, increment, to
; memory, bitmask
db %00000010 ; R2-Cycle length port B
db DMA_CONTINUOUS ; R4-Continuous mode (use this for block
; transfer), write dest adress
DMADest dw 0 ; R4-Dest address (destination address)
db %10000010 ; R5-Restart on end of block, RDY active
; LOW
db DMA_LOAD ; R6-Load
db DMA_ENABLE ; R6-Enable DMA

DMACode_Len equ $-DMACode

;------------------------------------------------------------------------------
; hl = source
; bc = length
; set port to write to with TBBLUE_REGISTER_SELECT
; prior to call
;------------------------------------------------------------------------------
TransferDMAPort
di
ld (DMASourceP),hl
ld (DMALengthP),bc
ld hl,DMACodeP
ld b,DMACode_LenP
ld c,ZXN_DMA_PORT
otir
ei
ret

DMACodeP db DMA_DISABLE
db %01111101 ; R0-Transfer mode, A -> B, write adress
; + block length
DMASourceP dw 0 ; R0-Port A, Start address (source address)
DMALengthP dw 0 ; R0-Block length (length in bytes)
db %01010100 ; R1-read A time byte, increment, to
; memory, bitmask
db %00000010 ; R1-Cycle length port A
db %01101000 ; R2-write B time byte, increment, to
; memory, bitmask
db %00000010 ; R2-Cycle length port B
db %10101101 ; R4-Continuous mode (use this for block
; transfer), write dest adress
dw $253b ; R4-Dest address (destination address)
db %10000010 ; R5-Restart on end of block, RDY active
; LOW
db DMA_LOAD ; R6-Load
db DMA_ENABLE ; R6-Enable DMA

DMACode_LenP equ $-DMACodeP
;------------------------------------------------------------------------------
; hl = source
; bc = length
;------------------------------------------------------------------------------
TransferDMASprite
di
ld (DMASourceS),hl
ld (DMALengthS),bc
ld hl,DMACodeS
ld b,DMACode_LenS
ld c,ZXN_DMA_PORT
otir
ei
ret

DMACodeS db DMA_DISABLE
db %01111101 ; R0-Transfer mode, A -> B, write adress
; + block length
DMASourceS dw 0 ; R0-Port A, Start address (source address)
DMALengthS dw 0 ; R0-Block length (length in bytes)
db %01010100 ; R1-read A time byte, increment, to
; memory, bitmask
db %00000010 ; R1-Cycle length port A
db %01101000 ; R2-write B time byte, increment, to
; memory, bitmask
db %00000010 ; R2-Cycle length port B
db %10101101 ; R4-Continuous mode (use this for block
; transfer), write dest adress
dw SPRITE_IMAGE_PORT ; R4-Dest address (destination address)
db %10000010 ; R5-Restart on end of block, RDY active
; LOW
db DMA_LOAD ; R6-Load
db DMA_ENABLE ; R6-Enable DMA
DMACode_LenS equ $-DMACodeS
;------------------------------------------------------------------------------
; de = dest, a = fill value, bc = lenth
;------------------------------------------------------------------------------
DMAFill
di
ld (FillValue),a
ld (DMACDest),de
ld (DMACLength),bc
ld hl,DMACCode
ld b,DMACCode_Len
ld c,ZXN_DMA_PORT
otir
ei
ret

FillValue db 22
DMACCode db DMA_DISABLE
db %01111101
DMACSource dw FillValue
DMACLength dw 0
db %00100100,%00010000,%10101101
DMACDest dw 0
db DMA_LOAD,DMA_ENABLE
DMACCode_Len equ $-DMACCode

;------------------------------------------------------------------------------
; End of file
;------------------------------------------------------------------------------

IFDEF testing
savenex open "DMAtest.nex", start, $FF00
savenex bank 5
ELSE
fin
savebin "DMATEST",start,fin-start
ENDIF
</pre>

Based on original text by: Allen Albright & Mike Dailly with input by Jim Bagley, Lyndon J Sharp and Phoebus R. Dokos

== Technical details (core 3.1.3+) ==

The Zilog/zxnDMA mode is now selected by using the particular I/O port number ({{PortNo|$xx6B}} for zxnDMA mode, {{PortNo|$xx0B}} for Zilog mode). The bit 6 in {{NextRegNo|$06}} is not DMA related any more and will be reused for something different.

The "counter" RR1-RR2 read back after transfer has correct byte order since core 3.1.4.

Other differences described below in "3.0.5" remains (but from practical point of view the Zilog DMA emulation in 3.1.4 is near-perfect, all the remaining differences are very minor).

== Technical details (core 3.0.5) ==

=== Zilog DMA compatibility mode ===
In Zilog DMA compatibility mode (bit 6 of {{NextRegNo|$06}}) the zxnDMA will mostly work as expected, but there are few differences in behaviour which may eventually throw off some rare SW, here is the list of the known differences (most of them describe also how the zxnDMA mode works):

The LOAD command must be issued with correct transfer direction, loading addresses in opposite direction and flipping direction afterward will mismatch the source/destination address data (Zilog/UA858D DMA chips are also sensitive to direction flip after LOAD, but the resulting transfer quirks in different way, reading source data byte after write, offsetting whole transfer by one and damaging start/end of sequence).
(does apply also to zxnDMA mode)

The LOAD command will NOT destroy the already issued "Initialize Read Sequence" - this is how even the original Zilog documentation describes the DMA chip operation, but the real Zilog DMA and UA858D (clone chip) both destroy read sequence upon LOAD command (zxnDMA is better).
(does apply also to zxnDMA mode)

The content of registers read back after finished transfer differs: the counter has swapped LSB with MSB byte, and both addresses will be adjusted length+1 times (Zilog/UA858D will return destination address adjusted only length-many times).
(does apply also to zxnDMA mode, except addresses are adjusted only "length" times of course, counter has still swapped bytes)

Any read of zxnDMA port without pending read request (commands "Read Status Byte" or "Initialize Read Sequence") will return status byte (Zilog will return random value vaguely similar to status byte, but incorrect, UA858D will return zero).
(does apply also to zxnDMA mode)

Status byte doesn't have bit 0 set (the "T" bit in description above).
(does apply also to zxnDMA mode)

Be aware that both custom timing cycles count, and prescalar values are preserved in zxnDMA even when future write to WR1/WR2 does skip these particular bytes. To reset prescalar or cycles timing, write explicitly zero into prescalar register or use commands reset/reset-port-timing.
(does apply also to zxnDMA mode, the prescalar works only in zxnDMA mode)

The destination port address is LOAD-ed even when it is "fixed" type (Contrary to Zilog DMA, which requires you to load such port as "source", flip the direction after and re-LOAD again with correct direction. UA858D chip does also load destination port address in any case, just like zxnDMA).
(does apply also to zxnDMA mode)

=== zxnDMA mode vs Zilog mode ===

In zxnDMA mode length of transfer is equal to the length written to WR0 register, port addresses are adjusted also only length-times.

Prescalar value will affect speed of transfer (use zero to switch prescalar off) (in burst mode during the extra idle time the CPU receives control back and can execute further instructions, in continuous mode the transfer will keep blocking CPU even when "slow" transfer is being done).

Sprites

2019-05-05T10:46:43Z

Intrepidis: Fix formatting in the Global Control of Sprites section.

The Spectrum Next has a hardware sprite system with the following characteristics:

* Total of 128 sprites
* Display surface is 320×256 overlapping the ULA screen by 32 pixels on each side
* Minimum of 100 sprites per scanline*
* Choice of 512 colours for each pixel
* Site of each sprite is 16×16 pixels but sprites can be magnified 2x, 4x or 8x horizontally and vertically
* Sprites can be mirrored and rotated
* Sprites can be grouped together to form larger sprites under the control of a single anchor
* A 16K pattern memory can contain 64 8-bit sprite images or 128 4-bit sprite images and combinations in-between
* A per sprite palette offset allows sprites to share images but colour them differently
* A nextreg interface allows the copper to move sprites during the video frame

<nowiki>*</nowiki>A minimum of 100 16×16 sprites is guaranteed to be displayed in any scanline. Any additional sprites will not be displayed with the hardware ensuring sprites are not partially plotted.

The actual limit is determined by how many 28MHz clock cycles there are in a scanline. The sprite hardware is able to plot one pixel cycle and uses one cycle to qualify each sprite. Since the number of cycles there are in a scanline varies with video timing (HDMI, VGA), the number of pixels that can be plotted also varies but the minimum will be 1600 pixels per line including overhead cycles needed to qualify 100 sprites. Since sprites magified horizontally involve plotting more pixels, x2 x4 x8 sprites will take more cycles to plot and the presence of these sprites in a line will reduce the total number of sprites that can be plotted.

== Sprite Patterns ==
Sprite patterns are the images that each sprite can take on. The images are stored in a 16K memory internal to the FPGA and are identified by pattern number. A particular sprite chooses a pattern by storing a pattern number in its attributes.

All sprites are 16×16 pixels in size but the come in two flavours: 4-bit and 8-bit. The bit width describes how many bits are used to code the colour of each pixel.

An 8-bit sprite uses a full byte to colour each of its pixels so that each pixel can be one of 256 colours. In this case, a 16×16 sprite requires 256 bytes of pattern memory to store its image.

A 4-bit sprite uses a nibble to colour each of its pixels so that each pixel can be one of 16 colours. In this case, a 16×16 sprite requires just 128 bytes of pattern memory to store its image.

The 16K pattern memory can contain any combination of these images, whether they are 128 bytes or 256 bytes and their locations in the pattern memory are described by a pattern number. This pattern number is 7 bits with bits named as follows:

=== Pattern Number ===
<pre>N5 N4 N3 N2 N1 N0 N6
N6, despite the name, is the least significant bit.</pre>

This 7-bit pattern number can identify 128 patterns in the 16k pattern memory, each of which are 128 bytes in size. The full 7-bits are therefore used for 4-bit sprites.

For 8-bit sprites, N6=0 always. The remaining 6 bits can identify 64 patterns, each of which is 256 bytes in size.

The N5:N0,N6 bits are stored in a particular sprite’s attributes to identify which image a sprite uses.

=== 8-Bit Sprite Patterns ===
The 16×16 pixel image uses 8-bits for each pixel so that each pixel can be one of 256 colours. One colour indicates transparency and this is programmed into the Sprite Transparency Index register (nextreg 0x4B). By default the transparent value is 0xE3.

As an example of an 8-bit sprite, let’s have a look at the sprite below:

[[File:Sprite_1.png|frame|center|Pattern example]]

Using the default palette, which is initialised with RGB332 colours from 0-255, the hexadecimal values for this pattern arranged in a 16×16 array are shown below:

<pre>04040404040404E3E3E3E3E3E3E3E3E3
04FFFFFFFFFF04E3E3E3E3E3E3E3E3E3
04FFFBFBFBFF04E3E3E3E3E3E3E3E3E3
04FFFBF5F5FBFF04E3E3E3E3E3E3E3E3
04FFFBF5A8A8FBFF04E3E3E3E3E3E3E3
04FFFFFBA844A8FBFF04E3E3E3E3E3E3
040404FFFBA844A8FBFF04E3E3E3E3E3
E3E3E304FFFBA84444FBFF04E304E3E3
E3E3E3E304FFFB444444FBFF044D04E3
E3E3E3E3E304FFFB44444444FA4D04E3
E3E3E3E3E3E304FFFB44FFF54404E3E3
E3E3E3E3E3E3E304FF44F5A804E3E3E3
E3E3E3E3E3E3E3E304FA4404A804E3E3
E3E3E3E3E3E3E3044D4D04E304F504E3
E3E3E3E3E3E3E3E30404E3E3E304FA04
E3E3E3E3E3E3E3E3E3E3E3E3E3E30404</pre>

Here 0xE3 is used as the transparent index.

These 256 bytes would be stored in pattern memory in left to right, top to bottom order.

=== 4-Bit Sprite Patterns ===
The 16×16 pixel image uses 4-bits for each pixel so that each pixel can be one of 16 colours. One colour indicates transparency and this is programmed into the lower 4-bits of the Sprite Transparency Index register (nextreg 0x4B). By default the transparency value is 0x3. Note that the same register is shared with 8-bit patterns to identify the transparent index.

Since each pixel only occupies 4-bits, two pixels are stored in each byte. The leftmost pixel is stored in the upper 4-bits and the rightmost pixel is stored in the lower 4-bits.

As an example we will use the same sprite image as was given in the 8-bit pattern example. Here only the lower 4 bits of each pixel is retained to confine each pixel’s color to 4-bits:

<pre>4444444333333333
4FFFFF4333333333
4FBBBF4333333333
4FB55BF433333333
4FB588BF43333333
4FFB848BF4333333
444FB848BF433333
3334FB844BF43433
33334FB444BF4D43
333334FB4444AD43
3333334FB4F54433
33333334F4584333
333333334A448433
33333334DD434543
33333333443334A4
3333333333333344</pre>

0x3 is used as the transparent index.

These 128 bytes would be stored in pattern memory in left to right, top to bottom order.

The actual colour that will appear on screen will depend on the palette, described below. The default palette will not likely generate suitable colours for 4-bit sprites.

=== Sprite Palette ===
Each pixel of a sprite image is 8-bit for 8-bit patterns or 4-bit for 4-bit patterns. The pixel value is known as a pixel colour index. This colour index is combined with the sprite’s palette offset. The palette offset is a 4-bit value added to the top 4-bits of the pixel colour index. The purpose of the palette offset is to allow a sprite to change the colour of an image.

The final sprite colour index generated by the sprite hardware is then the sum of the pixel index and the 4-bit palette offset. In pictures using binary math:

<pre>8-bit Sprite
PPPP0000
+ IIIIIIII
----------
SSSSSSSS

4-bit Sprite
PPPP0000
+ 0000IIII
----------
SSSSSSSS = PPPPIIII</pre>

Where “PPPP” is the 4-bit palette offset from the sprite’s attributes and the “I”s represent the pixel value from the sprite pattern. The final sprite index is represented by the 8-bit value “SSSSSSSS”.

For 4-bit sprites the palette offset can be thought of as selecting one of 16 different 16-colour palettes.

This final 8-bit sprite index is then passed through the sprite palette which acts like a lookup table that returns the 9-bit RGB333 colour associated with the sprite index.

At power up, the sprite palette is initialized such that the sprite index passes through unchanged and is therefore interpretted as an RGB332 colour. The missing third blue bit is generated as the logical OR of the two other blue bits. In short, for 8-bit sprites, the sprite index also acts like the colour when using the default palette.

=== Sprite Attributes ===
A sprite’s attributes is a list of properties that determine how and where the sprite is drawn.

Each sprite is described by either 4 or 5 attribute bytes listed below:

==== Sprite Attribute 0 ====
<pre>X X X X X X X X</pre>
The least significant eight bits of the sprite’s X coordinate. The ninth bit is found in sprite attribute 2.

==== Sprite Attribute 1 ====
<pre>Y Y Y Y Y Y Y Y</pre>
The least significant eight bits of the sprite’s Y coordinate. The ninth bit is optional and is found in attribute 4.

==== Sprite Attribute 2 ====
<pre>P P P P XM YM R X8/PR</pre>

P = 4-bit Palette Offset 
XM = 1 to mirror the sprite image horizontally 
YM = 1 to mirror the sprite image vertically 
R = 1 to rotate the sprite image 90 degrees clockwise 
X8 = Ninth bit of the sprite’s X coordinate 
PR = 1 to indicate P is relative to the anchor’s palette offset (relative sprites only)

Rotation is applied before mirroring. 
Relative sprites, described below, replace X8 with PR.

[[File:Sprite_flags.png|frame|center|All possibilities of Rotate, Mirror X and Mirror Y flags.]]

==== Sprite Attribute 3 ====
<pre>V E N5 N4 N3 N2 N1 N0</pre>
V = 1 to make the sprite visible 
E = 1 to enable attribute byte 4 
N = Sprite pattern to use 0-63

If E=0, the sprite is fully described by sprite attributes 0-3. The sprite pattern is an 8-bit one identified by pattern N=0-63. The sprite is an anchor and cannot be made relative. The sprite is displayed as if sprite attribute 4 is zero.

If E=1, the sprite is further described by sprite attribute 4.

==== Sprite Attribute 4 ====
===== A. Extended Anchor Sprite =====
<pre>H N6 T X X Y Y Y8</pre>
H = 1 if the sprite pattern is 4-bit 
N6 = 7th pattern bit if the sprite pattern is 4-bit 
T = 0 if relative sprites are composite type else 1 for unified type 
XX = Magnification in the X direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x) 
YY = Magnification in the Y direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x) 
Y8 = Ninth bit of the sprite’s Y coordinate

{H,N6} must not equal {0,1} as this combination is used to indicate a relative sprite.

===== B. Relative Sprite, Composite Type =====
<pre>0 1 N6 X X Y Y PO</pre>
N6 = 7th pattern bit if the sprite pattern is 4-bit 
XX = Magnification in the X direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x) 
YY = Magnification in the Y direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x) 
PO = 1 to indicate the sprite pattern number is relative to the anchor’s

===== C. Relative Sprite, Unified Type =====
<pre>0 1 N6 0 0 0 0 PO</pre>
N6 = 7th pattern bit if the sprite pattern is 4-bit 
PO = 1 to indicate the sprite pattern number is relative to the anchor’s

The display surface for sprites is 320×256. The X coordinate of the sprite is nine bits, ranging over 0-511, and the Y coordinate is optionally nine bits again ranging over 0-511 or is eight bits ranging over 0-255. The full extent 0-511 wraps on both axes, meaning a sprite 16 pixels wide plotted at X coordinate 511 would see its first pixel not displayed (coordinate 511) and the following pixels displayed in coordinates 0-14.

The full display area is visible in VGA. However, the HDMI display is vertically shorter so the top eight pixel rows (Y = 0-7) and the bottom eight pixel rows (Y = 248-255) will not be visible on an HDMI display.

Sprites can be fully described by sprite attributes 0-3 if the E bit in sprite attribute 3 is zero. These sprites are compatible with the original sprite module from core versions prior to 2.00.26.

If the E bit is set then a fifth sprite attribute, sprite attribute 4, becomes active. This attribute introduces scaling, 4-bit patterns, and relative sprites. Scaling is self-explanatory and 4-bit patterns were described in the last section. Relative sprites are described in the next section.

=== Relative Sprites ===
Normal sprites (sprites that are not relative) are known as anchor sprites. As the sprite module draws sprites in the order 0-127 (there are 128 sprites), it internally stores characteristics of the last anchor sprite seen. If following sprites are relative, they inherit some of these characteristics, which allows relative sprites to have, among other things, coordinates relative to the anchor. This means moving the anchor sprite also causes its relatives to move with it.

There are two types of relative sprites supported known as “Composite Sprites” and “Unified Sprites”. The type is determined by the anchor in the T bit of sprite attribute 4.

==== A. Composite Sprites ====
The sprite module records the following information from the anchor:

* Anchor.visible
* Anchor.X
* Anchor.Y
* Anchor.palette_offset
* Anchor.N (pattern number)
* Anchor.H (indicates if the sprite uses 4-bit patterns)

These recorded items are not used by composite sprites:

* Anchor.rotate
* Anchor.xmirror
* Anchor.ymirror
* Anchor.xscale
* Anchor.yscale

The anchor determines if all its relative sprites use 4-bit patterns or not.

The visibility of a particular relative sprite is the result of ANDing the anchor’s visibility with the relative sprite’s visibility. In other words, if the anchor is invisible then so are all its relatives.

Relative sprites only have 8-bit X and Y coordinates (the ninth bits are taken for other purposes). These are signed offsets from the anchor’s X,Y coordinate. Moving the anchor moves all its relatives along with it.

If the relative sprite has its PR bit set in sprite attribute 2, then the anchor’s palette offset is added to the relative sprite’s to determine the active palette offset for the relative sprite. Otherwise the relative sprite uses its own palette offset as usual.

If the relative sprite has its PO bit set in sprite attribute 4, then the anchor’s pattern number is added to the relative sprite’s to determine the pattern used for display. Otherwise the relative sprite uses its own pattern number as usual. The intention is to supply a method to easily animate a large sprite by manipulating the pattern number in the anchor.

A composite sprite is like a collection of independent sprites tied to an anchor.

==== B. Unified Sprites ====
Unified sprites are a further extension of the composite type. The same information is recorded from the anchor and the same behaviour as described under composite sprites applies.

The difference is the collection of anchor and relatives is treated as if it were a single 16×16 sprite. The anchor’s rotation, mirror, and scaling bits apply to all its relatives. Rotating the anchor causes all the relatives to rotate around the anchor. Mirroring the anchor causes the relatives to mirror around the anchor. The sprite hardware will automatically adjust X,Y coords and rotation, scaling and mirror bits of all relatives according to settings in the anchor.

Unified sprites should be defined as if all its parts are 16×16 in size with the anchor controlling the look of the whole.

A unified sprite is like a big version of an individual 16×16 sprite controlled by the anchor.

=== Programming Sprites ===
Sprites are created via three io registers and a nextreg interface.

Port 0x303B (W)

<pre>X S S S S S S S
N6 X N N N N N N</pre>

A write to this port has two effects.

One is it selects one of 128 sprites for writing sprite attributes via port 0x57.

The other is it selects one of 128 4-bit patterns in pattern memory for writing sprite patterns via port 0x5B. The N6 bit shown is the least significant in the 7-bit pattern number and should always be zero when selecting one of 64 8-bit patterns indicated by N.

Port 0x57 (W)

Once a sprite is selected via port 0x303B, its attributes can be written to this port one byte after another. Sprites can have either four or five attribute bytes and the internal attribute pointer will move onto the next sprite after those four or five attribute bytes are written. This means you can select a sprite via port 0x303B and write attributes for as many sequential sprites as desired. The attribute pointer will roll over from sprite 127 to sprite 0.

Port 0x5B (W)

Once a pattern number is selected via port 0x303B, the 256-byte or 128-byte pattern can be written to this port. The internal pattern pointer auto-increments after each write so as many sequential patterns as desired can be written. The internal pattern pointer will roll over from pattern 127 to pattern 0 (4-bit patterns) or from pattern 63 to pattern 0 (8-bit patterns) automatically.

Port 0x303B (R)

<pre>0 0 0 0 0 0 M C</pre>

M = 1 if the maximum number of sprites per line was exceeded 
C = 1 if any two displayed sprites collide on screen

Reading this port automatically resets the M and C bits.

Besides the i/o interface, there is a nextreg interface to sprite attributes. The nextreg interface allows the copper to manipulate sprites and grants the program random access to a sprite’s individual attribute bytes.

(R/W) 0x34 (52) => Sprite Number 
If the sprite number is in lockstep with io port 0x303B (nextreg 0x09 bit 4 is set) 
bits 7 = Pattern address offset (Add 128 to pattern address) 
bits 6-0 = Sprite number 0-127, Pattern number 0-63 
Selects which sprite has its attributes connected to the following registers. 
Effectively performs an out to port 0x303B with the same value 
Otherwise 
bit 7 = Ignored 
bits 6-0 = Sprite number 0-127 
Selects which sprite has its attributes connected to the following registers. 
Bit 7 always reads back as zero.

This nextreg can operate in two modes.

If nextreg 0x09 bit 4 is set, then this register is kept in lockstep with i/o port 0x303B. A write to this nextreg is equivalent to a write to port 0x303B and vice versa. In this mode, the i/o interface and nextreg interface are exactly equivalent.

If nextreg 0x09 bit 4 is reset, then the nextreg interface is decoupled from i/o port 0x303B. This nextreg is used to select a particular sprite 0-127 and this is completely independent from the sprite selected for the i/o interface. This independence allows the copper, for example, to manipulate different sprites than the cpu using the i/o interface.

(W) 0x35 (53) => Sprite Attribute 0 
(W) 0x75 (117) => Sprite Attribute 0 with automatic post increment of Sprite Number 
bits 7-0 = LSB of X coordinate

A write to nextreg 0x75 also increases the selected sprite in nextreg 0x34.

(W) 0x36 (54) => Sprite Attribute 1 
(W) 0x76 (118) => Sprite Attribute 1 with automatic post increment of Sprite Number 
bits 7-0 = LSB of Y coordinate

A write to nextreg 0x76 also increases the selected sprite in nextreg 0x34.

(W) 0x37 (55) => Sprite Attribute 2 
(W) 0x77 (119) => Sprite Attribute 2 with automatic post increment of Sprite Number 
bits 7-4 = Palette offset added to top 4 bits of sprite colour index 
bit 3 = X mirror 
bit 2 = Y mirror 
bit 1 = Rotate 
bit 0 = MSB of X coordinate

A write to nextreg 0x77 also increases the selected sprite in nextreg 0x34.

(W) 0x38 (56) => Sprite Attribute 3 
(W) 0x78 (120) => Sprite Attribute 3 with automatic post increment of Sprite Number 
bit 7 = Visible flag (1 = displayed) 
bit 6 = Extended attribute (1 = Sprite Attribute 4 is active) 
bits 5-0 = Pattern used by sprite (0-63)

A write to nextreg 0x78 also increases the selected sprite in nextreg 0x34.

(W) 0x39 (57) => Sprite Attribute 4 
(W) 0x79 (121) => Sprite Attribute 4 with automatic post increment of Sprite Number 
4-bit Sprites 
bit 7 = H (1 = sprite uses 4-bit patterns) 
bit 6 = N6 (0 = use the first 128 bytes of the pattern else use the last 128 bytes) 
bit 5 = 1 if relative sprites are composite, 0 if relative sprites are unified 
Scaling 
bits 4-3 = X scaling (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x) 
bits 2-1 = Y scaling (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x) 
bit 0 = MSB of Y coordinate 
A relative mode is enabled if H,N6 = 01. The byte format for relative sprites is described above.

A write to nextreg 0x79 also increases the selected sprite in nextreg 0x34.

=== Global Control of Sprites ===
The following nextreg are also of interest for sprites.

(R/W) 0x09 (09) => Peripheral 4 setting: 
bit 7 = Mono setting for AY 2 (1 = mono, 0 default) 
bit 6 = Mono setting for AY 1 (1 = mono, 0 default) 
bit 5 = Mono setting for AY 0 (1 = mono, 0 default) 
bit 4 = Sprite id lockstep (1 = Nextreg 0x34 and IO Port 0x303B are in lockstep, 0 default) 
bit 3 = Disables Kempston port ($DF) if set 
bit 2 = Disables divMMC ports ($E3, $E7, $EB) if set 
bits 1-0 = scanlines (0 after a PoR or Hard-reset) 
00 = scanlines off 
01 = scanlines 75% 
10 = scanlines 50% 
11 = scanlines 25%

Bit 4 determines if the i/o interface and nextreg interface operate in lockstep.

(R/W) 0x15 (21) => Sprite and Layers system 
bit 7 = LoRes mode, 128 x 96 x 256 colours (1 = enabled) 
bit 6 = Sprite priority (1 = sprite 0 on top, 0 = sprite 127 on top) 
bit 5 = Enable sprite clipping in over border mode (1 = enabled) 
bits 4-2 = set layers priorities: 
Reset default is 000, sprites over the Layer 2, over the ULA graphics 
000 – S L U 
001 – L S U 
010 – S U L 
011 – L U S 
100 – U S L 
101 – U L S 
110 – S(U+L) ULA and Layer 2 combined, colours clamped to 7 
111 – S(U+L-5) ULA and Layer 2 combined, colours clamped to [0,7] 
bit 1 = Over border (1 = yes)(Back to 0 after a reset) 
bit 0 = Sprites visible (1 = visible)(Back to 0 after a reset)

Bit 0 must be set for sprites to be visible.

Bit 1 set allows sprites to be visible in the border area. When this bit is reset, sprites will not display outside the 256×192 area of the ULA display.

Bit 5 set enables clipping when sprites are visible in the border area. If reset, no clipping is applied and sprites will be visible in the full 320×256 space.

The sprite module draws sprites in the order 0-127 in each scanline. Bit 6 determines whether sprite 0 is topmost or sprite 127 is topmost.

Bits 4:2 determine layer priority and how sprites overlay or are obscured by other layers.

(R/W) 0x19 (25) => Clip Window Sprites 
bits 7-0 = Cood. of the clip window 
1st write – X1 position 
2nd write – X2 position 
3rd write – Y1 position 
4rd write – Y2 position 
The values are 0,255,0,191 after a Reset 
Reads do not advance the clip position 
When the clip window is enabled for sprites in “over border” mode, the X coords are internally doubled and the clip window origin is moved to the sprite origin inside the border.

Sprites will only be visible inside the clipping window. When not in over-border mode (bit 1 of nextreg 0x15) the clipping window is given in ULA screen coordinates with 0,0 correspoding to the top left corner of the ULA screen. In over-border mode, the clipping window’s origin is moved to the sprite coordinate origin 32 pixels to the left and 32 pixels above the ULA screen origin.

Regardless, sprite position is always in sprite coordinates with 32,32 corresponding to the top left corner of the ULA screen.

(W) 0x1C (28) => Clip Window control 
bits 7-4 = Reserved, must be 0 
bit 3 – reset the tilemap clip index 
bit 2 – reset the ULA/LoRes clip index. 
bit 1 – reset the sprite clip index. 
bit 0 – reset the Layer 2 clip index.

Can be used to reset nextreg 0x19.

(R/W) 0x43 (67) => Palette Control 
bit 7 = ‘1’ to disable palette write auto-increment. 
bits 6-4 = Select palette for reading or writing: 
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 
bit 3 = Select Sprites palette (0 = first palette, 1 = second palette) 
bit 2 = Select Layer 2 palette (0 = first palette, 1 = second palette) 
bit 1 = Select ULA palette (0 = first palette, 1 = second palette) 
bit 0 = Enable ULANext mode if 1. (0 after a reset)

Sprites have two associated palettes which can be selected in this nextreg.

(R/W) 0x40 (64) => Palette Index 
bits 7-0 = Select the palette index to change the associated colour. 
For the ULA only, INKs are mapped to indices 0-7, Bright INKS to indices 8-15, PAPERs to indices 16-23 and Bright PAPERs to indices 24-31.
In ULANext mode, INKs come from a subset of indices 0-127 and PAPERs come from
a subset of indices 128-255. The number of active indices depends on the number
of attribute bits assigned to INK and PAPER out of the attribute byte.
The ULA always takes border colour from paper.

Select the starting palette index if writing the sprite palette.

Palette values can be written in either 8-bit or 9-bit form:

(R/W) 0x41 (65) => Palette Value (8 bit colour) 
bits 7-0 = Colour for the palette index selected by the register 0x40. 
(Format is RRRGGGBB – the lower blue bit of the 9-bit colour will be a logical OR of blue bits 1 and 0 of this 8-bit value.)
After the write, the palette index is auto-incremented to the next index if the auto-increment is enabled at reg 0x43. Reads do not auto-increment.

(R/W) 0x44 (68) => Palette Value (9 bit colour) 
Two consecutive writes are needed to write the 9 bit colour 
1st write: 
bits 7-0 = RRRGGGBB 
2nd write. 
If writing a L2 palette 
———————————————————————– 
bit 7 = 1 for L2 priority colour, 0 for normal 
Priority colour will always be on top even on an SLU priority arrangement. If you need the exact same colour on priority and non priority locations you will need to program the same colour twice changing bit 7 to 0 for the second colour 
bits 6-1 = Reserved, must be 0 
bit 0 = lsb B

If writing another palette 
———————————————————————– 
bits 7-1 = Reserved, must be 0 
bit 0 = lsb B

After the two consecutives writes the palette index is auto-incremented if the auto-increment is enabled by reg 0x43.

Reads only return the 2nd byte and do not auto-increment.

(R/W) 0x4B (75) => Transparency index for sprites 
bits 7-0 = Set the index value (0xE3 after reset) 
For 4-bit sprites only the bottom 4-bits are relevant.

Determines the transparent colour index used for sprites.

Sprites

2019-05-05T10:39:05Z

Intrepidis: Fix formatting in the Programming Sprites section.

The Spectrum Next has a hardware sprite system with the following characteristics:

* Total of 128 sprites
* Display surface is 320×256 overlapping the ULA screen by 32 pixels on each side
* Minimum of 100 sprites per scanline*
* Choice of 512 colours for each pixel
* Site of each sprite is 16×16 pixels but sprites can be magnified 2x, 4x or 8x horizontally and vertically
* Sprites can be mirrored and rotated
* Sprites can be grouped together to form larger sprites under the control of a single anchor
* A 16K pattern memory can contain 64 8-bit sprite images or 128 4-bit sprite images and combinations in-between
* A per sprite palette offset allows sprites to share images but colour them differently
* A nextreg interface allows the copper to move sprites during the video frame

<nowiki>*</nowiki>A minimum of 100 16×16 sprites is guaranteed to be displayed in any scanline. Any additional sprites will not be displayed with the hardware ensuring sprites are not partially plotted.

The actual limit is determined by how many 28MHz clock cycles there are in a scanline. The sprite hardware is able to plot one pixel cycle and uses one cycle to qualify each sprite. Since the number of cycles there are in a scanline varies with video timing (HDMI, VGA), the number of pixels that can be plotted also varies but the minimum will be 1600 pixels per line including overhead cycles needed to qualify 100 sprites. Since sprites magified horizontally involve plotting more pixels, x2 x4 x8 sprites will take more cycles to plot and the presence of these sprites in a line will reduce the total number of sprites that can be plotted.

== Sprite Patterns ==
Sprite patterns are the images that each sprite can take on. The images are stored in a 16K memory internal to the FPGA and are identified by pattern number. A particular sprite chooses a pattern by storing a pattern number in its attributes.

All sprites are 16×16 pixels in size but the come in two flavours: 4-bit and 8-bit. The bit width describes how many bits are used to code the colour of each pixel.

An 8-bit sprite uses a full byte to colour each of its pixels so that each pixel can be one of 256 colours. In this case, a 16×16 sprite requires 256 bytes of pattern memory to store its image.

A 4-bit sprite uses a nibble to colour each of its pixels so that each pixel can be one of 16 colours. In this case, a 16×16 sprite requires just 128 bytes of pattern memory to store its image.

The 16K pattern memory can contain any combination of these images, whether they are 128 bytes or 256 bytes and their locations in the pattern memory are described by a pattern number. This pattern number is 7 bits with bits named as follows:

=== Pattern Number ===
<pre>N5 N4 N3 N2 N1 N0 N6
N6, despite the name, is the least significant bit.</pre>

This 7-bit pattern number can identify 128 patterns in the 16k pattern memory, each of which are 128 bytes in size. The full 7-bits are therefore used for 4-bit sprites.

For 8-bit sprites, N6=0 always. The remaining 6 bits can identify 64 patterns, each of which is 256 bytes in size.

The N5:N0,N6 bits are stored in a particular sprite’s attributes to identify which image a sprite uses.

=== 8-Bit Sprite Patterns ===
The 16×16 pixel image uses 8-bits for each pixel so that each pixel can be one of 256 colours. One colour indicates transparency and this is programmed into the Sprite Transparency Index register (nextreg 0x4B). By default the transparent value is 0xE3.

As an example of an 8-bit sprite, let’s have a look at the sprite below:

[[File:Sprite_1.png|frame|center|Pattern example]]

Using the default palette, which is initialised with RGB332 colours from 0-255, the hexadecimal values for this pattern arranged in a 16×16 array are shown below:

<pre>04040404040404E3E3E3E3E3E3E3E3E3
04FFFFFFFFFF04E3E3E3E3E3E3E3E3E3
04FFFBFBFBFF04E3E3E3E3E3E3E3E3E3
04FFFBF5F5FBFF04E3E3E3E3E3E3E3E3
04FFFBF5A8A8FBFF04E3E3E3E3E3E3E3
04FFFFFBA844A8FBFF04E3E3E3E3E3E3
040404FFFBA844A8FBFF04E3E3E3E3E3
E3E3E304FFFBA84444FBFF04E304E3E3
E3E3E3E304FFFB444444FBFF044D04E3
E3E3E3E3E304FFFB44444444FA4D04E3
E3E3E3E3E3E304FFFB44FFF54404E3E3
E3E3E3E3E3E3E304FF44F5A804E3E3E3
E3E3E3E3E3E3E3E304FA4404A804E3E3
E3E3E3E3E3E3E3044D4D04E304F504E3
E3E3E3E3E3E3E3E30404E3E3E304FA04
E3E3E3E3E3E3E3E3E3E3E3E3E3E30404</pre>

Here 0xE3 is used as the transparent index.

These 256 bytes would be stored in pattern memory in left to right, top to bottom order.

=== 4-Bit Sprite Patterns ===
The 16×16 pixel image uses 4-bits for each pixel so that each pixel can be one of 16 colours. One colour indicates transparency and this is programmed into the lower 4-bits of the Sprite Transparency Index register (nextreg 0x4B). By default the transparency value is 0x3. Note that the same register is shared with 8-bit patterns to identify the transparent index.

Since each pixel only occupies 4-bits, two pixels are stored in each byte. The leftmost pixel is stored in the upper 4-bits and the rightmost pixel is stored in the lower 4-bits.

As an example we will use the same sprite image as was given in the 8-bit pattern example. Here only the lower 4 bits of each pixel is retained to confine each pixel’s color to 4-bits:

<pre>4444444333333333
4FFFFF4333333333
4FBBBF4333333333
4FB55BF433333333
4FB588BF43333333
4FFB848BF4333333
444FB848BF433333
3334FB844BF43433
33334FB444BF4D43
333334FB4444AD43
3333334FB4F54433
33333334F4584333
333333334A448433
33333334DD434543
33333333443334A4
3333333333333344</pre>

0x3 is used as the transparent index.

These 128 bytes would be stored in pattern memory in left to right, top to bottom order.

The actual colour that will appear on screen will depend on the palette, described below. The default palette will not likely generate suitable colours for 4-bit sprites.

=== Sprite Palette ===
Each pixel of a sprite image is 8-bit for 8-bit patterns or 4-bit for 4-bit patterns. The pixel value is known as a pixel colour index. This colour index is combined with the sprite’s palette offset. The palette offset is a 4-bit value added to the top 4-bits of the pixel colour index. The purpose of the palette offset is to allow a sprite to change the colour of an image.

The final sprite colour index generated by the sprite hardware is then the sum of the pixel index and the 4-bit palette offset. In pictures using binary math:

<pre>8-bit Sprite
PPPP0000
+ IIIIIIII
----------
SSSSSSSS

4-bit Sprite
PPPP0000
+ 0000IIII
----------
SSSSSSSS = PPPPIIII</pre>

Where “PPPP” is the 4-bit palette offset from the sprite’s attributes and the “I”s represent the pixel value from the sprite pattern. The final sprite index is represented by the 8-bit value “SSSSSSSS”.

For 4-bit sprites the palette offset can be thought of as selecting one of 16 different 16-colour palettes.

This final 8-bit sprite index is then passed through the sprite palette which acts like a lookup table that returns the 9-bit RGB333 colour associated with the sprite index.

At power up, the sprite palette is initialized such that the sprite index passes through unchanged and is therefore interpretted as an RGB332 colour. The missing third blue bit is generated as the logical OR of the two other blue bits. In short, for 8-bit sprites, the sprite index also acts like the colour when using the default palette.

=== Sprite Attributes ===
A sprite’s attributes is a list of properties that determine how and where the sprite is drawn.

Each sprite is described by either 4 or 5 attribute bytes listed below:

==== Sprite Attribute 0 ====
<pre>X X X X X X X X</pre>
The least significant eight bits of the sprite’s X coordinate. The ninth bit is found in sprite attribute 2.

==== Sprite Attribute 1 ====
<pre>Y Y Y Y Y Y Y Y</pre>
The least significant eight bits of the sprite’s Y coordinate. The ninth bit is optional and is found in attribute 4.

==== Sprite Attribute 2 ====
<pre>P P P P XM YM R X8/PR</pre>

P = 4-bit Palette Offset 
XM = 1 to mirror the sprite image horizontally 
YM = 1 to mirror the sprite image vertically 
R = 1 to rotate the sprite image 90 degrees clockwise 
X8 = Ninth bit of the sprite’s X coordinate 
PR = 1 to indicate P is relative to the anchor’s palette offset (relative sprites only)

Rotation is applied before mirroring. 
Relative sprites, described below, replace X8 with PR.

[[File:Sprite_flags.png|frame|center|All possibilities of Rotate, Mirror X and Mirror Y flags.]]

==== Sprite Attribute 3 ====
<pre>V E N5 N4 N3 N2 N1 N0</pre>
V = 1 to make the sprite visible 
E = 1 to enable attribute byte 4 
N = Sprite pattern to use 0-63

If E=0, the sprite is fully described by sprite attributes 0-3. The sprite pattern is an 8-bit one identified by pattern N=0-63. The sprite is an anchor and cannot be made relative. The sprite is displayed as if sprite attribute 4 is zero.

If E=1, the sprite is further described by sprite attribute 4.

==== Sprite Attribute 4 ====
===== A. Extended Anchor Sprite =====
<pre>H N6 T X X Y Y Y8</pre>
H = 1 if the sprite pattern is 4-bit 
N6 = 7th pattern bit if the sprite pattern is 4-bit 
T = 0 if relative sprites are composite type else 1 for unified type 
XX = Magnification in the X direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x) 
YY = Magnification in the Y direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x) 
Y8 = Ninth bit of the sprite’s Y coordinate

{H,N6} must not equal {0,1} as this combination is used to indicate a relative sprite.

===== B. Relative Sprite, Composite Type =====
<pre>0 1 N6 X X Y Y PO</pre>
N6 = 7th pattern bit if the sprite pattern is 4-bit 
XX = Magnification in the X direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x) 
YY = Magnification in the Y direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x) 
PO = 1 to indicate the sprite pattern number is relative to the anchor’s

===== C. Relative Sprite, Unified Type =====
<pre>0 1 N6 0 0 0 0 PO</pre>
N6 = 7th pattern bit if the sprite pattern is 4-bit 
PO = 1 to indicate the sprite pattern number is relative to the anchor’s

The display surface for sprites is 320×256. The X coordinate of the sprite is nine bits, ranging over 0-511, and the Y coordinate is optionally nine bits again ranging over 0-511 or is eight bits ranging over 0-255. The full extent 0-511 wraps on both axes, meaning a sprite 16 pixels wide plotted at X coordinate 511 would see its first pixel not displayed (coordinate 511) and the following pixels displayed in coordinates 0-14.

The full display area is visible in VGA. However, the HDMI display is vertically shorter so the top eight pixel rows (Y = 0-7) and the bottom eight pixel rows (Y = 248-255) will not be visible on an HDMI display.

Sprites can be fully described by sprite attributes 0-3 if the E bit in sprite attribute 3 is zero. These sprites are compatible with the original sprite module from core versions prior to 2.00.26.

If the E bit is set then a fifth sprite attribute, sprite attribute 4, becomes active. This attribute introduces scaling, 4-bit patterns, and relative sprites. Scaling is self-explanatory and 4-bit patterns were described in the last section. Relative sprites are described in the next section.

=== Relative Sprites ===
Normal sprites (sprites that are not relative) are known as anchor sprites. As the sprite module draws sprites in the order 0-127 (there are 128 sprites), it internally stores characteristics of the last anchor sprite seen. If following sprites are relative, they inherit some of these characteristics, which allows relative sprites to have, among other things, coordinates relative to the anchor. This means moving the anchor sprite also causes its relatives to move with it.

There are two types of relative sprites supported known as “Composite Sprites” and “Unified Sprites”. The type is determined by the anchor in the T bit of sprite attribute 4.

==== A. Composite Sprites ====
The sprite module records the following information from the anchor:

* Anchor.visible
* Anchor.X
* Anchor.Y
* Anchor.palette_offset
* Anchor.N (pattern number)
* Anchor.H (indicates if the sprite uses 4-bit patterns)

These recorded items are not used by composite sprites:

* Anchor.rotate
* Anchor.xmirror
* Anchor.ymirror
* Anchor.xscale
* Anchor.yscale

The anchor determines if all its relative sprites use 4-bit patterns or not.

The visibility of a particular relative sprite is the result of ANDing the anchor’s visibility with the relative sprite’s visibility. In other words, if the anchor is invisible then so are all its relatives.

Relative sprites only have 8-bit X and Y coordinates (the ninth bits are taken for other purposes). These are signed offsets from the anchor’s X,Y coordinate. Moving the anchor moves all its relatives along with it.

If the relative sprite has its PR bit set in sprite attribute 2, then the anchor’s palette offset is added to the relative sprite’s to determine the active palette offset for the relative sprite. Otherwise the relative sprite uses its own palette offset as usual.

If the relative sprite has its PO bit set in sprite attribute 4, then the anchor’s pattern number is added to the relative sprite’s to determine the pattern used for display. Otherwise the relative sprite uses its own pattern number as usual. The intention is to supply a method to easily animate a large sprite by manipulating the pattern number in the anchor.

A composite sprite is like a collection of independent sprites tied to an anchor.

==== B. Unified Sprites ====
Unified sprites are a further extension of the composite type. The same information is recorded from the anchor and the same behaviour as described under composite sprites applies.

The difference is the collection of anchor and relatives is treated as if it were a single 16×16 sprite. The anchor’s rotation, mirror, and scaling bits apply to all its relatives. Rotating the anchor causes all the relatives to rotate around the anchor. Mirroring the anchor causes the relatives to mirror around the anchor. The sprite hardware will automatically adjust X,Y coords and rotation, scaling and mirror bits of all relatives according to settings in the anchor.

Unified sprites should be defined as if all its parts are 16×16 in size with the anchor controlling the look of the whole.

A unified sprite is like a big version of an individual 16×16 sprite controlled by the anchor.

=== Programming Sprites ===
Sprites are created via three io registers and a nextreg interface.

Port 0x303B (W)

<pre>X S S S S S S S
N6 X N N N N N N</pre>

A write to this port has two effects.

One is it selects one of 128 sprites for writing sprite attributes via port 0x57.

The other is it selects one of 128 4-bit patterns in pattern memory for writing sprite patterns via port 0x5B. The N6 bit shown is the least significant in the 7-bit pattern number and should always be zero when selecting one of 64 8-bit patterns indicated by N.

Port 0x57 (W)

Once a sprite is selected via port 0x303B, its attributes can be written to this port one byte after another. Sprites can have either four or five attribute bytes and the internal attribute pointer will move onto the next sprite after those four or five attribute bytes are written. This means you can select a sprite via port 0x303B and write attributes for as many sequential sprites as desired. The attribute pointer will roll over from sprite 127 to sprite 0.

Port 0x5B (W)

Once a pattern number is selected via port 0x303B, the 256-byte or 128-byte pattern can be written to this port. The internal pattern pointer auto-increments after each write so as many sequential patterns as desired can be written. The internal pattern pointer will roll over from pattern 127 to pattern 0 (4-bit patterns) or from pattern 63 to pattern 0 (8-bit patterns) automatically.

Port 0x303B (R)

<pre>0 0 0 0 0 0 M C</pre>

M = 1 if the maximum number of sprites per line was exceeded 
C = 1 if any two displayed sprites collide on screen

Reading this port automatically resets the M and C bits.

Besides the i/o interface, there is a nextreg interface to sprite attributes. The nextreg interface allows the copper to manipulate sprites and grants the program random access to a sprite’s individual attribute bytes.

(R/W) 0x34 (52) => Sprite Number 
If the sprite number is in lockstep with io port 0x303B (nextreg 0x09 bit 4 is set) 
bits 7 = Pattern address offset (Add 128 to pattern address) 
bits 6-0 = Sprite number 0-127, Pattern number 0-63 
Selects which sprite has its attributes connected to the following registers. 
Effectively performs an out to port 0x303B with the same value 
Otherwise 
bit 7 = Ignored 
bits 6-0 = Sprite number 0-127 
Selects which sprite has its attributes connected to the following registers. 
Bit 7 always reads back as zero.

This nextreg can operate in two modes.

If nextreg 0x09 bit 4 is set, then this register is kept in lockstep with i/o port 0x303B. A write to this nextreg is equivalent to a write to port 0x303B and vice versa. In this mode, the i/o interface and nextreg interface are exactly equivalent.

If nextreg 0x09 bit 4 is reset, then the nextreg interface is decoupled from i/o port 0x303B. This nextreg is used to select a particular sprite 0-127 and this is completely independent from the sprite selected for the i/o interface. This independence allows the copper, for example, to manipulate different sprites than the cpu using the i/o interface.

(W) 0x35 (53) => Sprite Attribute 0 
(W) 0x75 (117) => Sprite Attribute 0 with automatic post increment of Sprite Number 
bits 7-0 = LSB of X coordinate

A write to nextreg 0x75 also increases the selected sprite in nextreg 0x34.

(W) 0x36 (54) => Sprite Attribute 1 
(W) 0x76 (118) => Sprite Attribute 1 with automatic post increment of Sprite Number 
bits 7-0 = LSB of Y coordinate

A write to nextreg 0x76 also increases the selected sprite in nextreg 0x34.

(W) 0x37 (55) => Sprite Attribute 2 
(W) 0x77 (119) => Sprite Attribute 2 with automatic post increment of Sprite Number 
bits 7-4 = Palette offset added to top 4 bits of sprite colour index 
bit 3 = X mirror 
bit 2 = Y mirror 
bit 1 = Rotate 
bit 0 = MSB of X coordinate

A write to nextreg 0x77 also increases the selected sprite in nextreg 0x34.

(W) 0x38 (56) => Sprite Attribute 3 
(W) 0x78 (120) => Sprite Attribute 3 with automatic post increment of Sprite Number 
bit 7 = Visible flag (1 = displayed) 
bit 6 = Extended attribute (1 = Sprite Attribute 4 is active) 
bits 5-0 = Pattern used by sprite (0-63)

A write to nextreg 0x78 also increases the selected sprite in nextreg 0x34.

(W) 0x39 (57) => Sprite Attribute 4 
(W) 0x79 (121) => Sprite Attribute 4 with automatic post increment of Sprite Number 
4-bit Sprites 
bit 7 = H (1 = sprite uses 4-bit patterns) 
bit 6 = N6 (0 = use the first 128 bytes of the pattern else use the last 128 bytes) 
bit 5 = 1 if relative sprites are composite, 0 if relative sprites are unified 
Scaling 
bits 4-3 = X scaling (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x) 
bits 2-1 = Y scaling (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x) 
bit 0 = MSB of Y coordinate 
A relative mode is enabled if H,N6 = 01. The byte format for relative sprites is described above.

A write to nextreg 0x79 also increases the selected sprite in nextreg 0x34.

=== Global Control of Sprites ===
The following nextreg are also of interest for sprites.

(R/W) 0x09 (09) => Peripheral 4 setting:
bit 7 = Mono setting for AY 2 (1 = mono, 0 default)
bit 6 = Mono setting for AY 1 (1 = mono, 0 default)
bit 5 = Mono setting for AY 0 (1 = mono, 0 default)
bit 4 = Sprite id lockstep (1 = Nextreg 0x34 and IO Port 0x303B are in lockstep, 0 default)
bit 3 = Disables Kempston port ($DF) if set
bit 2 = Disables divMMC ports ($E3, $E7, $EB) if set
bits 1-0 = scanlines (0 after a PoR or Hard-reset)
00 = scanlines off
01 = scanlines 75%
10 = scanlines 50%
11 = scanlines 25%

Bit 4 determines if the i/o interface and nextreg interface operate in lockstep.

(R/W) 0x15 (21) => Sprite and Layers system
bit 7 = LoRes mode, 128 x 96 x 256 colours (1 = enabled)
bit 6 = Sprite priority (1 = sprite 0 on top, 0 = sprite 127 on top)
bit 5 = Enable sprite clipping in over border mode (1 = enabled)
bits 4-2 = set layers priorities:
Reset default is 000, sprites over the Layer 2, over the ULA graphics
000 – S L U
001 – L S U
010 – S U L
011 – L U S
100 – U S L
101 – U L S
110 – S(U+L) ULA and Layer 2 combined, colours clamped to 7
111 – S(U+L-5) ULA and Layer 2 combined, colours clamped to [0,7]
bit 1 = Over border (1 = yes)(Back to 0 after a reset)
bit 0 = Sprites visible (1 = visible)(Back to 0 after a reset)

Bit 0 must be set for sprites to be visible.

Bit 1 set allows sprites to be visible in the border area. When this bit is reset, sprites will not display outside the 256×192 area of the ULA display.

Bit 5 set enables clipping when sprites are visible in the border area. If reset, no clipping is applied and sprites will be visible in the full 320×256 space.

The sprite module draws sprites in the order 0-127 in each scanline. Bit 6 determines whether sprite 0 is topmost or sprite 127 is topmost.

Bits 4:2 determine layer priority and how sprites overlay or are obscured by other layers.

(R/W) 0x19 (25) => Clip Window Sprites
bits 7-0 = Cood. of the clip window
1st write – X1 position
2nd write – X2 position
3rd write – Y1 position
4rd write – Y2 position
The values are 0,255,0,191 after a Reset
Reads do not advance the clip position
When the clip window is enabled for sprites in “over border” mode,
the X coords are internally doubled and the clip window origin is
moved to the sprite origin inside the border.

Sprites will only be visible inside the clipping window. When not in over-border mode (bit 1 of nextreg 0x15) the clipping window is given in ULA screen coordinates with 0,0 correspoding to the top left corner of the ULA screen. In over-border mode, the clipping window’s origin is moved to the sprite coordinate origin 32 pixels to the left and 32 pixels above the ULA screen origin.

Regardless, sprite position is always in sprite coordinates with 32,32 corresponding to the top left corner of the ULA screen.

(W) 0x1C (28) => Clip Window control
bits 7-4 = Reserved, must be 0
bit 3 – reset the tilemap clip index
bit 2 – reset the ULA/LoRes clip index.
bit 1 – reset the sprite clip index.
bit 0 – reset the Layer 2 clip index.

Can be used to reset nextreg 0x19.

(R/W) 0x43 (67) => Palette Control
bit 7 = ‘1’ to disable palette write auto-increment.
bits 6-4 = Select palette for reading or writing:
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
bit 3 = Select Sprites palette (0 = first palette, 1 = second palette)
bit 2 = Select Layer 2 palette (0 = first palette, 1 = second palette)
bit 1 = Select ULA palette (0 = first palette, 1 = second palette)
bit 0 = Enabe ULANext mode if 1. (0 after a reset)

Sprites have two associated palettes which can be selected in this nextreg.

(R/W) 0x40 (64) => Palette Index
bits 7-0 = Select the palette index to change the associated colour.
For the ULA only, INKs are mapped to indices 0-7, Bright INKS to indices 8-15,
PAPERs to indices 16-23 and Bright PAPERs to indices 24-31.
In ULANext mode, INKs come from a subset of indices 0-127 and PAPERs come from
a subset of indices 128-255. The number of active indices depends on the number
of attribute bits assigned to INK and PAPER out of the attribute byte.
The ULA always takes border colour from paper.

Select the starting palette index if writing the sprite palette.

Palette values can be written in either 8-bit or 9-bit form:

(R/W) 0x41 (65) => Palette Value (8 bit colour)
bits 7-0 = Colour for the palette index selected by the register 0x40.
(Format is RRRGGGBB – the lower blue bit of the 9-bit colour will
be a logical OR of blue bits 1 and 0 of this 8-bit value.)
After the write, the palette index is auto-incremented to the next index
if the auto-increment is enabled at reg 0x43. Reads do not auto-increment.

(R/W) 0x44 (68) => Palette Value (9 bit colour)
Two consecutive writes are needed to write the 9 bit colour
1st write:
bits 7-0 = RRRGGGBB
2nd write.
If writing a L2 palette
———————————————————————–
bit 7 = 1 for L2 priority colour, 0 for normal
Priority colour will always be on top even on an SLU priori-
ty arrangement. If you need the exact same colour on priori-
ty and non priority locations you will need to program the
same colour twice changing bit 7 to 0 for the second colour
bits 6-1 = Reserved, must be 0
bit 0 = lsb B

If writing another palette
———————————————————————–
bits 7-1 = Reserved, must be 0
bit 0 = lsb B

After the two consecutives writes the palette index is
auto-incremented if the auto-increment is enabled by reg 0x43.

Reads only return the 2nd byte and do not auto-increment.

(R/W) 0x4B (75) => Transparency index for sprites
bits 7-0 = Set the index value (0xE3 after reset)
For 4-bit sprites only the bottom 4-bits are relevant.

Determines the transparent colour index used for sprites.

Sprites

2019-05-05T10:33:31Z

Intrepidis: Add bullet points to Composite section.

The Spectrum Next has a hardware sprite system with the following characteristics:

* Total of 128 sprites
* Display surface is 320×256 overlapping the ULA screen by 32 pixels on each side
* Minimum of 100 sprites per scanline*
* Choice of 512 colours for each pixel
* Site of each sprite is 16×16 pixels but sprites can be magnified 2x, 4x or 8x horizontally and vertically
* Sprites can be mirrored and rotated
* Sprites can be grouped together to form larger sprites under the control of a single anchor
* A 16K pattern memory can contain 64 8-bit sprite images or 128 4-bit sprite images and combinations in-between
* A per sprite palette offset allows sprites to share images but colour them differently
* A nextreg interface allows the copper to move sprites during the video frame

<nowiki>*</nowiki>A minimum of 100 16×16 sprites is guaranteed to be displayed in any scanline. Any additional sprites will not be displayed with the hardware ensuring sprites are not partially plotted.

The actual limit is determined by how many 28MHz clock cycles there are in a scanline. The sprite hardware is able to plot one pixel cycle and uses one cycle to qualify each sprite. Since the number of cycles there are in a scanline varies with video timing (HDMI, VGA), the number of pixels that can be plotted also varies but the minimum will be 1600 pixels per line including overhead cycles needed to qualify 100 sprites. Since sprites magified horizontally involve plotting more pixels, x2 x4 x8 sprites will take more cycles to plot and the presence of these sprites in a line will reduce the total number of sprites that can be plotted.

== Sprite Patterns ==
Sprite patterns are the images that each sprite can take on. The images are stored in a 16K memory internal to the FPGA and are identified by pattern number. A particular sprite chooses a pattern by storing a pattern number in its attributes.

All sprites are 16×16 pixels in size but the come in two flavours: 4-bit and 8-bit. The bit width describes how many bits are used to code the colour of each pixel.

An 8-bit sprite uses a full byte to colour each of its pixels so that each pixel can be one of 256 colours. In this case, a 16×16 sprite requires 256 bytes of pattern memory to store its image.

A 4-bit sprite uses a nibble to colour each of its pixels so that each pixel can be one of 16 colours. In this case, a 16×16 sprite requires just 128 bytes of pattern memory to store its image.

The 16K pattern memory can contain any combination of these images, whether they are 128 bytes or 256 bytes and their locations in the pattern memory are described by a pattern number. This pattern number is 7 bits with bits named as follows:

=== Pattern Number ===
<pre>N5 N4 N3 N2 N1 N0 N6
N6, despite the name, is the least significant bit.</pre>

This 7-bit pattern number can identify 128 patterns in the 16k pattern memory, each of which are 128 bytes in size. The full 7-bits are therefore used for 4-bit sprites.

For 8-bit sprites, N6=0 always. The remaining 6 bits can identify 64 patterns, each of which is 256 bytes in size.

The N5:N0,N6 bits are stored in a particular sprite’s attributes to identify which image a sprite uses.

=== 8-Bit Sprite Patterns ===
The 16×16 pixel image uses 8-bits for each pixel so that each pixel can be one of 256 colours. One colour indicates transparency and this is programmed into the Sprite Transparency Index register (nextreg 0x4B). By default the transparent value is 0xE3.

As an example of an 8-bit sprite, let’s have a look at the sprite below:

[[File:Sprite_1.png|frame|center|Pattern example]]

Using the default palette, which is initialised with RGB332 colours from 0-255, the hexadecimal values for this pattern arranged in a 16×16 array are shown below:

<pre>04040404040404E3E3E3E3E3E3E3E3E3
04FFFFFFFFFF04E3E3E3E3E3E3E3E3E3
04FFFBFBFBFF04E3E3E3E3E3E3E3E3E3
04FFFBF5F5FBFF04E3E3E3E3E3E3E3E3
04FFFBF5A8A8FBFF04E3E3E3E3E3E3E3
04FFFFFBA844A8FBFF04E3E3E3E3E3E3
040404FFFBA844A8FBFF04E3E3E3E3E3
E3E3E304FFFBA84444FBFF04E304E3E3
E3E3E3E304FFFB444444FBFF044D04E3
E3E3E3E3E304FFFB44444444FA4D04E3
E3E3E3E3E3E304FFFB44FFF54404E3E3
E3E3E3E3E3E3E304FF44F5A804E3E3E3
E3E3E3E3E3E3E3E304FA4404A804E3E3
E3E3E3E3E3E3E3044D4D04E304F504E3
E3E3E3E3E3E3E3E30404E3E3E304FA04
E3E3E3E3E3E3E3E3E3E3E3E3E3E30404</pre>

Here 0xE3 is used as the transparent index.

These 256 bytes would be stored in pattern memory in left to right, top to bottom order.

=== 4-Bit Sprite Patterns ===
The 16×16 pixel image uses 4-bits for each pixel so that each pixel can be one of 16 colours. One colour indicates transparency and this is programmed into the lower 4-bits of the Sprite Transparency Index register (nextreg 0x4B). By default the transparency value is 0x3. Note that the same register is shared with 8-bit patterns to identify the transparent index.

Since each pixel only occupies 4-bits, two pixels are stored in each byte. The leftmost pixel is stored in the upper 4-bits and the rightmost pixel is stored in the lower 4-bits.

As an example we will use the same sprite image as was given in the 8-bit pattern example. Here only the lower 4 bits of each pixel is retained to confine each pixel’s color to 4-bits:

<pre>4444444333333333
4FFFFF4333333333
4FBBBF4333333333
4FB55BF433333333
4FB588BF43333333
4FFB848BF4333333
444FB848BF433333
3334FB844BF43433
33334FB444BF4D43
333334FB4444AD43
3333334FB4F54433
33333334F4584333
333333334A448433
33333334DD434543
33333333443334A4
3333333333333344</pre>

0x3 is used as the transparent index.

These 128 bytes would be stored in pattern memory in left to right, top to bottom order.

The actual colour that will appear on screen will depend on the palette, described below. The default palette will not likely generate suitable colours for 4-bit sprites.

=== Sprite Palette ===
Each pixel of a sprite image is 8-bit for 8-bit patterns or 4-bit for 4-bit patterns. The pixel value is known as a pixel colour index. This colour index is combined with the sprite’s palette offset. The palette offset is a 4-bit value added to the top 4-bits of the pixel colour index. The purpose of the palette offset is to allow a sprite to change the colour of an image.

The final sprite colour index generated by the sprite hardware is then the sum of the pixel index and the 4-bit palette offset. In pictures using binary math:

<pre>8-bit Sprite
PPPP0000
+ IIIIIIII
----------
SSSSSSSS

4-bit Sprite
PPPP0000
+ 0000IIII
----------
SSSSSSSS = PPPPIIII</pre>

Where “PPPP” is the 4-bit palette offset from the sprite’s attributes and the “I”s represent the pixel value from the sprite pattern. The final sprite index is represented by the 8-bit value “SSSSSSSS”.

For 4-bit sprites the palette offset can be thought of as selecting one of 16 different 16-colour palettes.

This final 8-bit sprite index is then passed through the sprite palette which acts like a lookup table that returns the 9-bit RGB333 colour associated with the sprite index.

At power up, the sprite palette is initialized such that the sprite index passes through unchanged and is therefore interpretted as an RGB332 colour. The missing third blue bit is generated as the logical OR of the two other blue bits. In short, for 8-bit sprites, the sprite index also acts like the colour when using the default palette.

=== Sprite Attributes ===
A sprite’s attributes is a list of properties that determine how and where the sprite is drawn.

Each sprite is described by either 4 or 5 attribute bytes listed below:

==== Sprite Attribute 0 ====
<pre>X X X X X X X X</pre>
The least significant eight bits of the sprite’s X coordinate. The ninth bit is found in sprite attribute 2.

==== Sprite Attribute 1 ====
<pre>Y Y Y Y Y Y Y Y</pre>
The least significant eight bits of the sprite’s Y coordinate. The ninth bit is optional and is found in attribute 4.

==== Sprite Attribute 2 ====
<pre>P P P P XM YM R X8/PR</pre>

P = 4-bit Palette Offset 
XM = 1 to mirror the sprite image horizontally 
YM = 1 to mirror the sprite image vertically 
R = 1 to rotate the sprite image 90 degrees clockwise 
X8 = Ninth bit of the sprite’s X coordinate 
PR = 1 to indicate P is relative to the anchor’s palette offset (relative sprites only)

Rotation is applied before mirroring. 
Relative sprites, described below, replace X8 with PR.

[[File:Sprite_flags.png|frame|center|All possibilities of Rotate, Mirror X and Mirror Y flags.]]

==== Sprite Attribute 3 ====
<pre>V E N5 N4 N3 N2 N1 N0</pre>
V = 1 to make the sprite visible 
E = 1 to enable attribute byte 4 
N = Sprite pattern to use 0-63

If E=0, the sprite is fully described by sprite attributes 0-3. The sprite pattern is an 8-bit one identified by pattern N=0-63. The sprite is an anchor and cannot be made relative. The sprite is displayed as if sprite attribute 4 is zero.

If E=1, the sprite is further described by sprite attribute 4.

==== Sprite Attribute 4 ====
===== A. Extended Anchor Sprite =====
<pre>H N6 T X X Y Y Y8</pre>
H = 1 if the sprite pattern is 4-bit 
N6 = 7th pattern bit if the sprite pattern is 4-bit 
T = 0 if relative sprites are composite type else 1 for unified type 
XX = Magnification in the X direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x) 
YY = Magnification in the Y direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x) 
Y8 = Ninth bit of the sprite’s Y coordinate

{H,N6} must not equal {0,1} as this combination is used to indicate a relative sprite.

===== B. Relative Sprite, Composite Type =====
<pre>0 1 N6 X X Y Y PO</pre>
N6 = 7th pattern bit if the sprite pattern is 4-bit 
XX = Magnification in the X direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x) 
YY = Magnification in the Y direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x) 
PO = 1 to indicate the sprite pattern number is relative to the anchor’s

===== C. Relative Sprite, Unified Type =====
<pre>0 1 N6 0 0 0 0 PO</pre>
N6 = 7th pattern bit if the sprite pattern is 4-bit 
PO = 1 to indicate the sprite pattern number is relative to the anchor’s

The display surface for sprites is 320×256. The X coordinate of the sprite is nine bits, ranging over 0-511, and the Y coordinate is optionally nine bits again ranging over 0-511 or is eight bits ranging over 0-255. The full extent 0-511 wraps on both axes, meaning a sprite 16 pixels wide plotted at X coordinate 511 would see its first pixel not displayed (coordinate 511) and the following pixels displayed in coordinates 0-14.

The full display area is visible in VGA. However, the HDMI display is vertically shorter so the top eight pixel rows (Y = 0-7) and the bottom eight pixel rows (Y = 248-255) will not be visible on an HDMI display.

Sprites can be fully described by sprite attributes 0-3 if the E bit in sprite attribute 3 is zero. These sprites are compatible with the original sprite module from core versions prior to 2.00.26.

If the E bit is set then a fifth sprite attribute, sprite attribute 4, becomes active. This attribute introduces scaling, 4-bit patterns, and relative sprites. Scaling is self-explanatory and 4-bit patterns were described in the last section. Relative sprites are described in the next section.

=== Relative Sprites ===
Normal sprites (sprites that are not relative) are known as anchor sprites. As the sprite module draws sprites in the order 0-127 (there are 128 sprites), it internally stores characteristics of the last anchor sprite seen. If following sprites are relative, they inherit some of these characteristics, which allows relative sprites to have, among other things, coordinates relative to the anchor. This means moving the anchor sprite also causes its relatives to move with it.

There are two types of relative sprites supported known as “Composite Sprites” and “Unified Sprites”. The type is determined by the anchor in the T bit of sprite attribute 4.

==== A. Composite Sprites ====
The sprite module records the following information from the anchor:

* Anchor.visible
* Anchor.X
* Anchor.Y
* Anchor.palette_offset
* Anchor.N (pattern number)
* Anchor.H (indicates if the sprite uses 4-bit patterns)

These recorded items are not used by composite sprites:

* Anchor.rotate
* Anchor.xmirror
* Anchor.ymirror
* Anchor.xscale
* Anchor.yscale

The anchor determines if all its relative sprites use 4-bit patterns or not.

The visibility of a particular relative sprite is the result of ANDing the anchor’s visibility with the relative sprite’s visibility. In other words, if the anchor is invisible then so are all its relatives.

Relative sprites only have 8-bit X and Y coordinates (the ninth bits are taken for other purposes). These are signed offsets from the anchor’s X,Y coordinate. Moving the anchor moves all its relatives along with it.

If the relative sprite has its PR bit set in sprite attribute 2, then the anchor’s palette offset is added to the relative sprite’s to determine the active palette offset for the relative sprite. Otherwise the relative sprite uses its own palette offset as usual.

If the relative sprite has its PO bit set in sprite attribute 4, then the anchor’s pattern number is added to the relative sprite’s to determine the pattern used for display. Otherwise the relative sprite uses its own pattern number as usual. The intention is to supply a method to easily animate a large sprite by manipulating the pattern number in the anchor.

A composite sprite is like a collection of independent sprites tied to an anchor.

==== B. Unified Sprites ====
Unified sprites are a further extension of the composite type. The same information is recorded from the anchor and the same behaviour as described under composite sprites applies.

The difference is the collection of anchor and relatives is treated as if it were a single 16×16 sprite. The anchor’s rotation, mirror, and scaling bits apply to all its relatives. Rotating the anchor causes all the relatives to rotate around the anchor. Mirroring the anchor causes the relatives to mirror around the anchor. The sprite hardware will automatically adjust X,Y coords and rotation, scaling and mirror bits of all relatives according to settings in the anchor.

Unified sprites should be defined as if all its parts are 16×16 in size with the anchor controlling the look of the whole.

A unified sprite is like a big version of an individual 16×16 sprite controlled by the anchor.

=== Programming Sprites ===
Sprites are created via three io registers and a nextreg interface.

Port 0x303B (W)

<pre>X S S S S S S S
N6 X N N N N N N</pre>

A write to this port has two effects.

One is it selects one of 128 sprites for writing sprite attributes via port 0x57.

The other is it selects one of 128 4-bit patterns in pattern memory for writing sprite patterns via port 0x5B. The N6 bit shown is the least significant in the 7-bit pattern number and should always be zero when selecting one of 64 8-bit patterns indicated by N.

Port 0x57 (W)

Once a sprite is selected via port 0x303B, its attributes can be written to this port one byte after another. Sprites can have either four or five attribute bytes and the internal attribute pointer will move onto the next sprite after those four or five attribute bytes are written. This means you can select a sprite via port 0x303B and write attributes for as many sequential sprites as desired. The attribute pointer will roll over from sprite 127 to sprite 0.

Port 0x5B (W)

Once a pattern number is selected via port 0x303B, the 256-byte or 128-byte pattern can be written to this port. The internal pattern pointer auto-increments after each write so as many sequential patterns as desired can be written. The internal pattern pointer will roll over from pattern 127 to pattern 0 (4-bit patterns) or from pattern 63 to pattern 0 (8-bit patterns) automatically.

Port 0x303B (R)

<pre>0 0 0 0 0 0 M C</pre>

M = 1 if the maximum number of sprites per line was exceeded
C = 1 if any two displayed sprites collide on screen

Reading this port automatically resets the M and C bits.

Besides the i/o interface, there is a nextreg interface to sprite attributes. The nextreg interface allows the copper to manipulate sprites and grants the program random access to a sprite’s individual attribute bytes.

(R/W) 0x34 (52) => Sprite Number
If the sprite number is in lockstep with io port 0x303B (nextreg 0x09 bit 4 is set)
bits 7 = Pattern address offset (Add 128 to pattern address)
bits 6-0 = Sprite number 0-127, Pattern number 0-63
Selects which sprite has its attributes connected to the following registers.
Effectively performs an out to port 0x303B with the same value
Otherwise
bit 7 = Ignored
bits 6-0 = Sprite number 0-127
Selects which sprite has its attributes connected to the following registers.
Bit 7 always reads back as zero.

This nextreg can operate in two modes.

If nextreg 0x09 bit 4 is set, then this register is kept in lockstep with i/o port 0x303B. A write to this nextreg is equivalent to a write to port 0x303B and vice versa. In this mode, the i/o interface and nextreg interface are exactly equivalent.

If nextreg 0x09 bit 4 is reset, then the nextreg interface is decoupled from i/o port 0x303B. This nextreg is used to select a particular sprite 0-127 and this is completely independent from the sprite selected for the i/o interface. This independence allows the copper, for example, to manipulate different sprites than the cpu using the i/o interface.

(W) 0x35 (53) => Sprite Attribute 0
(W) 0x75 (117) => Sprite Attribute 0 with automatic post increment of Sprite Number
bits 7-0 = LSB of X coordinate

A write to nextreg 0x75 also increases the selected sprite in nextreg 0x34.

(W) 0x36 (54) => Sprite Attribute 1
(W) 0x76 (118) => Sprite Attribute 1 with automatic post increment of Sprite Number
bits 7-0 = LSB of Y coordinate

A write to nextreg 0x76 also increases the selected sprite in nextreg 0x34.

(W) 0x37 (55) => Sprite Attribute 2
(W) 0x77 (119) => Sprite Attribute 2 with automatic post increment of Sprite Number
bits 7-4 = Palette offset added to top 4 bits of sprite colour index
bit 3 = X mirror
bit 2 = Y mirror
bit 1 = Rotate
bit 0 = MSB of X coordinate

A write to nextreg 0x77 also increases the selected sprite in nextreg 0x34.

(W) 0x38 (56) => Sprite Attribute 3
(W) 0x78 (120) => Sprite Attribute 3 with automatic post increment of Sprite Number
bit 7 = Visible flag (1 = displayed)
bit 6 = Extended attribute (1 = Sprite Attribute 4 is active)
bits 5-0 = Pattern used by sprite (0-63)

A write to nextreg 0x78 also increases the selected sprite in nextreg 0x34.

(W) 0x39 (57) => Sprite Attribute 4
(W) 0x79 (121) => Sprite Attribute 4 with automatic post increment of Sprite Number
4-bit Sprites
bit 7 = H (1 = sprite uses 4-bit patterns)
bit 6 = N6 (0 = use the first 128 bytes of the pattern else use the last 128 bytes)
bit 5 = 1 if relative sprites are composite, 0 if relative sprites are unified
Scaling
bits 4-3 = X scaling (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
bits 2-1 = Y scaling (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
bit 0 = MSB of Y coordinate
A relative mode is enabled if H,N6 = 01. The byte format for relative sprites is described above.

A write to nextreg 0x79 also increases the selected sprite in nextreg 0x34.

=== Global Control of Sprites ===
The following nextreg are also of interest for sprites.

(R/W) 0x09 (09) => Peripheral 4 setting:
bit 7 = Mono setting for AY 2 (1 = mono, 0 default)
bit 6 = Mono setting for AY 1 (1 = mono, 0 default)
bit 5 = Mono setting for AY 0 (1 = mono, 0 default)
bit 4 = Sprite id lockstep (1 = Nextreg 0x34 and IO Port 0x303B are in lockstep, 0 default)
bit 3 = Disables Kempston port ($DF) if set
bit 2 = Disables divMMC ports ($E3, $E7, $EB) if set
bits 1-0 = scanlines (0 after a PoR or Hard-reset)
00 = scanlines off
01 = scanlines 75%
10 = scanlines 50%
11 = scanlines 25%

Bit 4 determines if the i/o interface and nextreg interface operate in lockstep.

(R/W) 0x15 (21) => Sprite and Layers system
bit 7 = LoRes mode, 128 x 96 x 256 colours (1 = enabled)
bit 6 = Sprite priority (1 = sprite 0 on top, 0 = sprite 127 on top)
bit 5 = Enable sprite clipping in over border mode (1 = enabled)
bits 4-2 = set layers priorities:
Reset default is 000, sprites over the Layer 2, over the ULA graphics
000 – S L U
001 – L S U
010 – S U L
011 – L U S
100 – U S L
101 – U L S
110 – S(U+L) ULA and Layer 2 combined, colours clamped to 7
111 – S(U+L-5) ULA and Layer 2 combined, colours clamped to [0,7]
bit 1 = Over border (1 = yes)(Back to 0 after a reset)
bit 0 = Sprites visible (1 = visible)(Back to 0 after a reset)

Bit 0 must be set for sprites to be visible.

Bit 1 set allows sprites to be visible in the border area. When this bit is reset, sprites will not display outside the 256×192 area of the ULA display.

Bit 5 set enables clipping when sprites are visible in the border area. If reset, no clipping is applied and sprites will be visible in the full 320×256 space.

The sprite module draws sprites in the order 0-127 in each scanline. Bit 6 determines whether sprite 0 is topmost or sprite 127 is topmost.

Bits 4:2 determine layer priority and how sprites overlay or are obscured by other layers.

(R/W) 0x19 (25) => Clip Window Sprites
bits 7-0 = Cood. of the clip window
1st write – X1 position
2nd write – X2 position
3rd write – Y1 position
4rd write – Y2 position
The values are 0,255,0,191 after a Reset
Reads do not advance the clip position
When the clip window is enabled for sprites in “over border” mode,
the X coords are internally doubled and the clip window origin is
moved to the sprite origin inside the border.

Sprites will only be visible inside the clipping window. When not in over-border mode (bit 1 of nextreg 0x15) the clipping window is given in ULA screen coordinates with 0,0 correspoding to the top left corner of the ULA screen. In over-border mode, the clipping window’s origin is moved to the sprite coordinate origin 32 pixels to the left and 32 pixels above the ULA screen origin.

Regardless, sprite position is always in sprite coordinates with 32,32 corresponding to the top left corner of the ULA screen.

(W) 0x1C (28) => Clip Window control
bits 7-4 = Reserved, must be 0
bit 3 – reset the tilemap clip index
bit 2 – reset the ULA/LoRes clip index.
bit 1 – reset the sprite clip index.
bit 0 – reset the Layer 2 clip index.

Can be used to reset nextreg 0x19.

(R/W) 0x43 (67) => Palette Control
bit 7 = ‘1’ to disable palette write auto-increment.
bits 6-4 = Select palette for reading or writing:
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
bit 3 = Select Sprites palette (0 = first palette, 1 = second palette)
bit 2 = Select Layer 2 palette (0 = first palette, 1 = second palette)
bit 1 = Select ULA palette (0 = first palette, 1 = second palette)
bit 0 = Enabe ULANext mode if 1. (0 after a reset)

Sprites have two associated palettes which can be selected in this nextreg.

(R/W) 0x40 (64) => Palette Index
bits 7-0 = Select the palette index to change the associated colour.
For the ULA only, INKs are mapped to indices 0-7, Bright INKS to indices 8-15,
PAPERs to indices 16-23 and Bright PAPERs to indices 24-31.
In ULANext mode, INKs come from a subset of indices 0-127 and PAPERs come from
a subset of indices 128-255. The number of active indices depends on the number
of attribute bits assigned to INK and PAPER out of the attribute byte.
The ULA always takes border colour from paper.

Select the starting palette index if writing the sprite palette.

Palette values can be written in either 8-bit or 9-bit form:

(R/W) 0x41 (65) => Palette Value (8 bit colour)
bits 7-0 = Colour for the palette index selected by the register 0x40.
(Format is RRRGGGBB – the lower blue bit of the 9-bit colour will
be a logical OR of blue bits 1 and 0 of this 8-bit value.)
After the write, the palette index is auto-incremented to the next index
if the auto-increment is enabled at reg 0x43. Reads do not auto-increment.

(R/W) 0x44 (68) => Palette Value (9 bit colour)
Two consecutive writes are needed to write the 9 bit colour
1st write:
bits 7-0 = RRRGGGBB
2nd write.
If writing a L2 palette
———————————————————————–
bit 7 = 1 for L2 priority colour, 0 for normal
Priority colour will always be on top even on an SLU priori-
ty arrangement. If you need the exact same colour on priori-
ty and non priority locations you will need to program the
same colour twice changing bit 7 to 0 for the second colour
bits 6-1 = Reserved, must be 0
bit 0 = lsb B

If writing another palette
———————————————————————–
bits 7-1 = Reserved, must be 0
bit 0 = lsb B

After the two consecutives writes the palette index is
auto-incremented if the auto-increment is enabled by reg 0x43.

Reads only return the 2nd byte and do not auto-increment.

(R/W) 0x4B (75) => Transparency index for sprites
bits 7-0 = Set the index value (0xE3 after reset)
For 4-bit sprites only the bottom 4-bits are relevant.

Determines the transparent colour index used for sprites.

Sprites

2019-05-05T10:29:59Z

Intrepidis: Add better formatting to the attribute section.

The Spectrum Next has a hardware sprite system with the following characteristics:

* Total of 128 sprites
* Display surface is 320×256 overlapping the ULA screen by 32 pixels on each side
* Minimum of 100 sprites per scanline*
* Choice of 512 colours for each pixel
* Site of each sprite is 16×16 pixels but sprites can be magnified 2x, 4x or 8x horizontally and vertically
* Sprites can be mirrored and rotated
* Sprites can be grouped together to form larger sprites under the control of a single anchor
* A 16K pattern memory can contain 64 8-bit sprite images or 128 4-bit sprite images and combinations in-between
* A per sprite palette offset allows sprites to share images but colour them differently
* A nextreg interface allows the copper to move sprites during the video frame

<nowiki>*</nowiki>A minimum of 100 16×16 sprites is guaranteed to be displayed in any scanline. Any additional sprites will not be displayed with the hardware ensuring sprites are not partially plotted.

The actual limit is determined by how many 28MHz clock cycles there are in a scanline. The sprite hardware is able to plot one pixel cycle and uses one cycle to qualify each sprite. Since the number of cycles there are in a scanline varies with video timing (HDMI, VGA), the number of pixels that can be plotted also varies but the minimum will be 1600 pixels per line including overhead cycles needed to qualify 100 sprites. Since sprites magified horizontally involve plotting more pixels, x2 x4 x8 sprites will take more cycles to plot and the presence of these sprites in a line will reduce the total number of sprites that can be plotted.

== Sprite Patterns ==
Sprite patterns are the images that each sprite can take on. The images are stored in a 16K memory internal to the FPGA and are identified by pattern number. A particular sprite chooses a pattern by storing a pattern number in its attributes.

All sprites are 16×16 pixels in size but the come in two flavours: 4-bit and 8-bit. The bit width describes how many bits are used to code the colour of each pixel.

An 8-bit sprite uses a full byte to colour each of its pixels so that each pixel can be one of 256 colours. In this case, a 16×16 sprite requires 256 bytes of pattern memory to store its image.

A 4-bit sprite uses a nibble to colour each of its pixels so that each pixel can be one of 16 colours. In this case, a 16×16 sprite requires just 128 bytes of pattern memory to store its image.

The 16K pattern memory can contain any combination of these images, whether they are 128 bytes or 256 bytes and their locations in the pattern memory are described by a pattern number. This pattern number is 7 bits with bits named as follows:

=== Pattern Number ===
<pre>N5 N4 N3 N2 N1 N0 N6
N6, despite the name, is the least significant bit.</pre>

This 7-bit pattern number can identify 128 patterns in the 16k pattern memory, each of which are 128 bytes in size. The full 7-bits are therefore used for 4-bit sprites.

For 8-bit sprites, N6=0 always. The remaining 6 bits can identify 64 patterns, each of which is 256 bytes in size.

The N5:N0,N6 bits are stored in a particular sprite’s attributes to identify which image a sprite uses.

=== 8-Bit Sprite Patterns ===
The 16×16 pixel image uses 8-bits for each pixel so that each pixel can be one of 256 colours. One colour indicates transparency and this is programmed into the Sprite Transparency Index register (nextreg 0x4B). By default the transparent value is 0xE3.

As an example of an 8-bit sprite, let’s have a look at the sprite below:

[[File:Sprite_1.png|frame|center|Pattern example]]

Using the default palette, which is initialised with RGB332 colours from 0-255, the hexadecimal values for this pattern arranged in a 16×16 array are shown below:

<pre>04040404040404E3E3E3E3E3E3E3E3E3
04FFFFFFFFFF04E3E3E3E3E3E3E3E3E3
04FFFBFBFBFF04E3E3E3E3E3E3E3E3E3
04FFFBF5F5FBFF04E3E3E3E3E3E3E3E3
04FFFBF5A8A8FBFF04E3E3E3E3E3E3E3
04FFFFFBA844A8FBFF04E3E3E3E3E3E3
040404FFFBA844A8FBFF04E3E3E3E3E3
E3E3E304FFFBA84444FBFF04E304E3E3
E3E3E3E304FFFB444444FBFF044D04E3
E3E3E3E3E304FFFB44444444FA4D04E3
E3E3E3E3E3E304FFFB44FFF54404E3E3
E3E3E3E3E3E3E304FF44F5A804E3E3E3
E3E3E3E3E3E3E3E304FA4404A804E3E3
E3E3E3E3E3E3E3044D4D04E304F504E3
E3E3E3E3E3E3E3E30404E3E3E304FA04
E3E3E3E3E3E3E3E3E3E3E3E3E3E30404</pre>

Here 0xE3 is used as the transparent index.

These 256 bytes would be stored in pattern memory in left to right, top to bottom order.

=== 4-Bit Sprite Patterns ===
The 16×16 pixel image uses 4-bits for each pixel so that each pixel can be one of 16 colours. One colour indicates transparency and this is programmed into the lower 4-bits of the Sprite Transparency Index register (nextreg 0x4B). By default the transparency value is 0x3. Note that the same register is shared with 8-bit patterns to identify the transparent index.

Since each pixel only occupies 4-bits, two pixels are stored in each byte. The leftmost pixel is stored in the upper 4-bits and the rightmost pixel is stored in the lower 4-bits.

As an example we will use the same sprite image as was given in the 8-bit pattern example. Here only the lower 4 bits of each pixel is retained to confine each pixel’s color to 4-bits:

<pre>4444444333333333
4FFFFF4333333333
4FBBBF4333333333
4FB55BF433333333
4FB588BF43333333
4FFB848BF4333333
444FB848BF433333
3334FB844BF43433
33334FB444BF4D43
333334FB4444AD43
3333334FB4F54433
33333334F4584333
333333334A448433
33333334DD434543
33333333443334A4
3333333333333344</pre>

0x3 is used as the transparent index.

These 128 bytes would be stored in pattern memory in left to right, top to bottom order.

The actual colour that will appear on screen will depend on the palette, described below. The default palette will not likely generate suitable colours for 4-bit sprites.

=== Sprite Palette ===
Each pixel of a sprite image is 8-bit for 8-bit patterns or 4-bit for 4-bit patterns. The pixel value is known as a pixel colour index. This colour index is combined with the sprite’s palette offset. The palette offset is a 4-bit value added to the top 4-bits of the pixel colour index. The purpose of the palette offset is to allow a sprite to change the colour of an image.

The final sprite colour index generated by the sprite hardware is then the sum of the pixel index and the 4-bit palette offset. In pictures using binary math:

<pre>8-bit Sprite
PPPP0000
+ IIIIIIII
----------
SSSSSSSS

4-bit Sprite
PPPP0000
+ 0000IIII
----------
SSSSSSSS = PPPPIIII</pre>

Where “PPPP” is the 4-bit palette offset from the sprite’s attributes and the “I”s represent the pixel value from the sprite pattern. The final sprite index is represented by the 8-bit value “SSSSSSSS”.

For 4-bit sprites the palette offset can be thought of as selecting one of 16 different 16-colour palettes.

This final 8-bit sprite index is then passed through the sprite palette which acts like a lookup table that returns the 9-bit RGB333 colour associated with the sprite index.

At power up, the sprite palette is initialized such that the sprite index passes through unchanged and is therefore interpretted as an RGB332 colour. The missing third blue bit is generated as the logical OR of the two other blue bits. In short, for 8-bit sprites, the sprite index also acts like the colour when using the default palette.

=== Sprite Attributes ===
A sprite’s attributes is a list of properties that determine how and where the sprite is drawn.

Each sprite is described by either 4 or 5 attribute bytes listed below:

==== Sprite Attribute 0 ====
<pre>X X X X X X X X</pre>
The least significant eight bits of the sprite’s X coordinate. The ninth bit is found in sprite attribute 2.

==== Sprite Attribute 1 ====
<pre>Y Y Y Y Y Y Y Y</pre>
The least significant eight bits of the sprite’s Y coordinate. The ninth bit is optional and is found in attribute 4.

==== Sprite Attribute 2 ====
<pre>P P P P XM YM R X8/PR</pre>

P = 4-bit Palette Offset 
XM = 1 to mirror the sprite image horizontally 
YM = 1 to mirror the sprite image vertically 
R = 1 to rotate the sprite image 90 degrees clockwise 
X8 = Ninth bit of the sprite’s X coordinate 
PR = 1 to indicate P is relative to the anchor’s palette offset (relative sprites only)

Rotation is applied before mirroring. 
Relative sprites, described below, replace X8 with PR.

[[File:Sprite_flags.png|frame|center|All possibilities of Rotate, Mirror X and Mirror Y flags.]]

==== Sprite Attribute 3 ====
<pre>V E N5 N4 N3 N2 N1 N0</pre>
V = 1 to make the sprite visible 
E = 1 to enable attribute byte 4 
N = Sprite pattern to use 0-63

If E=0, the sprite is fully described by sprite attributes 0-3. The sprite pattern is an 8-bit one identified by pattern N=0-63. The sprite is an anchor and cannot be made relative. The sprite is displayed as if sprite attribute 4 is zero.

If E=1, the sprite is further described by sprite attribute 4.

==== Sprite Attribute 4 ====
===== A. Extended Anchor Sprite =====
<pre>H N6 T X X Y Y Y8</pre>
H = 1 if the sprite pattern is 4-bit 
N6 = 7th pattern bit if the sprite pattern is 4-bit 
T = 0 if relative sprites are composite type else 1 for unified type 
XX = Magnification in the X direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x) 
YY = Magnification in the Y direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x) 
Y8 = Ninth bit of the sprite’s Y coordinate

{H,N6} must not equal {0,1} as this combination is used to indicate a relative sprite.

===== B. Relative Sprite, Composite Type =====
<pre>0 1 N6 X X Y Y PO</pre>
N6 = 7th pattern bit if the sprite pattern is 4-bit 
XX = Magnification in the X direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x) 
YY = Magnification in the Y direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x) 
PO = 1 to indicate the sprite pattern number is relative to the anchor’s

===== C. Relative Sprite, Unified Type =====
<pre>0 1 N6 0 0 0 0 PO</pre>
N6 = 7th pattern bit if the sprite pattern is 4-bit 
PO = 1 to indicate the sprite pattern number is relative to the anchor’s

The display surface for sprites is 320×256. The X coordinate of the sprite is nine bits, ranging over 0-511, and the Y coordinate is optionally nine bits again ranging over 0-511 or is eight bits ranging over 0-255. The full extent 0-511 wraps on both axes, meaning a sprite 16 pixels wide plotted at X coordinate 511 would see its first pixel not displayed (coordinate 511) and the following pixels displayed in coordinates 0-14.

The full display area is visible in VGA. However, the HDMI display is vertically shorter so the top eight pixel rows (Y = 0-7) and the bottom eight pixel rows (Y = 248-255) will not be visible on an HDMI display.

Sprites can be fully described by sprite attributes 0-3 if the E bit in sprite attribute 3 is zero. These sprites are compatible with the original sprite module from core versions prior to 2.00.26.

If the E bit is set then a fifth sprite attribute, sprite attribute 4, becomes active. This attribute introduces scaling, 4-bit patterns, and relative sprites. Scaling is self-explanatory and 4-bit patterns were described in the last section. Relative sprites are described in the next section.

=== Relative Sprites ===
Normal sprites (sprites that are not relative) are known as anchor sprites. As the sprite module draws sprites in the order 0-127 (there are 128 sprites), it internally stores characteristics of the last anchor sprite seen. If following sprites are relative, they inherit some of these characteristics, which allows relative sprites to have, among other things, coordinates relative to the anchor. This means moving the anchor sprite also causes its relatives to move with it.

There are two types of relative sprites supported known as “Composite Sprites” and “Unified Sprites”. The type is determined by the anchor in the T bit of sprite attribute 4.

==== A. Composite Sprites ====
The sprite module records the following information from the anchor:

Anchor.visible
Anchor.X
Anchor.Y
Anchor.palette_offset
Anchor.N (pattern number)
Anchor.H (indicates if the sprite uses 4-bit patterns)
These recorded items are not used by composite sprites:

Anchor.rotate
Anchor.xmirror
Anchor.ymirror
Anchor.xscale
Anchor.yscale
The anchor determines if all its relative sprites use 4-bit patterns or not.

The visibility of a particular relative sprite is the result of ANDing the anchor’s visibility with the relative sprite’s visibility. In other words, if the anchor is invisible then so are all its relatives.

Relative sprites only have 8-bit X and Y coordinates (the ninth bits are taken for other purposes). These are signed offsets from the anchor’s X,Y coordinate. Moving the anchor moves all its relatives along with it.

If the relative sprite has its PR bit set in sprite attribute 2, then the anchor’s palette offset is added to the relative sprite’s to determine the active palette offset for the relative sprite. Otherwise the relative sprite uses its own palette offset as usual.

If the relative sprite has its PO bit set in sprite attribute 4, then the anchor’s pattern number is added to the relative sprite’s to determine the pattern used for display. Otherwise the relative sprite uses its own pattern number as usual. The intention is to supply a method to easily animate a large sprite by manipulating the pattern number in the anchor.

A composite sprite is like a collection of independent sprites tied to an anchor.

==== B. Unified Sprites ====
Unified sprites are a further extension of the composite type. The same information is recorded from the anchor and the same behaviour as described under composite sprites applies.

The difference is the collection of anchor and relatives is treated as if it were a single 16×16 sprite. The anchor’s rotation, mirror, and scaling bits apply to all its relatives. Rotating the anchor causes all the relatives to rotate around the anchor. Mirroring the anchor causes the relatives to mirror around the anchor. The sprite hardware will automatically adjust X,Y coords and rotation, scaling and mirror bits of all relatives according to settings in the anchor.

Unified sprites should be defined as if all its parts are 16×16 in size with the anchor controlling the look of the whole.

A unified sprite is like a big version of an individual 16×16 sprite controlled by the anchor.

=== Programming Sprites ===
Sprites are created via three io registers and a nextreg interface.

Port 0x303B (W)

<pre>X S S S S S S S
N6 X N N N N N N</pre>

A write to this port has two effects.

One is it selects one of 128 sprites for writing sprite attributes via port 0x57.

The other is it selects one of 128 4-bit patterns in pattern memory for writing sprite patterns via port 0x5B. The N6 bit shown is the least significant in the 7-bit pattern number and should always be zero when selecting one of 64 8-bit patterns indicated by N.

Port 0x57 (W)

Once a sprite is selected via port 0x303B, its attributes can be written to this port one byte after another. Sprites can have either four or five attribute bytes and the internal attribute pointer will move onto the next sprite after those four or five attribute bytes are written. This means you can select a sprite via port 0x303B and write attributes for as many sequential sprites as desired. The attribute pointer will roll over from sprite 127 to sprite 0.

Port 0x5B (W)

Once a pattern number is selected via port 0x303B, the 256-byte or 128-byte pattern can be written to this port. The internal pattern pointer auto-increments after each write so as many sequential patterns as desired can be written. The internal pattern pointer will roll over from pattern 127 to pattern 0 (4-bit patterns) or from pattern 63 to pattern 0 (8-bit patterns) automatically.

Port 0x303B (R)

<pre>0 0 0 0 0 0 M C</pre>

M = 1 if the maximum number of sprites per line was exceeded
C = 1 if any two displayed sprites collide on screen

Reading this port automatically resets the M and C bits.

Besides the i/o interface, there is a nextreg interface to sprite attributes. The nextreg interface allows the copper to manipulate sprites and grants the program random access to a sprite’s individual attribute bytes.

(R/W) 0x34 (52) => Sprite Number
If the sprite number is in lockstep with io port 0x303B (nextreg 0x09 bit 4 is set)
bits 7 = Pattern address offset (Add 128 to pattern address)
bits 6-0 = Sprite number 0-127, Pattern number 0-63
Selects which sprite has its attributes connected to the following registers.
Effectively performs an out to port 0x303B with the same value
Otherwise
bit 7 = Ignored
bits 6-0 = Sprite number 0-127
Selects which sprite has its attributes connected to the following registers.
Bit 7 always reads back as zero.

This nextreg can operate in two modes.

If nextreg 0x09 bit 4 is set, then this register is kept in lockstep with i/o port 0x303B. A write to this nextreg is equivalent to a write to port 0x303B and vice versa. In this mode, the i/o interface and nextreg interface are exactly equivalent.

If nextreg 0x09 bit 4 is reset, then the nextreg interface is decoupled from i/o port 0x303B. This nextreg is used to select a particular sprite 0-127 and this is completely independent from the sprite selected for the i/o interface. This independence allows the copper, for example, to manipulate different sprites than the cpu using the i/o interface.

(W) 0x35 (53) => Sprite Attribute 0
(W) 0x75 (117) => Sprite Attribute 0 with automatic post increment of Sprite Number
bits 7-0 = LSB of X coordinate

A write to nextreg 0x75 also increases the selected sprite in nextreg 0x34.

(W) 0x36 (54) => Sprite Attribute 1
(W) 0x76 (118) => Sprite Attribute 1 with automatic post increment of Sprite Number
bits 7-0 = LSB of Y coordinate

A write to nextreg 0x76 also increases the selected sprite in nextreg 0x34.

(W) 0x37 (55) => Sprite Attribute 2
(W) 0x77 (119) => Sprite Attribute 2 with automatic post increment of Sprite Number
bits 7-4 = Palette offset added to top 4 bits of sprite colour index
bit 3 = X mirror
bit 2 = Y mirror
bit 1 = Rotate
bit 0 = MSB of X coordinate

A write to nextreg 0x77 also increases the selected sprite in nextreg 0x34.

(W) 0x38 (56) => Sprite Attribute 3
(W) 0x78 (120) => Sprite Attribute 3 with automatic post increment of Sprite Number
bit 7 = Visible flag (1 = displayed)
bit 6 = Extended attribute (1 = Sprite Attribute 4 is active)
bits 5-0 = Pattern used by sprite (0-63)

A write to nextreg 0x78 also increases the selected sprite in nextreg 0x34.

(W) 0x39 (57) => Sprite Attribute 4
(W) 0x79 (121) => Sprite Attribute 4 with automatic post increment of Sprite Number
4-bit Sprites
bit 7 = H (1 = sprite uses 4-bit patterns)
bit 6 = N6 (0 = use the first 128 bytes of the pattern else use the last 128 bytes)
bit 5 = 1 if relative sprites are composite, 0 if relative sprites are unified
Scaling
bits 4-3 = X scaling (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
bits 2-1 = Y scaling (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
bit 0 = MSB of Y coordinate
A relative mode is enabled if H,N6 = 01. The byte format for relative sprites is described above.

A write to nextreg 0x79 also increases the selected sprite in nextreg 0x34.

=== Global Control of Sprites ===
The following nextreg are also of interest for sprites.

(R/W) 0x09 (09) => Peripheral 4 setting:
bit 7 = Mono setting for AY 2 (1 = mono, 0 default)
bit 6 = Mono setting for AY 1 (1 = mono, 0 default)
bit 5 = Mono setting for AY 0 (1 = mono, 0 default)
bit 4 = Sprite id lockstep (1 = Nextreg 0x34 and IO Port 0x303B are in lockstep, 0 default)
bit 3 = Disables Kempston port ($DF) if set
bit 2 = Disables divMMC ports ($E3, $E7, $EB) if set
bits 1-0 = scanlines (0 after a PoR or Hard-reset)
00 = scanlines off
01 = scanlines 75%
10 = scanlines 50%
11 = scanlines 25%

Bit 4 determines if the i/o interface and nextreg interface operate in lockstep.

(R/W) 0x15 (21) => Sprite and Layers system
bit 7 = LoRes mode, 128 x 96 x 256 colours (1 = enabled)
bit 6 = Sprite priority (1 = sprite 0 on top, 0 = sprite 127 on top)
bit 5 = Enable sprite clipping in over border mode (1 = enabled)
bits 4-2 = set layers priorities:
Reset default is 000, sprites over the Layer 2, over the ULA graphics
000 – S L U
001 – L S U
010 – S U L
011 – L U S
100 – U S L
101 – U L S
110 – S(U+L) ULA and Layer 2 combined, colours clamped to 7
111 – S(U+L-5) ULA and Layer 2 combined, colours clamped to [0,7]
bit 1 = Over border (1 = yes)(Back to 0 after a reset)
bit 0 = Sprites visible (1 = visible)(Back to 0 after a reset)

Bit 0 must be set for sprites to be visible.

Bit 1 set allows sprites to be visible in the border area. When this bit is reset, sprites will not display outside the 256×192 area of the ULA display.

Bit 5 set enables clipping when sprites are visible in the border area. If reset, no clipping is applied and sprites will be visible in the full 320×256 space.

The sprite module draws sprites in the order 0-127 in each scanline. Bit 6 determines whether sprite 0 is topmost or sprite 127 is topmost.

Bits 4:2 determine layer priority and how sprites overlay or are obscured by other layers.

(R/W) 0x19 (25) => Clip Window Sprites
bits 7-0 = Cood. of the clip window
1st write – X1 position
2nd write – X2 position
3rd write – Y1 position
4rd write – Y2 position
The values are 0,255,0,191 after a Reset
Reads do not advance the clip position
When the clip window is enabled for sprites in “over border” mode,
the X coords are internally doubled and the clip window origin is
moved to the sprite origin inside the border.

Sprites will only be visible inside the clipping window. When not in over-border mode (bit 1 of nextreg 0x15) the clipping window is given in ULA screen coordinates with 0,0 correspoding to the top left corner of the ULA screen. In over-border mode, the clipping window’s origin is moved to the sprite coordinate origin 32 pixels to the left and 32 pixels above the ULA screen origin.

Regardless, sprite position is always in sprite coordinates with 32,32 corresponding to the top left corner of the ULA screen.

(W) 0x1C (28) => Clip Window control
bits 7-4 = Reserved, must be 0
bit 3 – reset the tilemap clip index
bit 2 – reset the ULA/LoRes clip index.
bit 1 – reset the sprite clip index.
bit 0 – reset the Layer 2 clip index.

Can be used to reset nextreg 0x19.

(R/W) 0x43 (67) => Palette Control
bit 7 = ‘1’ to disable palette write auto-increment.
bits 6-4 = Select palette for reading or writing:
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
bit 3 = Select Sprites palette (0 = first palette, 1 = second palette)
bit 2 = Select Layer 2 palette (0 = first palette, 1 = second palette)
bit 1 = Select ULA palette (0 = first palette, 1 = second palette)
bit 0 = Enabe ULANext mode if 1. (0 after a reset)

Sprites have two associated palettes which can be selected in this nextreg.

(R/W) 0x40 (64) => Palette Index
bits 7-0 = Select the palette index to change the associated colour.
For the ULA only, INKs are mapped to indices 0-7, Bright INKS to indices 8-15,
PAPERs to indices 16-23 and Bright PAPERs to indices 24-31.
In ULANext mode, INKs come from a subset of indices 0-127 and PAPERs come from
a subset of indices 128-255. The number of active indices depends on the number
of attribute bits assigned to INK and PAPER out of the attribute byte.
The ULA always takes border colour from paper.

Select the starting palette index if writing the sprite palette.

Palette values can be written in either 8-bit or 9-bit form:

(R/W) 0x41 (65) => Palette Value (8 bit colour)
bits 7-0 = Colour for the palette index selected by the register 0x40.
(Format is RRRGGGBB – the lower blue bit of the 9-bit colour will
be a logical OR of blue bits 1 and 0 of this 8-bit value.)
After the write, the palette index is auto-incremented to the next index
if the auto-increment is enabled at reg 0x43. Reads do not auto-increment.

(R/W) 0x44 (68) => Palette Value (9 bit colour)
Two consecutive writes are needed to write the 9 bit colour
1st write:
bits 7-0 = RRRGGGBB
2nd write.
If writing a L2 palette
———————————————————————–
bit 7 = 1 for L2 priority colour, 0 for normal
Priority colour will always be on top even on an SLU priori-
ty arrangement. If you need the exact same colour on priori-
ty and non priority locations you will need to program the
same colour twice changing bit 7 to 0 for the second colour
bits 6-1 = Reserved, must be 0
bit 0 = lsb B

If writing another palette
———————————————————————–
bits 7-1 = Reserved, must be 0
bit 0 = lsb B

After the two consecutives writes the palette index is
auto-incremented if the auto-increment is enabled by reg 0x43.

Reads only return the 2nd byte and do not auto-increment.

(R/W) 0x4B (75) => Transparency index for sprites
bits 7-0 = Set the index value (0xE3 after reset)
For 4-bit sprites only the bottom 4-bits are relevant.

Determines the transparent colour index used for sprites.

File:Sprite flags.png

2019-05-05T10:25:29Z

Intrepidis: Sprite flags.

== Summary ==
Sprite flags.

Sprites

2019-05-05T10:24:46Z

Intrepidis: Add the sprite flags image link.

The Spectrum Next has a hardware sprite system with the following characteristics:

* Total of 128 sprites
* Display surface is 320×256 overlapping the ULA screen by 32 pixels on each side
* Minimum of 100 sprites per scanline*
* Choice of 512 colours for each pixel
* Site of each sprite is 16×16 pixels but sprites can be magnified 2x, 4x or 8x horizontally and vertically
* Sprites can be mirrored and rotated
* Sprites can be grouped together to form larger sprites under the control of a single anchor
* A 16K pattern memory can contain 64 8-bit sprite images or 128 4-bit sprite images and combinations in-between
* A per sprite palette offset allows sprites to share images but colour them differently
* A nextreg interface allows the copper to move sprites during the video frame

<nowiki>*</nowiki>A minimum of 100 16×16 sprites is guaranteed to be displayed in any scanline. Any additional sprites will not be displayed with the hardware ensuring sprites are not partially plotted.

The actual limit is determined by how many 28MHz clock cycles there are in a scanline. The sprite hardware is able to plot one pixel cycle and uses one cycle to qualify each sprite. Since the number of cycles there are in a scanline varies with video timing (HDMI, VGA), the number of pixels that can be plotted also varies but the minimum will be 1600 pixels per line including overhead cycles needed to qualify 100 sprites. Since sprites magified horizontally involve plotting more pixels, x2 x4 x8 sprites will take more cycles to plot and the presence of these sprites in a line will reduce the total number of sprites that can be plotted.

== Sprite Patterns ==
Sprite patterns are the images that each sprite can take on. The images are stored in a 16K memory internal to the FPGA and are identified by pattern number. A particular sprite chooses a pattern by storing a pattern number in its attributes.

All sprites are 16×16 pixels in size but the come in two flavours: 4-bit and 8-bit. The bit width describes how many bits are used to code the colour of each pixel.

An 8-bit sprite uses a full byte to colour each of its pixels so that each pixel can be one of 256 colours. In this case, a 16×16 sprite requires 256 bytes of pattern memory to store its image.

A 4-bit sprite uses a nibble to colour each of its pixels so that each pixel can be one of 16 colours. In this case, a 16×16 sprite requires just 128 bytes of pattern memory to store its image.

The 16K pattern memory can contain any combination of these images, whether they are 128 bytes or 256 bytes and their locations in the pattern memory are described by a pattern number. This pattern number is 7 bits with bits named as follows:

=== Pattern Number ===
<pre>N5 N4 N3 N2 N1 N0 N6
N6, despite the name, is the least significant bit.</pre>

This 7-bit pattern number can identify 128 patterns in the 16k pattern memory, each of which are 128 bytes in size. The full 7-bits are therefore used for 4-bit sprites.

For 8-bit sprites, N6=0 always. The remaining 6 bits can identify 64 patterns, each of which is 256 bytes in size.

The N5:N0,N6 bits are stored in a particular sprite’s attributes to identify which image a sprite uses.

=== 8-Bit Sprite Patterns ===
The 16×16 pixel image uses 8-bits for each pixel so that each pixel can be one of 256 colours. One colour indicates transparency and this is programmed into the Sprite Transparency Index register (nextreg 0x4B). By default the transparent value is 0xE3.

As an example of an 8-bit sprite, let’s have a look at the sprite below:

[[File:Sprite_1.png|frame|center|Pattern example]]

Using the default palette, which is initialised with RGB332 colours from 0-255, the hexadecimal values for this pattern arranged in a 16×16 array are shown below:

<pre>04040404040404E3E3E3E3E3E3E3E3E3
04FFFFFFFFFF04E3E3E3E3E3E3E3E3E3
04FFFBFBFBFF04E3E3E3E3E3E3E3E3E3
04FFFBF5F5FBFF04E3E3E3E3E3E3E3E3
04FFFBF5A8A8FBFF04E3E3E3E3E3E3E3
04FFFFFBA844A8FBFF04E3E3E3E3E3E3
040404FFFBA844A8FBFF04E3E3E3E3E3
E3E3E304FFFBA84444FBFF04E304E3E3
E3E3E3E304FFFB444444FBFF044D04E3
E3E3E3E3E304FFFB44444444FA4D04E3
E3E3E3E3E3E304FFFB44FFF54404E3E3
E3E3E3E3E3E3E304FF44F5A804E3E3E3
E3E3E3E3E3E3E3E304FA4404A804E3E3
E3E3E3E3E3E3E3044D4D04E304F504E3
E3E3E3E3E3E3E3E30404E3E3E304FA04
E3E3E3E3E3E3E3E3E3E3E3E3E3E30404</pre>

Here 0xE3 is used as the transparent index.

These 256 bytes would be stored in pattern memory in left to right, top to bottom order.

=== 4-Bit Sprite Patterns ===
The 16×16 pixel image uses 4-bits for each pixel so that each pixel can be one of 16 colours. One colour indicates transparency and this is programmed into the lower 4-bits of the Sprite Transparency Index register (nextreg 0x4B). By default the transparency value is 0x3. Note that the same register is shared with 8-bit patterns to identify the transparent index.

Since each pixel only occupies 4-bits, two pixels are stored in each byte. The leftmost pixel is stored in the upper 4-bits and the rightmost pixel is stored in the lower 4-bits.

As an example we will use the same sprite image as was given in the 8-bit pattern example. Here only the lower 4 bits of each pixel is retained to confine each pixel’s color to 4-bits:

<pre>4444444333333333
4FFFFF4333333333
4FBBBF4333333333
4FB55BF433333333
4FB588BF43333333
4FFB848BF4333333
444FB848BF433333
3334FB844BF43433
33334FB444BF4D43
333334FB4444AD43
3333334FB4F54433
33333334F4584333
333333334A448433
33333334DD434543
33333333443334A4
3333333333333344</pre>

0x3 is used as the transparent index.

These 128 bytes would be stored in pattern memory in left to right, top to bottom order.

The actual colour that will appear on screen will depend on the palette, described below. The default palette will not likely generate suitable colours for 4-bit sprites.

=== Sprite Palette ===
Each pixel of a sprite image is 8-bit for 8-bit patterns or 4-bit for 4-bit patterns. The pixel value is known as a pixel colour index. This colour index is combined with the sprite’s palette offset. The palette offset is a 4-bit value added to the top 4-bits of the pixel colour index. The purpose of the palette offset is to allow a sprite to change the colour of an image.

The final sprite colour index generated by the sprite hardware is then the sum of the pixel index and the 4-bit palette offset. In pictures using binary math:

<pre>8-bit Sprite
PPPP0000
+ IIIIIIII
----------
SSSSSSSS

4-bit Sprite
PPPP0000
+ 0000IIII
----------
SSSSSSSS = PPPPIIII</pre>

Where “PPPP” is the 4-bit palette offset from the sprite’s attributes and the “I”s represent the pixel value from the sprite pattern. The final sprite index is represented by the 8-bit value “SSSSSSSS”.

For 4-bit sprites the palette offset can be thought of as selecting one of 16 different 16-colour palettes.

This final 8-bit sprite index is then passed through the sprite palette which acts like a lookup table that returns the 9-bit RGB333 colour associated with the sprite index.

At power up, the sprite palette is initialized such that the sprite index passes through unchanged and is therefore interpretted as an RGB332 colour. The missing third blue bit is generated as the logical OR of the two other blue bits. In short, for 8-bit sprites, the sprite index also acts like the colour when using the default palette.

=== Sprite Attributes ===
A sprite’s attributes is a list of properties that determine how and where the sprite is drawn.

Each sprite is described by either 4 or 5 attribute bytes listed below:

==== Sprite Attribute 0 ====
<pre>X X X X X X X X</pre>
The least significant eight bits of the sprite’s X coordinate. The ninth bit is found in sprite attribute 2.

==== Sprite Attribute 1 ====
<pre>Y Y Y Y Y Y Y Y</pre>
The least significant eight bits of the sprite’s Y coordinate. The ninth bit is optional and is found in attribute 4.

==== Sprite Attribute 2 ====
<pre>P P P P XM YM R X8/PR</pre>

P = 4-bit Palette Offset 
XM = 1 to mirror the sprite image horizontally 
YM = 1 to mirror the sprite image vertically 
R = 1 to rotate the sprite image 90 degrees clockwise 
X8 = Ninth bit of the sprite’s X coordinate 
PR = 1 to indicate P is relative to the anchor’s palette offset (relative sprites only)

Rotation is applied before mirroring. 
Relative sprites, described below, replace X8 with PR.

[[File:Sprite_flags.png|frame|center|All possibilities of Rotate, Mirror X and Mirror Y flags.]]

==== Sprite Attribute 3 ====
<pre>V E N5 N4 N3 N2 N1 N0</pre>
V = 1 to make the sprite visible
E = 1 to enable attribute byte 4
N = Sprite pattern to use 0-63

If E=0, the sprite is fully described by sprite attributes 0-3. The sprite pattern is an 8-bit one identified by pattern N=0-63. The sprite is an anchor and cannot be made relative. The sprite is displayed as if sprite attribute 4 is zero.

If E=1, the sprite is further described by sprite attribute 4.

==== Sprite Attribute 4 ====
===== A. Extended Anchor Sprite =====
<pre>H N6 T X X Y Y Y8</pre>
H = 1 if the sprite pattern is 4-bit
N6 = 7th pattern bit if the sprite pattern is 4-bit
T = 0 if relative sprites are composite type else 1 for unified type
XX = Magnification in the X direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
YY = Magnification in the Y direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
Y8 = Ninth bit of the sprite’s Y coordinate

{H,N6} must not equal {0,1} as this combination is used to indicate a relative sprite.

===== B. Relative Sprite, Composite Type =====
<pre>0 1 N6 X X Y Y PO</pre>
N6 = 7th pattern bit if the sprite pattern is 4-bit
XX = Magnification in the X direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
YY = Magnification in the Y direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
PO = 1 to indicate the sprite pattern number is relative to the anchor’s

===== C. Relative Sprite, Unified Type =====
<pre>0 1 N6 0 0 0 0 PO</pre>
N6 = 7th pattern bit if the sprite pattern is 4-bit
PO = 1 to indicate the sprite pattern number is relative to the anchor’s

The display surface for sprites is 320×256. The X coordinate of the sprite is nine bits, ranging over 0-511, and the Y coordinate is optionally nine bits again ranging over 0-511 or is eight bits ranging over 0-255. The full extent 0-511 wraps on both axes, meaning a sprite 16 pixels wide plotted at X coordinate 511 would see its first pixel not displayed (coordinate 511) and the following pixels displayed in coordinates 0-14.

The full display area is visible in VGA. However, the HDMI display is vertically shorter so the top eight pixel rows (Y = 0-7) and the bottom eight pixel rows (Y = 248-255) will not be visible on an HDMI display.

Sprites can be fully described by sprite attributes 0-3 if the E bit in sprite attribute 3 is zero. These sprites are compatible with the original sprite module from core versions prior to 2.00.26.

If the E bit is set then a fifth sprite attribute, sprite attribute 4, becomes active. This attribute introduces scaling, 4-bit patterns, and relative sprites. Scaling is self-explanatory and 4-bit patterns were described in the last section. Relative sprites are described in the next section.

=== Relative Sprites ===
Normal sprites (sprites that are not relative) are known as anchor sprites. As the sprite module draws sprites in the order 0-127 (there are 128 sprites), it internally stores characteristics of the last anchor sprite seen. If following sprites are relative, they inherit some of these characteristics, which allows relative sprites to have, among other things, coordinates relative to the anchor. This means moving the anchor sprite also causes its relatives to move with it.

There are two types of relative sprites supported known as “Composite Sprites” and “Unified Sprites”. The type is determined by the anchor in the T bit of sprite attribute 4.

==== A. Composite Sprites ====
The sprite module records the following information from the anchor:

Anchor.visible
Anchor.X
Anchor.Y
Anchor.palette_offset
Anchor.N (pattern number)
Anchor.H (indicates if the sprite uses 4-bit patterns)
These recorded items are not used by composite sprites:

Anchor.rotate
Anchor.xmirror
Anchor.ymirror
Anchor.xscale
Anchor.yscale
The anchor determines if all its relative sprites use 4-bit patterns or not.

The visibility of a particular relative sprite is the result of ANDing the anchor’s visibility with the relative sprite’s visibility. In other words, if the anchor is invisible then so are all its relatives.

Relative sprites only have 8-bit X and Y coordinates (the ninth bits are taken for other purposes). These are signed offsets from the anchor’s X,Y coordinate. Moving the anchor moves all its relatives along with it.

If the relative sprite has its PR bit set in sprite attribute 2, then the anchor’s palette offset is added to the relative sprite’s to determine the active palette offset for the relative sprite. Otherwise the relative sprite uses its own palette offset as usual.

If the relative sprite has its PO bit set in sprite attribute 4, then the anchor’s pattern number is added to the relative sprite’s to determine the pattern used for display. Otherwise the relative sprite uses its own pattern number as usual. The intention is to supply a method to easily animate a large sprite by manipulating the pattern number in the anchor.

A composite sprite is like a collection of independent sprites tied to an anchor.

==== B. Unified Sprites ====
Unified sprites are a further extension of the composite type. The same information is recorded from the anchor and the same behaviour as described under composite sprites applies.

The difference is the collection of anchor and relatives is treated as if it were a single 16×16 sprite. The anchor’s rotation, mirror, and scaling bits apply to all its relatives. Rotating the anchor causes all the relatives to rotate around the anchor. Mirroring the anchor causes the relatives to mirror around the anchor. The sprite hardware will automatically adjust X,Y coords and rotation, scaling and mirror bits of all relatives according to settings in the anchor.

Unified sprites should be defined as if all its parts are 16×16 in size with the anchor controlling the look of the whole.

A unified sprite is like a big version of an individual 16×16 sprite controlled by the anchor.

=== Programming Sprites ===
Sprites are created via three io registers and a nextreg interface.

Port 0x303B (W)

<pre>X S S S S S S S
N6 X N N N N N N</pre>

A write to this port has two effects.

One is it selects one of 128 sprites for writing sprite attributes via port 0x57.

The other is it selects one of 128 4-bit patterns in pattern memory for writing sprite patterns via port 0x5B. The N6 bit shown is the least significant in the 7-bit pattern number and should always be zero when selecting one of 64 8-bit patterns indicated by N.

Port 0x57 (W)

Once a sprite is selected via port 0x303B, its attributes can be written to this port one byte after another. Sprites can have either four or five attribute bytes and the internal attribute pointer will move onto the next sprite after those four or five attribute bytes are written. This means you can select a sprite via port 0x303B and write attributes for as many sequential sprites as desired. The attribute pointer will roll over from sprite 127 to sprite 0.

Port 0x5B (W)

Once a pattern number is selected via port 0x303B, the 256-byte or 128-byte pattern can be written to this port. The internal pattern pointer auto-increments after each write so as many sequential patterns as desired can be written. The internal pattern pointer will roll over from pattern 127 to pattern 0 (4-bit patterns) or from pattern 63 to pattern 0 (8-bit patterns) automatically.

Port 0x303B (R)

<pre>0 0 0 0 0 0 M C</pre>

M = 1 if the maximum number of sprites per line was exceeded
C = 1 if any two displayed sprites collide on screen

Reading this port automatically resets the M and C bits.

Besides the i/o interface, there is a nextreg interface to sprite attributes. The nextreg interface allows the copper to manipulate sprites and grants the program random access to a sprite’s individual attribute bytes.

(R/W) 0x34 (52) => Sprite Number
If the sprite number is in lockstep with io port 0x303B (nextreg 0x09 bit 4 is set)
bits 7 = Pattern address offset (Add 128 to pattern address)
bits 6-0 = Sprite number 0-127, Pattern number 0-63
Selects which sprite has its attributes connected to the following registers.
Effectively performs an out to port 0x303B with the same value
Otherwise
bit 7 = Ignored
bits 6-0 = Sprite number 0-127
Selects which sprite has its attributes connected to the following registers.
Bit 7 always reads back as zero.

This nextreg can operate in two modes.

If nextreg 0x09 bit 4 is set, then this register is kept in lockstep with i/o port 0x303B. A write to this nextreg is equivalent to a write to port 0x303B and vice versa. In this mode, the i/o interface and nextreg interface are exactly equivalent.

If nextreg 0x09 bit 4 is reset, then the nextreg interface is decoupled from i/o port 0x303B. This nextreg is used to select a particular sprite 0-127 and this is completely independent from the sprite selected for the i/o interface. This independence allows the copper, for example, to manipulate different sprites than the cpu using the i/o interface.

(W) 0x35 (53) => Sprite Attribute 0
(W) 0x75 (117) => Sprite Attribute 0 with automatic post increment of Sprite Number
bits 7-0 = LSB of X coordinate

A write to nextreg 0x75 also increases the selected sprite in nextreg 0x34.

(W) 0x36 (54) => Sprite Attribute 1
(W) 0x76 (118) => Sprite Attribute 1 with automatic post increment of Sprite Number
bits 7-0 = LSB of Y coordinate

A write to nextreg 0x76 also increases the selected sprite in nextreg 0x34.

(W) 0x37 (55) => Sprite Attribute 2
(W) 0x77 (119) => Sprite Attribute 2 with automatic post increment of Sprite Number
bits 7-4 = Palette offset added to top 4 bits of sprite colour index
bit 3 = X mirror
bit 2 = Y mirror
bit 1 = Rotate
bit 0 = MSB of X coordinate

A write to nextreg 0x77 also increases the selected sprite in nextreg 0x34.

(W) 0x38 (56) => Sprite Attribute 3
(W) 0x78 (120) => Sprite Attribute 3 with automatic post increment of Sprite Number
bit 7 = Visible flag (1 = displayed)
bit 6 = Extended attribute (1 = Sprite Attribute 4 is active)
bits 5-0 = Pattern used by sprite (0-63)

A write to nextreg 0x78 also increases the selected sprite in nextreg 0x34.

(W) 0x39 (57) => Sprite Attribute 4
(W) 0x79 (121) => Sprite Attribute 4 with automatic post increment of Sprite Number
4-bit Sprites
bit 7 = H (1 = sprite uses 4-bit patterns)
bit 6 = N6 (0 = use the first 128 bytes of the pattern else use the last 128 bytes)
bit 5 = 1 if relative sprites are composite, 0 if relative sprites are unified
Scaling
bits 4-3 = X scaling (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
bits 2-1 = Y scaling (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
bit 0 = MSB of Y coordinate
A relative mode is enabled if H,N6 = 01. The byte format for relative sprites is described above.

A write to nextreg 0x79 also increases the selected sprite in nextreg 0x34.

=== Global Control of Sprites ===
The following nextreg are also of interest for sprites.

(R/W) 0x09 (09) => Peripheral 4 setting:
bit 7 = Mono setting for AY 2 (1 = mono, 0 default)
bit 6 = Mono setting for AY 1 (1 = mono, 0 default)
bit 5 = Mono setting for AY 0 (1 = mono, 0 default)
bit 4 = Sprite id lockstep (1 = Nextreg 0x34 and IO Port 0x303B are in lockstep, 0 default)
bit 3 = Disables Kempston port ($DF) if set
bit 2 = Disables divMMC ports ($E3, $E7, $EB) if set
bits 1-0 = scanlines (0 after a PoR or Hard-reset)
00 = scanlines off
01 = scanlines 75%
10 = scanlines 50%
11 = scanlines 25%

Bit 4 determines if the i/o interface and nextreg interface operate in lockstep.

(R/W) 0x15 (21) => Sprite and Layers system
bit 7 = LoRes mode, 128 x 96 x 256 colours (1 = enabled)
bit 6 = Sprite priority (1 = sprite 0 on top, 0 = sprite 127 on top)
bit 5 = Enable sprite clipping in over border mode (1 = enabled)
bits 4-2 = set layers priorities:
Reset default is 000, sprites over the Layer 2, over the ULA graphics
000 – S L U
001 – L S U
010 – S U L
011 – L U S
100 – U S L
101 – U L S
110 – S(U+L) ULA and Layer 2 combined, colours clamped to 7
111 – S(U+L-5) ULA and Layer 2 combined, colours clamped to [0,7]
bit 1 = Over border (1 = yes)(Back to 0 after a reset)
bit 0 = Sprites visible (1 = visible)(Back to 0 after a reset)

Bit 0 must be set for sprites to be visible.

Bit 1 set allows sprites to be visible in the border area. When this bit is reset, sprites will not display outside the 256×192 area of the ULA display.

Bit 5 set enables clipping when sprites are visible in the border area. If reset, no clipping is applied and sprites will be visible in the full 320×256 space.

The sprite module draws sprites in the order 0-127 in each scanline. Bit 6 determines whether sprite 0 is topmost or sprite 127 is topmost.

Bits 4:2 determine layer priority and how sprites overlay or are obscured by other layers.

(R/W) 0x19 (25) => Clip Window Sprites
bits 7-0 = Cood. of the clip window
1st write – X1 position
2nd write – X2 position
3rd write – Y1 position
4rd write – Y2 position
The values are 0,255,0,191 after a Reset
Reads do not advance the clip position
When the clip window is enabled for sprites in “over border” mode,
the X coords are internally doubled and the clip window origin is
moved to the sprite origin inside the border.

Sprites will only be visible inside the clipping window. When not in over-border mode (bit 1 of nextreg 0x15) the clipping window is given in ULA screen coordinates with 0,0 correspoding to the top left corner of the ULA screen. In over-border mode, the clipping window’s origin is moved to the sprite coordinate origin 32 pixels to the left and 32 pixels above the ULA screen origin.

Regardless, sprite position is always in sprite coordinates with 32,32 corresponding to the top left corner of the ULA screen.

(W) 0x1C (28) => Clip Window control
bits 7-4 = Reserved, must be 0
bit 3 – reset the tilemap clip index
bit 2 – reset the ULA/LoRes clip index.
bit 1 – reset the sprite clip index.
bit 0 – reset the Layer 2 clip index.

Can be used to reset nextreg 0x19.

(R/W) 0x43 (67) => Palette Control
bit 7 = ‘1’ to disable palette write auto-increment.
bits 6-4 = Select palette for reading or writing:
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
bit 3 = Select Sprites palette (0 = first palette, 1 = second palette)
bit 2 = Select Layer 2 palette (0 = first palette, 1 = second palette)
bit 1 = Select ULA palette (0 = first palette, 1 = second palette)
bit 0 = Enabe ULANext mode if 1. (0 after a reset)

Sprites have two associated palettes which can be selected in this nextreg.

(R/W) 0x40 (64) => Palette Index
bits 7-0 = Select the palette index to change the associated colour.
For the ULA only, INKs are mapped to indices 0-7, Bright INKS to indices 8-15,
PAPERs to indices 16-23 and Bright PAPERs to indices 24-31.
In ULANext mode, INKs come from a subset of indices 0-127 and PAPERs come from
a subset of indices 128-255. The number of active indices depends on the number
of attribute bits assigned to INK and PAPER out of the attribute byte.
The ULA always takes border colour from paper.

Select the starting palette index if writing the sprite palette.

Palette values can be written in either 8-bit or 9-bit form:

(R/W) 0x41 (65) => Palette Value (8 bit colour)
bits 7-0 = Colour for the palette index selected by the register 0x40.
(Format is RRRGGGBB – the lower blue bit of the 9-bit colour will
be a logical OR of blue bits 1 and 0 of this 8-bit value.)
After the write, the palette index is auto-incremented to the next index
if the auto-increment is enabled at reg 0x43. Reads do not auto-increment.

(R/W) 0x44 (68) => Palette Value (9 bit colour)
Two consecutive writes are needed to write the 9 bit colour
1st write:
bits 7-0 = RRRGGGBB
2nd write.
If writing a L2 palette
———————————————————————–
bit 7 = 1 for L2 priority colour, 0 for normal
Priority colour will always be on top even on an SLU priori-
ty arrangement. If you need the exact same colour on priori-
ty and non priority locations you will need to program the
same colour twice changing bit 7 to 0 for the second colour
bits 6-1 = Reserved, must be 0
bit 0 = lsb B

If writing another palette
———————————————————————–
bits 7-1 = Reserved, must be 0
bit 0 = lsb B

After the two consecutives writes the palette index is
auto-incremented if the auto-increment is enabled by reg 0x43.

Reads only return the 2nd byte and do not auto-increment.

(R/W) 0x4B (75) => Transparency index for sprites
bits 7-0 = Set the index value (0xE3 after reset)
For 4-bit sprites only the bottom 4-bits are relevant.

Determines the transparent colour index used for sprites.

Sprites

2019-05-05T10:19:17Z

Intrepidis: Format the code sections.

The Spectrum Next has a hardware sprite system with the following characteristics:

* Total of 128 sprites
* Display surface is 320×256 overlapping the ULA screen by 32 pixels on each side
* Minimum of 100 sprites per scanline*
* Choice of 512 colours for each pixel
* Site of each sprite is 16×16 pixels but sprites can be magnified 2x, 4x or 8x horizontally and vertically
* Sprites can be mirrored and rotated
* Sprites can be grouped together to form larger sprites under the control of a single anchor
* A 16K pattern memory can contain 64 8-bit sprite images or 128 4-bit sprite images and combinations in-between
* A per sprite palette offset allows sprites to share images but colour them differently
* A nextreg interface allows the copper to move sprites during the video frame

<nowiki>*</nowiki>A minimum of 100 16×16 sprites is guaranteed to be displayed in any scanline. Any additional sprites will not be displayed with the hardware ensuring sprites are not partially plotted.

The actual limit is determined by how many 28MHz clock cycles there are in a scanline. The sprite hardware is able to plot one pixel cycle and uses one cycle to qualify each sprite. Since the number of cycles there are in a scanline varies with video timing (HDMI, VGA), the number of pixels that can be plotted also varies but the minimum will be 1600 pixels per line including overhead cycles needed to qualify 100 sprites. Since sprites magified horizontally involve plotting more pixels, x2 x4 x8 sprites will take more cycles to plot and the presence of these sprites in a line will reduce the total number of sprites that can be plotted.

== Sprite Patterns ==
Sprite patterns are the images that each sprite can take on. The images are stored in a 16K memory internal to the FPGA and are identified by pattern number. A particular sprite chooses a pattern by storing a pattern number in its attributes.

All sprites are 16×16 pixels in size but the come in two flavours: 4-bit and 8-bit. The bit width describes how many bits are used to code the colour of each pixel.

An 8-bit sprite uses a full byte to colour each of its pixels so that each pixel can be one of 256 colours. In this case, a 16×16 sprite requires 256 bytes of pattern memory to store its image.

A 4-bit sprite uses a nibble to colour each of its pixels so that each pixel can be one of 16 colours. In this case, a 16×16 sprite requires just 128 bytes of pattern memory to store its image.

The 16K pattern memory can contain any combination of these images, whether they are 128 bytes or 256 bytes and their locations in the pattern memory are described by a pattern number. This pattern number is 7 bits with bits named as follows:

=== Pattern Number ===
<pre>N5 N4 N3 N2 N1 N0 N6
N6, despite the name, is the least significant bit.</pre>

This 7-bit pattern number can identify 128 patterns in the 16k pattern memory, each of which are 128 bytes in size. The full 7-bits are therefore used for 4-bit sprites.

For 8-bit sprites, N6=0 always. The remaining 6 bits can identify 64 patterns, each of which is 256 bytes in size.

The N5:N0,N6 bits are stored in a particular sprite’s attributes to identify which image a sprite uses.

=== 8-Bit Sprite Patterns ===
The 16×16 pixel image uses 8-bits for each pixel so that each pixel can be one of 256 colours. One colour indicates transparency and this is programmed into the Sprite Transparency Index register (nextreg 0x4B). By default the transparent value is 0xE3.

As an example of an 8-bit sprite, let’s have a look at the sprite below:

[[File:Sprite_1.png|frame|center|Pattern example]]

Using the default palette, which is initialised with RGB332 colours from 0-255, the hexadecimal values for this pattern arranged in a 16×16 array are shown below:

<pre>04040404040404E3E3E3E3E3E3E3E3E3
04FFFFFFFFFF04E3E3E3E3E3E3E3E3E3
04FFFBFBFBFF04E3E3E3E3E3E3E3E3E3
04FFFBF5F5FBFF04E3E3E3E3E3E3E3E3
04FFFBF5A8A8FBFF04E3E3E3E3E3E3E3
04FFFFFBA844A8FBFF04E3E3E3E3E3E3
040404FFFBA844A8FBFF04E3E3E3E3E3
E3E3E304FFFBA84444FBFF04E304E3E3
E3E3E3E304FFFB444444FBFF044D04E3
E3E3E3E3E304FFFB44444444FA4D04E3
E3E3E3E3E3E304FFFB44FFF54404E3E3
E3E3E3E3E3E3E304FF44F5A804E3E3E3
E3E3E3E3E3E3E3E304FA4404A804E3E3
E3E3E3E3E3E3E3044D4D04E304F504E3
E3E3E3E3E3E3E3E30404E3E3E304FA04
E3E3E3E3E3E3E3E3E3E3E3E3E3E30404</pre>

Here 0xE3 is used as the transparent index.

These 256 bytes would be stored in pattern memory in left to right, top to bottom order.

=== 4-Bit Sprite Patterns ===
The 16×16 pixel image uses 4-bits for each pixel so that each pixel can be one of 16 colours. One colour indicates transparency and this is programmed into the lower 4-bits of the Sprite Transparency Index register (nextreg 0x4B). By default the transparency value is 0x3. Note that the same register is shared with 8-bit patterns to identify the transparent index.

Since each pixel only occupies 4-bits, two pixels are stored in each byte. The leftmost pixel is stored in the upper 4-bits and the rightmost pixel is stored in the lower 4-bits.

As an example we will use the same sprite image as was given in the 8-bit pattern example. Here only the lower 4 bits of each pixel is retained to confine each pixel’s color to 4-bits:

<pre>4444444333333333
4FFFFF4333333333
4FBBBF4333333333
4FB55BF433333333
4FB588BF43333333
4FFB848BF4333333
444FB848BF433333
3334FB844BF43433
33334FB444BF4D43
333334FB4444AD43
3333334FB4F54433
33333334F4584333
333333334A448433
33333334DD434543
33333333443334A4
3333333333333344</pre>

0x3 is used as the transparent index.

These 128 bytes would be stored in pattern memory in left to right, top to bottom order.

The actual colour that will appear on screen will depend on the palette, described below. The default palette will not likely generate suitable colours for 4-bit sprites.

=== Sprite Palette ===
Each pixel of a sprite image is 8-bit for 8-bit patterns or 4-bit for 4-bit patterns. The pixel value is known as a pixel colour index. This colour index is combined with the sprite’s palette offset. The palette offset is a 4-bit value added to the top 4-bits of the pixel colour index. The purpose of the palette offset is to allow a sprite to change the colour of an image.

The final sprite colour index generated by the sprite hardware is then the sum of the pixel index and the 4-bit palette offset. In pictures using binary math:

<pre>8-bit Sprite
PPPP0000
+ IIIIIIII
----------
SSSSSSSS

4-bit Sprite
PPPP0000
+ 0000IIII
----------
SSSSSSSS = PPPPIIII</pre>

Where “PPPP” is the 4-bit palette offset from the sprite’s attributes and the “I”s represent the pixel value from the sprite pattern. The final sprite index is represented by the 8-bit value “SSSSSSSS”.

For 4-bit sprites the palette offset can be thought of as selecting one of 16 different 16-colour palettes.

This final 8-bit sprite index is then passed through the sprite palette which acts like a lookup table that returns the 9-bit RGB333 colour associated with the sprite index.

At power up, the sprite palette is initialized such that the sprite index passes through unchanged and is therefore interpretted as an RGB332 colour. The missing third blue bit is generated as the logical OR of the two other blue bits. In short, for 8-bit sprites, the sprite index also acts like the colour when using the default palette.

=== Sprite Attributes ===
A sprite’s attributes is a list of properties that determine how and where the sprite is drawn.

Each sprite is described by either 4 or 5 attribute bytes listed below:

==== Sprite Attribute 0 ====
<pre>X X X X X X X X</pre>
The least significant eight bits of the sprite’s X coordinate. The ninth bit is found in sprite attribute 2.

==== Sprite Attribute 1 ====
<pre>Y Y Y Y Y Y Y Y</pre>
The least significant eight bits of the sprite’s Y coordinate. The ninth bit is optional and is found in attribute 4.

==== Sprite Attribute 2 ====
<pre>P P P P XM YM R X8/PR</pre>
P = 4-bit Palette Offset
XM = 1 to mirror the sprite image horizontally
YM = 1 to mirror the sprite image vertically
R = 1 to rotate the sprite image 90 degrees clockwise
X8 = Ninth bit of the sprite’s X coordinate
PR = 1 to indicate P is relative to the anchor’s palette offset (relative sprites only)

Rotation is applied before mirroring.
Relative sprites, described below, replace X8 with PR.

All possibilities of Rotate, Mirror X and Mirror Y flags.

==== Sprite Attribute 3 ====
<pre>V E N5 N4 N3 N2 N1 N0</pre>
V = 1 to make the sprite visible
E = 1 to enable attribute byte 4
N = Sprite pattern to use 0-63

If E=0, the sprite is fully described by sprite attributes 0-3. The sprite pattern is an 8-bit one identified by pattern N=0-63. The sprite is an anchor and cannot be made relative. The sprite is displayed as if sprite attribute 4 is zero.

If E=1, the sprite is further described by sprite attribute 4.

==== Sprite Attribute 4 ====
===== A. Extended Anchor Sprite =====
<pre>H N6 T X X Y Y Y8</pre>
H = 1 if the sprite pattern is 4-bit
N6 = 7th pattern bit if the sprite pattern is 4-bit
T = 0 if relative sprites are composite type else 1 for unified type
XX = Magnification in the X direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
YY = Magnification in the Y direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
Y8 = Ninth bit of the sprite’s Y coordinate

{H,N6} must not equal {0,1} as this combination is used to indicate a relative sprite.

===== B. Relative Sprite, Composite Type =====
<pre>0 1 N6 X X Y Y PO</pre>
N6 = 7th pattern bit if the sprite pattern is 4-bit
XX = Magnification in the X direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
YY = Magnification in the Y direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
PO = 1 to indicate the sprite pattern number is relative to the anchor’s

===== C. Relative Sprite, Unified Type =====
<pre>0 1 N6 0 0 0 0 PO</pre>
N6 = 7th pattern bit if the sprite pattern is 4-bit
PO = 1 to indicate the sprite pattern number is relative to the anchor’s

The display surface for sprites is 320×256. The X coordinate of the sprite is nine bits, ranging over 0-511, and the Y coordinate is optionally nine bits again ranging over 0-511 or is eight bits ranging over 0-255. The full extent 0-511 wraps on both axes, meaning a sprite 16 pixels wide plotted at X coordinate 511 would see its first pixel not displayed (coordinate 511) and the following pixels displayed in coordinates 0-14.

The full display area is visible in VGA. However, the HDMI display is vertically shorter so the top eight pixel rows (Y = 0-7) and the bottom eight pixel rows (Y = 248-255) will not be visible on an HDMI display.

Sprites can be fully described by sprite attributes 0-3 if the E bit in sprite attribute 3 is zero. These sprites are compatible with the original sprite module from core versions prior to 2.00.26.

If the E bit is set then a fifth sprite attribute, sprite attribute 4, becomes active. This attribute introduces scaling, 4-bit patterns, and relative sprites. Scaling is self-explanatory and 4-bit patterns were described in the last section. Relative sprites are described in the next section.

=== Relative Sprites ===
Normal sprites (sprites that are not relative) are known as anchor sprites. As the sprite module draws sprites in the order 0-127 (there are 128 sprites), it internally stores characteristics of the last anchor sprite seen. If following sprites are relative, they inherit some of these characteristics, which allows relative sprites to have, among other things, coordinates relative to the anchor. This means moving the anchor sprite also causes its relatives to move with it.

There are two types of relative sprites supported known as “Composite Sprites” and “Unified Sprites”. The type is determined by the anchor in the T bit of sprite attribute 4.

==== A. Composite Sprites ====
The sprite module records the following information from the anchor:

Anchor.visible
Anchor.X
Anchor.Y
Anchor.palette_offset
Anchor.N (pattern number)
Anchor.H (indicates if the sprite uses 4-bit patterns)
These recorded items are not used by composite sprites:

Anchor.rotate
Anchor.xmirror
Anchor.ymirror
Anchor.xscale
Anchor.yscale
The anchor determines if all its relative sprites use 4-bit patterns or not.

The visibility of a particular relative sprite is the result of ANDing the anchor’s visibility with the relative sprite’s visibility. In other words, if the anchor is invisible then so are all its relatives.

Relative sprites only have 8-bit X and Y coordinates (the ninth bits are taken for other purposes). These are signed offsets from the anchor’s X,Y coordinate. Moving the anchor moves all its relatives along with it.

If the relative sprite has its PR bit set in sprite attribute 2, then the anchor’s palette offset is added to the relative sprite’s to determine the active palette offset for the relative sprite. Otherwise the relative sprite uses its own palette offset as usual.

If the relative sprite has its PO bit set in sprite attribute 4, then the anchor’s pattern number is added to the relative sprite’s to determine the pattern used for display. Otherwise the relative sprite uses its own pattern number as usual. The intention is to supply a method to easily animate a large sprite by manipulating the pattern number in the anchor.

A composite sprite is like a collection of independent sprites tied to an anchor.

==== B. Unified Sprites ====
Unified sprites are a further extension of the composite type. The same information is recorded from the anchor and the same behaviour as described under composite sprites applies.

The difference is the collection of anchor and relatives is treated as if it were a single 16×16 sprite. The anchor’s rotation, mirror, and scaling bits apply to all its relatives. Rotating the anchor causes all the relatives to rotate around the anchor. Mirroring the anchor causes the relatives to mirror around the anchor. The sprite hardware will automatically adjust X,Y coords and rotation, scaling and mirror bits of all relatives according to settings in the anchor.

Unified sprites should be defined as if all its parts are 16×16 in size with the anchor controlling the look of the whole.

A unified sprite is like a big version of an individual 16×16 sprite controlled by the anchor.

=== Programming Sprites ===
Sprites are created via three io registers and a nextreg interface.

Port 0x303B (W)

<pre>X S S S S S S S
N6 X N N N N N N</pre>

A write to this port has two effects.

One is it selects one of 128 sprites for writing sprite attributes via port 0x57.

The other is it selects one of 128 4-bit patterns in pattern memory for writing sprite patterns via port 0x5B. The N6 bit shown is the least significant in the 7-bit pattern number and should always be zero when selecting one of 64 8-bit patterns indicated by N.

Port 0x57 (W)

Once a sprite is selected via port 0x303B, its attributes can be written to this port one byte after another. Sprites can have either four or five attribute bytes and the internal attribute pointer will move onto the next sprite after those four or five attribute bytes are written. This means you can select a sprite via port 0x303B and write attributes for as many sequential sprites as desired. The attribute pointer will roll over from sprite 127 to sprite 0.

Port 0x5B (W)

Once a pattern number is selected via port 0x303B, the 256-byte or 128-byte pattern can be written to this port. The internal pattern pointer auto-increments after each write so as many sequential patterns as desired can be written. The internal pattern pointer will roll over from pattern 127 to pattern 0 (4-bit patterns) or from pattern 63 to pattern 0 (8-bit patterns) automatically.

Port 0x303B (R)

<pre>0 0 0 0 0 0 M C</pre>

M = 1 if the maximum number of sprites per line was exceeded
C = 1 if any two displayed sprites collide on screen

Reading this port automatically resets the M and C bits.

Besides the i/o interface, there is a nextreg interface to sprite attributes. The nextreg interface allows the copper to manipulate sprites and grants the program random access to a sprite’s individual attribute bytes.

(R/W) 0x34 (52) => Sprite Number
If the sprite number is in lockstep with io port 0x303B (nextreg 0x09 bit 4 is set)
bits 7 = Pattern address offset (Add 128 to pattern address)
bits 6-0 = Sprite number 0-127, Pattern number 0-63
Selects which sprite has its attributes connected to the following registers.
Effectively performs an out to port 0x303B with the same value
Otherwise
bit 7 = Ignored
bits 6-0 = Sprite number 0-127
Selects which sprite has its attributes connected to the following registers.
Bit 7 always reads back as zero.

This nextreg can operate in two modes.

If nextreg 0x09 bit 4 is set, then this register is kept in lockstep with i/o port 0x303B. A write to this nextreg is equivalent to a write to port 0x303B and vice versa. In this mode, the i/o interface and nextreg interface are exactly equivalent.

If nextreg 0x09 bit 4 is reset, then the nextreg interface is decoupled from i/o port 0x303B. This nextreg is used to select a particular sprite 0-127 and this is completely independent from the sprite selected for the i/o interface. This independence allows the copper, for example, to manipulate different sprites than the cpu using the i/o interface.

(W) 0x35 (53) => Sprite Attribute 0
(W) 0x75 (117) => Sprite Attribute 0 with automatic post increment of Sprite Number
bits 7-0 = LSB of X coordinate

A write to nextreg 0x75 also increases the selected sprite in nextreg 0x34.

(W) 0x36 (54) => Sprite Attribute 1
(W) 0x76 (118) => Sprite Attribute 1 with automatic post increment of Sprite Number
bits 7-0 = LSB of Y coordinate

A write to nextreg 0x76 also increases the selected sprite in nextreg 0x34.

(W) 0x37 (55) => Sprite Attribute 2
(W) 0x77 (119) => Sprite Attribute 2 with automatic post increment of Sprite Number
bits 7-4 = Palette offset added to top 4 bits of sprite colour index
bit 3 = X mirror
bit 2 = Y mirror
bit 1 = Rotate
bit 0 = MSB of X coordinate

A write to nextreg 0x77 also increases the selected sprite in nextreg 0x34.

(W) 0x38 (56) => Sprite Attribute 3
(W) 0x78 (120) => Sprite Attribute 3 with automatic post increment of Sprite Number
bit 7 = Visible flag (1 = displayed)
bit 6 = Extended attribute (1 = Sprite Attribute 4 is active)
bits 5-0 = Pattern used by sprite (0-63)

A write to nextreg 0x78 also increases the selected sprite in nextreg 0x34.

(W) 0x39 (57) => Sprite Attribute 4
(W) 0x79 (121) => Sprite Attribute 4 with automatic post increment of Sprite Number
4-bit Sprites
bit 7 = H (1 = sprite uses 4-bit patterns)
bit 6 = N6 (0 = use the first 128 bytes of the pattern else use the last 128 bytes)
bit 5 = 1 if relative sprites are composite, 0 if relative sprites are unified
Scaling
bits 4-3 = X scaling (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
bits 2-1 = Y scaling (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
bit 0 = MSB of Y coordinate
A relative mode is enabled if H,N6 = 01. The byte format for relative sprites is described above.

A write to nextreg 0x79 also increases the selected sprite in nextreg 0x34.

=== Global Control of Sprites ===
The following nextreg are also of interest for sprites.

(R/W) 0x09 (09) => Peripheral 4 setting:
bit 7 = Mono setting for AY 2 (1 = mono, 0 default)
bit 6 = Mono setting for AY 1 (1 = mono, 0 default)
bit 5 = Mono setting for AY 0 (1 = mono, 0 default)
bit 4 = Sprite id lockstep (1 = Nextreg 0x34 and IO Port 0x303B are in lockstep, 0 default)
bit 3 = Disables Kempston port ($DF) if set
bit 2 = Disables divMMC ports ($E3, $E7, $EB) if set
bits 1-0 = scanlines (0 after a PoR or Hard-reset)
00 = scanlines off
01 = scanlines 75%
10 = scanlines 50%
11 = scanlines 25%

Bit 4 determines if the i/o interface and nextreg interface operate in lockstep.

(R/W) 0x15 (21) => Sprite and Layers system
bit 7 = LoRes mode, 128 x 96 x 256 colours (1 = enabled)
bit 6 = Sprite priority (1 = sprite 0 on top, 0 = sprite 127 on top)
bit 5 = Enable sprite clipping in over border mode (1 = enabled)
bits 4-2 = set layers priorities:
Reset default is 000, sprites over the Layer 2, over the ULA graphics
000 – S L U
001 – L S U
010 – S U L
011 – L U S
100 – U S L
101 – U L S
110 – S(U+L) ULA and Layer 2 combined, colours clamped to 7
111 – S(U+L-5) ULA and Layer 2 combined, colours clamped to [0,7]
bit 1 = Over border (1 = yes)(Back to 0 after a reset)
bit 0 = Sprites visible (1 = visible)(Back to 0 after a reset)

Bit 0 must be set for sprites to be visible.

Bit 1 set allows sprites to be visible in the border area. When this bit is reset, sprites will not display outside the 256×192 area of the ULA display.

Bit 5 set enables clipping when sprites are visible in the border area. If reset, no clipping is applied and sprites will be visible in the full 320×256 space.

The sprite module draws sprites in the order 0-127 in each scanline. Bit 6 determines whether sprite 0 is topmost or sprite 127 is topmost.

Bits 4:2 determine layer priority and how sprites overlay or are obscured by other layers.

(R/W) 0x19 (25) => Clip Window Sprites
bits 7-0 = Cood. of the clip window
1st write – X1 position
2nd write – X2 position
3rd write – Y1 position
4rd write – Y2 position
The values are 0,255,0,191 after a Reset
Reads do not advance the clip position
When the clip window is enabled for sprites in “over border” mode,
the X coords are internally doubled and the clip window origin is
moved to the sprite origin inside the border.

Sprites will only be visible inside the clipping window. When not in over-border mode (bit 1 of nextreg 0x15) the clipping window is given in ULA screen coordinates with 0,0 correspoding to the top left corner of the ULA screen. In over-border mode, the clipping window’s origin is moved to the sprite coordinate origin 32 pixels to the left and 32 pixels above the ULA screen origin.

Regardless, sprite position is always in sprite coordinates with 32,32 corresponding to the top left corner of the ULA screen.

(W) 0x1C (28) => Clip Window control
bits 7-4 = Reserved, must be 0
bit 3 – reset the tilemap clip index
bit 2 – reset the ULA/LoRes clip index.
bit 1 – reset the sprite clip index.
bit 0 – reset the Layer 2 clip index.

Can be used to reset nextreg 0x19.

(R/W) 0x43 (67) => Palette Control
bit 7 = ‘1’ to disable palette write auto-increment.
bits 6-4 = Select palette for reading or writing:
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
bit 3 = Select Sprites palette (0 = first palette, 1 = second palette)
bit 2 = Select Layer 2 palette (0 = first palette, 1 = second palette)
bit 1 = Select ULA palette (0 = first palette, 1 = second palette)
bit 0 = Enabe ULANext mode if 1. (0 after a reset)

Sprites have two associated palettes which can be selected in this nextreg.

(R/W) 0x40 (64) => Palette Index
bits 7-0 = Select the palette index to change the associated colour.
For the ULA only, INKs are mapped to indices 0-7, Bright INKS to indices 8-15,
PAPERs to indices 16-23 and Bright PAPERs to indices 24-31.
In ULANext mode, INKs come from a subset of indices 0-127 and PAPERs come from
a subset of indices 128-255. The number of active indices depends on the number
of attribute bits assigned to INK and PAPER out of the attribute byte.
The ULA always takes border colour from paper.

Select the starting palette index if writing the sprite palette.

Palette values can be written in either 8-bit or 9-bit form:

(R/W) 0x41 (65) => Palette Value (8 bit colour)
bits 7-0 = Colour for the palette index selected by the register 0x40.
(Format is RRRGGGBB – the lower blue bit of the 9-bit colour will
be a logical OR of blue bits 1 and 0 of this 8-bit value.)
After the write, the palette index is auto-incremented to the next index
if the auto-increment is enabled at reg 0x43. Reads do not auto-increment.

(R/W) 0x44 (68) => Palette Value (9 bit colour)
Two consecutive writes are needed to write the 9 bit colour
1st write:
bits 7-0 = RRRGGGBB
2nd write.
If writing a L2 palette
———————————————————————–
bit 7 = 1 for L2 priority colour, 0 for normal
Priority colour will always be on top even on an SLU priori-
ty arrangement. If you need the exact same colour on priori-
ty and non priority locations you will need to program the
same colour twice changing bit 7 to 0 for the second colour
bits 6-1 = Reserved, must be 0
bit 0 = lsb B

If writing another palette
———————————————————————–
bits 7-1 = Reserved, must be 0
bit 0 = lsb B

After the two consecutives writes the palette index is
auto-incremented if the auto-increment is enabled by reg 0x43.

Reads only return the 2nd byte and do not auto-increment.

(R/W) 0x4B (75) => Transparency index for sprites
bits 7-0 = Set the index value (0xE3 after reset)
For 4-bit sprites only the bottom 4-bits are relevant.

Determines the transparent colour index used for sprites.

Sprites

2019-05-05T10:14:03Z

Intrepidis: Fix image caption.

The Spectrum Next has a hardware sprite system with the following characteristics:

* Total of 128 sprites
* Display surface is 320×256 overlapping the ULA screen by 32 pixels on each side
* Minimum of 100 sprites per scanline*
* Choice of 512 colours for each pixel
* Site of each sprite is 16×16 pixels but sprites can be magnified 2x, 4x or 8x horizontally and vertically
* Sprites can be mirrored and rotated
* Sprites can be grouped together to form larger sprites under the control of a single anchor
* A 16K pattern memory can contain 64 8-bit sprite images or 128 4-bit sprite images and combinations in-between
* A per sprite palette offset allows sprites to share images but colour them differently
* A nextreg interface allows the copper to move sprites during the video frame

<nowiki>*</nowiki>A minimum of 100 16×16 sprites is guaranteed to be displayed in any scanline. Any additional sprites will not be displayed with the hardware ensuring sprites are not partially plotted.

The actual limit is determined by how many 28MHz clock cycles there are in a scanline. The sprite hardware is able to plot one pixel cycle and uses one cycle to qualify each sprite. Since the number of cycles there are in a scanline varies with video timing (HDMI, VGA), the number of pixels that can be plotted also varies but the minimum will be 1600 pixels per line including overhead cycles needed to qualify 100 sprites. Since sprites magified horizontally involve plotting more pixels, x2 x4 x8 sprites will take more cycles to plot and the presence of these sprites in a line will reduce the total number of sprites that can be plotted.

== Sprite Patterns ==
Sprite patterns are the images that each sprite can take on. The images are stored in a 16K memory internal to the FPGA and are identified by pattern number. A particular sprite chooses a pattern by storing a pattern number in its attributes.

All sprites are 16×16 pixels in size but the come in two flavours: 4-bit and 8-bit. The bit width describes how many bits are used to code the colour of each pixel.

An 8-bit sprite uses a full byte to colour each of its pixels so that each pixel can be one of 256 colours. In this case, a 16×16 sprite requires 256 bytes of pattern memory to store its image.

A 4-bit sprite uses a nibble to colour each of its pixels so that each pixel can be one of 16 colours. In this case, a 16×16 sprite requires just 128 bytes of pattern memory to store its image.

The 16K pattern memory can contain any combination of these images, whether they are 128 bytes or 256 bytes and their locations in the pattern memory are described by a pattern number. This pattern number is 7 bits with bits named as follows:

=== Pattern Number ===
<pre>N5 N4 N3 N2 N1 N0 N6
N6, despite the name, is the least significant bit.</pre>

This 7-bit pattern number can identify 128 patterns in the 16k pattern memory, each of which are 128 bytes in size. The full 7-bits are therefore used for 4-bit sprites.

For 8-bit sprites, N6=0 always. The remaining 6 bits can identify 64 patterns, each of which is 256 bytes in size.

The N5:N0,N6 bits are stored in a particular sprite’s attributes to identify which image a sprite uses.

=== 8-Bit Sprite Patterns ===
The 16×16 pixel image uses 8-bits for each pixel so that each pixel can be one of 256 colours. One colour indicates transparency and this is programmed into the Sprite Transparency Index register (nextreg 0x4B). By default the transparent value is 0xE3.

As an example of an 8-bit sprite, let’s have a look at the sprite below:

[[File:Sprite_1.png|frame|center|Pattern example]]

Using the default palette, which is initialised with RGB332 colours from 0-255, the hexadecimal values for this pattern arranged in a 16×16 array are shown below:

<pre>04040404040404E3E3E3E3E3E3E3E3E3
04FFFFFFFFFF04E3E3E3E3E3E3E3E3E3
04FFFBFBFBFF04E3E3E3E3E3E3E3E3E3
04FFFBF5F5FBFF04E3E3E3E3E3E3E3E3
04FFFBF5A8A8FBFF04E3E3E3E3E3E3E3
04FFFFFBA844A8FBFF04E3E3E3E3E3E3
040404FFFBA844A8FBFF04E3E3E3E3E3
E3E3E304FFFBA84444FBFF04E304E3E3
E3E3E3E304FFFB444444FBFF044D04E3
E3E3E3E3E304FFFB44444444FA4D04E3
E3E3E3E3E3E304FFFB44FFF54404E3E3
E3E3E3E3E3E3E304FF44F5A804E3E3E3
E3E3E3E3E3E3E3E304FA4404A804E3E3
E3E3E3E3E3E3E3044D4D04E304F504E3
E3E3E3E3E3E3E3E30404E3E3E304FA04
E3E3E3E3E3E3E3E3E3E3E3E3E3E30404</pre>

Here 0xE3 is used as the transparent index.

These 256 bytes would be stored in pattern memory in left to right, top to bottom order.

=== 4-Bit Sprite Patterns ===
The 16×16 pixel image uses 4-bits for each pixel so that each pixel can be one of 16 colours. One colour indicates transparency and this is programmed into the lower 4-bits of the Sprite Transparency Index register (nextreg 0x4B). By default the transparency value is 0x3. Note that the same register is shared with 8-bit patterns to identify the transparent index.

Since each pixel only occupies 4-bits, two pixels are stored in each byte. The leftmost pixel is stored in the upper 4-bits and the rightmost pixel is stored in the lower 4-bits.

As an example we will use the same sprite image as was given in the 8-bit pattern example. Here only the lower 4 bits of each pixel is retained to confine each pixel’s color to 4-bits:

4444444333333333
4FFFFF4333333333
4FBBBF4333333333
4FB55BF433333333
4FB588BF43333333
4FFB848BF4333333
444FB848BF433333
3334FB844BF43433
33334FB444BF4D43
333334FB4444AD43
3333334FB4F54433
33333334F4584333
333333334A448433
33333334DD434543
33333333443334A4
3333333333333344
0x3 is used as the transparent index.

These 128 bytes would be stored in pattern memory in left to right, top to bottom order.

The actual colour that will appear on screen will depend on the palette, described below. The default palette will not likely generate suitable colours for 4-bit sprites.

=== Sprite Palette ===
Each pixel of a sprite image is 8-bit for 8-bit patterns or 4-bit for 4-bit patterns. The pixel value is known as a pixel colour index. This colour index is combined with the sprite’s palette offset. The palette offset is a 4-bit value added to the top 4-bits of the pixel colour index. The purpose of the palette offset is to allow a sprite to change the colour of an image.

The final sprite colour index generated by the sprite hardware is then the sum of the pixel index and the 4-bit palette offset. In pictures using binary math:

8-bit Sprite
PPPP0000
+ IIIIIIII
----------
SSSSSSSS

4-bit Sprite
PPPP0000
+ 0000IIII
----------
SSSSSSSS = PPPPIIII
Where “PPPP” is the 4-bit palette offset from the sprite’s attributes and the “I”s represent the pixel value from the sprite pattern. The final sprite index is represented by the 8-bit value “SSSSSSSS”.

For 4-bit sprites the palette offset can be thought of as selecting one of 16 different 16-colour palettes.

This final 8-bit sprite index is then passed through the sprite palette which acts like a lookup table that returns the 9-bit RGB333 colour associated with the sprite index.

At power up, the sprite palette is initialized such that the sprite index passes through unchanged and is therefore interpretted as an RGB332 colour. The missing third blue bit is generated as the logical OR of the two other blue bits. In short, for 8-bit sprites, the sprite index also acts like the colour when using the default palette.

=== Sprite Attributes ===
A sprite’s attributes is a list of properties that determine how and where the sprite is drawn.

Each sprite is described by either 4 or 5 attribute bytes listed below:

==== Sprite Attribute 0 ====
X X X X X X X X
The least significant eight bits of the sprite’s X coordinate. The ninth bit is found in sprite attribute 2.

==== Sprite Attribute 1 ====
Y Y Y Y Y Y Y Y
The least significant eight bits of the sprite’s Y coordinate. The ninth bit is optional and is found in attribute 4.

==== Sprite Attribute 2 ====
P P P P XM YM R X8/PR
P = 4-bit Palette Offset
XM = 1 to mirror the sprite image horizontally
YM = 1 to mirror the sprite image vertically
R = 1 to rotate the sprite image 90 degrees clockwise
X8 = Ninth bit of the sprite’s X coordinate
PR = 1 to indicate P is relative to the anchor’s palette offset (relative sprites only)

Rotation is applied before mirroring.
Relative sprites, described below, replace X8 with PR.

All possibilities of Rotate, Mirror X and Mirror Y flags.

==== Sprite Attribute 3 ====
V E N5 N4 N3 N2 N1 N0
V = 1 to make the sprite visible
E = 1 to enable attribute byte 4
N = Sprite pattern to use 0-63

If E=0, the sprite is fully described by sprite attributes 0-3. The sprite pattern is an 8-bit one identified by pattern N=0-63. The sprite is an anchor and cannot be made relative. The sprite is displayed as if sprite attribute 4 is zero.

If E=1, the sprite is further described by sprite attribute 4.

==== Sprite Attribute 4 ====
===== A. Extended Anchor Sprite =====
H N6 T X X Y Y Y8
H = 1 if the sprite pattern is 4-bit
N6 = 7th pattern bit if the sprite pattern is 4-bit
T = 0 if relative sprites are composite type else 1 for unified type
XX = Magnification in the X direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
YY = Magnification in the Y direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
Y8 = Ninth bit of the sprite’s Y coordinate

{H,N6} must not equal {0,1} as this combination is used to indicate a relative sprite.

===== B. Relative Sprite, Composite Type =====
0 1 N6 X X Y Y PO
N6 = 7th pattern bit if the sprite pattern is 4-bit
XX = Magnification in the X direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
YY = Magnification in the Y direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
PO = 1 to indicate the sprite pattern number is relative to the anchor’s

===== C. Relative Sprite, Unified Type =====
0 1 N6 0 0 0 0 PO
N6 = 7th pattern bit if the sprite pattern is 4-bit
PO = 1 to indicate the sprite pattern number is relative to the anchor’s

The display surface for sprites is 320×256. The X coordinate of the sprite is nine bits, ranging over 0-511, and the Y coordinate is optionally nine bits again ranging over 0-511 or is eight bits ranging over 0-255. The full extent 0-511 wraps on both axes, meaning a sprite 16 pixels wide plotted at X coordinate 511 would see its first pixel not displayed (coordinate 511) and the following pixels displayed in coordinates 0-14.

The full display area is visible in VGA. However, the HDMI display is vertically shorter so the top eight pixel rows (Y = 0-7) and the bottom eight pixel rows (Y = 248-255) will not be visible on an HDMI display.

Sprites can be fully described by sprite attributes 0-3 if the E bit in sprite attribute 3 is zero. These sprites are compatible with the original sprite module from core versions prior to 2.00.26.

If the E bit is set then a fifth sprite attribute, sprite attribute 4, becomes active. This attribute introduces scaling, 4-bit patterns, and relative sprites. Scaling is self-explanatory and 4-bit patterns were described in the last section. Relative sprites are described in the next section.

=== Relative Sprites ===
Normal sprites (sprites that are not relative) are known as anchor sprites. As the sprite module draws sprites in the order 0-127 (there are 128 sprites), it internally stores characteristics of the last anchor sprite seen. If following sprites are relative, they inherit some of these characteristics, which allows relative sprites to have, among other things, coordinates relative to the anchor. This means moving the anchor sprite also causes its relatives to move with it.

There are two types of relative sprites supported known as “Composite Sprites” and “Unified Sprites”. The type is determined by the anchor in the T bit of sprite attribute 4.

==== A. Composite Sprites ====
The sprite module records the following information from the anchor:

Anchor.visible
Anchor.X
Anchor.Y
Anchor.palette_offset
Anchor.N (pattern number)
Anchor.H (indicates if the sprite uses 4-bit patterns)
These recorded items are not used by composite sprites:

Anchor.rotate
Anchor.xmirror
Anchor.ymirror
Anchor.xscale
Anchor.yscale
The anchor determines if all its relative sprites use 4-bit patterns or not.

The visibility of a particular relative sprite is the result of ANDing the anchor’s visibility with the relative sprite’s visibility. In other words, if the anchor is invisible then so are all its relatives.

Relative sprites only have 8-bit X and Y coordinates (the ninth bits are taken for other purposes). These are signed offsets from the anchor’s X,Y coordinate. Moving the anchor moves all its relatives along with it.

If the relative sprite has its PR bit set in sprite attribute 2, then the anchor’s palette offset is added to the relative sprite’s to determine the active palette offset for the relative sprite. Otherwise the relative sprite uses its own palette offset as usual.

If the relative sprite has its PO bit set in sprite attribute 4, then the anchor’s pattern number is added to the relative sprite’s to determine the pattern used for display. Otherwise the relative sprite uses its own pattern number as usual. The intention is to supply a method to easily animate a large sprite by manipulating the pattern number in the anchor.

A composite sprite is like a collection of independent sprites tied to an anchor.

==== B. Unified Sprites ====
Unified sprites are a further extension of the composite type. The same information is recorded from the anchor and the same behaviour as described under composite sprites applies.

The difference is the collection of anchor and relatives is treated as if it were a single 16×16 sprite. The anchor’s rotation, mirror, and scaling bits apply to all its relatives. Rotating the anchor causes all the relatives to rotate around the anchor. Mirroring the anchor causes the relatives to mirror around the anchor. The sprite hardware will automatically adjust X,Y coords and rotation, scaling and mirror bits of all relatives according to settings in the anchor.

Unified sprites should be defined as if all its parts are 16×16 in size with the anchor controlling the look of the whole.

A unified sprite is like a big version of an individual 16×16 sprite controlled by the anchor.

=== Programming Sprites ===
Sprites are created via three io registers and a nextreg interface.

Port 0x303B (W)

X S S S S S S S
N6 X N N N N N N
A write to this port has two effects.

One is it selects one of 128 sprites for writing sprite attributes via port 0x57.

The other is it selects one of 128 4-bit patterns in pattern memory for writing sprite patterns via port 0x5B. The N6 bit shown is the least significant in the 7-bit pattern number and should always be zero when selecting one of 64 8-bit patterns indicated by N.

Port 0x57 (W)

Once a sprite is selected via port 0x303B, its attributes can be written to this port one byte after another. Sprites can have either four or five attribute bytes and the internal attribute pointer will move onto the next sprite after those four or five attribute bytes are written. This means you can select a sprite via port 0x303B and write attributes for as many sequential sprites as desired. The attribute pointer will roll over from sprite 127 to sprite 0.

Port 0x5B (W)

Once a pattern number is selected via port 0x303B, the 256-byte or 128-byte pattern can be written to this port. The internal pattern pointer auto-increments after each write so as many sequential patterns as desired can be written. The internal pattern pointer will roll over from pattern 127 to pattern 0 (4-bit patterns) or from pattern 63 to pattern 0 (8-bit patterns) automatically.

Port 0x303B (R)

0 0 0 0 0 0 M C
M = 1 if the maximum number of sprites per line was exceeded
C = 1 if any two displayed sprites collide on screen

Reading this port automatically resets the M and C bits.

Besides the i/o interface, there is a nextreg interface to sprite attributes. The nextreg interface allows the copper to manipulate sprites and grants the program random access to a sprite’s individual attribute bytes.

(R/W) 0x34 (52) => Sprite Number
If the sprite number is in lockstep with io port 0x303B (nextreg 0x09 bit 4 is set)
bits 7 = Pattern address offset (Add 128 to pattern address)
bits 6-0 = Sprite number 0-127, Pattern number 0-63
Selects which sprite has its attributes connected to the following registers.
Effectively performs an out to port 0x303B with the same value
Otherwise
bit 7 = Ignored
bits 6-0 = Sprite number 0-127
Selects which sprite has its attributes connected to the following registers.
Bit 7 always reads back as zero.

This nextreg can operate in two modes.

If nextreg 0x09 bit 4 is set, then this register is kept in lockstep with i/o port 0x303B. A write to this nextreg is equivalent to a write to port 0x303B and vice versa. In this mode, the i/o interface and nextreg interface are exactly equivalent.

If nextreg 0x09 bit 4 is reset, then the nextreg interface is decoupled from i/o port 0x303B. This nextreg is used to select a particular sprite 0-127 and this is completely independent from the sprite selected for the i/o interface. This independence allows the copper, for example, to manipulate different sprites than the cpu using the i/o interface.

(W) 0x35 (53) => Sprite Attribute 0
(W) 0x75 (117) => Sprite Attribute 0 with automatic post increment of Sprite Number
bits 7-0 = LSB of X coordinate

A write to nextreg 0x75 also increases the selected sprite in nextreg 0x34.

(W) 0x36 (54) => Sprite Attribute 1
(W) 0x76 (118) => Sprite Attribute 1 with automatic post increment of Sprite Number
bits 7-0 = LSB of Y coordinate

A write to nextreg 0x76 also increases the selected sprite in nextreg 0x34.

(W) 0x37 (55) => Sprite Attribute 2
(W) 0x77 (119) => Sprite Attribute 2 with automatic post increment of Sprite Number
bits 7-4 = Palette offset added to top 4 bits of sprite colour index
bit 3 = X mirror
bit 2 = Y mirror
bit 1 = Rotate
bit 0 = MSB of X coordinate

A write to nextreg 0x77 also increases the selected sprite in nextreg 0x34.

(W) 0x38 (56) => Sprite Attribute 3
(W) 0x78 (120) => Sprite Attribute 3 with automatic post increment of Sprite Number
bit 7 = Visible flag (1 = displayed)
bit 6 = Extended attribute (1 = Sprite Attribute 4 is active)
bits 5-0 = Pattern used by sprite (0-63)

A write to nextreg 0x78 also increases the selected sprite in nextreg 0x34.

(W) 0x39 (57) => Sprite Attribute 4
(W) 0x79 (121) => Sprite Attribute 4 with automatic post increment of Sprite Number
4-bit Sprites
bit 7 = H (1 = sprite uses 4-bit patterns)
bit 6 = N6 (0 = use the first 128 bytes of the pattern else use the last 128 bytes)
bit 5 = 1 if relative sprites are composite, 0 if relative sprites are unified
Scaling
bits 4-3 = X scaling (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
bits 2-1 = Y scaling (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
bit 0 = MSB of Y coordinate
A relative mode is enabled if H,N6 = 01. The byte format for relative sprites is described above.

A write to nextreg 0x79 also increases the selected sprite in nextreg 0x34.

=== Global Control of Sprites ===
The following nextreg are also of interest for sprites.

(R/W) 0x09 (09) => Peripheral 4 setting:
bit 7 = Mono setting for AY 2 (1 = mono, 0 default)
bit 6 = Mono setting for AY 1 (1 = mono, 0 default)
bit 5 = Mono setting for AY 0 (1 = mono, 0 default)
bit 4 = Sprite id lockstep (1 = Nextreg 0x34 and IO Port 0x303B are in lockstep, 0 default)
bit 3 = Disables Kempston port ($DF) if set
bit 2 = Disables divMMC ports ($E3, $E7, $EB) if set
bits 1-0 = scanlines (0 after a PoR or Hard-reset)
00 = scanlines off
01 = scanlines 75%
10 = scanlines 50%
11 = scanlines 25%

Bit 4 determines if the i/o interface and nextreg interface operate in lockstep.

(R/W) 0x15 (21) => Sprite and Layers system
bit 7 = LoRes mode, 128 x 96 x 256 colours (1 = enabled)
bit 6 = Sprite priority (1 = sprite 0 on top, 0 = sprite 127 on top)
bit 5 = Enable sprite clipping in over border mode (1 = enabled)
bits 4-2 = set layers priorities:
Reset default is 000, sprites over the Layer 2, over the ULA graphics
000 – S L U
001 – L S U
010 – S U L
011 – L U S
100 – U S L
101 – U L S
110 – S(U+L) ULA and Layer 2 combined, colours clamped to 7
111 – S(U+L-5) ULA and Layer 2 combined, colours clamped to [0,7]
bit 1 = Over border (1 = yes)(Back to 0 after a reset)
bit 0 = Sprites visible (1 = visible)(Back to 0 after a reset)

Bit 0 must be set for sprites to be visible.

Bit 1 set allows sprites to be visible in the border area. When this bit is reset, sprites will not display outside the 256×192 area of the ULA display.

Bit 5 set enables clipping when sprites are visible in the border area. If reset, no clipping is applied and sprites will be visible in the full 320×256 space.

The sprite module draws sprites in the order 0-127 in each scanline. Bit 6 determines whether sprite 0 is topmost or sprite 127 is topmost.

Bits 4:2 determine layer priority and how sprites overlay or are obscured by other layers.

(R/W) 0x19 (25) => Clip Window Sprites
bits 7-0 = Cood. of the clip window
1st write – X1 position
2nd write – X2 position
3rd write – Y1 position
4rd write – Y2 position
The values are 0,255,0,191 after a Reset
Reads do not advance the clip position
When the clip window is enabled for sprites in “over border” mode,
the X coords are internally doubled and the clip window origin is
moved to the sprite origin inside the border.

Sprites will only be visible inside the clipping window. When not in over-border mode (bit 1 of nextreg 0x15) the clipping window is given in ULA screen coordinates with 0,0 correspoding to the top left corner of the ULA screen. In over-border mode, the clipping window’s origin is moved to the sprite coordinate origin 32 pixels to the left and 32 pixels above the ULA screen origin.

Regardless, sprite position is always in sprite coordinates with 32,32 corresponding to the top left corner of the ULA screen.

(W) 0x1C (28) => Clip Window control
bits 7-4 = Reserved, must be 0
bit 3 – reset the tilemap clip index
bit 2 – reset the ULA/LoRes clip index.
bit 1 – reset the sprite clip index.
bit 0 – reset the Layer 2 clip index.

Can be used to reset nextreg 0x19.

(R/W) 0x43 (67) => Palette Control
bit 7 = ‘1’ to disable palette write auto-increment.
bits 6-4 = Select palette for reading or writing:
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
bit 3 = Select Sprites palette (0 = first palette, 1 = second palette)
bit 2 = Select Layer 2 palette (0 = first palette, 1 = second palette)
bit 1 = Select ULA palette (0 = first palette, 1 = second palette)
bit 0 = Enabe ULANext mode if 1. (0 after a reset)

Sprites have two associated palettes which can be selected in this nextreg.

(R/W) 0x40 (64) => Palette Index
bits 7-0 = Select the palette index to change the associated colour.
For the ULA only, INKs are mapped to indices 0-7, Bright INKS to indices 8-15,
PAPERs to indices 16-23 and Bright PAPERs to indices 24-31.
In ULANext mode, INKs come from a subset of indices 0-127 and PAPERs come from
a subset of indices 128-255. The number of active indices depends on the number
of attribute bits assigned to INK and PAPER out of the attribute byte.
The ULA always takes border colour from paper.

Select the starting palette index if writing the sprite palette.

Palette values can be written in either 8-bit or 9-bit form:

(R/W) 0x41 (65) => Palette Value (8 bit colour)
bits 7-0 = Colour for the palette index selected by the register 0x40.
(Format is RRRGGGBB – the lower blue bit of the 9-bit colour will
be a logical OR of blue bits 1 and 0 of this 8-bit value.)
After the write, the palette index is auto-incremented to the next index
if the auto-increment is enabled at reg 0x43. Reads do not auto-increment.

(R/W) 0x44 (68) => Palette Value (9 bit colour)
Two consecutive writes are needed to write the 9 bit colour
1st write:
bits 7-0 = RRRGGGBB
2nd write.
If writing a L2 palette
———————————————————————–
bit 7 = 1 for L2 priority colour, 0 for normal
Priority colour will always be on top even on an SLU priori-
ty arrangement. If you need the exact same colour on priori-
ty and non priority locations you will need to program the
same colour twice changing bit 7 to 0 for the second colour
bits 6-1 = Reserved, must be 0
bit 0 = lsb B

If writing another palette
———————————————————————–
bits 7-1 = Reserved, must be 0
bit 0 = lsb B

After the two consecutives writes the palette index is
auto-incremented if the auto-increment is enabled by reg 0x43.

Reads only return the 2nd byte and do not auto-increment.

(R/W) 0x4B (75) => Transparency index for sprites
bits 7-0 = Set the index value (0xE3 after reset)
For 4-bit sprites only the bottom 4-bits are relevant.

Determines the transparent colour index used for sprites.

Sprites

2019-05-04T11:52:47Z

Intrepidis: Add formatting to headers.

The Spectrum Next has a hardware sprite system with the following characteristics:

* Total of 128 sprites
* Display surface is 320×256 overlapping the ULA screen by 32 pixels on each side
* Minimum of 100 sprites per scanline*
* Choice of 512 colours for each pixel
* Site of each sprite is 16×16 pixels but sprites can be magnified 2x, 4x or 8x horizontally and vertically
* Sprites can be mirrored and rotated
* Sprites can be grouped together to form larger sprites under the control of a single anchor
* A 16K pattern memory can contain 64 8-bit sprite images or 128 4-bit sprite images and combinations in-between
* A per sprite palette offset allows sprites to share images but colour them differently
* A nextreg interface allows the copper to move sprites during the video frame

<nowiki>*</nowiki>A minimum of 100 16×16 sprites is guaranteed to be displayed in any scanline. Any additional sprites will not be displayed with the hardware ensuring sprites are not partially plotted.

The actual limit is determined by how many 28MHz clock cycles there are in a scanline. The sprite hardware is able to plot one pixel cycle and uses one cycle to qualify each sprite. Since the number of cycles there are in a scanline varies with video timing (HDMI, VGA), the number of pixels that can be plotted also varies but the minimum will be 1600 pixels per line including overhead cycles needed to qualify 100 sprites. Since sprites magified horizontally involve plotting more pixels, x2 x4 x8 sprites will take more cycles to plot and the presence of these sprites in a line will reduce the total number of sprites that can be plotted.

== Sprite Patterns ==
Sprite patterns are the images that each sprite can take on. The images are stored in a 16K memory internal to the FPGA and are identified by pattern number. A particular sprite chooses a pattern by storing a pattern number in its attributes.

All sprites are 16×16 pixels in size but the come in two flavours: 4-bit and 8-bit. The bit width describes how many bits are used to code the colour of each pixel.

An 8-bit sprite uses a full byte to colour each of its pixels so that each pixel can be one of 256 colours. In this case, a 16×16 sprite requires 256 bytes of pattern memory to store its image.

A 4-bit sprite uses a nibble to colour each of its pixels so that each pixel can be one of 16 colours. In this case, a 16×16 sprite requires just 128 bytes of pattern memory to store its image.

The 16K pattern memory can contain any combination of these images, whether they are 128 bytes or 256 bytes and their locations in the pattern memory are described by a pattern number. This pattern number is 7 bits with bits named as follows:

=== Pattern Number ===
<pre>N5 N4 N3 N2 N1 N0 N6
N6, despite the name, is the least significant bit.</pre>

This 7-bit pattern number can identify 128 patterns in the 16k pattern memory, each of which are 128 bytes in size. The full 7-bits are therefore used for 4-bit sprites.

For 8-bit sprites, N6=0 always. The remaining 6 bits can identify 64 patterns, each of which is 256 bytes in size.

The N5:N0,N6 bits are stored in a particular sprite’s attributes to identify which image a sprite uses.

=== 8-Bit Sprite Patterns ===
The 16×16 pixel image uses 8-bits for each pixel so that each pixel can be one of 256 colours. One colour indicates transparency and this is programmed into the Sprite Transparency Index register (nextreg 0x4B). By default the transparent value is 0xE3.

As an example of an 8-bit sprite, let’s have a look at the sprite below:

[[File:Sprite_1.png]]

===== Pattern example =====

Using the default palette, which is initialised with RGB332 colours from 0-255, the hexadecimal values for this pattern arranged in a 16×16 array are shown below:

<pre>04040404040404E3E3E3E3E3E3E3E3E3
04FFFFFFFFFF04E3E3E3E3E3E3E3E3E3
04FFFBFBFBFF04E3E3E3E3E3E3E3E3E3
04FFFBF5F5FBFF04E3E3E3E3E3E3E3E3
04FFFBF5A8A8FBFF04E3E3E3E3E3E3E3
04FFFFFBA844A8FBFF04E3E3E3E3E3E3
040404FFFBA844A8FBFF04E3E3E3E3E3
E3E3E304FFFBA84444FBFF04E304E3E3
E3E3E3E304FFFB444444FBFF044D04E3
E3E3E3E3E304FFFB44444444FA4D04E3
E3E3E3E3E3E304FFFB44FFF54404E3E3
E3E3E3E3E3E3E304FF44F5A804E3E3E3
E3E3E3E3E3E3E3E304FA4404A804E3E3
E3E3E3E3E3E3E3044D4D04E304F504E3
E3E3E3E3E3E3E3E30404E3E3E304FA04
E3E3E3E3E3E3E3E3E3E3E3E3E3E30404</pre>

Here 0xE3 is used as the transparent index.

These 256 bytes would be stored in pattern memory in left to right, top to bottom order.

=== 4-Bit Sprite Patterns ===
The 16×16 pixel image uses 4-bits for each pixel so that each pixel can be one of 16 colours. One colour indicates transparency and this is programmed into the lower 4-bits of the Sprite Transparency Index register (nextreg 0x4B). By default the transparency value is 0x3. Note that the same register is shared with 8-bit patterns to identify the transparent index.

Since each pixel only occupies 4-bits, two pixels are stored in each byte. The leftmost pixel is stored in the upper 4-bits and the rightmost pixel is stored in the lower 4-bits.

As an example we will use the same sprite image as was given in the 8-bit pattern example. Here only the lower 4 bits of each pixel is retained to confine each pixel’s color to 4-bits:

4444444333333333
4FFFFF4333333333
4FBBBF4333333333
4FB55BF433333333
4FB588BF43333333
4FFB848BF4333333
444FB848BF433333
3334FB844BF43433
33334FB444BF4D43
333334FB4444AD43
3333334FB4F54433
33333334F4584333
333333334A448433
33333334DD434543
33333333443334A4
3333333333333344
0x3 is used as the transparent index.

These 128 bytes would be stored in pattern memory in left to right, top to bottom order.

The actual colour that will appear on screen will depend on the palette, described below. The default palette will not likely generate suitable colours for 4-bit sprites.

=== Sprite Palette ===
Each pixel of a sprite image is 8-bit for 8-bit patterns or 4-bit for 4-bit patterns. The pixel value is known as a pixel colour index. This colour index is combined with the sprite’s palette offset. The palette offset is a 4-bit value added to the top 4-bits of the pixel colour index. The purpose of the palette offset is to allow a sprite to change the colour of an image.

The final sprite colour index generated by the sprite hardware is then the sum of the pixel index and the 4-bit palette offset. In pictures using binary math:

8-bit Sprite
PPPP0000
+ IIIIIIII
----------
SSSSSSSS

4-bit Sprite
PPPP0000
+ 0000IIII
----------
SSSSSSSS = PPPPIIII
Where “PPPP” is the 4-bit palette offset from the sprite’s attributes and the “I”s represent the pixel value from the sprite pattern. The final sprite index is represented by the 8-bit value “SSSSSSSS”.

For 4-bit sprites the palette offset can be thought of as selecting one of 16 different 16-colour palettes.

This final 8-bit sprite index is then passed through the sprite palette which acts like a lookup table that returns the 9-bit RGB333 colour associated with the sprite index.

At power up, the sprite palette is initialized such that the sprite index passes through unchanged and is therefore interpretted as an RGB332 colour. The missing third blue bit is generated as the logical OR of the two other blue bits. In short, for 8-bit sprites, the sprite index also acts like the colour when using the default palette.

=== Sprite Attributes ===
A sprite’s attributes is a list of properties that determine how and where the sprite is drawn.

Each sprite is described by either 4 or 5 attribute bytes listed below:

==== Sprite Attribute 0 ====
X X X X X X X X
The least significant eight bits of the sprite’s X coordinate. The ninth bit is found in sprite attribute 2.

==== Sprite Attribute 1 ====
Y Y Y Y Y Y Y Y
The least significant eight bits of the sprite’s Y coordinate. The ninth bit is optional and is found in attribute 4.

==== Sprite Attribute 2 ====
P P P P XM YM R X8/PR
P = 4-bit Palette Offset
XM = 1 to mirror the sprite image horizontally
YM = 1 to mirror the sprite image vertically
R = 1 to rotate the sprite image 90 degrees clockwise
X8 = Ninth bit of the sprite’s X coordinate
PR = 1 to indicate P is relative to the anchor’s palette offset (relative sprites only)

Rotation is applied before mirroring.
Relative sprites, described below, replace X8 with PR.

All possibilities of Rotate, Mirror X and Mirror Y flags.

==== Sprite Attribute 3 ====
V E N5 N4 N3 N2 N1 N0
V = 1 to make the sprite visible
E = 1 to enable attribute byte 4
N = Sprite pattern to use 0-63

If E=0, the sprite is fully described by sprite attributes 0-3. The sprite pattern is an 8-bit one identified by pattern N=0-63. The sprite is an anchor and cannot be made relative. The sprite is displayed as if sprite attribute 4 is zero.

If E=1, the sprite is further described by sprite attribute 4.

==== Sprite Attribute 4 ====
===== A. Extended Anchor Sprite =====
H N6 T X X Y Y Y8
H = 1 if the sprite pattern is 4-bit
N6 = 7th pattern bit if the sprite pattern is 4-bit
T = 0 if relative sprites are composite type else 1 for unified type
XX = Magnification in the X direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
YY = Magnification in the Y direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
Y8 = Ninth bit of the sprite’s Y coordinate

{H,N6} must not equal {0,1} as this combination is used to indicate a relative sprite.

===== B. Relative Sprite, Composite Type =====
0 1 N6 X X Y Y PO
N6 = 7th pattern bit if the sprite pattern is 4-bit
XX = Magnification in the X direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
YY = Magnification in the Y direction (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
PO = 1 to indicate the sprite pattern number is relative to the anchor’s

===== C. Relative Sprite, Unified Type =====
0 1 N6 0 0 0 0 PO
N6 = 7th pattern bit if the sprite pattern is 4-bit
PO = 1 to indicate the sprite pattern number is relative to the anchor’s

The display surface for sprites is 320×256. The X coordinate of the sprite is nine bits, ranging over 0-511, and the Y coordinate is optionally nine bits again ranging over 0-511 or is eight bits ranging over 0-255. The full extent 0-511 wraps on both axes, meaning a sprite 16 pixels wide plotted at X coordinate 511 would see its first pixel not displayed (coordinate 511) and the following pixels displayed in coordinates 0-14.

The full display area is visible in VGA. However, the HDMI display is vertically shorter so the top eight pixel rows (Y = 0-7) and the bottom eight pixel rows (Y = 248-255) will not be visible on an HDMI display.

Sprites can be fully described by sprite attributes 0-3 if the E bit in sprite attribute 3 is zero. These sprites are compatible with the original sprite module from core versions prior to 2.00.26.

If the E bit is set then a fifth sprite attribute, sprite attribute 4, becomes active. This attribute introduces scaling, 4-bit patterns, and relative sprites. Scaling is self-explanatory and 4-bit patterns were described in the last section. Relative sprites are described in the next section.

=== Relative Sprites ===
Normal sprites (sprites that are not relative) are known as anchor sprites. As the sprite module draws sprites in the order 0-127 (there are 128 sprites), it internally stores characteristics of the last anchor sprite seen. If following sprites are relative, they inherit some of these characteristics, which allows relative sprites to have, among other things, coordinates relative to the anchor. This means moving the anchor sprite also causes its relatives to move with it.

There are two types of relative sprites supported known as “Composite Sprites” and “Unified Sprites”. The type is determined by the anchor in the T bit of sprite attribute 4.

==== A. Composite Sprites ====
The sprite module records the following information from the anchor:

Anchor.visible
Anchor.X
Anchor.Y
Anchor.palette_offset
Anchor.N (pattern number)
Anchor.H (indicates if the sprite uses 4-bit patterns)
These recorded items are not used by composite sprites:

Anchor.rotate
Anchor.xmirror
Anchor.ymirror
Anchor.xscale
Anchor.yscale
The anchor determines if all its relative sprites use 4-bit patterns or not.

The visibility of a particular relative sprite is the result of ANDing the anchor’s visibility with the relative sprite’s visibility. In other words, if the anchor is invisible then so are all its relatives.

Relative sprites only have 8-bit X and Y coordinates (the ninth bits are taken for other purposes). These are signed offsets from the anchor’s X,Y coordinate. Moving the anchor moves all its relatives along with it.

If the relative sprite has its PR bit set in sprite attribute 2, then the anchor’s palette offset is added to the relative sprite’s to determine the active palette offset for the relative sprite. Otherwise the relative sprite uses its own palette offset as usual.

If the relative sprite has its PO bit set in sprite attribute 4, then the anchor’s pattern number is added to the relative sprite’s to determine the pattern used for display. Otherwise the relative sprite uses its own pattern number as usual. The intention is to supply a method to easily animate a large sprite by manipulating the pattern number in the anchor.

A composite sprite is like a collection of independent sprites tied to an anchor.

==== B. Unified Sprites ====
Unified sprites are a further extension of the composite type. The same information is recorded from the anchor and the same behaviour as described under composite sprites applies.

The difference is the collection of anchor and relatives is treated as if it were a single 16×16 sprite. The anchor’s rotation, mirror, and scaling bits apply to all its relatives. Rotating the anchor causes all the relatives to rotate around the anchor. Mirroring the anchor causes the relatives to mirror around the anchor. The sprite hardware will automatically adjust X,Y coords and rotation, scaling and mirror bits of all relatives according to settings in the anchor.

Unified sprites should be defined as if all its parts are 16×16 in size with the anchor controlling the look of the whole.

A unified sprite is like a big version of an individual 16×16 sprite controlled by the anchor.

=== Programming Sprites ===
Sprites are created via three io registers and a nextreg interface.

Port 0x303B (W)

X S S S S S S S
N6 X N N N N N N
A write to this port has two effects.

One is it selects one of 128 sprites for writing sprite attributes via port 0x57.

The other is it selects one of 128 4-bit patterns in pattern memory for writing sprite patterns via port 0x5B. The N6 bit shown is the least significant in the 7-bit pattern number and should always be zero when selecting one of 64 8-bit patterns indicated by N.

Port 0x57 (W)

Once a sprite is selected via port 0x303B, its attributes can be written to this port one byte after another. Sprites can have either four or five attribute bytes and the internal attribute pointer will move onto the next sprite after those four or five attribute bytes are written. This means you can select a sprite via port 0x303B and write attributes for as many sequential sprites as desired. The attribute pointer will roll over from sprite 127 to sprite 0.

Port 0x5B (W)

Once a pattern number is selected via port 0x303B, the 256-byte or 128-byte pattern can be written to this port. The internal pattern pointer auto-increments after each write so as many sequential patterns as desired can be written. The internal pattern pointer will roll over from pattern 127 to pattern 0 (4-bit patterns) or from pattern 63 to pattern 0 (8-bit patterns) automatically.

Port 0x303B (R)

0 0 0 0 0 0 M C
M = 1 if the maximum number of sprites per line was exceeded
C = 1 if any two displayed sprites collide on screen

Reading this port automatically resets the M and C bits.

Besides the i/o interface, there is a nextreg interface to sprite attributes. The nextreg interface allows the copper to manipulate sprites and grants the program random access to a sprite’s individual attribute bytes.

(R/W) 0x34 (52) => Sprite Number
If the sprite number is in lockstep with io port 0x303B (nextreg 0x09 bit 4 is set)
bits 7 = Pattern address offset (Add 128 to pattern address)
bits 6-0 = Sprite number 0-127, Pattern number 0-63
Selects which sprite has its attributes connected to the following registers.
Effectively performs an out to port 0x303B with the same value
Otherwise
bit 7 = Ignored
bits 6-0 = Sprite number 0-127
Selects which sprite has its attributes connected to the following registers.
Bit 7 always reads back as zero.

This nextreg can operate in two modes.

If nextreg 0x09 bit 4 is set, then this register is kept in lockstep with i/o port 0x303B. A write to this nextreg is equivalent to a write to port 0x303B and vice versa. In this mode, the i/o interface and nextreg interface are exactly equivalent.

If nextreg 0x09 bit 4 is reset, then the nextreg interface is decoupled from i/o port 0x303B. This nextreg is used to select a particular sprite 0-127 and this is completely independent from the sprite selected for the i/o interface. This independence allows the copper, for example, to manipulate different sprites than the cpu using the i/o interface.

(W) 0x35 (53) => Sprite Attribute 0
(W) 0x75 (117) => Sprite Attribute 0 with automatic post increment of Sprite Number
bits 7-0 = LSB of X coordinate

A write to nextreg 0x75 also increases the selected sprite in nextreg 0x34.

(W) 0x36 (54) => Sprite Attribute 1
(W) 0x76 (118) => Sprite Attribute 1 with automatic post increment of Sprite Number
bits 7-0 = LSB of Y coordinate

A write to nextreg 0x76 also increases the selected sprite in nextreg 0x34.

(W) 0x37 (55) => Sprite Attribute 2
(W) 0x77 (119) => Sprite Attribute 2 with automatic post increment of Sprite Number
bits 7-4 = Palette offset added to top 4 bits of sprite colour index
bit 3 = X mirror
bit 2 = Y mirror
bit 1 = Rotate
bit 0 = MSB of X coordinate

A write to nextreg 0x77 also increases the selected sprite in nextreg 0x34.

(W) 0x38 (56) => Sprite Attribute 3
(W) 0x78 (120) => Sprite Attribute 3 with automatic post increment of Sprite Number
bit 7 = Visible flag (1 = displayed)
bit 6 = Extended attribute (1 = Sprite Attribute 4 is active)
bits 5-0 = Pattern used by sprite (0-63)

A write to nextreg 0x78 also increases the selected sprite in nextreg 0x34.

(W) 0x39 (57) => Sprite Attribute 4
(W) 0x79 (121) => Sprite Attribute 4 with automatic post increment of Sprite Number
4-bit Sprites
bit 7 = H (1 = sprite uses 4-bit patterns)
bit 6 = N6 (0 = use the first 128 bytes of the pattern else use the last 128 bytes)
bit 5 = 1 if relative sprites are composite, 0 if relative sprites are unified
Scaling
bits 4-3 = X scaling (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
bits 2-1 = Y scaling (00 = 1x, 01 = 2x, 10 = 4x, 11 = 8x)
bit 0 = MSB of Y coordinate
A relative mode is enabled if H,N6 = 01. The byte format for relative sprites is described above.

A write to nextreg 0x79 also increases the selected sprite in nextreg 0x34.

=== Global Control of Sprites ===
The following nextreg are also of interest for sprites.

(R/W) 0x09 (09) => Peripheral 4 setting:
bit 7 = Mono setting for AY 2 (1 = mono, 0 default)
bit 6 = Mono setting for AY 1 (1 = mono, 0 default)
bit 5 = Mono setting for AY 0 (1 = mono, 0 default)
bit 4 = Sprite id lockstep (1 = Nextreg 0x34 and IO Port 0x303B are in lockstep, 0 default)
bit 3 = Disables Kempston port ($DF) if set
bit 2 = Disables divMMC ports ($E3, $E7, $EB) if set
bits 1-0 = scanlines (0 after a PoR or Hard-reset)
00 = scanlines off
01 = scanlines 75%
10 = scanlines 50%
11 = scanlines 25%

Bit 4 determines if the i/o interface and nextreg interface operate in lockstep.

(R/W) 0x15 (21) => Sprite and Layers system
bit 7 = LoRes mode, 128 x 96 x 256 colours (1 = enabled)
bit 6 = Sprite priority (1 = sprite 0 on top, 0 = sprite 127 on top)
bit 5 = Enable sprite clipping in over border mode (1 = enabled)
bits 4-2 = set layers priorities:
Reset default is 000, sprites over the Layer 2, over the ULA graphics
000 – S L U
001 – L S U
010 – S U L
011 – L U S
100 – U S L
101 – U L S
110 – S(U+L) ULA and Layer 2 combined, colours clamped to 7
111 – S(U+L-5) ULA and Layer 2 combined, colours clamped to [0,7]
bit 1 = Over border (1 = yes)(Back to 0 after a reset)
bit 0 = Sprites visible (1 = visible)(Back to 0 after a reset)

Bit 0 must be set for sprites to be visible.

Bit 1 set allows sprites to be visible in the border area. When this bit is reset, sprites will not display outside the 256×192 area of the ULA display.

Bit 5 set enables clipping when sprites are visible in the border area. If reset, no clipping is applied and sprites will be visible in the full 320×256 space.

The sprite module draws sprites in the order 0-127 in each scanline. Bit 6 determines whether sprite 0 is topmost or sprite 127 is topmost.

Bits 4:2 determine layer priority and how sprites overlay or are obscured by other layers.

(R/W) 0x19 (25) => Clip Window Sprites
bits 7-0 = Cood. of the clip window
1st write – X1 position
2nd write – X2 position
3rd write – Y1 position
4rd write – Y2 position
The values are 0,255,0,191 after a Reset
Reads do not advance the clip position
When the clip window is enabled for sprites in “over border” mode,
the X coords are internally doubled and the clip window origin is
moved to the sprite origin inside the border.

Sprites will only be visible inside the clipping window. When not in over-border mode (bit 1 of nextreg 0x15) the clipping window is given in ULA screen coordinates with 0,0 correspoding to the top left corner of the ULA screen. In over-border mode, the clipping window’s origin is moved to the sprite coordinate origin 32 pixels to the left and 32 pixels above the ULA screen origin.

Regardless, sprite position is always in sprite coordinates with 32,32 corresponding to the top left corner of the ULA screen.

(W) 0x1C (28) => Clip Window control
bits 7-4 = Reserved, must be 0
bit 3 – reset the tilemap clip index
bit 2 – reset the ULA/LoRes clip index.
bit 1 – reset the sprite clip index.
bit 0 – reset the Layer 2 clip index.

Can be used to reset nextreg 0x19.

(R/W) 0x43 (67) => Palette Control
bit 7 = ‘1’ to disable palette write auto-increment.
bits 6-4 = Select palette for reading or writing:
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
bit 3 = Select Sprites palette (0 = first palette, 1 = second palette)
bit 2 = Select Layer 2 palette (0 = first palette, 1 = second palette)
bit 1 = Select ULA palette (0 = first palette, 1 = second palette)
bit 0 = Enabe ULANext mode if 1. (0 after a reset)

Sprites have two associated palettes which can be selected in this nextreg.

(R/W) 0x40 (64) => Palette Index
bits 7-0 = Select the palette index to change the associated colour.
For the ULA only, INKs are mapped to indices 0-7, Bright INKS to indices 8-15,
PAPERs to indices 16-23 and Bright PAPERs to indices 24-31.
In ULANext mode, INKs come from a subset of indices 0-127 and PAPERs come from
a subset of indices 128-255. The number of active indices depends on the number
of attribute bits assigned to INK and PAPER out of the attribute byte.
The ULA always takes border colour from paper.

Select the starting palette index if writing the sprite palette.

Palette values can be written in either 8-bit or 9-bit form:

(R/W) 0x41 (65) => Palette Value (8 bit colour)
bits 7-0 = Colour for the palette index selected by the register 0x40.
(Format is RRRGGGBB – the lower blue bit of the 9-bit colour will
be a logical OR of blue bits 1 and 0 of this 8-bit value.)
After the write, the palette index is auto-incremented to the next index
if the auto-increment is enabled at reg 0x43. Reads do not auto-increment.

(R/W) 0x44 (68) => Palette Value (9 bit colour)
Two consecutive writes are needed to write the 9 bit colour
1st write:
bits 7-0 = RRRGGGBB
2nd write.
If writing a L2 palette
———————————————————————–
bit 7 = 1 for L2 priority colour, 0 for normal
Priority colour will always be on top even on an SLU priori-
ty arrangement. If you need the exact same colour on priori-
ty and non priority locations you will need to program the
same colour twice changing bit 7 to 0 for the second colour
bits 6-1 = Reserved, must be 0
bit 0 = lsb B

If writing another palette
———————————————————————–
bits 7-1 = Reserved, must be 0
bit 0 = lsb B

After the two consecutives writes the palette index is
auto-incremented if the auto-increment is enabled by reg 0x43.

Reads only return the 2nd byte and do not auto-increment.

(R/W) 0x4B (75) => Transparency index for sprites
bits 7-0 = Set the index value (0xE3 after reset)
For 4-bit sprites only the bottom 4-bits are relevant.

Determines the transparent colour index used for sprites.