|QA1||I'd like to know the address of a ROM area...|
|QA2||Where does ROM stop and RAM begin?|
|QA3||DMA interrupts between RAM and RDRAM|
Q1 I'd like to know the address of a ROM area...
A1 Very detailed memory maps are given in the file /usr/include/PR/rcp.h and in the Kantan Manual, Step 1. Please review these. However, these show only physical addresses. The addresses actually required by the CPU are not physical addresses, but are virtual addresses. In the case of kseg 0, which is generally supported by the libraries, 0x8000_0000 is allotted, therefore it is 0x9000_0000.
Q2 Where does ROM end and RAM begin (or do I need to worry about that from a programming standpoint)?
A2 At first it is all ROM. During startup, a segment (at most 1MB) specified by flags BOOT in the spec file is transferred to RAM. Thereafter, reading from ROM must be managed by the game application. To put it simply, ROM is no more than a fast, small-capacity auxiliary storage device, like a CD ROM. Like past ROM, such as the SFC, the CPU does not directly direct the PC (program counter) to the ROM. As shown in the block diagram of the hardware, the CPU and ROM are completely independent, connected only by the DMA (RCP). The CPU only refers to the DRAM by a virtual address.
Q3 DMA interrupts between ROM and RDRAM
A3 The only function used while a DMA is being executed is OsPiStartDma. If there is a request to run a DMA, the message queue is used. These requests normally are processed in the order in which they were received, according to the amount of buffer in which the message queue is stored and how much can be stored there.
This has been generally stated before, but the following two types of requests can be sent. If the priority is High in OsPiStartDma, there is an interrupt at the head of the buffer so that it is processed first. If Normal has been specified, it is appended to the end of the buffer. In any case, since the DMA currently being executed cannot be stopped and interrupted, avoid doing so by allotting a great deal of storage buffer while keeping the transfer size in as small a range as possible.
Essentially, since it is faster to handle large quantities of data, it is best to transfer large quantities while booting up or when there are vast changes in the stage, and minimize processing to a certain extent while the game is processing.