Sprite Attribute 3 (with INC) Register

Number	TBRegisterNumber::$78
Readable	TBRegisterReadable::No
Writable	TBRegisterWritable::Yes
Short Description	[[ShortDesc::Same as {{#ask: TBRegisterNumber::$38 }} ($38) (write fourth byte of sprite-attributes), plus increments {{#ask: TBRegisterNumber::$34 }} ($34)]]

Byte 4 is bitmapped:

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 {{#ask: TBRegisterNumber::$39 }} ($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 {{#ask: TBRegisterNumber::$39 }} ($39) explicitly, even if you use "0" for bit 6 here.

After write into sprite-attribute "byte 4" ({{#ask: PortNumber::$xx57 }} ($xx57{{#ask: PortNumber::$xx57 |mainlabel=- |headers=hide |intro= /  |?NumberDec#- }})), the {{#ask: TBRegisterNumber::$34 }} ($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.