Sprite Status/Slot Select - Revision history

Ped7g: improving info about HW algorithm

2020-11-12T23:59:15Z

improving info about HW algorithm

← Older revision		Revision as of 00:59, 13 November 2020
Line 31:		Line 31:

	== Sprite Engine internals information ==		== Sprite Engine internals information ==
	Sprite renderer is able to draw roughly about 1600..1800 pixels per line (exact amount depends on the video mode timing, slower modes like 50Hz will give renderer more time per line, HDMI 60Hz mode is the most demanding one, allowing only about 100,6 sprites visible per line). In practice at least 100 non-scaled 16x16 sprites should be always rendered without any issue. When up-scaled sprites are used, the rendering time may get exhausted sooner (then bit 1 "maximum sprites" will get set, and rendering is aborted unfinished with some sprite graphics (of sprites defined later in the list) missing in final result). Sprites partially ~~crossing left-boundary~~ (~~screen border or clip window~~) will use the pixel bandwidth in the same way as if the ~~invisible~~ part of sprite was actually drawn. ~~Sprites partially~~ crossing right ~~boundary terminate~~ drawing ~~as soon as boundary is reached~~, saving the pixel bandwidth for later sprites.		Sprite renderer is able to draw roughly about 1600..1800 pixels per line (exact amount depends on the video mode timing, slower modes like 50Hz will give renderer more time per line, HDMI 60Hz mode is the most demanding one, allowing only about 100,6 sprites visible per line). In practice at least 100 non-scaled 16x16 sprites should be always rendered without any issue. When up-scaled sprites are used, the rendering time may get exhausted sooner (then bit 1 "maximum sprites" will get set, and rendering is aborted unfinished with some sprite graphics (of sprites defined later in the list) missing in final result). Sprites partially reaching into screen (pixels X=0..319) from left side will use the pixel bandwidth in the same way as if the out-of-screen part of sprite was actually drawn. The sprite part crossing the right side of screen terminates drawing early, saving the pixel bandwidth for later sprites (the clip window does not affect this optimization, it is fixed to 0..319 area).

	The rendering does proceed through list of sprites from sprite 0 to sprite 127, preparing sprite graphics for next scanline, i.e. when ULA pixel area is drawing line Y=14 (raster line register reads 14), the sprite graphics for line 14 was prepared during line 13. Thus "maximum" and "collision" flags read at the end of scanline 13 (start of scanline 14) contains already results of what is visible as line 14 on screen.		The rendering does proceed through list of sprites from sprite 0 to sprite 127, preparing sprite graphics for next scanline, i.e. when ULA pixel area is drawing line Y=14 (raster line register reads 14), the sprite graphics for line 14 was prepared during line 13. Thus "maximum" and "collision" flags read at the end of scanline 13 (start of scanline 14) contains already results of what is visible as line 14 on screen.

Ped7g at 11:44, 4 May 2020

2020-05-04T11:44:40Z

← Older revision		Revision as of 12:44, 4 May 2020
Line 1:		Line 1:
	{{Port		{{Port
	\|Number=$303B		\|Number=$303B
			\|NumberDec=12347
			\|PortMask=%0011 0000 0011 1011 ??
	\|ShortDesc=Sets active sprite-attribute index and pattern-slot index, reads sprite status.		\|ShortDesc=Sets active sprite-attribute index and pattern-slot index, reads sprite status.
	\|Readable=Yes		\|Readable=Yes
	\|Writable=Yes		\|Writable=Yes
	\|Subsystem=Sprites		\|Subsystem=Sprites
	~~\|PortMask=%0011 0000 0011 1011 ??~~
	}}		}}
	== Write functionality ==		== Write functionality ==

Xalior at 23:04, 19 April 2019

2019-04-19T23:04:44Z

← Older revision		Revision as of 00:04, 20 April 2019
Line 2:		Line 2:
	\|Number=$303B		\|Number=$303B
	\|ShortDesc=Sets active sprite-attribute index and pattern-slot index, reads sprite status.		\|ShortDesc=Sets active sprite-attribute index and pattern-slot index, reads sprite status.
	~~\|PortMask=%0011 0000 0011 1011 ??~~
	\|Readable=Yes		\|Readable=Yes
	\|Writable=Yes		\|Writable=Yes
	\|Subsystem=Sprites		\|Subsystem=Sprites
			\|PortMask=%0011 0000 0011 1011 ??
	}}		}}
	== Write functionality ==		== Write functionality ==

