Sprite Attribute Upload - Revision history

Ped7g at 11:49, 4 May 2020

2020-05-04T11:49:02Z

← Older revision		Revision as of 12:49, 4 May 2020
Line 1:		Line 1:
	{{Port		{{Port
	\|Number=$xx57		\|Number=$xx57
			\|NumberDec=87
			\|PortMask=%---- ---- 0101 0111
	\|ShortDesc=Uploads sprite positions, visibility, colour type and effect flags.		\|ShortDesc=Uploads sprite positions, visibility, colour type and effect flags.
	\|Readable=No		\|Readable=No
	\|Writable=Yes		\|Writable=Yes
	\|Subsystem=Sprites		\|Subsystem=Sprites
	~~\|PortMask=%---- ---- 0101 0111~~
	}}		}}
	Uploads attributes of the sprite slot selected by {{PortNo\|$303B}}. Attributes are sent in 4-5 byte blocks. After sending 4 or 5 bytes block the sprite-index (slot) auto-increments to the next sprite. This auto-increment is independent of other sprite ports, but may be interlinked with {{NextRegNo\|$34}} (see details there). The auto-increment from value 127 is officially "undefined behaviour" and index must be explicitly reset back to 0..127 after such auto-increment to make the code behave predictably in future.		Uploads attributes of the sprite slot selected by {{PortNo\|$303B}}. Attributes are sent in 4-5 byte blocks. After sending 4 or 5 bytes block the sprite-index (slot) auto-increments to the next sprite. This auto-increment is independent of other sprite ports, but may be interlinked with {{NextRegNo\|$34}} (see details there). The auto-increment from value 127 is officially "undefined behaviour" and index must be explicitly reset back to 0..127 after such auto-increment to make the code behave predictably in future.

Xalior at 23:01, 19 April 2019

2019-04-19T23:01:21Z

← Older revision		Revision as of 00:01, 20 April 2019
Line 2:		Line 2:
	\|Number=$xx57		\|Number=$xx57
	\|ShortDesc=Uploads sprite positions, visibility, colour type and effect flags.		\|ShortDesc=Uploads sprite positions, visibility, colour type and effect flags.
	~~\|PortMask=%---- ---- 0101 0111~~
	\|Readable=No		\|Readable=No
	\|Writable=Yes		\|Writable=Yes
	\|Subsystem=Sprites		\|Subsystem=Sprites
			\|PortMask=%---- ---- 0101 0111
	}}		}}
	Uploads attributes of the sprite slot selected by {{PortNo\|$303B}}. Attributes are sent in 4-5 byte blocks. After sending 4 or 5 bytes block the sprite-index (slot) auto-increments to the next sprite. This auto-increment is independent of other sprite ports, but may be interlinked with {{NextRegNo\|$34}} (see details there). The auto-increment from value 127 is officially "undefined behaviour" and index must be explicitly reset back to 0..127 after such auto-increment to make the code behave predictably in future.		Uploads attributes of the sprite slot selected by {{PortNo\|$303B}}. Attributes are sent in 4-5 byte blocks. After sending 4 or 5 bytes block the sprite-index (slot) auto-increments to the next sprite. This auto-increment is independent of other sprite ports, but may be interlinked with {{NextRegNo\|$34}} (see details there). The auto-increment from value 127 is officially "undefined behaviour" and index must be explicitly reset back to 0..127 after such auto-increment to make the code behave predictably in future.

Specnext: 10 revisions imported

2019-04-14T10:00:20Z

10 revisions imported

← Older revision	Revision as of 11:00, 14 April 2019
(No difference)

wiki>Ped7g: Core 2.00.27 (or 28) changes to relative sprite system.

2019-02-11T00:50:24Z

Core 2.00.27 (or 28) changes to relative sprite system.

Show changes

wiki>Ped7g: Core 2.00.26 changes

2019-01-27T09:25:08Z

Core 2.00.26 changes

