Sprite Attribute 3 (with INC) Register - Revision history

Xalior: Xalior moved page Sprite port-mirror Attribute 3 (with INC) Register to Sprite Attribute 3 (with INC) Register

2025-10-14T12:19:04Z

Xalior moved page Sprite port-mirror Attribute 3 (with INC) Register to Sprite Attribute 3 (with INC) Register

← Older revision		Revision as of 13:19, 14 October 2025
(No difference)

Ped7g: refresh sprite info

2019-12-09T23:19:28Z

refresh sprite info

← Older revision		Revision as of 00:19, 10 December 2019
Line 11:		Line 11:
	\| 7 \|\| Enable visibility		\| 7 \|\| Enable visibility
	\|-		\|-
	\| 6 \|\| ~~? see note below.~~		\| 6 \|\| Enable fifth sprite attribute byte
	\|-		\|-
	\| 5-0 \|\| Pattern index ("Name")		\| 5-0 \|\| Pattern index ("Name")
	\|}		\|}

	~~Bit~~ 6 is ~~in normal port writing used to indicate there will be~~ "~~byte 5~~" ~~following~~, ~~while with NextReg mirror~~ the "byte ~~5" is directly accessible at~~ {{NextRegNo\|$39}}~~. At~~ the ~~time~~ of ~~adding this documentation,~~ it is ~~not clear what bit 6 does here, but value "0" may work as "reset whole byte 5~~ to ~~zero", so~~ if you ~~intend~~ to use ~~extended "~~byte ~~5" features, write "1" or test with actual HW~~. ~~And other way too, if~~ you ~~don't plan to use~~ the ~~extra features, probably write zero~~ to ~~{{NextRegNo\|$39}} explicitly~~, ~~even if you use "0" for~~ bit 6 here.		When the bit 6 is "0", the sprite renderer will ignore value written in fifth attribute byte, for example by {{NextRegNo\|$39}}, and it will use zero for all the features of fifth attribute byte (it is safe to initialize only four bytes if you are planning to use 4-byte type of sprites).

			If you want the value in fifth attribute byte to apply during rendering, bit 6 here must be set to "1".

	After write into sprite-attribute "byte 4" ({{PortNo\|$xx57}}), the {{NextRegNo\|$34}} is incremented (with all consequences stemming from such action). If the sprite 127 was modified, the result of the increment is officially "undefined behaviour", and code should explicitly set valid 0..127 sprite index before next sprite-attribute manipulation.		After write into sprite-attribute "byte 4" ({{PortNo\|$xx57}}), the {{NextRegNo\|$34}} is incremented (with all consequences stemming from such action). If the sprite 127 was modified, the result of the increment is officially "undefined behaviour", and code should explicitly set valid 0..127 sprite index before next sprite-attribute manipulation.

Specnext: 2 revisions imported

2019-04-14T10:00:21Z

2 revisions imported

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

wiki>Ped7g: Core 2.00.26 changes

2019-01-27T09:11:08Z

Core 2.00.26 changes

← Older revision		Revision as of 10:11, 27 January 2019
Line 18:		Line 18:
	Bit 6 is in normal port writing used to indicate there will be "byte 5" following, while with NextReg mirror the "byte 5" is directly accessible at {{NextRegNo\|$39}}. At the time of adding this documentation, it is not clear what bit 6 does here, but value "0" may work as "reset whole byte 5 to zero", so if you intend to use extended "byte 5" features, write "1" or test with actual HW. And other way too, if you don't plan to use the extra features, probably write zero to {{NextRegNo\|$39}} explicitly, even if you use "0" for bit 6 here.		Bit 6 is in normal port writing used to indicate there will be "byte 5" following, while with NextReg mirror the "byte 5" is directly accessible at {{NextRegNo\|$39}}. At the time of adding this documentation, it is not clear what bit 6 does here, but value "0" may work as "reset whole byte 5 to zero", so if you intend to use extended "byte 5" features, write "1" or test with actual HW. And other way too, if you don't plan to use the extra features, probably write zero to {{NextRegNo\|$39}} explicitly, even if you use "0" for bit 6 here.

	After write into sprite-attribute "byte 4" ({{PortNo\|$xx57}}), the {{NextRegNo\|$34}} is incremented (with all consequences stemming from such action). If the sprite 63 was modified, the result of the increment is officially "undefined behaviour", and code should explicitly set valid 0..63 sprite index before next sprite-attribute manipulation.		After write into sprite-attribute "byte 4" ({{PortNo\|$xx57}}), the {{NextRegNo\|$34}} is incremented (with all consequences stemming from such action). If the sprite 127 was modified, the result of the increment is officially "undefined behaviour", and code should explicitly set valid 0..127 sprite index before next sprite-attribute manipulation.

wiki>Ped7g: core 2.00.23 changes

2018-12-28T20:14:17Z

core 2.00.23 changes

New page

{{NextRegister
|Number=$78
|Readable=No
|Writable=Yes
|ShortDesc=Same as {{NextRegNo|$38}} (write fourth byte of sprite-attributes), plus increments {{NextRegNo|$34}}
}}
Byte 4 is bitmapped:
{|class="wikitable"
! Bit !! Description
|-
| 7 || Enable visibility
|-
| 6 || ? see note below.
|-
| 5-0 || Pattern index ("Name")
|}

Bit 6 is in normal port writing used to indicate there will be "byte 5" following, while with NextReg mirror the "byte 5" is directly accessible at {{NextRegNo|$39}}. At the time of adding this documentation, it is not clear what bit 6 does here, but value "0" may work as "reset whole byte 5 to zero", so if you intend to use extended "byte 5" features, write "1" or test with actual HW. And other way too, if you don't plan to use the extra features, probably write zero to {{NextRegNo|$39}} explicitly, even if you use "0" for bit 6 here.

After write into sprite-attribute "byte 4" ({{PortNo|$xx57}}), the {{NextRegNo|$34}} is incremented (with all consequences stemming from such action). If the sprite 63 was modified, the result of the increment is officially "undefined behaviour", and code should explicitly set valid 0..63 sprite index before next sprite-attribute manipulation.