Copper - Revision history

SevenFFF at 20:04, 10 October 2025

2025-10-10T20:04:23Z

← Older revision		Revision as of 21:04, 10 October 2025
Line 8:		Line 8:
	! Opcode !! Bit pattern !! Effect		! Opcode !! Bit pattern !! Effect
	\|-		\|-
	\| WAIT \|\| %1hhhhhhv %vvvvvvvv \|\| Wait for raster line v (0-311) and horizontal position h*8 (h is 0-55) (duration 1 CLOCK)		\| WAIT \|\| %1hhhhhhv %vvvvvvvv \|\| Wait for raster line v (0-311) and horizontal position h*8 (h is 0-56) (duration 1 CLOCK)
	\|-		\|-
	\| MOVE \|\| %0rrrrrrr %vvvvvvvv \|\| Write value '''v''' to Next register '''r''' (duration 2 CLOCKS)		\| MOVE \|\| %0rrrrrrr %vvvvvvvv \|\| Write value '''v''' to Next register '''r''' (duration 2 CLOCKS)

Ped7g at 11:56, 10 October 2025

2025-10-10T11:56:59Z

← Older revision		Revision as of 12:56, 10 October 2025
Line 39:		Line 39:
	The precise timing and many more details are currently documented in distribution file [https://gitlab.com/thesmog358/tbblue/blob/a0d25589bd28b05c510e528332bcd192bc414ebb/docs/extra-hw/copper/COPPER-v0.1c.TXT "/docs/extra-hw/copper/COPPER-v0.1c.TXT"].		The precise timing and many more details are currently documented in distribution file [https://gitlab.com/thesmog358/tbblue/blob/a0d25589bd28b05c510e528332bcd192bc414ebb/docs/extra-hw/copper/COPPER-v0.1c.TXT "/docs/extra-hw/copper/COPPER-v0.1c.TXT"].

	(core 2.0) the copper code is executed at 14MHz, and the COPPER-v0.1c.TXT document above describes timing of the ~~core2~~.0.		(core 2.0) the copper code is executed at 14MHz, and the COPPER-v0.1c.TXT document above describes timing of the core 2.0.<br>

	(core 3.0) the copper code is executed at 28MHz, the precise timing is not documented yet		(core 3.0) the copper code is executed at 28MHz, the precise timing is not documented yet

Ped7g at 11:53, 10 October 2025

2025-10-10T11:53:28Z

← Older revision		Revision as of 12:53, 10 October 2025
Line 46:		Line 46:
	Important values affecting pixel display are now sampled at the same moment when the pixel is drawn (no test yet to describe what does that mean at sub-pixel accuracy terms and in which order the copper MOVEs should be done with what kind of lead in case you want to set for example 6 different display-affecting registers, by theoretical approach of single MOVE taking half-pixel width you should start precisely 3 pixels ahead of the edge where all values should be set, but YMMV) (overall it's probably much wiser to avoid situations where you need sub-pixel precision, or test with the real board heavily)		Important values affecting pixel display are now sampled at the same moment when the pixel is drawn (no test yet to describe what does that mean at sub-pixel accuracy terms and in which order the copper MOVEs should be done with what kind of lead in case you want to set for example 6 different display-affecting registers, by theoretical approach of single MOVE taking half-pixel width you should start precisely 3 pixels ahead of the edge where all values should be set, but YMMV) (overall it's probably much wiser to avoid situations where you need sub-pixel precision, or test with the real board heavily)

	Extra notes based on discussion with AA at Next discord:		Extra notes based on discussion with AA at Next discord:<br>
	The copper is 16-bit :		The copper is 16-bit:
	- it fetches its 16-bit instruction in 1 T (16b atomic fetch from copper code memory) and executes it		* it fetches its 16-bit instruction in 1 T (16b atomic fetch from copper code memory) and executes it
	- NOOP (alias MOVE without writing nextreg) takes thus 1 T in total		* NOOP (alias MOVE without writing nextreg) takes thus 1 T in total
	- MOVE with writing nextreg is finished in first T state, but then there is 1 T delay to not 100% occupy nextreg logic (starving CPU/DMA of access). So MOVE instruction takes 2 T in total and nextreg reads new value 2 T after MOVE execution.		* MOVE with writing nextreg is finished in first T state, but then there is 1 T delay to not 100% occupy nextreg logic (starving CPU/DMA of access). So MOVE instruction takes 2 T in total and nextreg reads new value 2 T after MOVE execution.

Ped7g at 10:05, 10 October 2025

2025-10-10T10:05:53Z

← Older revision		Revision as of 11:05, 10 October 2025
Line 46:		Line 46:
	Important values affecting pixel display are now sampled at the same moment when the pixel is drawn (no test yet to describe what does that mean at sub-pixel accuracy terms and in which order the copper MOVEs should be done with what kind of lead in case you want to set for example 6 different display-affecting registers, by theoretical approach of single MOVE taking half-pixel width you should start precisely 3 pixels ahead of the edge where all values should be set, but YMMV) (overall it's probably much wiser to avoid situations where you need sub-pixel precision, or test with the real board heavily)		Important values affecting pixel display are now sampled at the same moment when the pixel is drawn (no test yet to describe what does that mean at sub-pixel accuracy terms and in which order the copper MOVEs should be done with what kind of lead in case you want to set for example 6 different display-affecting registers, by theoretical approach of single MOVE taking half-pixel width you should start precisely 3 pixels ahead of the edge where all values should be set, but YMMV) (overall it's probably much wiser to avoid situations where you need sub-pixel precision, or test with the real board heavily)

	Extra ~~note from~~ discord ~~by AA~~: The copper is 16-bit :- it fetches its 16-bit instruction in 1 T and ~~actually all move instructions take~~ 1 T~~. However if the move is~~ writing to nextreg ~~(ie it's not a nop)~~ then there is a 1 T delay ~~for it~~ to ~~go through the~~ nextreg ~~path for the~~ nextreg ~~write to take effect. While that goes on, the next copper intruction is already executing~~.		Extra notes based on discussion with AA at Next discord:
			The copper is 16-bit :
			- it fetches its 16-bit instruction in 1 T (16b atomic fetch from copper code memory) and executes it
			- NOOP (alias MOVE without writing nextreg) takes thus 1 T in total
			- MOVE with writing nextreg is finished in first T state, but then there is 1 T delay to not 100% occupy nextreg logic (starving CPU/DMA of access). So MOVE instruction takes 2 T in total and nextreg reads new value 2 T after MOVE execution.

Ped7g at 00:45, 10 October 2025

2025-10-10T00:45:17Z

← Older revision		Revision as of 01:45, 10 October 2025
Line 45:		Line 45:

	Important values affecting pixel display are now sampled at the same moment when the pixel is drawn (no test yet to describe what does that mean at sub-pixel accuracy terms and in which order the copper MOVEs should be done with what kind of lead in case you want to set for example 6 different display-affecting registers, by theoretical approach of single MOVE taking half-pixel width you should start precisely 3 pixels ahead of the edge where all values should be set, but YMMV) (overall it's probably much wiser to avoid situations where you need sub-pixel precision, or test with the real board heavily)		Important values affecting pixel display are now sampled at the same moment when the pixel is drawn (no test yet to describe what does that mean at sub-pixel accuracy terms and in which order the copper MOVEs should be done with what kind of lead in case you want to set for example 6 different display-affecting registers, by theoretical approach of single MOVE taking half-pixel width you should start precisely 3 pixels ahead of the edge where all values should be set, but YMMV) (overall it's probably much wiser to avoid situations where you need sub-pixel precision, or test with the real board heavily)

			Extra note from discord by AA: The copper is 16-bit :- it fetches its 16-bit instruction in 1 T and actually all move instructions take 1 T. However if the move is writing to nextreg (ie it's not a nop) then there is a 1 T delay for it to go through the nextreg path for the nextreg write to take effect. While that goes on, the next copper intruction is already executing.

Tanepiper: Make the text about the opcodes clearer

2020-09-11T17:52:21Z

Make the text about the opcodes clearer

← Older revision		Revision as of 18:52, 11 September 2020
Line 3:		Line 3:
	"Copper" is a strangulation of "co-processor" and is a term taken from the Amiga which had a similar function. The copper on the Spectrum Next is not associated with the [[RPi0 Acceleration\|Raspberry Pi 'coprocessor']].		"Copper" is a strangulation of "co-processor" and is a term taken from the Amiga which had a similar function. The copper on the Spectrum Next is not associated with the [[RPi0 Acceleration\|Raspberry Pi 'coprocessor']].

	A program is uploaded to the Copper by sending it, byte by byte, to {{NextRegNo\|$60}}. Each Copper instruction is 16 bits wide and there are 4 opcodes~~, so only~~ a single bit in an instruction determines the operation. ~~The~~ four operations are:		A program is uploaded to the Copper by sending it, byte by byte, to {{NextRegNo\|$60}}. Each Copper instruction is 16 bits wide and there are 2 opcodes with a single bit in an instruction determines the operation and two special case opcodes. In total the four operations are:

	{\| class="wikitable"		{\| class="wikitable"

Tanepiper: Updated to reflect there are 4 op codes

2020-09-11T17:47:32Z

Updated to reflect there are 4 op codes

← Older revision		Revision as of 18:47, 11 September 2020
Line 3:		Line 3:
	"Copper" is a strangulation of "co-processor" and is a term taken from the Amiga which had a similar function. The copper on the Spectrum Next is not associated with the [[RPi0 Acceleration\|Raspberry Pi 'coprocessor']].		"Copper" is a strangulation of "co-processor" and is a term taken from the Amiga which had a similar function. The copper on the Spectrum Next is not associated with the [[RPi0 Acceleration\|Raspberry Pi 'coprocessor']].

	A program is uploaded to the Copper by sending it, byte by byte, to {{NextRegNo\|$60}}. Each Copper instruction is 16 bits wide and there are ~~only 2~~ opcodes, so only a single bit in an instruction determines the operation. The ~~two~~ operations are:		A program is uploaded to the Copper by sending it, byte by byte, to {{NextRegNo\|$60}}. Each Copper instruction is 16 bits wide and there are 4 opcodes, so only a single bit in an instruction determines the operation. The four operations are:

	{\| class="wikitable"		{\| class="wikitable"

Ped7g at 15:25, 4 October 2019

2019-10-04T15:25:55Z

← Older revision		Revision as of 16:25, 4 October 2019
Line 38:		Line 38:

	The precise timing and many more details are currently documented in distribution file [https://gitlab.com/thesmog358/tbblue/blob/a0d25589bd28b05c510e528332bcd192bc414ebb/docs/extra-hw/copper/COPPER-v0.1c.TXT "/docs/extra-hw/copper/COPPER-v0.1c.TXT"].		The precise timing and many more details are currently documented in distribution file [https://gitlab.com/thesmog358/tbblue/blob/a0d25589bd28b05c510e528332bcd192bc414ebb/docs/extra-hw/copper/COPPER-v0.1c.TXT "/docs/extra-hw/copper/COPPER-v0.1c.TXT"].

			(core 2.0) the copper code is executed at 14MHz, and the COPPER-v0.1c.TXT document above describes timing of the core2.0.
			(core 3.0) the copper code is executed at 28MHz, the precise timing is not documented yet

			From practical test (with the Swedish-flags copper test) the coordinates for WAIT are identical, MOVE is twice as fast (flags are half of original width because each pixel is created by single MOVE instruction).

			Important values affecting pixel display are now sampled at the same moment when the pixel is drawn (no test yet to describe what does that mean at sub-pixel accuracy terms and in which order the copper MOVEs should be done with what kind of lead in case you want to set for example 6 different display-affecting registers, by theoretical approach of single MOVE taking half-pixel width you should start precisely 3 pixels ahead of the edge where all values should be set, but YMMV) (overall it's probably much wiser to avoid situations where you need sub-pixel precision, or test with the real board heavily)

Specnext: 4 revisions imported

2019-04-14T09:59:51Z

4 revisions imported

← Older revision		Revision as of 10:59, 14 April 2019
(No difference)

wiki>Ped7g: Adding info (and rewording) from distro docs.

2018-12-23T00:50:06Z

Adding info (and rewording) from distro docs.

← Older revision		Revision as of 01:50, 23 December 2018
Line 8:		Line 8:
	! Opcode !! Bit pattern !! Effect		! Opcode !! Bit pattern !! Effect
	\|-		\|-
	\| WAIT \|\| %1hhhhhhv %vvvvvvvv \|\| Wait for raster line v (0-311) and horizontal position h*8 (h is 0-55)		\| WAIT \|\| %1hhhhhhv %vvvvvvvv \|\| Wait for raster line v (0-311) and horizontal position h*8 (h is 0-55) (duration 1 CLOCK)
	\|-		\|-
	\| MOVE \|\| %0rrrrrrr %vvvvvvvv \|\| Write value v to Next register r		\| MOVE \|\| %0rrrrrrr %vvvvvvvv \|\| Write value '''v''' to Next register '''r''' (duration 2 CLOCKS)
			\|-
			\| NOOP \|\| %00000000 %00000000 \|\| Special case of "value 0 to port 0" works as "no operation" (duration 1 CLOCK)
			\|-
			\| HALT \|\| %11111111 %11111111 \|\| Special case of "WAIT 63,511" works as "halt" instruction
	\|}		\|}

	The copper's program storage is 1k big; since each instruction is 2 bytes it can store exactly ~~512~~ instructions, numbered 0-~~511~~. The copper is controlled by a word accessed through Next Registers {{NextRegNo\|$61}} and {{NextRegNo\|$62}}.		The copper's program storage is 2k big; since each instruction is 2 bytes it can store exactly 1024 instructions, numbered 0-1023. The copper is controlled by a word accessed through Next Registers {{NextRegNo\|$61}} and {{NextRegNo\|$62}}. The internal "program counter" ('''CPC''') has 10 bits (0-1023), auto-incrementing it after each instruction, wrapping around after last one back to first one.

	~~Update: From TBU .26 this will have increased to 2K so it can store 1024 instructions numbered 0-1023.~~		The copper control word has the structure: %cc000iii %iiiiiiii. '''I''' is the storage position (0-2047) (for writing instructions with {{NextRegNo\|$60}}), and '''c''' is used to set the behaviour mode of the copper, as follows:

	The copper control word has the structure: %~~cc00000i~~ %iiiiiiii. I is the ~~instruction index~~ (0-~~511~~), and c is used to set the ~~behavior~~ mode of the copper, as follows:

	{\| class="wikitable"		{\| class="wikitable"
	! C bits !! Effect		! C bits !! Effect
	\|-		\|-
	\| %00 \|\| STOP, copper does nothing		\| %00 \|\| STOP, copper does nothing (CPC keeps its current value)
	\|-		\|-
	\| %01 \|\| ~~START~~, then ~~never reset~~		\| %01 \|\| reset CPC to 0, then START
	\|-		\|-
	\| %10 \|\| START~~, loop continuously~~		\| %10 \|\| START (resumes from current CPC)
	\|-		\|-
	\| %11 \|\| ~~START~~, then reset ~~at next VBlank~~		\| %11 \|\| reset CPC to 0, then START; Also VBLANK does reset CPC to 0
	\|}		\|}

	If you ~~are using one of~~ the ~~resetting modes (%01) (%11)~~ then you can mark the "end" of the copper program by waiting for a line higher than 311. Since these lines will never be reached, the copper will essentially halt until reset.		When '''c''' bits are identical to previously written value, the control mode is ignored, and only write-index '''I''' is modified.

			If you don't want the copper program to loop infinitely, then you can mark the "end" of the copper program by waiting for a line higher than 311 ("HALT" instruction). Since these lines will never be reached, the copper will essentially halt until reset.

			The precise timing and many more details are currently documented in distribution file [https://gitlab.com/thesmog358/tbblue/blob/a0d25589bd28b05c510e528332bcd192bc414ebb/docs/extra-hw/copper/COPPER-v0.1c.TXT "/docs/extra-hw/copper/COPPER-v0.1c.TXT"].

← Older revision		Revision as of 18:52, 11 September 2020
Line 3:		Line 3:
	"Copper" is a strangulation of "co-processor" and is a term taken from the Amiga which had a similar function. The copper on the Spectrum Next is not associated with the [[RPi0 Acceleration\|Raspberry Pi 'coprocessor']].		"Copper" is a strangulation of "co-processor" and is a term taken from the Amiga which had a similar function. The copper on the Spectrum Next is not associated with the [[RPi0 Acceleration\|Raspberry Pi 'coprocessor']].

	A program is uploaded to the Copper by sending it, byte by byte, to {{NextRegNo\|$60}}. Each Copper instruction is 16 bits wide and there are 4 opcodes~~, so only~~ a single bit in an instruction determines the operation. ~~The~~ four operations are:		A program is uploaded to the Copper by sending it, byte by byte, to {{NextRegNo\|$60}}. Each Copper instruction is 16 bits wide and there are 2 opcodes with a single bit in an instruction determines the operation and two special case opcodes. In total the four operations are:

	{\| class="wikitable"		{\| class="wikitable"

← Older revision		Revision as of 18:47, 11 September 2020
Line 3:		Line 3:
	"Copper" is a strangulation of "co-processor" and is a term taken from the Amiga which had a similar function. The copper on the Spectrum Next is not associated with the [[RPi0 Acceleration\|Raspberry Pi 'coprocessor']].		"Copper" is a strangulation of "co-processor" and is a term taken from the Amiga which had a similar function. The copper on the Spectrum Next is not associated with the [[RPi0 Acceleration\|Raspberry Pi 'coprocessor']].

	A program is uploaded to the Copper by sending it, byte by byte, to {{NextRegNo\|$60}}. Each Copper instruction is 16 bits wide and there are ~~only 2~~ opcodes, so only a single bit in an instruction determines the operation. The ~~two~~ operations are:		A program is uploaded to the Copper by sending it, byte by byte, to {{NextRegNo\|$60}}. Each Copper instruction is 16 bits wide and there are 4 opcodes, so only a single bit in an instruction determines the operation. The four operations are:

	{\| class="wikitable"		{\| class="wikitable"