← Older revision		Revision as of 10:25, 27 January 2019
Line 7:		Line 7:
	\|Subsystem=Sprites		\|Subsystem=Sprites
	}}		}}
	Uploads attributes of the sprite slot selected by {{PortNo\|$303B}}. Attributes are sent in 4-5 byte blocks. After sending 4 or 5 bytes block the sprite-index (slot) auto-increments to the next sprite. This auto-increment is independent of other sprite ports, but may be interlinked with {{NextRegNo\|$34}} (see details there). The auto-increment from value 63 is officially "undefined behaviour" and index must be explicitly reset back to 0..63 after such auto-increment to make the code behave predictably in future.		Uploads attributes of the sprite slot selected by {{PortNo\|$303B}}. Attributes are sent in 4-5 byte blocks. After sending 4 or 5 bytes block the sprite-index (slot) auto-increments to the next sprite. This auto-increment is independent of other sprite ports, but may be interlinked with {{NextRegNo\|$34}} (see details there). The auto-increment from value 127 is officially "undefined behaviour" and index must be explicitly reset back to 0..127 after such auto-increment to make the code behave predictably in future.

	The 4-5 bytes sprite-attribute structure is as follows:		The 4-5 bytes sprite-attribute structure is as follows:
Line 75:		Line 75:
	Every normal sprite works as "anchor" sprite for all following relative sprites (i.e. sprite 12 is anchor for relative sprites 13, 14, ..., until another normal sprite sets up new "anchor").		Every normal sprite works as "anchor" sprite for all following relative sprites (i.e. sprite 12 is anchor for relative sprites 13, 14, ..., until another normal sprite sets up new "anchor").

	Every anchor sprite sets '''anchor.x''', '''anchor.y''' (coordinates), '''anchor.H''' (4-bit or 8-bit colour pattern mode) and '''anchor.visibility''' variables in sprite engine (anchor.visibility is zero at beginning of line rendering, before sprite 0 is processed). All following "relative" sprites then:		Every '''anchor''' sprite sets '''anchor.x''', '''anchor.y''' (coordinates), '''anchor.H''' (4-bit or 8-bit colour pattern mode) and '''anchor.visibility''' variables in sprite engine (anchor.visibility is zero at beginning of line rendering, before sprite 0 is processed). All following '''relative''' sprites then:
	* use '''(anchor.visibility AND relative.visibility)''' to determine visibility status of relative sprite		* use '''(anchor.visibility AND relative.visibility)''' to determine visibility status of relative sprite
	* use '''[(anchor.x + x), (anchor.y + y)]''' coordinates (i.e. relative.x = 510 works as "-2": X = (anchor.x - 2), and relative.x = 5 works as X = (anchor.x + 5))		* use '''[(anchor.x + x), (anchor.y + y)]''' coordinates (i.e. relative.x = 510 works as "-2": X = (anchor.x - 2), and relative.x = 5 works as X = (anchor.x + 5))
Line 81:		Line 81:
	* if '''anchor.H''' is set (4-bit colour mode), then bit 5 in fifth attribute byte of relative sprite determines the top/bottom part of pattern to draw (instead of bit 6 having this function for normal sprites)		* if '''anchor.H''' is set (4-bit colour mode), then bit 5 in fifth attribute byte of relative sprite determines the top/bottom part of pattern to draw (instead of bit 6 having this function for normal sprites)

	This allows to create "clusters" of sprites where each processed "normal" (non-relative) sprite is new "anchor", providing global display position, visibility-master and colour mode for all following "relative" sprites. Those are positioned relatively against that last "anchor" sprite. To move such cluster of sprites on the screen, you need to update only the anchor position in attributes data (or to hide whole cluster, set anchor.visibility to 0). The relative sprites are always drawn above or below anchor pattern, depending on the rendering priority set in bit 6 of {{NextRegNo\|$15}} (sprites in the sprite-engine are processed always in order from Sprite 0 to Sprite 63).		This allows to create "clusters" of sprites where each processed "normal" (non-relative) sprite is new "anchor", providing global display position, visibility-master and colour mode for all following "relative" sprites. Those are positioned relatively against that last "anchor" sprite. To move such cluster of sprites on the screen, you need to update only the anchor position in attributes data (or to hide whole cluster, set anchor.visibility to 0). The relative sprites are always drawn above or below anchor pattern, depending on the rendering priority set in bit 6 of {{NextRegNo\|$15}} (sprites in the sprite-engine are processed always in order from Sprite 0 to Sprite 127).

