GPU/External Registers: Difference between revisions

Line 238:

|-

| 0x1EF00C00

| Input physical address>>3

| Input physical address >> 3

|-

| 0x1EF00C04

| Output physical address>>3

| Output physical address >> 3

|-

| 0x1EF00C08

| ~~Output framebuffer dimensions, used with cmd3~~

| DisplayTransfer output width (bits 0-15) and height (bits 16-31).

|-

| 0x1EF00C0C

| ~~Input framebuffer dimensions, used with cmd3~~

| DisplayTransfer input width and height.

|-

| 0x1EF00C10

| ~~Flags, used with cmd3 and cmd4~~.

| Transfer flags. (See below)

|-

| 0x1EF00C14

Line 259:

|-

| 0x1EF00C20

| ~~Texture info? used with cmd4 ("Size"~~ in ~~[[GSP_Shared_Memory|GX command]])~~

| TextureCopy total amount of data to copy, in bytes.

|-

| 0x1EF00C24

| ~~Texture info? used with cmd4~~ (~~"Input dimensions?"~~ in ~~[[GSP_Shared_Memory|GX command]])~~

| TextureCopy input line width (bits 0-15) and gap (bits 16-31), in bytes.

|-

| 0x1EF00C28

| ~~Texture info? used with cmd4 ("Output dimensions?" in [[GSP_Shared_Memory|GX command]])~~

| TextureCopy output line width and gap.

|}

These registers are used by [[GSP_Shared_Memory|GX command]] 3 and 4. For cmd4, *0x1EF00C18 |= 1 is used instead of just writing value 1~~. The dimensions fields seem to use the same format as [[LCD]] register 0x1EF00X5C. The input framebuffer width for the main screen is normally 480~~.

These registers are used by [[GSP_Shared_Memory|GX command]] 3 and 4. For cmd4, *0x1EF00C18 |= 1 is used instead of just writing value 1.

==== 0x1EF00C10 ====

==== Flags Register - 0x1EF00C10 ====

{| class="wikitable" border="1"

! Bit

Line 285:

|-

| 3

| Uses a TextureCopy mode transfer. ~~All other bits in this register seem to be ignored when this is set~~.

| Uses a TextureCopy mode transfer. See below for details.

|-

| 4

Line 320:

| Not writable

|}

=== TextureCopy ===

When bit 3 of the control register is set, the hardware performs a TextureCopy-mode transfer. In this mode, all other bits of the control register (except for bit 2, which still needs to be set correctly) and the regular dimension registers are ignored, and no format conversions are done. Instead, it performs a raw data copy from the source to the destination, but with a configurable gap between lines. The total amount of bytes to copy is specified in the size register, and the hardware loops reading lines from the input and writing them to the output until this amount is copied. The "gap" specified in the input/output dimension register is the number of bytes to skip after each "width" bytes of the input/output, and is NOT counted towards the total size of the transfer.

By correctly calculating the input and output gap sizes it is possible to use this functionality to copy arbitrary sub-rectangles between differently-sized framebuffers or textures, which is one of its main uses over a regular no-conversion DisplayTransfer. When copying tiled textures/framebuffers it's important to remember that the contents of a tile are laid out sequentially in memory, and so this should be taken into account when calculating the transfer parameters.

== Command List ==

@@ Line 238: / Line 238: @@
 |-
 | 0x1EF00C00
-| Input physical address>>3
+| Input physical address >> 3
 |-
 | 0x1EF00C04
-| Output physical address>>3
+| Output physical address >> 3
 |-
 | 0x1EF00C08
-| Output framebuffer dimensions, used with cmd3
+| DisplayTransfer output width (bits 0-15) and height (bits 16-31).
 |-
 | 0x1EF00C0C
-| Input framebuffer dimensions, used with cmd3
+| DisplayTransfer input width and height.
 |-
 | 0x1EF00C10
-| Flags, used with cmd3 and cmd4.
+| Transfer flags. (See below)
 |-
 | 0x1EF00C14
@@ Line 259: / Line 259: @@
 |-
 | 0x1EF00C20
-| Texture info? used with cmd4 ("Size" in [[GSP_Shared_Memory|GX command]])
+| TextureCopy total amount of data to copy, in bytes.
 |-
 | 0x1EF00C24
-| Texture info? used with cmd4 ("Input dimensions?" in [[GSP_Shared_Memory|GX command]])
+| TextureCopy input line width (bits 0-15) and gap (bits 16-31), in bytes.
 |-
 | 0x1EF00C28
-| Texture info? used with cmd4 ("Output dimensions?" in [[GSP_Shared_Memory|GX command]])
+| TextureCopy output line width and gap.
 |}
-These registers are used by [[GSP_Shared_Memory|GX command]] 3 and 4. For cmd4, *0x1EF00C18 |= 1 is used instead of just writing value 1. The dimensions fields seem to use the same format as [[LCD]] register 0x1EF00X5C. The input framebuffer width for the main screen is normally 480.
+These registers are used by [[GSP_Shared_Memory|GX command]] 3 and 4. For cmd4, *0x1EF00C18 |= 1 is used instead of just writing value 1.
-==== 0x1EF00C10 ====
+==== Flags Register - 0x1EF00C10 ====
 {| class="wikitable" border="1"
 !  Bit
@@ Line 285: / Line 285: @@
 |-
 | 3
-| Uses a TextureCopy mode transfer. All other bits in this register seem to be ignored when this is set.
+| Uses a TextureCopy mode transfer. See below for details.
 |-
 | 4
@@ Line 320: / Line 320: @@
 | Not writable
 |}
+=== TextureCopy ===
+When bit 3 of the control register is set, the hardware performs a TextureCopy-mode transfer. In this mode, all other bits of the control register (except for bit 2, which still needs to be set correctly) and the regular dimension registers are ignored, and no format conversions are done. Instead, it performs a raw data copy from the source to the destination, but with a configurable gap between lines. The total amount of bytes to copy is specified in the size register, and the hardware loops reading lines from the input and writing them to the output until this amount is copied. The "gap" specified in the input/output dimension register is the number of bytes to skip after each "width" bytes of the input/output, and is NOT counted towards the total size of the transfer.
+By correctly calculating the input and output gap sizes it is possible to use this functionality to copy arbitrary sub-rectangles between differently-sized framebuffers or textures, which is one of its main uses over a regular no-conversion DisplayTransfer. When copying tiled textures/framebuffers it's important to remember that the contents of a tile are laid out sequentially in memory, and so this should be taken into account when calculating the transfer parameters.
 == Command List ==