I should really get around to trialling megadrive debuggers before long as this is not the first time I have had to say this (and I do like many megadrive games). They tend to be weaker than what is seen on other systems (if you are used to something like fceux or no$gba, never mind PC based stuff, they will be wanting) but still are big enough and ugly enough to get it done. I do however have no suggestions other than maybe see what the tool assisted speedrunners have as they will tend to have good stuff here -- if your hobby necessarily revolves around understanding how the game works at the lowest levels and manipulating it accordingly...
That looks like a basic tile, palette (CRAM = Colour RAM) and VRAM viewer along with sprite positions (object area memory being the term in many other systems/emulators/tech docs, though sprite attribute table is what the main Sega docs call it
http://techdocs.exodusemulator.com/Console/SegaMegaDrive/Documentation.html ).
In any case it is unlikely to contain any info on the original location of the sprites in the ROM -- it is no great use for the running of the system or those programming it (they would be expected to know where they left things after all). Some rare debugger or sprite ripper emulators might have something that tries to note it, though if compression is a thing that first bounces things around the RAM to decompress then that is one way to make such things tricky at best and more likely useless.
Either way once you have a debugger with breakpoint support you would presumably set a break on write to the location in the VRAM just before it gets written there (might be copied when a new level starts, might be when you press start on the title screen, might be... either way you can usually set them to update in real time, play the game a bit and wait for it to happen). If there was no compression then you might get a nice DMA (direct memory access, a way of grabbing data from one part of memory, which can include the ROM, to another without bothering the CPU) read from the source in the ROM to the destination in video memory (and you will also have any mode, palette or similar information likely also there already or coming shortly afterwards), hence why debuggers, or more correctly using them to perform a tracing session, is such a powerful method over reverse lookup*, pressing down a lot in a tile editor, corruption and all the other means. If compression is in the mix the the CPU will likely get involved to generate the final image before it gets copied to VRAM (or it might be able to operate in VRAM -- I don't know for this but newer systems and older systems I do know well tend not to be so keen on editing things here as much as copying data from elsewhere with less restrictive memory sections). It might be a fair few steps as a raw number of them but decompression it will likely be a simple loop it runs a few dozen times and before that it will have fetched it from the ROM. Some will work back up until something interesting happens, others might see if the decompression function is a small area of code (again 16 bit era compression is likely very simple in the abstract with it mostly being "is compressed then do this, is not compressed then go to next section, is end of compressed data go back to normal game" run a few dozens times) and set a new breakpoint on that (albeit break on execute this time) and hope the instructions preceding that before it first called (might want to go back a few more seconds before it is loaded) are the simple DMA to the main memory to then proceed with decompression. Also means you would have the method of decompression (might not be as quick or elegant as you can do on a PC to decompress the same data but will work) if it was unknown to you, or just a custom tweak on an otherwise known method. Once you do know one or two locations then do check to see if there is a nice magic stamp or something you could use to search the ROM in favour of that; for the GBA and DS stuff mentioned earlier then compression search tools do tend to be things that search the ROM for 10h, 11h or 40h and attempt to see if the following data, usually a size value and then compressed data, makes sense to call a potentially compressed spot so don't overlook the option to make things nice like that.
*dump the VRAM. Other than compression and weird games that edit things at runtime then most likely it will be the same data in the ROM. Search for that and up might pop the data in the ROM itself. Can also work for compression if you do a small snippet from early on in the sprite where compression is least but by no means guaranteed.
If the Huffman, RLE, LZ and whatever else stuff earlier served to confuse and you are curious (or maybe just want to know what you might see doing the decompression so as to skip it in favour of something interesting) then my usual introduction to compression in general is
https://ece.uwaterloo.ca/~ece611/LempelZiv.pdf (despite the name it does cover good stuff).
Topic: Need help finding out where compressed graphics are located (Read 1903 times)