Reality Display Processor/Interface: Difference between revisions
(Some DPS_TEST_MODE and related) |
|||
Line 369: | Line 369: | ||
}} |
}} |
||
====<span style="display:none;">0x0420 0004 - DPS_TEST_MODE ==== |
====<span style="display:none;">0x0420 0004 - DPS_TEST_MODE ==== |
||
---- |
|||
----{{#invoke:Register table|head|1200px|DPS_TEST_MODE <code>0x0420 0004</code>}} |
|||
'''When Reading:''' |
|||
{{#invoke:Register table|head|1200px|DPS_TEST_MODE <code>0x0420 0004</code>}} |
|||
{{#invoke:Register table|row|31:24}} |
|||
| colspan="4" | U-4 || colspan="4" | R-4 |
|||
|- |
|||
| colspan="4" | 0 || colspan="4" | cspan0[3:0] |
|||
{{#invoke:Register table|row|23:16}} |
|||
| colspan="4" | R-4 || colspan="4" | R-4 |
|||
|- |
|||
| colspan="4" | cspan1[3:0] || colspan="4" | zspan0[3:0] |
|||
{{#invoke:Register table|row|15:8}} |
|||
| colspan="4" | R-4 || U-? || U-? || U-? || U-? |
|||
|- |
|||
| colspan="4" | zspan1[3:0] || ? || ? || ? || ? |
|||
{{#invoke:Register table|row|7:0}} |
|||
| U-? || U-? || U-? || U-? || U-? || U-? || U-? || R-1 |
|||
|- |
|||
| 1 || ? || ? || ? || ? || 1 || ? || TEST_ENABLE |
|||
{{#invoke:Register table|foot}} |
|||
{{#invoke:Register table|definitions |
|||
| 31-28 | 0 | Always 0? |
|||
| 27-24 | cspan0[3:0] | Color span counter? Increments (and potentially overflows) based on how many 16-byte segments a drawn primitive covers. |
|||
| 23-20 | cspan1[3:0] | Color span counter? Synced with the other counter; if the other counter has the msbit unset this one has it set and vice-versa. |
|||
| 19-16 | zspan0[3:0] | Depth span counter? Increments (and potentially overflows) based on how many 16-byte segments a drawn primitive covers, only when depth read or write is enabled. |
|||
| 15-12 | zspan1[3:0] | Depth span counter? Synced with the other counter; if the other counter has the msbit unset this one has it set and vice-versa. |
|||
| 7 | 1 | Always 1? |
|||
| 2 | 1 | Always 1? |
|||
| 0 | TEST_ENABLE | Whether span buffer testing is enabled. |
|||
}} |
|||
'''When Writing:''' |
|||
{{#invoke:Register table|head|1200px|DPS_TEST_MODE <code>0x0420 0004</code>}} |
|||
{{#invoke:Register table|row|31:24}} |
{{#invoke:Register table|row|31:24}} |
||
| U-? || U-? || U-? || U-? || U-? || U-? || U-? || U-? |
| U-? || U-? || U-? || U-? || U-? || U-? || U-? || U-? |
||
Line 383: | Line 418: | ||
| — || — || — || — || — || — || — || — |
| — || — || — || — || — || — || — || — |
||
{{#invoke:Register table|row|7:0}} |
{{#invoke:Register table|row|7:0}} |
||
| U-? || U-? || U-? || U-? || U-? || U-? || U-? || |
| U-? || U-? || U-? || U-? || U-? || U-? || U-? || W-1 |
||
|- |
|- |
||
| — || — || — || — || — || — || — || |
| — || — || — || — || — || — || — || TEST_ENABLE |
||
{{#invoke:Register table|foot}} |
{{#invoke:Register table|foot}} |
||
{{#invoke:Register table|definitions |
{{#invoke:Register table|definitions |
||
| 0 | TEST_ENABLE | Enables span buffer test access via '''DPS_BUFTEST_ADDR''' and '''DPS_BUFTEST_DATA'''. '''Warning:''' If the span test mode is used the RDP should be idle, else the RDP may hang. |
|||
| 0 | ENABLE | ? |
|||
}} |
}} |
||
====<span style="display:none;">0x0420 0008 - DPS_BUFTEST_ADDR ==== |
====<span style="display:none;">0x0420 0008 - DPS_BUFTEST_ADDR ==== |
||
----{{#invoke:Register table|head|1200px|DPS_BUFTEST_ADDR <code>0x0420 0008</code>}} |
----{{#invoke:Register table|head|1200px|DPS_BUFTEST_ADDR <code>0x0420 0008</code>}} |
||
{{#invoke:Register table|row|31:24}} |
{{#invoke:Register table|row|31:24}} |
||
| colspan="8" | U-8 |
|||
| U-? || U-? || U-? || U-? || U-? || U-? || U-? || U-? |
|||
|- |
|- |
||
| colspan="8" | — |
|||
| — || — || — || — || — || — || — || — |
|||
{{#invoke:Register table|row|23:16}} |
{{#invoke:Register table|row|23:16}} |
||
| colspan="8" | U-8 |
|||
| U-? || U-? || U-? || U-? || U-? || U-? || U-? || U-? |
|||
|- |
|- |
||
| colspan="8" | — |
|||
| — || — || — || — || — || — || — || — |
|||
{{#invoke:Register table|row|15:8}} |
{{#invoke:Register table|row|15:8}} |
||
| colspan="8" | U-8 |
|||
| U-? || U-? || U-? || U-? || U-? || U-? || U-? || U-? |
|||
|- |
|- |
||
| colspan="8" | — |
|||
| — || — || — || — || — || — || — || — |
|||
{{#invoke:Register table|row|7:0}} |
{{#invoke:Register table|row|7:0}} |
||
| U- |
| U-1 || colspan="7" | RW-7 |
||
|- |
|- |
||
| — || colspan=7| ADDRESS[6:0] |
| — || colspan=7| ADDRESS[6:0] |
||
{{#invoke:Register table|foot}} |
{{#invoke:Register table|foot}} |
||
{{#invoke:Register table|definitions |
{{#invoke:Register table|definitions |
||
| 6-0 | ADDRESS[6:0] | |
| 6-0 | ADDRESS[6:0] | Sets the span buffer word address that '''DPS_BUFTEST_DATA''' will read from or write to. |
||
}} |
}} |
||
Span buffers are 288 bytes of memory while a 7-bit word index can address up to 512 bytes; when some addresses are read/written with '''DPS_BUFTEST_DATA''' some bits are fixed to 0. The span buffer data is arrayed such that 72 bits are accessed over 4 word addresses. The data layout is shown below, the first two columns can contain color/depth/texture data while the third column can contain coverage. |
|||
<pre> |
|||
| 0 1 2 3 |
|||
----+------------------------------------ |
|||
0 | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
4 | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
8 | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
C | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
10 | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
14 | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
18 | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
1C | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
20 | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
24 | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
28 | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
2C | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
30 | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
34 | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
38 | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
3C | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
40 | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
44 | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
48 | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
4C | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
50 | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
54 | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
58 | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
5C | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
60 | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
64 | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
68 | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
6C | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
70 | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
74 | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
78 | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
7C | XXXXXXXX XXXXXXXX 000000XX 00000000 |
|||
</pre> |
|||
====<span style="display:none;">0x0410 000C - DPS_BUFTEST_DATA ==== |
====<span style="display:none;">0x0410 000C - DPS_BUFTEST_DATA ==== |
||
----{{#invoke:Register table|head|1200px|DPS_BUFTEST_DATA <code>0x0420 000C</code>}} |
----{{#invoke:Register table|head|1200px|DPS_BUFTEST_DATA <code>0x0420 000C</code>}} |
||
{{#invoke:Register table|row|31:24}} |
{{#invoke:Register table|row|31:24}} |
||
| colspan="8" | RW-8 |
|||
| RW-? || RW-? || RW-? || RW-? || RW-? || RW-? || RW-? || RW-? |
|||
|- |
|- |
||
| colspan=8|DATA[31:24] |
| colspan=8|DATA[31:24] |
||
{{#invoke:Register table|row|23:16}} |
{{#invoke:Register table|row|23:16}} |
||
| colspan="8" | RW-8 |
|||
| RW-? || RW-? || RW-? || RW-? || RW-? || RW-? || RW-? || RW-? |
|||
|- |
|- |
||
| colspan=8|DATA[23:16] |
| colspan=8|DATA[23:16] |
||
{{#invoke:Register table|row|15:8}} |
{{#invoke:Register table|row|15:8}} |
||
| colspan="8" | RW-8 |
|||
| RW-? || RW-? || RW-? || RW-? || RW-? || RW- || RW-? || RW-? |
|||
|- |
|- |
||
| colspan=8|DATA[15:0] |
| colspan=8|DATA[15:0] |
||
{{#invoke:Register table|row|7:0}} |
{{#invoke:Register table|row|7:0}} |
||
| colspan="8" | RW-8 |
|||
| RW-? || RW-? || RW-? || RW-? || RW-? || RW-? || RW-? || RW-? |
|||
|- |
|- |
||
| colspan=8|DATA[7:0] |
| colspan=8|DATA[7:0] |
||
{{#invoke:Register table|foot}} |
{{#invoke:Register table|foot}} |
||
{{#invoke:Register table|definitions |
{{#invoke:Register table|definitions |
||
| 31-0 | DATA | Reading from this register reads the span buffer data at the current '''DPS_BUFTEST_ADDR'''. Writing to this register sets the span buffer data at the current '''DPS_BUFTEST_ADDR''' to the write value. |
|||
| 31-0 | DATA | ? |
|||
}} |
}} |
||
This register requires span buffer test access to be enabled in '''DPS_TEST_MODE_REG''' to be functional. |
Revision as of 04:43, 21 March 2024
The RDP interface is the set of registers that allow to control the RDP and make it perform the required rasterization jobs.
RDP executes a stream of commands called primitives that are sent to it via DMA. The RDP interface allows to initiate and monitor the DMA transfers to RDP, and to query the current status of RDP.
DMA transfers
DMA transfers allow to send a sequence of primitives from RDRAM or DMEM to the RDP. When a DMA is triggered the RDP will start fetching the primitives in small batches within an internal command buffer, from which they will get run; the DMA will then wait for space to become available in this internal command buffer before more data can be transferred.
Primitives can be stored in either RDRAM or DMEM. Bit 0 of DP_STATUS is used to select whether RDRAM or DMEM is used. When reading data from DMEM, the RDP uses an internal bus in the RCP called XBUS, so normally "using XBUS" is a shorthand expression for "programming the RDP to fetch primitives from DMEM". Notice that both VR4300 and RSP can program the RDP to either use XBUS or not; there is no correlation between the CPU programming the RDP and the data source being used.
RDP is a highly parallel unit. There is thus no correlation between a DMA being finished and the respective primitives being finished (that is, pixels drawn into the framebuffer). Instead, the end of DMA can just be used as a signal that the RDRAM/DMEM buffer that stores the primitives can be recycled, but no further information can be deducted about the actual execution of the primitives. A few syncing primitives can be used to create syncing points in the various RDP internal parallel units; see the SYNC primitives of more information.
RDP primitives are made of one or multiple 64-bit (8 bytes) words. For this reason, RDP DMA must fetch data from an address that is 64-bit aligned: in fact, the lowest 3 bits of the DMA address register are ignored. There is no destination register: the destination is the RDP itself and its internal command buffer is not addressable in any way.
Incremental transfers
To allow the RDP to begin processing primitives as soon as they are available (that is, while the VR4300 and RSP are generating them), the RDP DMA allows for incremental transfers: in fact, the DP_END register can be updated while a DMA is in progress (or after it has finished) and the effect is that the DMA will continue running until the new end pointer is reached. This operation is totally safe and free of race conditions. The intended purpose is that the VR4300 or the RSP can continue updating the DP_END register while they add more data to the primitive buffer in RDRAM/DMEM, until it is full. At that point, they can start another transfer to switch to another buffer.
Double buffering
DMA registers are double-buffered: this means that it is possible to program a new DMA transfer while another one is in progress. A new DMA transfer in this context means starting again from another buffer: we do not consider incremental transfers described above as "new transfers".
To program a pending DMA transfer, just write to DP_START
/DP_END
a new buffer start/end address. The START_PENDING
/ END_PENDING
bits in DP_STATUS
will be set to 1, signaling that a transfer is indeed pending. New writes to DP_END
will now update the pending transfer; in other words, after a new DMA transfer is pending, it is not possible to incrementally add more primitives to the currently-running transfer.
Programming considerations
The choice between using XBUS or not is an open debate. There is no clear cut answer and it should be carefully considered depending on the expected performance implications:
- If primitives are already in RDRAM (eg: a static display list of RDP commands, read from ROM), then it is obviously more efficient to send them directly from there, without copying them first to DMEM. Libultra does not support this (in libultra, all RDP primitives are always passed through RSP as they were RSP commands first, causing a double memory bandwidth impact if they are then sent back to RDRAM for RDP DMA); in libdragon, this is supported via rdpq_exec.
- Symmetrically, short display lists of RDP commands can be already available in RSP DMEM (as part of the data segment of a RSP microcode). In this case, pushing them directly to RDP via XBUS is surely the fastest option.
- If primitives are generated by the RSP (eg: triangles at the end of a T&L pipeline), consider the following aspects:
- sending back all the primitives to RDRAM will have an impact on memory bandwidth (first, to transfer them from DMEM to RDRAM, and later from RDRAM to RDP). Memory bandwidth is often a bottleneck on N64.
- on the other hand, RDRAM allows for much larger buffers. When the buffers are small (like they typically are in DMEM), it means that the RSP could be forced to wait for the RDP to process the primitives before producing new ones (basically this is back-pressure from RDP to RSP), and in turns it could cause a back-pressure on the VR4300. Often, RDP is the slowest among the three, so a larger buffer allows for better pacing.
While preparing buffers on RDP primitives, it is useful to take advantage of incremental transfers. This is a possible algorithm:
- Prepare two buffers (in either DMEM or RDRAM).
- Get ready to send the first buffer by setting
DP_START
=DP_END
= pointer to the start of the first buffer. This will not actually transfer any byte (remember DP_END is an exclusive bound, so if you setDP_START
=DP_END
, this means "0 byte buffer"), but will setup the DMA engine as such. - Generate RDP primitives into the first buffer (assuming this is RSP, depending whether you are using XBUS or not, either just write them to DMEM, or also DMA them to RDRAM into the first buffer). Any time a new primitive is added to the buffer, write
DP_END
to point past it. This basically tells the RDP that there are more primitives to run, as soon as it is ready. - When the buffer is full, go back to point 2, switching to the next buffer. Notice that the RDP DMA on the first buffer will continue running until all primitives have been fetched, so the new buffer will be effectively pending at this point. Anyway, you can continue working on the new buffer and keep writing
DP_END
: this is totally race-free, whether the new transfer is still pending, is ongoing, or even if it is finished. - Consider that the RDP can only have one transfer pending. So anytime you write
DP_START
to switch to a new buffer, first check if another transfer is already pending (by checking if theSTART_PENDING
bit is set inDP_STATUS
). If it is pending, then you will need to wait for it. This also makes sure you don't start pushing new primitives into the first buffer again, before the previous contents have been fully consumed.
Another possible approach to push primitives into RDP is using a single buffer, and checking DP_CURRENT
to race against the DMA. The idea is using the buffer as a circular one, and have the DMA constantly trailing behind our write pointer.
- Prepare a single buffer (in either DMEM or RDRAM). Write
DP_START
=DP_END
= pointer to the start of the buffer. Notice that, as soon as the RDP accepts these register writes,DP_CURRENT
will also point there when read. - Generate RDP primitives and write them into the buffer. Any time a new primitive is written, update
DP_END
. At this point, there are no pending DMAs (START_PENDING
= 0), and in general we will have thatDP_START
<=DP_CURRENT
<=DP_END
. To visualize this, remember thatDP_CURRENT
is basically the "read pointer", whileDP_END
is our "write pointer", within the same circular buffer. - When we reach the end of the buffer, schedule a new DMA transfer on the same buffer from the beginning (so again
DP_START
=DP_END
= pointer to the start of the buffer). At this point, this second transfer will be pending (START_PENDING
= 1), but the RDP DMA will probably be still going through the buffer on the first time. So at this point we haveDP_START
<=DP_END
<DP_CURRENT
. Notice in fact that readingDP_START
andDP_END
will return the pending values (the new run on the buffer), whileDP_CURRENT
will still report the currently running transfer, and will keep going until the end of the buffer. - Keep writing primitives from the start of the buffer. This time, though, make sure that you never write past the current value of
DP_CURRENT
. If you need to write a primitive but you have reached the current value ofDP_CURRENT
, it means that you risk overwriting primitives that have not been sent to RDP yet. So in this case, you will need to throttle (wait) for a bit. - As soon as the RDP has finished going through the buffer, it will run the pending transfer and thus start from the beginning of the buffer again. After this happens (you can check it with
START_PENDING
becoming 0), you can freely go through the buffer writing primitives, without checkingDP_CURRENT
anymore. In fact, at this point we are back to the initial situation in whichDP_START
<=DP_CURRENT
<=DP_END
so it is possible to keep writing until the end of the buffer.
In general, the second algorithm is more complex and requires a bit more code to be implemented, but it allows for less throttling and more efficient use of the memory. In fact, in the first scenario, whenever we have filled the available memory (two buffers) and we throttle, we will need to wait until the RDP finishes processing the whole first buffer. In the second scenario, instead, throttling is much reduced because as soon as the RDP processes one primitive, we get room for one more primitive to write.
RDP Interface Registers
The RDP interface registers are memory mapped into the VR4300 physical address space starting from 0x0410 0000
. Normally, accesses are performed through the virtual uncached segment, so at 0xA410 0000
.
The exact same physical registers are also exposed as COP0 registers to RSP itself, and can thus be accessed using the MTC0
/ MFC0
opcodes. Since access to all registers is shared by VR4300 and RSP, special care must be taken while writing software to decide who is in charge of each different resource / feature. For instance, normally DMA operations are performed by either the CPU or the RSP only; if the software architecture requires both to issue DMA transfers, some kind of mutex protocol must be established (for instance, using either the SIG bits in the SP_STATUS
register, or the SP_SEMAPHORE
register).
VR4300 address | RSP COP0 register | Name | Description |
---|---|---|---|
0x0410 0000 | c8 | DP_START | Start address in RDRAM / DMEM for a DMA transfer of RDP primitives |
0x0410 0004 | c9 | DP_END | End address in RDRAM / DMEM for a DMA transfer of RDP primitives (exclusive bound) |
0x0410 0008 | c10 | DP_CURRENT | Current address in RDRAM / DMEM being transferred by the DMA engine |
0x0410 000C | c11 | DP_STATUS | Status register |
0x0410 0010 | c12 | ||
0x0410 0014 | c13 | ||
0x0410 0018 | c14 | ||
0x0410 001C | c15 |
The registers mirror every 0x20 bytes across the whole range 0x0410'0000
- 0x041F'FFFF
.
DP_START 0x0410 0000 (c8 )
| ||||||||
---|---|---|---|---|---|---|---|---|
31:24 | U-? | U-? | U-? | U-? | U-? | U-? | U-? | U-? |
— | — | — | — | — | — | — | — | |
23:16 | RW-? | RW-? | RW-? | RW-? | RW-? | RW-? | RW-? | RW-? |
START[23:16] | ||||||||
15:8 | RW-? | RW-? | RW-? | RW-? | RW-? | RW- | RW-? | RW-? |
START[15:0] | ||||||||
7:0 | RW-? | RW-? | RW-? | RW-? | RW-? | U-0 | U-0 | U-0 |
START[7:0] |
bit 23-0 | START[23:0]: Physical address of the start of the primitive buffer in RDRAM or DMEM. When reading, it always returns the last written value. |
Extra Details:
- START This address points to the beginning of the primitive buffer from which primitives will be fetched by the DMA. After writing this register, the address is latched into the RDP interface, and the
START_PENDING
bit inDP_STATUS
becomes 1, but no transfer is started. WritingDP_END
will actually initiate the transfer. Selection of the data source (RDRAM or DMEM) is controller by bit 0 ofDP_STATUS
. WritingDP_START
while another value is pending (START_PENDING
is 1) will update the pending value. Notice though that this is a risky operation because of races: the pending transfer could in fact start at any point, and if you write a new pending value just before or just after the transfer starts, the behavior will be totally different; in general, it is better to avoid writingDP_START
ifSTART_PENDING
is 1.
DP_END 0x0410 0004 (c9 )
| ||||||||
---|---|---|---|---|---|---|---|---|
31:24 | U-? | U-? | U-? | U-? | U-? | U-? | U-? | U-? |
— | — | — | — | — | — | — | — | |
23:16 | RW-? | RW-? | RW-? | RW-? | RW-? | RW-? | RW-? | RW-? |
END[23:16] | ||||||||
15:8 | RW-? | RW-? | RW-? | RW-? | RW-? | RW- | RW-? | RW-? |
END[15:0] | ||||||||
7:0 | RW-? | RW-? | RW-? | RW-? | RW-? | U-0 | U-0 | U-0 |
END[7:0] |
bit 23-0 | END[23:0]: Physical address of the end of the primitive buffer (in RDRAM or DMEM). When reading, it always returns the last written value. |
Extra Details:
- END This address points to the end of the primitive buffer. The address is interpreted as an exclusive bound, so it must point after the last primitive to transfer. Notice that writing
DP_START
=DP_END
is well formed, and will run a perfectly valid zero byte transfer (which can later extended via an incremental transfer).
When DP_END
is written, the RDP does the following:
- if
START_PENDING
(inDP_STATUS
) is 0, the write is considered an "incremental transfer", so the RDP DMA is programmed to continue the last transfer up to the new value ofDP_END
. This works whether the previous transfer is still running or was already finished; in both cases, the transfer is continued/restored until the newDP_END
is reached; - if
START_PENDING
(inDP_STATUS
) is 1, the behavior depends on whether a transfer is running or not:- if no transfer is running, the new transfer is started (from
DP_START
toDP_END
), andSTART_PENDING
goes back to 0. - if a transfer is in progress,
END_PENDING
is set to 1 and the new transfer remains pending and will start as soon as the current transfer is finished. Further writes toDP_END
in this state will simply update the pending transfer's end address.
- if no transfer is running, the new transfer is started (from
WARNING: do not start a DMA transfer or even process any primitive if you have previously enqueued a SYNC_FULL
primitive. There is a RDP hardware bug that makes RDP sometimes crash if any other primitive is processed while SYNC_FULL
is run. Thus, when you schedule a SYNC_FULL
(usually at the end of the frame), it must be the last scheduled primitive (DP_END
must point immediately after it), and you must wait until the RDP has processed it and got back to fully idle status (BUSY
bit goes to 0 in DP_STATUS
), before starting a new DMA transfer, even just an incremental one. It is fine to just write DP_START
though, as that doesn't start a transfer.
DP_CURRENT 0x0410 0008 (c10 )
| ||||||||
---|---|---|---|---|---|---|---|---|
31:24 | U-? | U-? | U-? | U-? | U-? | U-? | U-? | U-? |
— | — | — | — | — | — | — | — | |
23:16 | R-? | R-? | R-? | R-? | R-? | R-? | R-? | R-? |
CURRENT[23:16] | ||||||||
15:8 | R-? | R-? | R-? | R-? | R-? | R-? | R-? | R-? |
CURRENT[15:0] | ||||||||
7:0 | R-? | R-? | R-? | R-? | R-? | R-? | R-? | R-? |
CURRENT[7:0] |
bit 23-0 | CURRENT[23:0]: Read the current address being transferred by DMA. |
Extra Details:
- CURRENT This address points after the last primitive that was transferred by DMA. It is possible to monitor this register to know how far the transfer has gone. In general, it is expected that
DP_START
<=DP_CURRENT
<=DP_END
, and thus the portion of the buffer betweenDP_START
andDP_CURRENT
is free to be recycled for other uses. When a transfer is finished,DP_CURRENT
will always be equal toDP_END
. Notice that whenSTART_PENDING
orEND_PENDING
are 1, readingDP_START
andDP_END
will return the pending values, while readingDP_CURRENT
will always refer to the currently running (or last finished) transfer.
DP_STATUS 0x0410 000C (c11 ) - Read access
| ||||||||
---|---|---|---|---|---|---|---|---|
31:24 | U-? | U-? | U-? | U-? | U-? | U-? | U-? | U-? |
— | — | — | — | — | — | — | — | |
23:16 | U-? | U-? | U-? | U-? | U-? | U-? | U-? | U-? |
— | — | — | — | — | — | — | — | |
15:8 | U-? | U-? | U-? | U-? | U-? | R-? | R-? | R-? |
— | — | — | — | — | START_PENDING | END_PENDING | DMA_BUSY | |
7:0 | R-? | R-? | R-? | R-? | R-? | R-? | R-? | R-? |
READY | BUSY | PIPE_BUSY | TMEM_BUSY | START_GCLK | FLUSH | FREEZE | XBUS |
bit 10 | START_PENDING: Set if DP_START was written and the value is still pending because DP_END was not written yet, or another transfer is in progress (see DP_START and DP_END). |
bit 9 | END_PENDING: Set if DP_END was written and the value is still pending because another transfer is in progress (see DP_END) |
bit 8 | DMA_BUSY: ? |
bit 7 | READY: ? |
bit 6 | BUSY: Becomes 1 as soon as a DMA transfer starts, and stays to 1 until a SYNC_FULL primitive is run.
|
bit 5 | PIPE_BUSY: ? |
bit 4 | TMEM_BUSY: ? |
bit 3 | START_GCLK: ? |
bit 2 | FLUSH: While set, all RDP transfers in progress or started are immediately terminated |
bit 1 | FREEZE: While set, RDP will stop processing primitives |
bit 0 | XBUS: 0: DMA transfer source is XBUS; 1: DMA transfer source is DMEM |
DPC_STATUS 0x0410 000C - Write access
| ||||||||
---|---|---|---|---|---|---|---|---|
31:24 | U-? | U-? | U-? | U-? | U-? | U-? | U-? | U-? |
— | — | — | — | — | — | — | — | |
23:16 | U-? | U-? | U-? | U-? | U-? | U-? | U-? | U-? |
— | — | — | — | — | — | — | — | |
15:8 | U-? | U-? | U-? | U-? | U-? | U-? | W-? | W-? |
— | — | — | — | — | — | CLR_CLOCK | CLR_BUFFER_BUSY | |
7:0 | W-? | W-? | W-? | W-? | W-? | W-? | W-? | W-? |
CLR_PIPE_BUSY | CLR_TMEM_BUSY | SET_FLUSH | CLR_FLUSH | SET_FREEZE | CLR_FREEZE | SET_SOURCE | CLR_SOURCE |
bit 9 | CLR_CLOCK: Reset the `DP_CLOCK` to zero. |
bit 8 | CLR_BUFFER_BUSY: ? |
bit 7 | CLR_PIPE_BUSY: ? |
bit 6 | CLR_TMEM_BUSY: ? |
bit 5 | SET_FLUSH: Set the FLUSH bit to 1 |
bit 4 | CLR_FLUSH: Clear the FLUSH bit to 0 |
bit 3 | SET_FREEZE: Set the FREEZE bit to 1 |
bit 2 | CLR_FREEZE: Clear the FREEZE bit to 0 |
bit 1 | SET_XBUS: Set the XBUS bit to 1 |
bit 0 | CLR_XBUS: Clear the XBUS bit to 0 |
Extra Details:
- FREEZE During freeze, the RDP DMA engine is suspended (paused). If a transfer was ongoing, it is paused and will resume as soon as the freeze bit is reset to 0. During the freeze, it is still possible to write DP_START or DP_END, and the writes will still affect the START_PENDING / END_PENDING bits, but no transfer will be initiated.
- FLUSH While FLUSH is set, all DMA transfers are instantly terminated (flushed). Pulsing the FLUSH bit is a good way to force-reset the RDP DMA engine and make sure the RDP is ready to initiate a new transfer.
- BUSY This bit seems to refer to a more general state of RDP, which is not related to actually performing any task. When the bit is 0, the RDP is like "turned off". As long as a single primitive is sent to RDP, this bit goes to 1 and will stay there even if after that single primitive, you wait for seconds, far beyond the actual execution time of that primitive. It looks like the RDP is now "turned on". To turn it off again, the only known way is sending a SYNC_FULL. After processing a SYNC_FULL, the BUSY bit goes back to 0 again.
DP_CLOCK 0x0410 0010
| ||||||||
---|---|---|---|---|---|---|---|---|
31:24 | U-? | U-? | U-? | U-? | U-? | U-? | U-? | U-? |
— | — | — | — | — | — | — | — | |
23:16 | R-? | R-? | R-? | R-? | R-? | R-? | R-? | R-? |
CLOCK[23:16] | ||||||||
15:8 | R-? | R-? | R-? | R-? | R-? | R-? | R-? | R-? |
CLOCK[15:0] | ||||||||
7:0 | R-? | R-? | R-? | R-? | R-? | R-? | R-? | R-? |
CLOCK[7:0] |
bit 23-0 | CLOCK[23:0]: 24-bit counter running at RCP frequency |
Extra Details:
- CLOCK This register accesses a read-only 24-bit clock that runs at the RCP frequency (which is 62.5 Mhz on standard N64, and 96 Mhz on iQue). The counter starts ticking from boot and does not stop (not even if you freeze the RDP via the `FREEZE` bit in `DP_STATUS`). The only possible interaction from the CPU/RSP is to reset it to 0 by writing the `CLR_CLOCK` bit in `DP_STATUS`. Being the only counter available directly from RSP, it can be useful to perform benchmarks on it.
DPC_BUSY 0x0410 0014
| ||||||||
---|---|---|---|---|---|---|---|---|
31:24 | U-? | U-? | U-? | U-? | U-? | U-? | U-? | U-? |
— | — | — | — | — | — | — | — | |
23:16 | R-? | R-? | R-? | R-? | R-? | R-? | R-? | R-? |
BUSY[23:16] | ||||||||
15:8 | R-? | R-? | R-? | R-? | R-? | R-? | R-? | R-? |
BUSY[15:0] | ||||||||
7:0 | R-? | R-? | R-? | R-? | R-? | R-? | R-? | R-? |
BUSY[7:0] |
bit 23-0 | BUSY[23:0]: ? |
DPC_PIPE_BUSY 0x0410 0018
| ||||||||
---|---|---|---|---|---|---|---|---|
31:24 | U-? | U-? | U-? | U-? | U-? | U-? | U-? | U-? |
— | — | — | — | — | — | — | — | |
23:16 | R-? | R-? | R-? | R-? | R-? | R-? | R-? | R-? |
PIPE_BUSY[23:16] | ||||||||
15:8 | R-? | R-? | R-? | R-? | R-? | R-? | R-? | R-? |
PIPE_BUSY[15:0] | ||||||||
7:0 | R-? | R-? | R-? | R-? | R-? | R-? | R-? | R-? |
PIPE_BUSY[7:0] |
bit 23-0 | PIPE_BUSY[23:0]: ? |
DPC_TMEM_BUSY 0x0410 001C
| ||||||||
---|---|---|---|---|---|---|---|---|
31:24 | U-? | U-? | U-? | U-? | U-? | U-? | U-? | U-? |
— | — | — | — | — | — | — | — | |
23:16 | R-? | R-? | R-? | R-? | R-? | R-? | R-? | R-? |
TMEM_BUSY[23:16] | ||||||||
15:8 | R-? | R-? | R-? | R-? | R-? | R-? | R-? | R-? |
TMEM_BUSY[15:0] | ||||||||
7:0 | R-? | R-? | R-? | R-? | R-? | R-? | R-? | R-? |
TMEM_BUSY[7:0] |
bit 23-0 | TMEM_BUSY[23:0]: ? |
DPS_TBIST 0x0420 0000
| ||||||||
---|---|---|---|---|---|---|---|---|
31:24 | U-? | U-? | U-? | U-? | U-? | U-? | U-? | U-? |
— | — | — | — | — | — | — | — | |
23:16 | U-? | U-? | U-? | U-? | U-? | U-? | U-? | U-? |
— | — | — | — | — | — | — | — | |
15:8 | U-? | U-? | U-? | U-? | U-? | R-? | R-? | R-? |
— | — | — | — | — | FAIL[7:5] | |||
7:0 | R-? | R-? | R-? | R-? | R-? | RW-? | RW-? | RW-? |
FAIL[4:0] | DONE | GO | CHECK |
bit 10-3 | FAIL[7:0]: ? |
bit 2 | DONE: ? |
bit 1 | GO: ? |
bit 0 | CHECK: ? |
When Reading:
DPS_TEST_MODE 0x0420 0004
| ||||||||
---|---|---|---|---|---|---|---|---|
31:24 | U-4 | R-4 | ||||||
0 | cspan0[3:0] | |||||||
23:16 | R-4 | R-4 | ||||||
cspan1[3:0] | zspan0[3:0] | |||||||
15:8 | R-4 | U-? | U-? | U-? | U-? | |||
zspan1[3:0] | ? | ? | ? | ? | ||||
7:0 | U-? | U-? | U-? | U-? | U-? | U-? | U-? | R-1 |
1 | ? | ? | ? | ? | 1 | ? | TEST_ENABLE |
bit 31-28 | 0: Always 0? |
bit 27-24 | cspan0[3:0]: Color span counter? Increments (and potentially overflows) based on how many 16-byte segments a drawn primitive covers. |
bit 23-20 | cspan1[3:0]: Color span counter? Synced with the other counter; if the other counter has the msbit unset this one has it set and vice-versa. |
bit 19-16 | zspan0[3:0]: Depth span counter? Increments (and potentially overflows) based on how many 16-byte segments a drawn primitive covers, only when depth read or write is enabled. |
bit 15-12 | zspan1[3:0]: Depth span counter? Synced with the other counter; if the other counter has the msbit unset this one has it set and vice-versa. |
bit 7 | 1: Always 1? |
bit 2 | 1: Always 1? |
bit 0 | TEST_ENABLE: Whether span buffer testing is enabled. |
When Writing:
DPS_TEST_MODE 0x0420 0004
| ||||||||
---|---|---|---|---|---|---|---|---|
31:24 | U-? | U-? | U-? | U-? | U-? | U-? | U-? | U-? |
— | — | — | — | — | — | — | — | |
23:16 | U-? | U-? | U-? | U-? | U-? | U-? | U-? | U-? |
— | — | — | — | — | — | — | — | |
15:8 | U-? | U-? | U-? | U-? | U-? | U-? | U-? | U-? |
— | — | — | — | — | — | — | — | |
7:0 | U-? | U-? | U-? | U-? | U-? | U-? | U-? | W-1 |
— | — | — | — | — | — | — | TEST_ENABLE |
bit 0 | TEST_ENABLE: Enables span buffer test access via DPS_BUFTEST_ADDR and DPS_BUFTEST_DATA. Warning: If the span test mode is used the RDP should be idle, else the RDP may hang. |
DPS_BUFTEST_ADDR 0x0420 0008
| ||||||||
---|---|---|---|---|---|---|---|---|
31:24 | U-8 | |||||||
— | ||||||||
23:16 | U-8 | |||||||
— | ||||||||
15:8 | U-8 | |||||||
— | ||||||||
7:0 | U-1 | RW-7 | ||||||
— | ADDRESS[6:0] |
bit 6-0 | ADDRESS[6:0]: Sets the span buffer word address that DPS_BUFTEST_DATA will read from or write to. |
Span buffers are 288 bytes of memory while a 7-bit word index can address up to 512 bytes; when some addresses are read/written with DPS_BUFTEST_DATA some bits are fixed to 0. The span buffer data is arrayed such that 72 bits are accessed over 4 word addresses. The data layout is shown below, the first two columns can contain color/depth/texture data while the third column can contain coverage.
| 0 1 2 3 ----+------------------------------------ 0 | XXXXXXXX XXXXXXXX 000000XX 00000000 4 | XXXXXXXX XXXXXXXX 000000XX 00000000 8 | XXXXXXXX XXXXXXXX 000000XX 00000000 C | XXXXXXXX XXXXXXXX 000000XX 00000000 10 | XXXXXXXX XXXXXXXX 000000XX 00000000 14 | XXXXXXXX XXXXXXXX 000000XX 00000000 18 | XXXXXXXX XXXXXXXX 000000XX 00000000 1C | XXXXXXXX XXXXXXXX 000000XX 00000000 20 | XXXXXXXX XXXXXXXX 000000XX 00000000 24 | XXXXXXXX XXXXXXXX 000000XX 00000000 28 | XXXXXXXX XXXXXXXX 000000XX 00000000 2C | XXXXXXXX XXXXXXXX 000000XX 00000000 30 | XXXXXXXX XXXXXXXX 000000XX 00000000 34 | XXXXXXXX XXXXXXXX 000000XX 00000000 38 | XXXXXXXX XXXXXXXX 000000XX 00000000 3C | XXXXXXXX XXXXXXXX 000000XX 00000000 40 | XXXXXXXX XXXXXXXX 000000XX 00000000 44 | XXXXXXXX XXXXXXXX 000000XX 00000000 48 | XXXXXXXX XXXXXXXX 000000XX 00000000 4C | XXXXXXXX XXXXXXXX 000000XX 00000000 50 | XXXXXXXX XXXXXXXX 000000XX 00000000 54 | XXXXXXXX XXXXXXXX 000000XX 00000000 58 | XXXXXXXX XXXXXXXX 000000XX 00000000 5C | XXXXXXXX XXXXXXXX 000000XX 00000000 60 | XXXXXXXX XXXXXXXX 000000XX 00000000 64 | XXXXXXXX XXXXXXXX 000000XX 00000000 68 | XXXXXXXX XXXXXXXX 000000XX 00000000 6C | XXXXXXXX XXXXXXXX 000000XX 00000000 70 | XXXXXXXX XXXXXXXX 000000XX 00000000 74 | XXXXXXXX XXXXXXXX 000000XX 00000000 78 | XXXXXXXX XXXXXXXX 000000XX 00000000 7C | XXXXXXXX XXXXXXXX 000000XX 00000000
DPS_BUFTEST_DATA 0x0420 000C
| ||||||||
---|---|---|---|---|---|---|---|---|
31:24 | RW-8 | |||||||
DATA[31:24] | ||||||||
23:16 | RW-8 | |||||||
DATA[23:16] | ||||||||
15:8 | RW-8 | |||||||
DATA[15:0] | ||||||||
7:0 | RW-8 | |||||||
DATA[7:0] |
bit 31-0 | DATA: Reading from this register reads the span buffer data at the current DPS_BUFTEST_ADDR. Writing to this register sets the span buffer data at the current DPS_BUFTEST_ADDR to the write value. |
This register requires span buffer test access to be enabled in DPS_TEST_MODE_REG to be functional.