The PS1 is slightly harder than some older systems by virtue of being both more potent hardware over the older stuff but also not as streamlined as newer, and also somewhat lacking in examples and documents to learn from. If this is the thing that will get you to learn though then don't be discouraged as more has been achieved with far less than is out there for the PS1.
A debugger will tell you the limits and mode of operation of a given format if you ask it nicely enough but it is not the only way to achieve a hack.
I usually approach using a debugger as more of a quick(er) way, as well as perhaps a more definitive way, of answering questions about a format. While every game is potentially unique if you see enough formats and approaches to the world then there are patterns, and only so many ways a developer seeking to do 1 way code in real time on a console will be able to do anything. Or if you prefer I like to play a thought exercise of "how would I do this task?".
So you have a lot of map files. Big maps, small maps, maps with no text and maps with a lot of text. You might also be able to swap maps around to see what does what. Do a compare to see roughly where you think the text will be*, possibly tweak something to see. From there you know where in the file at least part of it is.
*text also looks quite different in terms of the patterns/"feel" of the hex (rarely will more than 8 characters go by without a space, a paragraph is rarely going to be more than about 5 sentence, while Japanese has enough characters to need a 16 bit encoding most of the time there are not enough in common rotation to step outside of 3 hex digits and even then there are greater patterns with kana and whatnot, and other such linguistical tricks), especially to a map file which probably looks like more a table of locations, or is a straight representation of the final image. Generally it will be at the start or the end of the file/section for something like this rather than intermingled.
You can watch for this in memory (or a CD read) and from there figure out what the game does to decode it as the game quite literally does it in front of you, and as part of that also what part of the code is responsible for it in case you need to expand it. Graphics are nicer for this than text and music but if you can spot it in memory then you can still trace it back. This is what debugging usually entails as far as figuring out formats and where they are stashed in the ROM/ISO.
Debuggers can have different functions available to them. What constitutes a core function varies but generally you have viewers (memory, graphical, IO, live disassembly), editors (which might mean making it a cheat or playing savestate editor as not all editors will allow you to tap away in real time), and breakpoints.
Breakpoints are where the real fun starts. Break on read (often written as bpr) and break on write (bpw) are the two most common but log on read/write, break/log on access and conditionals to all of those are also options. Some will give you run to line where the code is allowed to run until it reaches a given point and then halts.
seems to have left out the debugger options from the online version of the hardware docs so I can't run through what each does here right now. Hopefully the offline version has something.https://www.romhacking.net/documents/361/
is for an old command line GBA debugger but as a worked example of following something's path through to memory it is great.