Page 1 of 1
Some questions about the ps2 memory
Posted: Fri Sep 17, 2004 12:16 pm
by tumnes
I am not exactly sure where this belongs on the forums but this seems like the best spot. I found some information about what gets loaded into memory where on this web page
http://ps2dev.org/kb.x?T=457. I was wondering if anyone could clarify a couple questions I have.
1) It says that .elf executables are loaded at 0x200000. Is the exact place where any program loaded to from cd by being specified in the system.cnf file?
2) Is all the memory from 0x200000 to 0x2000000 free except the part that contains the program that has been loaded?
3) Is it correct that anything from 0x0 to 0x200000 is stuff that you would not want to write over?
4) It mentions something about a compressed bios in a memory address that is far past 32mb, how is this possible?
I am curious about all this because I want to understand more about how it all works. If anyone has any answers to any of my questions please feel free to respond. Thanks in advance[/url]
Posted: Fri Sep 17, 2004 1:26 pm
by ooPo
1) ELF files are loaded according to the addresses in the ELF header. Google for more info...
2) Its all yours... go wild! Although typically if you use a malloc function, like in ps2sdk, you won't have to worry about those details. So you can go a bit less wild, but still wild. Ish.
3) If you're loading things using something like ps2link, or ps2menu, it is generally located in this memory area. Even if you're not, its a good idea to leave a bit of space in case you want to do so later on...
4) Although there is only 32MB of physical memory, there are other things mapped into memory locations above this. Mostly things like registers to control other devices (dmac, gif, etc) or 'exotic' extra memory (scratchpad ram, or even access IOP memory). For ease of use it is presented like ordinary ram so you don't have to do anything special but write to it to do things.
Anything else?
Changing an Elf Starting Address
Posted: Fri Sep 17, 2004 1:37 pm
by tumnes
Thank you for the response, it has been very helpful. I think now I will take a look at the elf file format reference at
www.x86.org
[edit]
One more quick question. I'm pretty sure with win32 binaries that the machine code depends on the starting address. Is it correct to assume that changing the correct item in the ELF header to specify the starting location would only cause the machine code to not work as expected? In other words, I probably have to use the compiler to somehow change the start address if i wanted. That or implement virtual memory.
Posted: Fri Sep 17, 2004 11:43 pm
by ooPo
For the most part you would have to do it in the linking stage instead of just changing the header. I believe you could also use 'position-independant code (PIC)' when you link and be able to just change it in the header later. I really haven't played with that at all though...
Posted: Tue Sep 21, 2004 7:54 pm
by teaeg
ooPo wrote:
4) Although there is only 32MB of physical memory, there are other things mapped into memory locations above this. Mostly things like registers to control other devices (dmac, gif, etc) or 'exotic' extra memory (scratchpad ram, or even access IOP memory). For ease of use it is presented like ordinary ram so you don't have to do anything special but write to it to do things.
Anything else?
Another PS2 memory--related question to pros: Where in the EE memory is the range corresponding to the IOP's 2Mb ram? And are there any restrictions on its use?
Regards, teaeg
Posted: Tue Sep 21, 2004 9:25 pm
by pixel
teaeg wrote:Another PS2 memory--related question to pros: Where in the EE memory is the range corresponding to the IOP's 2Mb ram? And are there any restrictions on its use?
Regards, teaeg
From mrbrown's sbv.h:
Code: Select all
/* IOP RAM is mysteriously mapped into EE HW space at this address. I first
noticed it was used by SCE in the PS2/Linux kernel, where it's used in the
USB core driver. It's also used in a few places in the EE kernel.
I'm not exactly sure how the mapping looks to the bus, reads and writes to
it are extremely fast, and data width hasn't been a problem for me yet (so
you can use memcpy(), and obviously 16-byte reads and writes work). */
#define SUB_VIRT_MEM 0xbc000000