News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

Author Topic: MAME file extraction  (Read 1677 times)

Zoobuddydoo

  • Jr. Member
  • **
  • Posts: 8
    • View Profile
MAME file extraction
« on: September 30, 2015, 02:41:32 am »
Hey,

Does anyone know if any programs exist that can extract images from games run on MAME?

FAST6191

  • Hero Member
  • *****
  • Posts: 2962
    • View Profile
Re: MAME file extraction
« Reply #1 on: September 30, 2015, 05:12:06 am »
I assume you do not mean in game tile viewers and the like that most emulators will at least have a debug mode to access. MAME has some pretty good debug functionality for most boards if you get the right version of it.

Likewise I assume this is a follow on from the Ehrgeiz discussion but I will go a bit more general.

After that... most MAME games do not really have a file system to speak of so you are back in classic ROM hacking territory where everything is more or less in one big lump, assuming you have a decrypted ( https://www.youtube.com/watch?v=2q_qXGIj-jg , not necessary but very nice background to it all) ROM anyway. Fortunately for all that might be said about the likes of Mario, Zelda, Final Fantasy, Megaman and other very well documented games it would probably seem that many arcade boards have even better game documentation in some cases -- when there were only maybe 12 games released for a "system", and each may well represent the pinnacle of a series/gameplay style, it becomes far more agreeable to document each and every game. The place for said documentation, usually the MAME source code for a given board ( https://github.com/mamedev/mame/tree/704594332184de279135d29028df9dae0894acf6/src/mame/drivers ), may not quite be some what you would see on http://datacrystal.romhacking.net/wiki/Category:ROM_maps but at times it is not far off and is very valuable for those attempting to generate the equivalent sort of things seen on said link for the arcade game in question. Though in the case of Ehrgeiz it was some of the weakest documentation I have seen on that front, compare it to something like http://git.redump.net/mame/tree/src/mame/drivers/segas16a.c which is about as obscure as well.

Most of this is not worked up into a high level tool like you might see for all those games but should be able to direct you with a tile editor, hex editor or whatever else.

Zoobuddydoo

  • Jr. Member
  • **
  • Posts: 8
    • View Profile
Re: MAME file extraction
« Reply #2 on: October 01, 2015, 04:45:24 am »
...You lost me.

Is there any kind of tutorial that I could see?

As you know, I'm new, and this is all so overwhelming for me.

FAST6191

  • Hero Member
  • *****
  • Posts: 2962
    • View Profile
Re: MAME file extraction
« Reply #3 on: October 01, 2015, 08:51:43 am »
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)