Specnext: 13 revisions imported

2019-04-14T10:00:21Z

13 revisions imported

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

wiki>Ped7g: Core 2.00.26 changes

2019-01-27T08:22:34Z

Core 2.00.26 changes

← Older revision		Revision as of 09:22, 27 January 2019
Line 8:		Line 8:
	}}		}}
	== Write functionality ==		== Write functionality ==
	Used to select the sprite index/slot (0..63 for ~~both~~ pattern slots and sprite attribute slots) ~~configured~~ by {{PortNo\|$xx57}} and {{PortNo\|$xx5B}}. Once written, these ports may auto-increment the sprite index they are addressing. This auto-increment happens independently and so the two ports may end up addressing different sprites as a result. A write to this port will resynchronise them to the same sprite. ~~The attribute-index has now~~ also {{NextRegNo\|$34}} ~~mirror~~, which can be set to operate either independently or in link with values set on this port (details in NextReg $34 description).		Used to select the sprite index/slot (0..63 for pattern slots and 0..127 for sprite attribute slots) used by {{PortNo\|$xx57}} and {{PortNo\|$xx5B}}. Once written, these ports may auto-increment the sprite index they are addressing. This auto-increment happens independently and so the two ports may end up addressing different sprites as a result. A write to this port will resynchronise them to the same sprite. There is also {{NextRegNo\|$34}}, which can be set to operate either independently or in link (bit 4 in {{NextRegNo\|$09}}) with values set on this port (details in NextReg $34 description).

	Write to this port with bit 7 set adds an offset of 128 to the pattern upload index (aiming at the second half of 256 byte pattern slot 0..63).		Write to this port with bit 7 set adds an offset of 128 to the pattern upload index (aiming at the second half of 256 byte pattern slot 0..63).
