Learning PSP assembly
|
12-09-2016, 09:09 PM
Post: #16
|
|||
|
|||
RE: Learning PSP assembly
Never really pay much attention to it myself, but that's just a temporary counter of ticks registered. If you stop execution either by pressing stop or hitting a breakpoint, then this number will show how many instructions it went through(including delay slots) from the start or the previous stop. Easier to see what it counts, if you set breakpoints close one after another.
http://forums.ppsspp.org/showthread.php?tid=6594 - Custom PPSSPP Shaders! http://forums.ppsspp.org/showthread.php?tid=3590&pid=117172#pid117172 - simple CE scripts to help creating CWCheats, https://github.com/LunaMoo/PPSSPP_workarounds - CWCheat workarounds. |
|||
12-20-2016, 11:58 AM
Post: #17
|
|||
|
|||
RE: Learning PSP assembly
Usually the translation will have more text than original one. So the text file size increase, pushes the address after it forward, causing crashing when played.
For PSX game, I use TOC change to move the text file to unused sectors/LBA. For PSP, I wonder how can one solve this problem? |
|||
01-08-2017, 04:23 PM
(This post was last modified: 01-08-2017 04:23 PM by Yugisokubodai.)
Post: #18
|
|||
|
|||
RE: Learning PSP assembly
I want to track when $t1 is written with a specific value.
For example, $t1 hold an important data to me, which value is 990CD28. In this case, how do I set the breakpoint that it should snap when this value is written to $t1? |
|||
01-09-2017, 04:54 AM
Post: #19
|
|||
|
|||
RE: Learning PSP assembly
No idea about your previous problem, pretty sure it's nothing universal, can't really tell much about it as the only time I injected big translated script into a game was with Zettai Zetsumei Toshi 3 and had a tool written specially for that game which was moving all the pointers that game loaded from the script files. If you literally running out of memory you probably will have to recode things differently to make room. I would imagine most fan translations doesn't bother as they often end up having glitches related to this or choose to intentionally remove certain elements like longer descriptions or tutorials to save up some memory.
As for breakpoints through, it's easy, just add "condition" to a breakpoint like that: Code: t1==0x990CD28 http://forums.ppsspp.org/showthread.php?tid=6594 - Custom PPSSPP Shaders! http://forums.ppsspp.org/showthread.php?tid=3590&pid=117172#pid117172 - simple CE scripts to help creating CWCheats, https://github.com/LunaMoo/PPSSPP_workarounds - CWCheat workarounds. |
|||
01-09-2017, 10:43 AM
(This post was last modified: 01-09-2017 10:43 AM by Yugisokubodai.)
Post: #20
|
|||
|
|||
RE: Learning PSP assembly
For the first problem, I solved it by a simple MTE coding, which allow multi characters with a single byte.
For the second one, I just want to know how to make the emulator snap when it hit a specific value. When setting break point wethere on read/write or execute, it snap every time when the provided address is access. This can be very frustrating because many unwanted routines access the same address and many unwanted values. Therefore, I think by setting a condition can eliminate this. For example, 08A54758z_un_08a54758: addiu sp,sp,-0x10 move t1,a1 move t2,a2 As you can see, at 08a54760 the value of t1 is modified. If I set execution break point on that address, it will snap thousand of times. I just want it to snap only when the value 990CD28 is written to t1. I wonder is there a way? P/s: It's very hard to keep things tracked on the debug console. I wonder how to make the emu write log to txt file, just like Snes's Geiger like this. http://i.imgur.com/Dj2Mplg.png For the first problem, I solved it by a simple MTE coding, which allow multi characters with a single byte. For the second one, I just want to know how to make the emulator snap when it hit a specific value. When setting break point wethere on read/write or execute, it snap every time when the provided address is access. This can be very frustrating because many unwanted routines access the same address and many unwanted values. Therefore, I think by setting a condition can eliminate this. For example, 08A54758z_un_08a54758: addiu sp,sp,-0x10 move t1,a1 move t2,a2 As you can see, at 08a54760 the value of t1 is modified. If I set execution break point on that address, it will snap thousand of times. I just want it to snap only when the value 990CD28 is written to t1. I wonder is there a way? P/s: It's very hard to keep things tracked on the debug console. I wonder how to make the emu write log to txt file, just like Snes's Geiger like this. http://i.imgur.com/Dj2Mplg.png |
|||
01-09-2017, 06:03 PM
(This post was last modified: 01-09-2017 06:09 PM by LunaMoo.)
Post: #21
|
|||
|
|||
RE: Learning PSP assembly
As I wrote that above, just set a condition to the breakpoint.
When you create/edit execute breakpoints notice the two longer input fields: one is called Condition where you can set such conditions, so if you have a code like that: Code: move t1,a1 #1 Code: a1==0x990CD28 Code: t1==0x990CD28 Note that condition can't be set for memory breakpoints, only execute ones. Another field to input text there is called Log fmt where you can specify format of the text printed to the log you enter descriptions as text and registers inside {}, for example typing there a1: {a1}, t1: {t1} would print: Code: *time* *thread_name*[JIT]: Debugger\Breakpoints.cpp:320 BKP PC=*current address*: a1: *value of a1*, t1: *value of t1* If you want to print all breakpoints to a text file same as I mentioned on previous page here - just use InfoLog.bat which again is included in all nightly builds from Orphis buildbot or run it with --log=filename.txt commandline doing so will print everything to that text file instead to it's log window. Also if you don't want the log to have any other text just breakpoints, before running the game (or soon after) go to tools->dev tools->logging channels and disable everything except JIT compiler(so use toggle all, then re-activate just that), you can also switch it to "notice". Might not be worth doing since info log isn't usually that spammy and you will have to change those log settings every ppsspp restart. http://forums.ppsspp.org/showthread.php?tid=6594 - Custom PPSSPP Shaders! http://forums.ppsspp.org/showthread.php?tid=3590&pid=117172#pid117172 - simple CE scripts to help creating CWCheats, https://github.com/LunaMoo/PPSSPP_workarounds - CWCheat workarounds. |
|||
01-12-2017, 02:30 PM
Post: #22
|
|||
|
|||
RE: Learning PSP assembly
Thank you very much.
I have one question: in Mips emulator susch as Spim or Mars, syscall is executed with the corresponding value in $v0. For example, to print text string to console, $v0 must be 4. I wonder which register it is for the psp syscall? In psx, it's $t1. |
|||
01-12-2017, 05:18 PM
Post: #23
|
|||
|
|||
RE: Learning PSP assembly
For those you listed "v*" registers are simply returning function results(so if a syscall returns a value, it'll be there), "t*" registers are temporary(they get purged with syscall so if they store anything important it's to you to save it), general purpose registers.
Argument registers "a*" as their name suggests are used for function parameters, if a syscall does take any input, the data will be set or pointed to by those arguments. Most mips documents out there should list all register types and how they're used. To understand syscalls you really need SDK, however obtaining proper, updated PSP SDK is impossible, there are some outdated sdk's on the net which people usually use when they code anything for psp and for most stuff it's good enough. Sources of jpcsp and ppsspp would be the most updated thing to check, unfortunately there are still some, maybe even quite many syscalls which noone really have a clue about, info we have might be either wrong or incomplete, might also differ betweed firmware versions. PPSSPP is also handling lots of functions too fast hence poorly coded games can suffer from timing related issues that might affect virtually anything from causing crashes to variable input timing. http://forums.ppsspp.org/showthread.php?tid=6594 - Custom PPSSPP Shaders! http://forums.ppsspp.org/showthread.php?tid=3590&pid=117172#pid117172 - simple CE scripts to help creating CWCheats, https://github.com/LunaMoo/PPSSPP_workarounds - CWCheat workarounds. |
|||
01-15-2017, 12:06 AM
Post: #24
|
|||
|
|||
RE: Learning PSP assembly
Thank you for your precious information. I solved all of my problems with the current PSP project.
I have one more question: in PPSSPP, there 're functions like zz_scEiOpen.... and z_un_address,... I know that zz_sceIopen and the like are syscall function, but how about zz_un_address (for example zz_un_08a91d30)? I always see they're treated as nornal register/address because they're followed by JR or JAL. IS z_un_address the syscall functions? |
|||
01-15-2017, 05:30 AM
Post: #25
|
|||
|
|||
RE: Learning PSP assembly
Nah, syscalls are as the name suggests functions of the system, there are usually stubs for all syscalls grouped together in small functions after other code and each of those functions look alike:
Code: zz_sceKernelWakeupThread: Now we have stuff like "jal zz_sceKernelWakeupThread" which is not a syscall, but simply Jump-and-link instruction leading to the start of that small function by label. Also note that RA is just register storing return address, it's set by "link" instructions like JAL. Another fun fact, syscalls are executed from delay slot, so it's not really followed by, but it starts from "jr ra". If you never heard about it, maybe you should google for "delay slot" as it can be confusing especially with "likely" instructions like bnel where delay slot is only executed when branch is taken, it's pretty easy to understand by just observing game disassembly through. You'll never see what syscall does by looking at it's function in game, that is unless you guess by observing everything which can be impossible in many cases;p. To see what syscall exactly does as mentioned you need to check it in SDK(aka use google) or search for it in ppsspp code on github ie like this. You have no means of affecting those system functions from in-game aside from calling them and using different arguments and again not all are known/emulated, most games will show some unimplemented syscalls in the log which we have no idea about, but most of these as long as everything is ok should just return 0 and that's exactly what emulators do with them.;] As for labels, they mark the start of a function, they can be: - named after syscalls, - loaded from game's debug data if it exist(I would guess it's rare;p), - assigned by ppsspp function replacement(mostly common functions like memcopy or some trigonometry stuff etc., replaced for compatibility, so they might behave weirdly in disassembly, but it shows when they're replaced), - assigned by user who's into symbols ~ never really bother using it myself since I'm too impatient for longer projects(;p) and reasonably good memory for weird stuff like asm, right click menu in disassembly has some options for creating/renaming functions, probably best used with ini-only setting "AutoSaveSymbolMap" which set to "true" should save them, - neither of the above, will just have that generic name with address. http://forums.ppsspp.org/showthread.php?tid=6594 - Custom PPSSPP Shaders! http://forums.ppsspp.org/showthread.php?tid=3590&pid=117172#pid117172 - simple CE scripts to help creating CWCheats, https://github.com/LunaMoo/PPSSPP_workarounds - CWCheat workarounds. |
|||
« Next Oldest | Next Newest »
|