Changes

Jump to navigation Jump to search
1,033 bytes added ,  19:39, 16 August 2015
→‎Transfer Engine: Added TextureCopy documentation
|-
| 0x1EF00C00
| Input physical address>>3
|-
| 0x1EF00C04
| Output physical address>>3
|-
| 0x1EF00C08
| Output framebuffer dimensions, used with cmd3DisplayTransfer output width (bits 0-15) and height (bits 16-31).
|-
| 0x1EF00C0C
| Input framebuffer dimensions, used with cmd3DisplayTransfer input width and height.
|-
| 0x1EF00C10
| Flags, used with cmd3 and cmd4Transfer flags.(See below)
|-
| 0x1EF00C14
|-
| 0x1EF00C20
| Texture info? used with cmd4 ("Size" TextureCopy total amount of data to copy, in [[GSP_Shared_Memory|GX command]])bytes.
|-
| 0x1EF00C24
| Texture info? used with cmd4 TextureCopy input line width ("Input dimensions?" bits 0-15) and gap (bits 16-31), in [[GSP_Shared_Memory|GX command]])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.
==== Flags Register - 0x1EF00C10 ====
{| class="wikitable" border="1"
! Bit
|-
| 3
| Uses a TextureCopy mode transfer. All other bits in this register seem to be ignored when this is setSee below for details.
|-
| 4
| 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 ==
110

edits

Navigation menu