Memory management in PSX

[Vision_Thing]

Hello!

I am writing a general purpose emulator for MIPS R3000A platforms and started writing a PSX emulator with it to show what it's features. But the memory organization of the PSX just doesn't add up...

http://www.futureworlds.it/~quequero/psx/tute/faq.html says "The CPU for this console is a modified r3000 (see www.sgi.com and www.idt.com for more details) which runs at 33Mhz, it has a stripped down MMU which (among other things) means that the memory addresses are hard wired: the logical addresses 0x00xxxxxx, 0xA0xxxxxx, 0x80xxxxxx all point to the same physical memory (the difference lies in caching etc.).".
Does this mean that the TLB is *bypassed* for kuseg addresses (msb 000), and handled similarly to kseg0 and kseg1 (ie no pageing and address ANDed with 0x1FFFFFFF)?

Also, how are kseg2 accesses (msb 11) handled; are they paged etc? I tried to boot from the PSX boot ROM and there is an access to 0xFFFE0130... Now, there doesn't seem to be any I/O-mapped device at that location and the address is out of range to be a physical access (even when 3 msbs removed), so the only solutions I can see are either pageing (for kseg2), or wrapping around. But the exception vector in the boot ROM doesn't contain any meaningful code for filling the TLB so I suppose these addresses aren't paged either... or?

Thanks in advance for answers,
Tommi

[zenogais]

Originally Posted by Vision_Thing

Hello!

I am writing a general purpose emulator for MIPS R3000A platforms and started writing a PSX emulator with it to show what it's features. But the memory organization of the PSX just doesn't add up...

http://www.futureworlds.it/~quequero/psx/tute/faq.html says "The CPU for this console is a modified r3000 (see www.sgi.com and www.idt.com for more details) which runs at 33Mhz, it has a stripped down MMU which (among other things) means that the memory addresses are hard wired: the logical addresses 0x00xxxxxx, 0xA0xxxxxx, 0x80xxxxxx all point to the same physical memory (the difference lies in caching etc.).".
Does this mean that the TLB is *bypassed* for kuseg addresses (msb 000), and handled similarly to kseg0 and kseg1 (ie no pageing and address ANDed with 0x1FFFFFFF)?

Also, how are kseg2 accesses (msb 11) handled; are they paged etc? I tried to boot from the PSX boot ROM and there is an access to 0xFFFE0130... Now, there doesn't seem to be any I/O-mapped device at that location and the address is out of range to be a physical access (even when 3 msbs removed), so the only solutions I can see are either pageing (for kseg2), or wrapping around. But the exception vector in the boot ROM doesn't contain any meaningful code for filling the TLB so I suppose these addresses aren't paged either... or?

Thanks in advance for answers,
Tommi

The PSX uses the virutal memory technique and thats why those locations all point to same memory addresses. Also I don't know why there would be an access to 0xFFFE0130. Here's some links to some helpful sites that might be worth a read:

http://psx.rules.org/psxrul2.shtml
http://www.runix.ru/html/Documentation%20kit/
PSX Documentation Project

Hope this helps, If you find the answer your looking for please post it in this topic because I would love to find out as well.

__________________
-----------------
Emu Tinkerer and C++ Programmer

[zenogais]

Firstly, I'd like to apologize for bringing up a dead topic, but I just wanted to answer the question thorougly this time around. Firstly, the playstation as you probably already know has two coprocessors cop0 and cop2, cop1 would have been an FPU but none was included with any version of the PSX. Now the "System Control CoProcessor" or cop1, is used to handle memory reads/writes through a system known as virtual memory, meaning that the original 2 MBs of RAM are mirrored twice from kuseg over kseg0 and kseg1. The difference between the two segments is that kseg0 is cached, while kseg1 is not.

Now the virtual memory caching and access is managed through a "Translation Lookaside Buffer" or TLB. The TLB is used to translate the virtual address into their physical equivalent and to throw a "TLB Miss" exception when an invalid memory space access is attempted, now virtual memory access are handled using a "Virtual Page Number" or VPN. The 3 most-significant bits (MSB) of the page number indicate which virtual page the user is attempting to write to, the three MSBs are as follows:

• kuseg - MSB: 0xx [in decimal form that would be 0-3] Actual RAM
• kseg0 - MSB: 100 [in decimal form that would be 4] paged RAM cached
• kseg1 - MSB: 101 [in decimal form that would be 5] paged RAM uncached

Now I'm not sure whether or not the TLB is bypassed for calls outside of paged memory, but according to Xeven (author of PSXeven) in another thread the Playstation contains "a stripped MMU", meaning that the TLB may not even be used by the Playstation at all. Now I still haven't managed to verify this information, but if thats true then the only reason for CoProcessor0 to still be around would be for exception handling purposes. Its funny now though, because Xeven used a similar example to the one you gave above stating than an access to an obviously invalid address such as 0xFFFE0130 has a very specific purpose, such as cache flusing, which would make perfect sense in the context for which you described. At the startup of the Playstation the caches are in a random state thus meaning that any attempt to read cached data would have unpredictable results, thus whatever bootup code is being loaded most certainly would need to flush all the caches it needed to use , Probably the Instruction Cache and the Data Cache. Now according to the official MIPS R30xx family doc ( http://decstation.unix-ag.org/docs/ic_docs/3467.pdf ), the caches would first need to be isolated, and then systematically flushed. This is probably what that bit of code does, and that MIPS document should help you alot. Hopefully I've finally answered your question.

EDIT: Look further into it you'll find that 0xFFFE0130 falls into the kseg2 memory space. This is the area of memory that can only be accessed while in kernel mode. This memory commonly contains resources such as page tables and the like. Well I'm not sure this is true for the Playstations R3K cpu, it would appear to be so.

__________________
-----------------
Emu Tinkerer and C++ Programmer

---

Last edited by zenogais; August 6th, 2004 at 08:04..

[André Ventura]

I think that the CPU is derived from a base version of the MIPS architecture.
So, it don't have a TLB.

It seems to use an direct mapped memory, where the main memory is divided by 65356 sizes sub-segments, for all main segments KUSEG, KSEG0 and 1.

The ROM is sub-segmented too, but i miss the sizes of them.

Its seems to be not so simple, like in the native MIPS base versions.

[zenogais]

Originally Posted by André Ventura

I think that the CPU is derived from a base version of the MIPS architecture.
So, it don't have a TLB.

It seems to use an direct mapped memory, where the main memory is divided by 65356 sizes sub-segments, for all main segments KUSEG, KSEG0 and 1.

The ROM is sub-segmented too, but i miss the sizes of them.

Its seems to be not so simple, like in the native MIPS base versions.

You're correct in assuming that it is a "base version" of the MIPS R30xx Architecture. You're also correct in assuming that it doesn't have a TLB. Basically the PSX uses the R3000A CPU with, as Xeven stated, a "stripped MMU". The only instruction from the CoProcessor0 that appears to be executable is the Return From Exception(RFE) instruction. Meaning that the MMU of the PSX is designed only to handle exceptional conditions and nothing more.

__________________
-----------------
Emu Tinkerer and C++ Programmer