"but the scripts that show up in-game and in the ram are always the original dialogue and I can't figure out why. I don't think they're being pulled from another file, but I also can't find any other spots in the GVF_DAT.bin file that have that specific dialogue text."
Simplest answer is usually the correct one. It is unlikely the text engine has some kind of parity assisted regeneration of text so princess is in all likelihood in another castle and this is some leftover file from development (they left their spreadsheet as it were), or the devs provisioned for multiple languages and copy-pasted filler. Only possibility is somehow the text that is actually used is in the file but in another encoding, compressed, encrypted or some combo of any of those. Different encoding would be rare for this sort of thing, compressed is a possibility but chances are you would have seen it already and encryption outside the PC is super rare (even more so if they left it plain like this).
If you have not tried relative search (preferably without a new line, placeholder*, markup or similar in there to trouble things) then do that.
https://www.romhacking.net/utilities/513/ being my usual choice for such toys. Not all encodings will be relative but worth a look.
*"it costs [insert value in this town] to stay here this evening"
After this then you have multiple routes before breaking out the debugger for a tracing session. As well as relative search you have other mathematical methods for guessing at an encoding (space matching, letter distribution), corruption (the ROM hacking equivalent of what does this button do?/what happens when I cut this wire?), RAM matching (compression gets in the way but sounds like you can already find text in RAM to compare to the ROM).
Tracing/assembly then.
There are three main things you do with a section of memory in classical computing (modern security can make things marginally more complex but the PSP does not really fall into that).
1) Read data on it.
2) Write data to it.
3) Execute code on it.
Guess what the three main classes of breakpoint/watchpoint are?
Break being the classical term for "stop code from running" (see pause/break on your keyboard about page up/page down).
Break on read, bpr in most debuggers, doing much as it says and halting emulation when something is read.
Break on write, bpw in most debuggers, also being obvious in that is halts emulation when an area is written to.
Break on execute, bow/bpw and a few different things depending upon the debugger, completing the trend and halting proceedings when a section of memory is visited by the CPU for instructions to do.
There are also log points/watchpoints that will not halt proceedings and instead note it all to a big list.
There are umbrella concepts like break on access (set a break on read and you can write to it all day without it saying heh, want it to break when it so much as considers its existence in any way...), and some break on execute might have special cases like run to line.
In classic consoles the cartridge is visible in memory (or maybe sections at a time are -- see bank switching, windowing and page swapping) so that makes life easier. With nice sector based optical media/desire to hold more data (32 bits is just about 4 gigs if you have nothing else happening in memory if you address it as per what you see in your hex editor) you have an intermediate step as the console/code will have to formulate a request to whatever the console uses to speak to the cartridge. For some aspects of hacking this is great, for some it is an annoying extra step with it probably being on the latter here.
Sector based is just a way to get more data addressable at the cost of sacrificing a bit of space. Instead of saying fetch these bytes you say go fetch these sectors (which might be hundreds of kilobytes/megabytes) and read accordingly, any leftover from the sector being wasted space -- heresy in the NES era, wasting hundreds of kilobytes on a PSP game and nobody will probably ever know if it does not hit memory.
I don't know the PSP UMD/whatever read protocol offhand but it is going to be the subject of something in a programming doc, emulator source code, hacking document... somewhere.
Anyway so you find some area of memory that is connected to the area you want (if you can find the text in RAM, hold it as something different with a cheat and have the game reflect this change) you are off to the races. Hopefully it is text in RAM and not having to work backwards from what it draws on screen, or button press it fetches to advance to the next one, but yeah.
The breakpoint will also include the last ? executed instructions, and you can work backwards through those seeing what changed, what happened and what goes. If those ? are not enough you repeat the process having gone back as far as you can, and then maybe again... until you land where you want. Tedious, high skill barrier in some regards (there can be, will not always be) and other words that are broadly synonymous with those but if the game does it then you literally have the steps it took where everything else in hacking is guesswork and things that have worked in the past.
Instructions. The PSP did use a somewhat unique setup compared to a lot of things used today (things looking a bit different to ARM and X86) but you still have the classical general overview.
For my money there are three classes of instruction
1) Maths. If you can do all the sorts of maths you meet on a spreadsheet/hex editor/intro to electronics course then this is that. Adding, subtracting, boolean logic, shifts, rotates... some CPUs make lack one or more features here (the GBA's ARM7TDMI for instance can't divide in CPU and you have to use alternative methods) but it is what it is.
2) Housekeeping. So you have 30 registers (don't know what the PSP has offhand but that could be a lot in some CPUs -- the NES basically has 3 you can use in general operations, possibly more like 2 for some), say 32 bits (yes bits) each. That is not a lot so you will need to shuffle things in, out, around and between them. In most setups this is the mov instruction for copying data (or sometimes memory locations or simple immediate values) into registers, push (stores register data on the stack) and pop (returns data from the stack) being the main things of the big three unless there is a dedicated memory read/write instruction (not all CPUs, instructions or assemblers will do direct memory reads/writes from any instruction) in which case big four.
3) Program flow. Adding things (which is the basis of all computing maths -- adding is adding, subtracting is a type of adding, multiplication is adding, division is adding if you go for logarithms...) and shuffling data around is fun but making decisions based upon outcomes/user input is where it is at.
If you are familiar with basic programming loops (pick a language as they will all cover it) like IF ELSE, WHILE, FOR EACH... then these get manifested as instructions and quite basic ones.
Compare and branch being the ones in most, what the PSP uses I am too bone idle to look up right now.
Anyway compare these two numbers and IF they are equal then BRANCH/Jump/goto (
https://xkcd.com/292/ ) this location ELSE (which might just mean next instruction**) do this.
If your instruction sets a number to something as a consequence (button pressed = 1 say) then you can hopefully see where WHILE comes in.
Anyway if equal, if not equal, if greater than, if lower than, if greater than or equal to... various options might well exist for you to construct programs around.
**knocking out a result of a check such that the outcome you want always happens being a popular edit -- thank you Mr save checker for telling me my edits broke the hash, ignore that and carry on as though it were good, oh look the next save in the game fixed it, thank you very much. Oh no is it really a pirated game, well ignore it and carry on. Oh am I really out of bullets, well fire anyway...
So anyway you get to pick your way up through the steps the program took with those sorts of things in mind. Something that might take a line of human text or a few lines of high level code might take an awful lot in assembly as you do have to do the "how do you eat a whole elephant? one bite at a time" approach in assembly coding.
https://www.romhacking.net/documents/361/ is for an old command line based emulator but the principles are much the same.
Art of assembly
https://www.plantation-productions.com/Webster/ and
https://stuff.pypt.lt/ggt80x86a/asm1.htm are both for the PC (
http://www.coranac.com/tonc/text/asm.htm for the GBA) and I don't really have much for the PSP and its family offhand but can be nice starts into the general concept.
