Sprite port-mirror Attribute 3 (with INC) Register
| Number | $78 |
|---|---|
| Readable | No |
| Writable | Yes |
| Short Description | Same as Sprite port-mirror Attribute 3 Register ($38) (write fourth byte of sprite-attributes), plus increments Sprite port-mirror Index Register ($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 Sprite port-mirror Attribute 4 Register ($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 Sprite port-mirror Attribute 4 Register ($39) explicitly, even if you use "0" for bit 6 here.
After write into sprite-attribute "byte 4" (Sprite Attribute Upload ($xx57 / 87)), the Sprite port-mirror Index Register ($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.