OK so you started on PS1 stuff by the sounds of things. There you get a nice iso extraction tool and for the vast majority of games you have nice file names, file sizes, folder names, extensions... to look at. There are some exceptions (raw LBA addressing and such), as well as just the option for unhelpful names but it is still good for most things. This would be known as a filesystem and was not really seen on the home consoles that were not also a computer until the DS.
Things based around CDs and things that were not computers (think the Amiga) tended to use what is technically termed binary inclusion or incbin if you are more of a C family programmer. This means you tend to find yourself staring at one lump of code that has graphics, actual code that runs on the processor (and game consoles, especially arcades, often had one more than one type of processor), numbers that said processor code might use (think stats tables, levels and things that are not instructions), audio... There is usually some rhyme and reason as to what goes where, though it might not be simple for reasons discussed elsewhere) but nothing you can feed to ultraiso or whatever like a PS1 game. Figuring out what is what is a good chunk of what ROM hacking is, and the other half is usually figuring out how it works once you have found it. There are benefits for programmers and hackers to this, indeed there is a reason it probably stuck around into the GBA era and may even be better overall. It is what it is though and though going against the grain can get you good places it is usually far easier to go with it.
There are endless methods to do this figuring out business, some aimed at certain aspects (there is a very powerful tool called relative search that will often very quickly find you text in languages that use the Roman character set, it is pretty useless for audio though) and others far harder to pick up (assembly driven tracing for instance) but far more reliable and far more wide ranging.
First though we have to discuss pointers as they will come up time and time again. If you have ever learned a programming language it might have tried to teach you this, ROM hacking pointers are directly related to this but I reckon a bit simpler to grasp. You can make a program that runs from start to finish and the next thing is loads is the next instruction or data for it. Such programming is not really suited to a game which takes input in real time though so you will have to do certain things at certain times, maybe only once or twice an hour though. As you can not fit the whole game into memory this then gets loaded on demand and the thing that tells the game where to look is called a pointer, mainly as it points the way to something else. If you prefer a higher level example my go to one is the contents or index page in a book, which also brings me nicely to the next part of the problem. If you insert a bunch of data (or pages if you are sticking with the book) in the middle of the program then everything that follows is now however much out from what it expects, do this 50 times and it all breaks, hence the focus on fixing pointers. Assembly is basically a human readable version of the very simple instructions that a program runs and unlike basically every other programming language out there it expects you to handle the memory from the ground on up. Early games and games designed for speed would use assembly and thus if a section was to be scrapped it would not just be delete as they would also face issues with pointers. This is why stuff can end up in somewhat of a random order within it, scattered about and also why we can occasionally pull things from games that might not have made the final cut.
Back on topic though there are endless methods there are better ways to set about it. As speed is a thing you do not want your game decoding some nice XML format or something that humans can read easily and instead want it to be able to copy things directly to the graphics memory and have it work pretty much from there. This is why hardware docs get linked and people learn the hardware for a console. Some newer devices will pay this penalty, some times it does not matter (if it takes an extra second to decode the menu but allows you to put a nice TGA image in there...), and some times newer devices will in turn gain hardware support for higher level formats (the little ARM chip in your phone probably does not do well at decoding H264 video but a chip dedicated to it would probably be able to, the 360 quite notably includes WMA audio decoding hardware, newer opengl and directX do some very odd things with regards to higher level formats) but old consoles and old arcade hardware (which today will look very similar to old console hardware) will typically stick to the hardware side of things.
Equally as you are storing things on limited space (ROM chips back in the day were not cheap and if you are creating 100000 carts then an extra dollar or two is real money) and copying into memory then you also have the possibility for compression, and you may also want to prevent people from messing with things so encryption is an option, as is obfuscation.
All is not lost though as you can do things like load the whole ROM into a tile editor, set it to the mode used by the hardware in question (or one of the modes as there may well be many) and press page down a lot, and there are simple to use tools for other things (I already mentioned relative search) as well as simple techniques you can use in a hex editor (relative search does well for text, however have you ever considered why scrabble scores the way it does -- find a text section and run a frequency of bytes analysis on it and it is a good bet it will be a close match for it) and in the case of MAME then there are usually few enough games to use a given hardware type that they are all known -- there are how many hundred NES games, thousands of GBA games, even more DS games.... but 15 games and never likely to be any more you can do. With that in mind many of the MAME/MESS emulator authors, or just fans of a given hardware type, will tend to have key parts of the ROM documented. Other games do get documented (I linked http://datacrystal.romhacking.net/wiki/Category:ROM_maps
before for a reason)