Memory map: Difference between revisions
→Physical Memory Map
No edit summary |
|||
Line 61:
|-
| rowspan="4" |PI external bus
| 0x05000000 || 0x05FFFFFF ||
Accesses here are forwarded to the [[PI|PI bus]], with the same address within the PI address space, using the "Domain 1" configuration set.
When not present, this is a [[Peripheral Interface#Open bus behavior|PI open bus]] area.
|-
| 0x06000000 || 0x07FFFFFF || N64DD IPL ROM || Contains the N64DD ROM used during boot, sometimes called IPL4. This is executed whenever the console is turned on with a N64DD connected, in place of the [[PIF-NUS#Console startup|IPL3]].
Accesses here are forwarded to the [[PI|PI bus]], with the same address within the PI address space, using the "Domain 1" configuration set.
When not present, this is a [[Peripheral Interface#Open bus behavior|PI open bus]] area.
|-
| 0x08000000 || 0x0FFFFFFF || Cartridge
Accesses here are forwarded to the [[PI|PI bus]], with the same address within the PI address space, using the "Domain 2" configuration set. This is one of the few address ranges which are in Domain 2 probably because it is common to access a SRAM with a different (slower) protocol.
When not present, this is a [[Peripheral Interface#Open bus behavior|PI open bus]] area.
|-
| 0x10000000 || 0x1FBFFFFF || [[ROM Header|Cartridge ROM]]|| The cartridges expose the ROM at this address. Normally, games will load assets and overlays via PI DMA for speed concerns, but the ROM is nonetheless memory mapped. Notice that cache accesses are not allowed here (and in all PI external bus accesses, see below for details), so while it is possible to run code directly from ROM, it will be extremely slow as it would not leverage the instruction cache.
Accesses here are forwarded to the [[PI|PI bus]], with the same address within the PI address space, using the "Domain 1" configuration set.
When not present (eg: when booting a disk-only N64DD game without a cartridge), this is a [[Peripheral Interface#Open bus behavior|PI open bus]] area.
|-
| rowspan="3" |SI external bus
Line 77 ⟶ 85:
|-
| rowspan="2" |PI external bus
| 0x1FD00000 || 0x1FFFFFFF ||
No known PI device uses this range, so it will normally be a [[Peripheral Interface#Open bus behavior|PI open bus]] area.
|-
|0x20000000
|0x7FFFFFFF
|Unused
|Accesses here are forwarded to the [[PI|PI bus]], with the same address within the PI address space, using the "Domain 1" configuration set.
No known PI device uses this range, so it will normally be a [[Peripheral Interface#Open bus behavior|PI open bus]] area.
NOTE: this range can be accessed by CPU only via TLBs or via direct 64-bit addressing, using the directly mapped, uncached segment (virtual 64-bit address: <code>0x9000_0000_nnnn_nnnn</code>).
|-
Line 88 ⟶ 99:
| 0x80000000 || 0xFFFFFFFF || Unmapped || This area is completely ignored by the RCP. Any access in this area will freeze the CPU as the RCP will ignore the read/write and the CPU will never receive a reply.
|}
== Physical Memory Map accesses ==
Line 102 ⟶ 112:
=== Range 0x0000'0000 - 0x03EF'FFFF (RDRAM memory) ===
The accesses in this area are handled by RCP via RI (Ram Interface). When the VR4300 reads or writes a location in this range, it gets stalled while the RI communicates with the RDRAM via the RAMBUS serial protocol. As soon as the read or write is finished, the VR4300 is released. Effectively, all reads and writes are synchronous (blocking) from the point of view of the VR4300, as you would expect when accessing a RAM. All access sizes work correctly: 8-bit, 16-bit, 32-bit, 64-bit.
The RDRAM area is the only ares in the memory map where the RCP supports '''cached''' accesses. This allows the VR4300 to issue the cache fills/flushes at the SysAD level to leverage the internal data and instruction cache (either via the KSEG0 directly-mapped segment, or through a TLB configured with the cache setting). Instead cache requests are ignored for all the other address ranges, and they will thus freeze the CPU requiring a hard reset.
=== Range 0x03F0'0000 - 0x03FF'FFFF (RDRAM registers) ===
Line 109 ⟶ 121:
The accesses in this area are handled by RCP itself without going to an external bus, and are dispatched internally to the correct subsystem. Access to a register might optionally stall the VR4300 if the subsystem is designed to do so (eg: to perform a long blocking operation on write), but in general for standard registers, they are quite fast and take only 5-6 PClock cycles (MI regs are a bit faster and take about 2 cycles).
Accesses in this area are affected by a simplified hardware implementation of the RCP SysAD bus, so '''''access size is ignored'''''. Only uncached accesses are allowed; cached accesses will be ignored by RCP causing a VR4300 freeze, requiring a hard reboot. This means that:
* Reads: RCP will ignore the requested access size and will just put the requested 32-bit word on the bus. Luckily, this is the correct behavior for 8-bit and 16-bit accesses (as explained above), so the VR4300 will be able to extract the correct portion. 64-bit reads instead will completely freeze the VR4300 (and thus the whole console), because it will stall waiting for the second word to appear on the bus that the RCP will never put.
Line 120 ⟶ 132:
All accesses made by the VR4300 in these ranges are forward externally by RCP on the external PI bus. This allows the CPU to access external devices connected to the parallel bus like the cartridge ROM and SRAM.
Accesses in this area are affected by the same simplified SysAD implementation described above, so '''access size is ignored.''' Only uncached accesses are allowed; cached accesses will be ignored by RCP causing a VR4300 freeze, requiring a hard reboot. The effect is the same described before.
Moreover, there are two important additional details:
| |||