Line 30:		Line 30:

	== Sprite Engine internals information ==		== Sprite Engine internals information ==
	Sprite renderer is able to draw roughly about ~~1300~~..~~1600~~ pixels per line (exact amount depends on the video mode timing, slower modes like 50Hz will give renderer more time per line)~~, i~~.~~e. all 64~~ non-scaled 16x16 sprites should be always rendered without any issue. When up-scaled sprites are used, the rendering time may get exhausted sooner (then bit 1 "maximum sprites" will get set, and rendering is aborted unfinished with some sprite graphics (of sprites defined later in the list) missing in final result).		Sprite renderer is able to draw roughly about 1600..1800 pixels per line (exact amount depends on the video mode timing, slower modes like 50Hz will give renderer more time per line, HDMI 60Hz mode is the most demanding one, allowing only about 100,6 sprites visible per line). In practice at least 100 non-scaled 16x16 sprites should be always rendered without any issue. When up-scaled sprites are used, the rendering time may get exhausted sooner (then bit 1 "maximum sprites" will get set, and rendering is aborted unfinished with some sprite graphics (of sprites defined later in the list) missing in final result). Sprites partially crossing left-boundary (screen border or clip window) will use the pixel bandwidth in the same way as if the invisible part of sprite was actually drawn. Sprites partially crossing right boundary terminate drawing as soon as boundary is reached, saving the pixel bandwidth for later sprites.

	The rendering does proceed through list of sprites from sprite 0 to sprite 63, preparing sprite graphics for next scanline, i.e. when ULA pixel area is drawing line Y=14 (raster line register reads 14), the sprite graphics for line 14 was prepared during line 13. Thus "maximum" and "collision" flags read at the end of scanline 13 (start of scanline 14) contains already results of what is visible as line 14 on screen.		The rendering does proceed through list of sprites from sprite 0 to sprite 127, preparing sprite graphics for next scanline, i.e. when ULA pixel area is drawing line Y=14 (raster line register reads 14), the sprite graphics for line 14 was prepared during line 13. Thus "maximum" and "collision" flags read at the end of scanline 13 (start of scanline 14) contains already results of what is visible as line 14 on screen.

	The attributes of particular sprite are read in single 28MHz cycle when the sprite rendering starts, i.e. attributes of sprite 0 are read somewhere around ~~very start~~ of scanline, and as rendering progresses, attributes of sprite 63 are read somewhere toward end of scanline (or completely skipped in case the sprite renderer runs out of time due to large-scale sprites encountered early - the skipped sprites are also missing in the "collision" test, the "collision" flag is set only when particular colliding sprite pixels are rendered successfully and collision was "visible" on screen).		The attributes of particular sprite are read in single 28MHz cycle when the sprite rendering starts, i.e. attributes of sprite 0 are read somewhere around end of previous scanline (after pixel at sprite coordinate 319 is outputted), and as rendering progresses, attributes of sprite 127 are read somewhere toward end of scanline (or completely skipped in case the sprite renderer runs out of time due to large-scale sprites encountered early - the skipped sprites are also missing in the "collision" test, the "collision" flag is set only when particular colliding sprite pixels are rendered successfully and collision was "visible" on screen).

	In case you are "multiplexing" sprites (changing sprite attributes during single frame to make particular sprite appear multiple times at screen at different lines), the sprite attributes for line ''Y'' must be updated when line ''Y-1'' video output starts (for sprite 0 obviously slightly ahead of ''Y-1'' scanline start, but not at start of ''Y-2'' scanline, as that would modify sprite position already for scanline ''Y-1'' result.		In case you are "multiplexing" sprites (changing sprite attributes during single frame to make particular sprite appear multiple times at screen at different lines), the sprite attributes for line ''Y'' must be updated when line ''Y-1'' video output starts (for sprite 0 obviously slightly ahead of ''Y-1'' scanline start, but not at start of ''Y-2'' scanline, as that would modify sprite position already for scanline ''Y-1'' result.

	It is not possible to obtain from the sprite hardware the numbers or IDs of the sprites which overlapped in the "collision". The collision flag should thus be seen as initial broad phase collision detection (you can slightly narrow the detection by reading the flag at different scanlines, for example reading it at player's "top" line first to reset it, and at player's "bottom" line to ignore all sprite collisions happening above/below player).		It is not possible to obtain from the sprite hardware the numbers or IDs of the sprites which overlapped in the "collision". The collision flag should thus be seen as initial broad phase collision detection (you can slightly narrow the detection by reading the flag at different scanlines, for example reading it at player's "top" line first to reset it, and at player's "bottom" line to ignore all sprite collisions happening above/below player).

wiki>Ped7g: Removing info about sprite palette port $53 completely (it does not exist on 2.00.xx cores)

2019-01-01T00:10:43Z

Removing info about sprite palette port $53 completely (it does not exist on 2.00.xx cores)

← Older revision		Revision as of 01:10, 1 January 2019
Line 9:		Line 9:
	== Write functionality ==		== Write functionality ==
	Used to select the sprite index/slot (0..63 for both pattern slots and sprite attribute slots) configured by {{PortNo\|$xx57}} and {{PortNo\|$xx5B}}. Once written, these ports may auto-increment the sprite index they are addressing. This auto-increment happens independently and so the two ports may end up addressing different sprites as a result. A write to this port will resynchronise them to the same sprite. The attribute-index has now also {{NextRegNo\|$34}} mirror, which can be set to operate either independently or in link with values set on this port (details in NextReg $34 description).		Used to select the sprite index/slot (0..63 for both pattern slots and sprite attribute slots) configured by {{PortNo\|$xx57}} and {{PortNo\|$xx5B}}. Once written, these ports may auto-increment the sprite index they are addressing. This auto-increment happens independently and so the two ports may end up addressing different sprites as a result. A write to this port will resynchronise them to the same sprite. The attribute-index has now also {{NextRegNo\|$34}} mirror, which can be set to operate either independently or in link with values set on this port (details in NextReg $34 description).

	Also any write to this port resets the index of the {{PortNo\|$xx53}} to zero (note by ped7g: not sure how primary/secondary palette is selected, seems like you should rather use Next-registers to manipulate sprite palettes, this port is sort of legacy from earlier versions of Next core firmware .. then again, even next registers are accessible through ordinary I/O ports too, which may be even faster for block transfers, than series of "nextreg" instructions).

	Write to this port with bit 7 set adds an offset of 128 to the pattern upload index (aiming at the second half of 256 byte pattern slot 0..63).		Write to this port with bit 7 set adds an offset of 128 to the pattern upload index (aiming at the second half of 256 byte pattern slot 0..63).

wiki>Ped7g at 19:48, 28 December 2018

2018-12-28T19:48:24Z

← Older revision		Revision as of 20:48, 28 December 2018
Line 7:		Line 7:
	\|Subsystem=Sprites		\|Subsystem=Sprites
	}}		}}
			== Write functionality ==
	Used to select the sprite index/slot (0..63 for both pattern slots and sprite attribute slots) configured by {{PortNo\|$xx57}} and {{PortNo\|$xx5B}}. Once written, these ports may auto-increment the sprite index they are addressing. This auto-increment happens independently and so the two ports may end up addressing different sprites as a result. A write to this port will resynchronise them to the same sprite. The attribute-index has now also {{NextRegNo\|$34}} mirror, which can be set to operate either independently or in link with values set on this port (details in NextReg $34 description).		Used to select the sprite index/slot (0..63 for both pattern slots and sprite attribute slots) configured by {{PortNo\|$xx57}} and {{PortNo\|$xx5B}}. Once written, these ports may auto-increment the sprite index they are addressing. This auto-increment happens independently and so the two ports may end up addressing different sprites as a result. A write to this port will resynchronise them to the same sprite. The attribute-index has now also {{NextRegNo\|$34}} mirror, which can be set to operate either independently or in link with values set on this port (details in NextReg $34 description).