wiki>Ped7g: Fixing info about reversed sprite priority, the technical description (guessed by me) was wrong

2018-12-28T18:00:59Z

Fixing info about reversed sprite priority, the technical description (guessed by me) was wrong

← Older revision		Revision as of 19:00, 28 December 2018
Line 7:		Line 7:
	\|Subsystem=Sprites		\|Subsystem=Sprites
	}}		}}
	Uploads attributes of the sprite slot selected by {{PortNo\|$303B}}. Attributes are sent in 4-5 byte blocks. After sending 4 or 5 bytes block the sprite-index (slot) auto-increments to the next sprite. This auto-increment is independent of other sprite ports, but may be interlinked with {{NextRegNo\|$34}} (see details there). The auto-increment from value 63 is officially "undefined behaviour" and index must be explicitly reset back to 0..63 after such auto-increment to make the ~~SW predictable~~ in future.		Uploads attributes of the sprite slot selected by {{PortNo\|$303B}}. Attributes are sent in 4-5 byte blocks. After sending 4 or 5 bytes block the sprite-index (slot) auto-increments to the next sprite. This auto-increment is independent of other sprite ports, but may be interlinked with {{NextRegNo\|$34}} (see details there). The auto-increment from value 63 is officially "undefined behaviour" and index must be explicitly reset back to 0..63 after such auto-increment to make the code behave predictably in future.

	The 4-5 bytes sprite-attribute structure is as follows:		The 4-5 bytes sprite-attribute structure is as follows:
