Page 1 of 1
keeping an app in RAM?
Posted: Sun Apr 23, 2006 7:54 am
by JorDy
can someone explain to me (or help me) how i can keep my programme "alive" in RAM. Im guessing it involes modifying your BIOS so you can call your function constantly. Does PS2Link stay "alive" in RAM or does it have aother method so you can capture output from your elfs?
Thanks in advance
Posted: Sun Apr 23, 2006 3:13 pm
by Drakonite
Uh.. what?
Posted: Sun Apr 23, 2006 6:48 pm
by JorDy
Um im not very good at explaining things, I want my appliction to stay alive in RAM and not be over written when i load another elf. For example
http://forums.ps2dev.org/viewtopic.php?t=5436
Moonlight modifies the bootstrap so his patching function is called all the time so it is not overwritten.
Posted: Sun Apr 23, 2006 8:42 pm
by weltall
are you asking about ps2 or psp? here is the ps2 forum.
for ps2 you need to load yourself in a lower adress (which is not normally used) and load the app you want as a thread.
for psp you need prx
Posted: Sun Apr 23, 2006 9:40 pm
by JorDy
no as a ps2 i was using the psp one as an example where here modified the boot. i want to go as high as i can what is the best area to use? and how do i load it as a thread? do you mean use loadmodule not loadexec
Posted: Sun Apr 23, 2006 9:59 pm
by Drakonite
PS2 and PSP are not even remotely the same when it comes to this.
If you look at the toolchain you'll see that by default homebrew programs are loaded at a specific address, just below that is a small piece of ram where ps2link lives, and between that and kernel memory is a tiny bit of space where loaders launch a loader core so they can safely load other programs into memory.
You can find the memory addresses, how to load there, and how to load a program as a thread all in ps2link. If you can't figure it out from there, then no offense but what you want to do is probably well above your head.
Keep in mind that the only reason ps2link can survive how it does is because of a other programs letting it. Once another program is launched you have no choice but to sit back and hope it doesn't use the memory you are in, and you have no guarentee it'll give up control and let your program do anything anymore.
Posted: Sun Apr 23, 2006 11:04 pm
by JorDy
yeah ive noticed that programs like hdloader kill ps2link so it must be over written. I know how to change were my games are loaded that is fine its just getting the right address. Do programs like cheat devices survive by loading in unused memory?
Posted: Sun Apr 23, 2006 11:07 pm
by Drakonite
We don't deal with hacking official games here.
Posted: Mon Apr 24, 2006 1:25 am
by JorDy
im not hacking official games i was wondering if that is how cheat devices are able to run throught a game
Posted: Mon Apr 24, 2006 2:49 am
by Drakonite
Really couldn't tell ya, and I doubt you'll get much of a response about it here.
Posted: Mon Apr 24, 2006 2:58 am
by JorDy
ok thanks for the help anyway
Posted: Tue Apr 25, 2006 3:53 am
by misfire
JorDy wrote:yeah ive noticed that programs like hdloader kill ps2link so it must be over written. I know how to change were my games are loaded that is fine its just getting the right address. Do programs like cheat devices survive by loading in unused memory?
Yes. This is how cheat devices work. They are loaded in unused memory space (0x80000, for instance) and hook some syscalls to "keep alive."
Posted: Wed Apr 26, 2006 3:58 am
by JorDy
but does the game not clear all memory apart from kernel used memory, this is the problem i have with one or two of my homebrew apps which kill my process by overwritting it
Posted: Wed Apr 26, 2006 4:45 am
by misfire
Nope. Calling LoadExecPS2() only wipes the user memory (0x00100000 - 0x02000000).
The kernel is located below 0x80000, so load your program at 0x80000/0xA0000/0xC0000/etc., and it will stay there.
Posted: Wed Apr 26, 2006 4:56 am
by JorDy
i see i never realsied it only wiped that range i always thought it was higher. thankyou
Posted: Wed Apr 26, 2006 6:39 am
by TyRaNiD
Of course LOADEE (which is loaded by LoadExecPS2 to start your new app) will be loaded into some part of user memory, probably 0x80000 but don't remember that for a fact so 0x80000 -> 0x90000 is probably out. Of course just cause your memory survives doesn't mean that your code will still work without effort at least if you are utilising SIFRPC stuff as EELOAD will reset the IOP and remove any IOP sides of your handlers. It will also remove threads, dmac and interrupts handlers if I remember rightly so you need to do something clever to find a way of getting your code restarted ;)
All depends what you actually want to achieve I guess.
Posted: Wed Apr 26, 2006 6:58 am
by JorDy
I had searched the forums of LoadExec and i came across all the info you just told me and a little about loadEE thats were i became stumped on the survival after everythign has been reset. well im working on it with help from misfire
Posted: Wed Apr 26, 2006 7:28 am
by misfire
I don't know where EELOAD resides, but the CodeBreaker cheat device places its cheat engine at 0x80000.
On my console I can use 0x80000 - 0x81DC0 without any problems. The memory space above seems to be used by the runtime core of my DMS3 modchip/EELOAD/or whatever.