ah, i wrote this up before klarth's post... but i think most of it should still be fresh. apologies if i'm wrong about this... but even the PS-EXE case can be handled and be made much more convenient using pointer search, if there are a lot of pointers that use the same high word. you'd still have to do some shenanigans for when pointers change high words, and then hand-modify the atlas scripts to include the high word/low word thing, but it would still be useful to use pointer search. obviously a custom tool would be preferable, though.
You can't define or dump it in Cartographer. You CAN add the pointer to a pointer list and dump that way.
that doesn't make any sense. if you can put it in a pointer list, you can search for it. (or did you simply mean that cartographer doesn't currently support it, but your new program will?)
Your method has limited application to absolute pointers where all bytes that make up the pointer are stored together. I'd prefer something with a more widespread application.
???? this is not limited at all. this is a very, incredibly, widespread case. in fact i would be willing to bet money that this is a more common case than when you have multiple instructions being used together in such a way as to make this method excessively inconvenient (meaning, you might as well just use single pointer dumps) or impossible (would bet money that this is would be a laughably fringe case). at the very minimum, it is very much applicable to GBA and NDS hacking, which are fairly popular systems to romhack.
(and no, as i said before, it does not have to be absolute pointers -- relative pointers are fine too. though absolute is preferred, for increased specificity due to lack of starting at 0.)
I think I am clear, but I still think it is extremely limited in application. Let's talk 'brute force'.
1. Ok, you start in the data area. You dump what's pointed to by 4-byte <String1Pointer>. Move to the next 'pointer' which is <SomeOtherCrapDataAssociatedWithTheMenuOrWhatever1>. The program won't crash on an 'invalid' pointer. However, what if this data is 1 byte long then the real pointers continue after that. You were dumping by 4-byte long pointers. The entire thing is thrown completely off on the first invalid pointer onwards unless the pointers and data are 4-byte aligned.
at least on GBA/NDS, it makes no sense to do this, as it is an incredible amount of extra work that no one would go through the effort to do, seeing as how there is no benefit whatsoever. pointers should always be word-aligned or maybe half-word aligned (for 2-byte relative pointers) depending on how the code is set up. is that sort of thing commonplace in 6502 or 65816? even so, you can still brute force it by checking for a pointer at every location instead of limiting yourself to being word-aligned.
Now 'pointer search' method.
2. I see a little more merit in this method. However, this goes back to the first paragraph where it's only going to work where the pointers are absolute
just to reiterate, no.
and bytes stored together
again just to reiterate, this is a very frequent occurrence. certainly frequent enough to merit inclusion.
but I don't see that as often on other platforms.
which other platforms? even without having any experience with anything but PC programming and GBA/NDS ASM i would again be willing to bet money that just about any 32-bit platform would find my method to be applicable, with varying degrees of specificity and convenience improvement vs. the alternatives. do you have real experience with many different platforms to be able to make this kind of statement...
Yes, that's what I'm saying. It's useful only in specific cases that aren't too common on some platforms, but more common on others. I'd rather work on something with more wide spread, flexible application.
... and more importantly, this kind of judgment? if not, what you're essentially saying is "i haven't seen much use for this on NES/SNES, so it's not worth including". which i find curious considering NES/SNES is not the only systems people are romhacking, and in fact there is ongoing discussion right now
about how there should be more documentation for hacking newer systems.
You can't search for relative pointers when you don't know what they're relative to. Games I've seen that use this have a base value they use and calculate the actual pointer by manipulating a relative pointer and adding it to the base. What is the base?
this is irrelevant. you would need to know the base to use any method at all other than RAW dumping.
What is the manipulation? It may be a shift operation, it may be more.
as long as the least significant part of the pointer is simply added to the result (which is necessarily true if the string being pointed to can start on any byte/doesn't need to be word or halfword aligned, which i suspect forms the majority of cases), this is irrelevant.
I meant the load AND the pointer bytes themselves are split. the load is across multiple instructions and the pointer bytes themselves are stored separately and combined by the instructions.
once again irrelevant, in the example you gave, because it was basically a relative pointer with offset $cb0000. if each pointer uses a different initial instruction, then yes, it would not be convenient enough to be worth using (and coincidentally enough (not), as i pointed out above, pointer lists would also be useless, unless you're keeping track of that initial instruction for each individual entry... in which case it's not really a pointer list anymore). if a lot of pointers use $cb, however, it would be very useful.
I'd much rather see a more program intelligent way to address these situations that would handle your case and some of the ones I have brought up. Off the top of my head, a pointer list generating program with some ability for patterns, wild cards, equations, and searching might be what the doctor ordered.
implementing regex or some kind of complicated parser would be very powerful indeed. however, it would be probably be a pain to do -- both on your end and the user end. much simpler, both for yourself and the user, would be to simply include pointer search and brute force. (not that you have to actually DO anything to support brute force, other than not have it crash or halt execution when it hits an invalid pointer