Line 73:		Line 73:
	=== Relative sprites ===		=== Relative sprites ===

	Every normal sprite works as "anchor" sprite for all following relative sprites (i.e. sprite 12 is anchor for relative sprites 13 ~~and~~ 14, ~~etc, until another normal sprite sets up new anchor - when rendering in normal order) (when order of rendering is reversed by bit 6 in {{NextRegNo\|$15}}, the ordering of sprites is descending (i~~.e. ~~normal sprite 15 is new anchor for relative sprites 14 , 13, etc~~, until another normal sprite sets up new anchor).		Every normal sprite works as "anchor" sprite for all following relative sprites (i.e. sprite 12 is anchor for relative sprites 13, 14, ..., until another normal sprite sets up new "anchor").

	Every anchor sprite sets ~~temporarily~~ '''anchor.x''', '''anchor.y''' (coordinates), '''anchor.H''' (4-bit or 8-bit colour pattern mode) and '''anchor.visibility''' variables in sprite engine. All following "relative" sprites then:		Every anchor sprite sets '''anchor.x''', '''anchor.y''' (coordinates), '''anchor.H''' (4-bit or 8-bit colour pattern mode) and '''anchor.visibility''' variables in sprite engine (anchor.visibility is zero at beginning of line rendering, before sprite 0 is processed). All following "relative" sprites then:
	* use '''(anchor.visibility AND relative.visibility)''' to determine visibility status of relative sprite		* use '''(anchor.visibility AND relative.visibility)''' to determine visibility status of relative sprite
	* use '''[(anchor.x + x), (anchor.y + y)]''' coordinates (i.e. relative.x = 510 works as "-2": X = (anchor.x - 2), and relative.x = 5 works as X = (anchor.x + 5))		* use '''[(anchor.x + x), (anchor.y + y)]''' coordinates (i.e. relative.x = 510 works as "-2": X = (anchor.x - 2), and relative.x = 5 works as X = (anchor.x + 5))
	* use '''anchor.H''' to select 4 or 8 bit colour rendering mode for pattern (relative sprite can't have different colour mode than anchor has)		* use '''anchor.H''' to select 4 or 8 bit colour rendering mode for pattern (relative sprite can't have different colour mode than anchor has)
	* if '''anchor.H''' is set (4-bit colour mode), then bit 5 in fifth attribute byte of relative sprite determines the top/bottom part of pattern to draw (instead of bit 6 having this function for ~~anchor~~ sprites)		* if '''anchor.H''' is set (4-bit colour mode), then bit 5 in fifth attribute byte of relative sprite determines the top/bottom part of pattern to draw (instead of bit 6 having this function for normal sprites)

	This allows to create "clusters" of sprites where ~~the last~~ processed "normal" (non-relative) sprite is "anchor", providing global display position, visibility-master and colour mode ~~- followed by one or more~~ "relative" sprites ~~which~~ are positioned relatively against ~~the~~ last "anchor" sprite. To move such cluster of sprites on the screen, you need to update only the anchor position in attributes data (or to hide whole cluster, set anchor.visibility to 0). The relative sprites are always drawn above anchor (~~as they~~ are ~~defined "after" anchor~~ in ~~whichever direction of sprite list is used~~),		This allows to create "clusters" of sprites where each processed "normal" (non-relative) sprite is new "anchor", providing global display position, visibility-master and colour mode for all following "relative" sprites. Those are positioned relatively against that last "anchor" sprite. To move such cluster of sprites on the screen, you need to update only the anchor position in attributes data (or to hide whole cluster, set anchor.visibility to 0). The relative sprites are always drawn above or below anchor pattern, depending on the rendering priority set in bit 6 of {{NextRegNo\|$15}} (sprites in the sprite-engine are processed always in order from Sprite 0 to Sprite 63).

wiki>Ped7g: Core 2.00.23 changes (relative sprites added and sprite-index link with NextReg $34)

2018-12-28T14:39:01Z

Core 2.00.23 changes (relative sprites added and sprite-index link with NextReg $34)

← Older revision		Revision as of 15:39, 28 December 2018
Line 7:		Line 7:
	\|Subsystem=Sprites		\|Subsystem=Sprites
	}}		}}
	Uploads attributes of the sprite slot selected by {{PortNo\|$303B}}. Attributes are in 4-5 byte blocks ~~sent in the following order; after~~ sending 4 or 5 bytes the ~~address~~ auto-increments to the next sprite. This auto-increment is independent of other sprite ports. The 4-5 bytes ~~are~~ as follows:		Uploads attributes of the sprite slot selected by {{PortNo\|$303B}}. Attributes are sent in 4-5 byte blocks. After sending 4 or 5 bytes block the sprite-index (slot) auto-increments to the next sprite. This auto-increment is independent of other sprite ports, but may be interlinked with {{NextRegNo\|$34}} (see details there). The auto-increment from value 63 is officially "undefined behaviour" and index must be explicitly reset back to 0..63 after such auto-increment to make the SW predictable in future.

			The 4-5 bytes sprite-attribute structure is as follows:

	Byte 1 is the low bits of the X position. The MSB is in byte 3.		Byte 1 is the low bits of the X position. The MSB is in byte 3.
Line 46:		Line 48:
	\| 7 \|\| If 1, the pattern will be treated as 4-bit colour one (128 bytes), 0 is for 8-bit colour patterns (256 bytes)		\| 7 \|\| If 1, the pattern will be treated as 4-bit colour one (128 bytes), 0 is for 8-bit colour patterns (256 bytes)
	\|-		\|-
	\| 6 \|\| Chooses top/bottom part of pattern slot ~~(for~~ 4-bit colour ~~patterns)~~		\| 6 \|\| (if bit 7 = 1): Chooses top/bottom part of pattern slot when 4-bit colour pattern
	0 will target bytes 0..127 of pattern "Name" (byte 4), 1 will target bytes 128..255 of pattern "Name".		0 will target bytes 0..127 of pattern "Name" (byte 4), 1 will target bytes 128..255 of pattern "Name".

			(if bit 7 = 0): make this sprite "relative" one: 1 = relative, 0 = normal (anchor) type
	\|-		\|-
	\| 5 \|\| ~~Reserved~~, use always 0		\| 5 \|\| (if bit 7-6 = %01) for "relative" sprite, this bit chooses top/bottom part of pattern slot for 4-bit colour mode (4 or 8 bit mode is set by anchor sprite, relative sprite can't switch the colour mode). See Bit 6 description above, if anchor sprite is in 4-bit mode. If anchor sprite is in 8-bit mode, use always 0
			(else) For normal (anchor) sprites this is reserved, use always 0
	\|-		\|-
	\| 4-3 \|\| x-axis scale factor: %00 = 1x (16 pixels), %01 = 2x, %10 = 4x, %11 = 8x (128 pixels)		\| 4-3 \|\| x-axis scale factor: %00 = 1x (16 pixels), %01 = 2x, %10 = 4x, %11 = 8x (128 pixels)
Line 57:		Line 62:
	\| 0 \|\| MSB of Y coordinate		\| 0 \|\| MSB of Y coordinate
	\|}		\|}

			=== Normal (= anchor) sprites ===

	About [X,Y] coordinates: 9 bit values allow for 0..511 coordinate. The top-left ULA pixel ("paper" area) is at [32,32] and bottom-right ULA pixel is at [287,223] (256x192 pixel area).		About [X,Y] coordinates: 9 bit values allow for 0..511 coordinate. The top-left ULA pixel ("paper" area) is at [32,32] and bottom-right ULA pixel is at [287,223] (256x192 pixel area).
Line 63:		Line 70:

	All coordinates beyond these act as wrap-around 0..511 coordinate system, with sprite getting outside of drawing area, i.e. [X,Y]=[511,510] will render sprite in top left corner over "border" area, with left-most column already not visible (511 works as "-1" X coordinate) and two top-most rows not visible (510 works as "-2" Y coordinate), only remaining 15x14 pixels of sprite pattern are visible in top-left corner. Similarly sprite at coordinates [310,250] will render only 10x6 pixels of pattern in bottom right corner, rest of pattern being already outside of rendering area and not visible (assuming the over-border is enabled and not clipped by sprite clip-window).		All coordinates beyond these act as wrap-around 0..511 coordinate system, with sprite getting outside of drawing area, i.e. [X,Y]=[511,510] will render sprite in top left corner over "border" area, with left-most column already not visible (511 works as "-1" X coordinate) and two top-most rows not visible (510 works as "-2" Y coordinate), only remaining 15x14 pixels of sprite pattern are visible in top-left corner. Similarly sprite at coordinates [310,250] will render only 10x6 pixels of pattern in bottom right corner, rest of pattern being already outside of rendering area and not visible (assuming the over-border is enabled and not clipped by sprite clip-window).

			=== Relative sprites ===

			Every normal sprite works as "anchor" sprite for all following relative sprites (i.e. sprite 12 is anchor for relative sprites 13 and 14, etc, until another normal sprite sets up new anchor - when rendering in normal order) (when order of rendering is reversed by bit 6 in {{NextRegNo\|$15}}, the ordering of sprites is descending (i.e. normal sprite 15 is new anchor for relative sprites 14 , 13, etc, until another normal sprite sets up new anchor).

			Every anchor sprite sets temporarily '''anchor.x''', '''anchor.y''' (coordinates), '''anchor.H''' (4-bit or 8-bit colour pattern mode) and '''anchor.visibility''' variables in sprite engine. All following "relative" sprites then:
			* use '''(anchor.visibility AND relative.visibility)''' to determine visibility status of relative sprite
			* use '''[(anchor.x + x), (anchor.y + y)]''' coordinates (i.e. relative.x = 510 works as "-2": X = (anchor.x - 2), and relative.x = 5 works as X = (anchor.x + 5))
			* use '''anchor.H''' to select 4 or 8 bit colour rendering mode for pattern (relative sprite can't have different colour mode than anchor has)
			* if '''anchor.H''' is set (4-bit colour mode), then bit 5 in fifth attribute byte of relative sprite determines the top/bottom part of pattern to draw (instead of bit 6 having this function for anchor sprites)

			This allows to create "clusters" of sprites where the last processed "normal" (non-relative) sprite is "anchor", providing global display position, visibility-master and colour mode - followed by one or more "relative" sprites which are positioned relatively against the last "anchor" sprite. To move such cluster of sprites on the screen, you need to update only the anchor position in attributes data (or to hide whole cluster, set anchor.visibility to 0). The relative sprites are always drawn above anchor (as they are defined "after" anchor in whichever direction of sprite list is used),

wiki>Ped7g: further details from Jim in forum post

2018-12-21T19:19:41Z

further details from Jim in forum post

← Older revision		Revision as of 20:19, 21 December 2018
Line 34:		Line 34:
	\| 7 \|\| Enable visibility		\| 7 \|\| Enable visibility
	\|-		\|-
	\| 6 \|\| If 1, the optional 5th attribute byte should follow. If 0, only four attribute bytes are expected.		\| 6 \|\| If 1, the optional 5th attribute byte should follow fourth one.
			If 0, only four attribute bytes are expected (accidental fifth byte send to port will be treated as first byte of next sprite attributes), and all extra sprite features (not covered by 4 byte block) will be reset to zero (as if 5th byte equal to value zero was explicitly sent).
	\|-		\|-
	\| 5-0 \|\| Pattern index ("Name")		\| 5-0 \|\| Pattern index ("Name")
Line 46:		Line 47:
	\|-		\|-
	\| 6 \|\| Chooses top/bottom part of pattern slot (for 4-bit colour patterns)		\| 6 \|\| Chooses top/bottom part of pattern slot (for 4-bit colour patterns)
			0 will target bytes 0..127 of pattern "Name" (byte 4), 1 will target bytes 128..255 of pattern "Name".
	\|-		\|-
	\| 5 \|\| Reserved, use always 0		\| 5 \|\| Reserved, use always 0

wiki>Ped7g: Added extra info about coordinates from forum post.

2018-12-21T13:00:12Z

Added extra info about coordinates from forum post.

← Older revision		Revision as of 14:00, 21 December 2018
Line 9:		Line 9:
	Uploads attributes of the sprite slot selected by {{PortNo\|$303B}}. Attributes are in 4-5 byte blocks sent in the following order; after sending 4 or 5 bytes the address auto-increments to the next sprite. This auto-increment is independent of other sprite ports. The 4-5 bytes are as follows:		Uploads attributes of the sprite slot selected by {{PortNo\|$303B}}. Attributes are in 4-5 byte blocks sent in the following order; after sending 4 or 5 bytes the address auto-increments to the next sprite. This auto-increment is independent of other sprite ports. The 4-5 bytes are as follows:

	Byte 1 is the low bits of the X position~~. Legal X positions are 0-319 if sprites are allowed over the border or 32-287 if not~~. The MSB is in byte 3.		Byte 1 is the low bits of the X position. The MSB is in byte 3.

	Byte 2 is the Y position. ~~Legal Y positions are 0-255 if sprites are allowed over the border or 32-223 if not (with "core 2.00.22" there's now Y8 bit~~ in ~~b0 of~~ byte 5~~, allowing for positions 0-511, but I'm not sure at this moment what are legal values)~~.		Byte 2 is the low bits of the Y position. The MSB is in optional byte 5.

	Byte 3 is bitmapped:		Byte 3 is bitmapped:
Line 55:		Line 55:
	\| 0 \|\| MSB of Y coordinate		\| 0 \|\| MSB of Y coordinate
	\|}		\|}

			About [X,Y] coordinates: 9 bit values allow for 0..511 coordinate. The top-left ULA pixel ("paper" area) is at [32,32] and bottom-right ULA pixel is at [287,223] (256x192 pixel area).

			When sprites are configured to be drawn "over border", there is fixed-size 32 pixels wide area around pixel area (so called "border" in BASIC terms), i.e. coordinates [0,0] to [319,255] are coordinates of visible over-border sprite area.

			All coordinates beyond these act as wrap-around 0..511 coordinate system, with sprite getting outside of drawing area, i.e. [X,Y]=[511,510] will render sprite in top left corner over "border" area, with left-most column already not visible (511 works as "-1" X coordinate) and two top-most rows not visible (510 works as "-2" Y coordinate), only remaining 15x14 pixels of sprite pattern are visible in top-left corner. Similarly sprite at coordinates [310,250] will render only 10x6 pixels of pattern in bottom right corner, rest of pattern being already outside of rendering area and not visible (assuming the over-border is enabled and not clipped by sprite clip-window).

wiki>Ped7g: Core 2.00.22 changes.

2018-12-20T02:49:31Z

Core 2.00.22 changes.

← Older revision		Revision as of 03:49, 20 December 2018
Line 1:		Line 1:
	{{Port		{{Port
	\|Number=$xx57		\|Number=$xx57
	\|ShortDesc=Uploads sprite positions, visibility and effect flags.		\|ShortDesc=Uploads sprite positions, visibility, colour type and effect flags.
	\|PortMask=%---- ---- 0101 0111		\|PortMask=%---- ---- 0101 0111
	\|Readable=No		\|Readable=No
Line 7:		Line 7:
	\|Subsystem=Sprites		\|Subsystem=Sprites
	}}		}}
	Uploads attributes of the sprite slot selected by {{PortNo\|$303B}}. Attributes are in 4 byte blocks sent in the following order; after sending 4 bytes the address auto-increments to the next sprite. This auto-increment is independent of other sprite ports. The 4 bytes are as follows:		Uploads attributes of the sprite slot selected by {{PortNo\|$303B}}. Attributes are in 4-5 byte blocks sent in the following order; after sending 4 or 5 bytes the address auto-increments to the next sprite. This auto-increment is independent of other sprite ports. The 4-5 bytes are as follows:

	Byte 1 is the low bits of the X position. Legal X positions are 0-319 if sprites are allowed over the border or 32-287 if not. The MSB is in byte 3.		Byte 1 is the low bits of the X position. Legal X positions are 0-319 if sprites are allowed over the border or 32-287 if not. The MSB is in byte 3.

	Byte 2 is the Y position. Legal Y positions are 0-255 if sprites are allowed over the border or 32-223 if not.		Byte 2 is the Y position. Legal Y positions are 0-255 if sprites are allowed over the border or 32-223 if not (with "core 2.00.22" there's now Y8 bit in b0 of byte 5, allowing for positions 0-511, but I'm not sure at this moment what are legal values).

	Byte 3 is bitmapped:		Byte 3 is bitmapped:
Line 28:		Line 28:
	\|}		\|}

	Byte 4 is ~~also~~ bitmapped:		Byte 4 is bitmapped:
	{\|class="wikitable"		{\|class="wikitable"
	! Bit !! Description		! Bit !! Description
Line 34:		Line 34:
	\| 7 \|\| Enable visibility		\| 7 \|\| Enable visibility
	\|-		\|-
	\| 6 \|\| ~~Reserved~~		\| 6 \|\| If 1, the optional 5th attribute byte should follow. If 0, only four attribute bytes are expected.
	\|-		\|-
	\| 5-0 \|\| Pattern index ("Name")		\| 5-0 \|\| Pattern index ("Name")
			\|}

			Optional (when bit 6 is set in byte 4) byte 5 is bitmapped:
			{\|class="wikitable"
			! Bit !! Description
			\|-
			\| 7 \|\| If 1, the pattern will be treated as 4-bit colour one (128 bytes), 0 is for 8-bit colour patterns (256 bytes)
			\|-
			\| 6 \|\| Chooses top/bottom part of pattern slot (for 4-bit colour patterns)
			\|-
			\| 5 \|\| Reserved, use always 0
			\|-
			\| 4-3 \|\| x-axis scale factor: %00 = 1x (16 pixels), %01 = 2x, %10 = 4x, %11 = 8x (128 pixels)
			\|-
			\| 2-1 \|\| y-axis scale factor: %00 = 1x (16 pixels), %01 = 2x, %10 = 4x, %11 = 8x (128 pixels)
			\|-
			\| 0 \|\| MSB of Y coordinate
	\|}		\|}