Line 13:		Line 14:
	Write to this port with bit 7 set adds an offset of 128 to the pattern upload index (aiming at the second half of 256 byte pattern slot 0..63).		Write to this port with bit 7 set adds an offset of 128 to the pattern upload index (aiming at the second half of 256 byte pattern slot 0..63).

			== Read functionality ==
	When read, returns sprite status information as follows:		When read, returns sprite status information as follows:

Line 29:		Line 31:
	\|}		\|}

			== Sprite Engine internals information ==
	Sprite renderer is able to draw roughly about 1300..1600 pixels per line (exact amount depends on the video mode timing, slower modes like 50Hz will give renderer more time per line), i.e. all 64 non-scaled 16x16 sprites should be always rendered without any issue. When up-scaled sprites are used, the rendering time may get exhausted sooner (then bit 1 "maximum sprites" will get set, and rendering is aborted unfinished with some sprite graphics (of sprites defined later in the list) missing in final result).		Sprite renderer is able to draw roughly about 1300..1600 pixels per line (exact amount depends on the video mode timing, slower modes like 50Hz will give renderer more time per line), i.e. all 64 non-scaled 16x16 sprites should be always rendered without any issue. When up-scaled sprites are used, the rendering time may get exhausted sooner (then bit 1 "maximum sprites" will get set, and rendering is aborted unfinished with some sprite graphics (of sprites defined later in the list) missing in final result).

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

2018-12-28T18:41:41Z

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

← Older revision		Revision as of 19:41, 28 December 2018
Line 7:		Line 7:
	\|Subsystem=Sprites		\|Subsystem=Sprites
	}}		}}
	Used to select the sprite index/slot configured by {{PortNo\|$xx57}} and {{PortNo\|$xx5B}}. Once written, these ports may auto-increment the sprite index they are addressing. This auto-increment happens independently and so the two ports may end up addressing different sprites as a result. A write to this port will resynchronise them to the same sprite. The attribute-index has now also {{NextRegNo\|$34}} mirror, which can be set to operate either independently or in link with values set on this port (details in NextReg $34 description).		Used to select the sprite index/slot (0..63 for both pattern slots and sprite attribute slots) configured by {{PortNo\|$xx57}} and {{PortNo\|$xx5B}}. Once written, these ports may auto-increment the sprite index they are addressing. This auto-increment happens independently and so the two ports may end up addressing different sprites as a result. A write to this port will resynchronise them to the same sprite. The attribute-index has now also {{NextRegNo\|$34}} mirror, which can be set to operate either independently or in link with values set on this port (details in NextReg $34 description).

	Also any write to this port resets the index of the {{PortNo\|$xx53}} to zero (note by ped7g: not sure how primary/secondary palette is selected, seems like you should rather use Next-registers to manipulate sprite palettes, this port is sort of legacy from earlier versions of Next core firmware).		Also any write to this port resets the index of the {{PortNo\|$xx53}} to zero (note by ped7g: not sure how primary/secondary palette is selected, seems like you should rather use Next-registers to manipulate sprite palettes, this port is sort of legacy from earlier versions of Next core firmware .. then again, even next registers are accessible through ordinary I/O ports too, which may be even faster for block transfers, than series of "nextreg" instructions).

	Write to this port with bit 7 set adds an offset of 128 to the pattern upload index (aiming at the second half of 256 byte pattern slot 0..63).		Write to this port with bit 7 set adds an offset of 128 to the pattern upload index (aiming at the second half of 256 byte pattern slot 0..63).
