What is the feature set of the main PS1 debuggers compared to other systems or what is debugging in general?
The PS1 stuff is not as good as the likes of FCEUX but it can do a lot and looking at the three main options you have most of the normal things covered. The PS1 piped most things over 3d though, even what you think is 2d, so you are a bit more limited compared to some of the things you could do in 16 bit and older systems as well as the handhelds. Certainly nothing truly exotic though, for instance if you want to do return oriented programming on the PS1 you are probably going to have to invent it there yourself where I could probably point at something on the PC (why you would do this for the PS1 I have no idea). Indeed I would be quite surprised if you could step backwards (some emulators will store everything that happens and allow you to rewind time).
More generally debugging, at least when a ROM hacker speaks of it, is a powerful set of tools, techniques and ways of thinking that allow you to reverse engineer ROMs. For example the technique known as relative searching will often give you the data necessary to make a table for a script, however it is a shot in the dark based upon what has happened (albeit hundreds of times across time, consoles and developers as well as common programming languages being designed to do it) before and could well get you nowhere. Debugging would straight up tell you, assuming you were skilled enough at it to make it happen.
I am not sure how to proceed from there, many would go into tracing, indeed it is the impulse I have, but looking at it another way most of debugging could be viewed as tracing of some form.
Taking a step back though debugging will at the crudest level allow you to look at the memory, the registers of a CPU, the flags of a CPU.... basically everything that can be changed so as to allow the program to run, better ones will decode this in a variety of manners (disassembly, register decoding if you are looking at a purpose specific register), decode the contents of the palettes, graphics, backgrounds, audio channels...... You can also set instructions to stop when certain things happen (breakpoints) or log them. Better debuggers allow you to set more exotic breakpoints, indeed certain emulators will even interface will full programming languages (sometimes their own scripting engine, in the likes of FCEUX and Desmume it is Lua). As well as decoding, stopping and logging you can also manipulate parts of the system, this is what the final part of the debugger does, the basic stuff is memory, sound channels and registers, more advanced stuff is actually being able to write assembly code into the running game and have it work from there.
Generally viewing memory, registers and basic disassembly and tile/palette/background viewing is the first step towards being called a debugging emulator, some stop here and frankly they are not really that useful if you want to do more than make basic cheats or rip sprites. Better ones will
I tried to list most of the big features for debuggers, including all the types of breakpoints I could think of that have been used over the years, to have in
http://www.romhacking.net/forum/index.php/topic,17234.0.htmlA further tool that is very popular among hackers is called IDA which has a lot of other features as well, however it typically does not do full emulation like you might seen in an emulator so at points it is somewhat lesser. Of course full computer emulation is possible so that is used at times, likewise for emulators without debuggers, or when there are better game playing emulators than there are ones with debuggers, you can use PC debugging techniques to read them, popular cheating tools like emuhaste and artmoney being good examples of the concept being taken to an advanced/specific level.
To just cover tracing though. If you want to edit a sprite it will have to be loaded into memory, some rare systems will instead load a reference to the ROM image but either way something in the writable portion of a console will have the relevant info. You then go back to a point before it is visible on screen (in theory it could happen right at boot but in practice it does not, not being on screen and not being in memory are two different things though) and say "when this value gets written into memory stop the game and tell me". When it happens you may have got lucky and it is a direct copy from a place in the ROM, other times you might find a decompression has happened first, other times something old was copied from memory and edited a bit along the way so you get to repeat the process with the results there until you get back to the ROM. For the latter part you will have to observe what happens during a set of instructions which is why tracing, when viewed from a certain angle at least, is so encompassing.
Naturally tracing is made considerably easier by assembly knowledge, though more commonly learning to trace leads to assembly knowledge if you did not have it before, and is very powerful which is why hackers that know assembly can get on with things so well.
Topic: Playstation 1 hacking (Read 11744 times)