MIPS Interface: Difference between revisions

Minor formatting fixes
(Document what MI_MODE actually does.)
(Minor formatting fixes)
Line 76:
}}
 
'''MI's ModesMode:'''
 
The mode controls how 32bit SysAD bus transfers are mapped onto DBus and EBus.
 
RI only uses 64bit aligned reads/writes when accessing RDRAM. For operations smaller than 64bits, the data needs to be shifted into the correct bytes of DBUS. When writing, the Rambus device will use the lower 3 bits of the address and byte count as a byte mask. When reading, all 64bits are returned and the receiving device will need to implement its own byte masking. The VR4300's pipeline already shifts smaller loads/stores into the correct part of the 64bit double word and implements byte masking for loads, but because 8bit/16bit/32bit operations only result in 32bits of data being transferred across SysAD bus, MI still needs to shift each 32bit word into the correct half of DBus.
 
These modes impact all reads and writesaccess to the RDRAM address range, bothnot regularjust memory andRambus registers, but actual memory too. Reads and Writes to other RCP registers and MMIO (like SI, PI or RSP DMEM/IMEM) are unaffected, as that data goes over CBus.
The VR4300's pipeline already shifts smaller memory operations into the correct part of the 64bit double word and implements byte masking for reads, but because 8bit/16bit/32bit operations only result in 32bits of data being transferred across SysAD bus, MI needs to shift each 32bit word into the correct half of DBus.
 
: '''Normal mode:''' MIWhen wordall special mode bits are disabled, MI maps words onto the DBus as expected. 32bit words are shifted into the upper or low half of the 64bits depending on Addr[2] and any "critical word first" rules.<Br> EBus appears to default to the sign extension of each byte (further testing needed)
These modes impact all reads and writes to the RDRAM address range, both regular memory and registers. Reads and Writes to other RCP registers and MMIO (like SI, PI or RSP DMEM/IMEM) are unaffected, as that data goes over CBus.
 
: '''Upper mode:''' 32bit transfers are always shifted into the upper half of the 64bit bus.<Br> This mode is labeled as '''"RDRAM register mode"''' in some documentation and is useful for accessing registers on Rambus devices. The Rambus Rreg, Wreg, and WregB commands are hardcoded to ignore the count field of request packets and always do a 32bit transfers. When misinterpreting the RI's 8 byte transfer, the Rambus device always takes the first 4 bytes (which are the upper 32bits of DBus, because RCP is big endian) and ignores the next 4 bytes. Normal mode should produce correct results for registers at even offsets, but you need switch MI into Upper mode to correctly access odd registers.
: '''Normal mode:''' MI word maps onto the DBus as expected. 32bit words are shifted into the upper or low half of the 64bits depending on Addr[2] and any critical word first rules. EBus appears to default to the sign extension of each byte (further testing needed)
 
: '''EBus modę:''' The lower 4 bits of the 32bit word are mapped onto 4 bits of EBus.<Br>In typical operation, EBus is used by RDP and VI to access the extra 9th bit (aka parity/error bit) that RDRAM provides for each byte. This mode allows the CPU to read this extra information back.<Br> Unfortunately this mode doesn't appear to be useful for writing to AAAntialiased framebuffers, as thereyou isncan't a way to combine a normal mode write and a EBus mode write without overwriting each other. (Future testing required, maybe 64bit transfers work?)
: '''Upper mode:''' 32bit transfers are always shifted into the upper half of the 64bit bus.<Br>
This mode is labeled as '''"RDRAM register mode"''' in some documentation and is useful for accessing registers on Rambus devices. The Rambus Rreg, Wreg, and WregB commands are hardcoded to ignore the count field of request packets and always do a 32bit transfers. When misinterpreting the RI's 8 byte transfer, the Rambus device always takes the first 4 bytes (which are the upper 32bits of DBus, because RCP is big endian) and ignores the next 4 bytes. Normal mode should produce correct results for registers at even offsets, but you need switch MI into Upper mode to correctly access odd registers.
 
: '''EBus modę:''' The lower 4 bits of the 32bit word are mapped onto 4 bits of EBus.<Br>
In typical operation, EBus is used by RDP and VI to access the extra 9th bit (aka parity/error bit) that RDRAM provides for each byte. This mode allows the CPU to read this extra information back.<Br> Unfortunately this doesn't appear to be useful for writing to AA framebuffers, as there isn't a way to combine a normal mode write and a EBus mode write without overwriting each other.
 
: '''Repeat Mode:''' 32bit writes result in <code>RepeatCount + 1</code> bytes being written, with the same 32bit word repeating every 32bits. Reading with this mode causes a hang. <br>In this mode, MI duplicates the 32bit word into both the upper and lower half of DBUS, and then lies to RI about the transfer count. Instead of 4, it sends ```RepeatCount```. The full Count is inserted into the Rambus request packet and the Rambus device uses the lower 3 bits for byte masking. RI looks at RepeatCount[6:3] to calculate the number 64bit transfers.
 
: '''Repeat Mode:''' 32bit writes result in <code>RepeatCount + 1</code> bytes being written, with the same 32bit word repeating every 32bits. Reading with this mode causescan cause a hang. <br>In this mode, MI duplicates the 32bit word into both the upper and lower half of DBUS, and then lies to RI about the transfer count. Instead of 4, it sends ```RepeatCount```. The full Count is inserted into the Rambus request packet and the Rambus device uses the lower 3 bits for byte masking. RI looks at RepeatCount[6:3] to calculate the number 64bit transfers.
: This mode is labeled as '''"Init Mode"''' in some documentation. It's only used once during IPL3's RDRAM initialization to do a broadcast write to the '''Delay''' register. This is needed because after reset, the default timings in the '''Delay''' register result in the Rambus device sampling the data from the Rambus way too late and sampling garbage data. RI's timings are baked into hardware and can't be changed, but IPL3 uses a clever trick:<Br>
By enabling Repeat Mode and setting RepeatCount to 15, the 32bit value is repeated 4 times, and the Rambus device now samples thevalid data we need to write into the '''Delay''' register. However, the default timings aren't off by an integer multiple of the RCP clock, soand the Rambus device actuallysamples halfway between two repetitions of the 32bit word. SoTo IPL3work takesaround thethis, additional step ofIPL3 rotatingrotates the value by 16 bits before writing.
 
 
22

edits