Line 29:		Line 29:
	\|}		\|}

	Sprite renderer is able to draw roughly about 1300..1600 pixels per line (exact amount depends on the video mode timing, slower modes like 50Hz will give renderer more time per line), i.e. all 64 non-scaled 16x16 sprites should be always rendered without any issue. When up-scaled sprites are used, the rendering time may get exhausted sooner (then bit 1 "maximum sprites" will get set, and rendering is aborted unfinished with some sprite ~~gfx~~ missing in final result).		Sprite renderer is able to draw roughly about 1300..1600 pixels per line (exact amount depends on the video mode timing, slower modes like 50Hz will give renderer more time per line), i.e. all 64 non-scaled 16x16 sprites should be always rendered without any issue. When up-scaled sprites are used, the rendering time may get exhausted sooner (then bit 1 "maximum sprites" will get set, and rendering is aborted unfinished with some sprite graphics (of sprites defined later in the list) missing in final result).

	The rendering does proceed through list of sprites from sprite 0 to sprite 63 ~~(or from sprite 63 to sprite 0 when priority is reversed by bit 6 in {{NextRegNo\|$15}})~~, preparing sprite graphics for next scanline, i.e. when ULA pixel area is drawing line Y=14 (raster line register reads 14), the sprite graphics for line 14 was prepared during line 13. Thus "maximum" and "collision" flags read at the end of scanline 13 (start of scanline 14) contains already results of what is visible as line 14 on screen.		The rendering does proceed through list of sprites from sprite 0 to sprite 63, preparing sprite graphics for next scanline, i.e. when ULA pixel area is drawing line Y=14 (raster line register reads 14), the sprite graphics for line 14 was prepared during line 13. Thus "maximum" and "collision" flags read at the end of scanline 13 (start of scanline 14) contains already results of what is visible as line 14 on screen.

	The attributes of particular sprite are read in single 28MHz cycle when the sprite rendering starts, i.e. attributes of sprite 0 are read somewhere around very start of scanline, and as rendering progresses, attributes of sprite 63 are read somewhere toward end of scanline (or completely skipped in case the sprite renderer runs out of time due to large-scale sprites encountered early - the skipped sprites are also missing in the "collision" test, the "collision" flag is set only when particular colliding sprite pixels are rendered successfully and collision was "visible" on screen).		The attributes of particular sprite are read in single 28MHz cycle when the sprite rendering starts, i.e. attributes of sprite 0 are read somewhere around very start of scanline, and as rendering progresses, attributes of sprite 63 are read somewhere toward end of scanline (or completely skipped in case the sprite renderer runs out of time due to large-scale sprites encountered early - the skipped sprites are also missing in the "collision" test, the "collision" flag is set only when particular colliding sprite pixels are rendered successfully and collision was "visible" on screen).

wiki>Ped7g: core 2.00.23 changes + rewording some parts

2018-12-28T14:55:20Z

core 2.00.23 changes + rewording some parts

← Older revision		Revision as of 15:55, 28 December 2018
Line 1:		Line 1:
	{{Port		{{Port
	\|Number=$303B		\|Number=$303B
	\|ShortDesc=~~Selects~~ active sprite slot ~~and palette address~~, ~~and returns~~ sprite status.		\|ShortDesc=Sets active sprite-attribute index and pattern-slot index, reads sprite status.
	\|PortMask=%0011 0000 0011 1011 ??		\|PortMask=%0011 0000 0011 1011 ??
	\|Readable=Yes		\|Readable=Yes
Line 7:		Line 7:
	\|Subsystem=Sprites		\|Subsystem=Sprites
	}}		}}
	Used to select the sprite slot configured by {{PortNo\|$xx57}} and {{PortNo\|$xx5B}}. Once written, these ports may auto-increment the sprite ~~number~~ they are addressing. This auto-increment happens independently and so the two ports may end up addressing different sprites as a result. A write to this port will resynchronise them to the same sprite.		Used to select the sprite index/slot configured by {{PortNo\|$xx57}} and {{PortNo\|$xx5B}}. Once written, these ports may auto-increment the sprite index they are addressing. This auto-increment happens independently and so the two ports may end up addressing different sprites as a result. A write to this port will resynchronise them to the same sprite. The attribute-index has now also {{NextRegNo\|$34}} mirror, which can be set to operate either independently or in link with values set on this port (details in NextReg $34 description).

	Also ~~"initializes~~ the ~~address~~ of the palette".		Also any write to this port resets the index of the {{PortNo\|$xx53}} to zero (note by ped7g: not sure how primary/secondary palette is selected, seems like you should rather use Next-registers to manipulate sprite palettes, this port is sort of legacy from earlier versions of Next core firmware).

	Write to this port with bit 7 set adds an offset of 128 to the pattern upload index (aiming at the second half of 256 byte pattern slot 0..63).		Write to this port with bit 7 set adds an offset of 128 to the pattern upload index (aiming at the second half of 256 byte pattern slot 0..63).

wiki>Ped7g: Core 2.00.22 changes, and forum knowledge from Jim Bagley distilled.

2018-12-21T17:16:48Z

Core 2.00.22 changes, and forum knowledge from Jim Bagley distilled.

← Older revision		Revision as of 18:16, 21 December 2018
Line 20:		Line 20:
	\| 2-7 \|\| Reserved		\| 2-7 \|\| Reserved
	\|-		\|-
	\| 1 \|\| ~~Max~~ sprites per line flag ~~(set if more than 12 sprites share a line)~~		\| 1 \|\| Maximum sprites per line flag.
			Set to 1 when sprite renderer ran out of time when preparing next scanline.
			Reading the port will reset it to 0.
	\|-		\|-
	\| 0 \|\| Collision flag ~~(set if~~ non transparent ~~areas~~ of any 2 sprites overlap)		\| 0 \|\| Collision flag.
			Set to 1 when non transparent pixels of any 2 sprites overlap during rendering scanline.
			Reading the port will reset it to 0.
	\|}		\|}

	It is not possible to obtain from the sprite hardware the numbers or IDs of the sprites which overlapped. The collision flag should thus be seen as initial broad phase collision detection.		Sprite renderer is able to draw roughly about 1300..1600 pixels per line (exact amount depends on the video mode timing, slower modes like 50Hz will give renderer more time per line), i.e. all 64 non-scaled 16x16 sprites should be always rendered without any issue. When up-scaled sprites are used, the rendering time may get exhausted sooner (then bit 1 "maximum sprites" will get set, and rendering is aborted unfinished with some sprite gfx missing in final result).

			The rendering does proceed through list of sprites from sprite 0 to sprite 63 (or from sprite 63 to sprite 0 when priority is reversed by bit 6 in {{NextRegNo\|$15}}), preparing sprite graphics for next scanline, i.e. when ULA pixel area is drawing line Y=14 (raster line register reads 14), the sprite graphics for line 14 was prepared during line 13. Thus "maximum" and "collision" flags read at the end of scanline 13 (start of scanline 14) contains already results of what is visible as line 14 on screen.

			The attributes of particular sprite are read in single 28MHz cycle when the sprite rendering starts, i.e. attributes of sprite 0 are read somewhere around very start of scanline, and as rendering progresses, attributes of sprite 63 are read somewhere toward end of scanline (or completely skipped in case the sprite renderer runs out of time due to large-scale sprites encountered early - the skipped sprites are also missing in the "collision" test, the "collision" flag is set only when particular colliding sprite pixels are rendered successfully and collision was "visible" on screen).

			In case you are "multiplexing" sprites (changing sprite attributes during single frame to make particular sprite appear multiple times at screen at different lines), the sprite attributes for line ''Y'' must be updated when line ''Y-1'' video output starts (for sprite 0 obviously slightly ahead of ''Y-1'' scanline start, but not at start of ''Y-2'' scanline, as that would modify sprite position already for scanline ''Y-1'' result.

			It is not possible to obtain from the sprite hardware the numbers or IDs of the sprites which overlapped in the "collision". The collision flag should thus be seen as initial broad phase collision detection (you can slightly narrow the detection by reading the flag at different scanlines, for example reading it at player's "top" line first to reset it, and at player's "bottom" line to ignore all sprite collisions happening above/below player).