If someone wanted to make their own Free Play ROM modification...

modessitt

Volunteer: Encyclopedia Submission Moderator
Joined
Mar 22, 2007
Messages
33,414
Reaction score
325
Location
Austin, Texas
If someone wanted to make their own Free Play ROM modification...

What would you recommend as the things they would need to learn (as well as equipment to have) to do so? And please don't say "a six-year degree from MIT".

Let's say a favorite nephew came up to you (who know how to do this) and said, "I want to learn how to do this myself". What steps would you give them to accomplish this task?

I ask because I'd like to learn myself, and it seems nobody else wants to make any for the "crappy" games I want them for (without money).

I assume you'd need a ROM burner (got one). You'd need to know how to use some type(s) of programming code. You'd need to know how to read the code in a way to determine where to alter or add the Free Play option. You'd probably need some type of code software or compiler. Maybe some knowledge of modifying the hardware?

Can anyone give specifics? I have no problem getting books or whatever to teach myself....
 
If I wanted to hack a ROM for a specific game (which is essentially what you're trying to do here) I'd first get the datasheet or instruction manual for the processor of the game in question. Like the Z80 or 6502 for example. This way you can make sense of the assembly code for the game.

Then I would take the ROMs for the game and toss it into a disassembler. This will spit out the assembly for the game. You may want to take a peek at the mame source code to see what the address mapping looks like. Then you can identify when it's grabbing information from DIP switches, I/O and the like. Perfect thing to search for would be where the code is that samples the signal coming from the coin switches. This will lead you to the code that tracks credits and you can start to mess with the code there.

Here's a good link to get more info:
http://www.jeffsromhack.com/toolbox/index.htm
 
Yeah, it's going to be quite a lot of work with minimal benefit. Each game will take quite a bit of investigation. But yeah, if you learn assembler for those to microprocessors it will get you pretty far along the way. But the code doesn't pop out of the disassembler with comments so you will need to be pretty adept at coding.

And it's not just a matter of inserting a "jump" instruction to bypass the coin switch requirement. You are probably going to want to code it properly to say "Free Play" somewhere on the screen. And I'm guessing you will want the attract mode to continue. And there are a gazillion more things I'm sure you will need to take into consideration. But I haven't programmed assembler in years so I'm not the best person to ask.

If you really want to pay someone, you can always post an ad on Craigslist looking for the right skill set. Someone may be willing to do it who isn't necessarily an "arcade guy". Just an old electronics/programming guru.
 
After some practice all you really need is a hex editor and MAMED to step through the game.
Start by just setting breakpoints in MAMED and figuring out what the functions do. It takes a lot of time and effort so hopefully you like the games you are trying to make mods for. MAMED and the MAME driver for the game are your best friend.
 
Well, I used to know Assembly pretty good 20-some years ago, but it's been a while.

I was thinking it might have been a bit more complicated. I remember Mark once mentioning some old game programmed in "cleartext" or something like that? Wasn't sure whether the game programs were written in some old COBOL or FORTRAN or some early version of C or something.

I'd first get the datasheet or instruction manual for the processor of the game in question. Like the Z80 or 6502 for example. This way you can make sense of the assembly code for the game.

Can you elaborate on why this is important? How does the processor affect how the program is run? I guess I'm stuck in today's technology where you can have different PCs with different processors all run the same program...
 
Well, I used to know Assembly pretty good 20-some years ago, but it's been a while.

I was thinking it might have been a bit more complicated. I remember Mark once mentioning some old game programmed in "cleartext" or something like that? Wasn't sure whether the game programs were written in some old COBOL or FORTRAN or some early version of C or something.



Can you elaborate on why this is important? How does the processor affect how the program is run? I guess I'm stuck in today's technology where you can have different PCs with different processors all run the same program...

Assembly is unique to each processor family, so the data sheet will really help figuring out the registers and what the processor is capable of. I played with 8051 and Arm7 assembly in school last year, and the data sheets (books) for both came in handy. The assembly language is different too, so you need to know the different syntax for each.

I am hoping to find the time to start playing with the roms as well. Maybe after school is done. Please post your progress as you start learning.
 
Well, with different assembly types, I guess my first step is to figure out how to recognize which type is used, unless there is a program out there that can analyze a file and tell me.

Then I can try to track down a book at the library or someplace that teaches the type I need to learn.

Then I start looking at code and seeing if I can interpret what's going on.

Then I guess I find the sections I need.

Then before I make changes, I should ask someone who knows what is going on to look it over to see if they spot a mistake.

Then I figure out how to put it all back together to burn onto the ROM(s).

And hope it works...
 
It's a fairly arcane set of knowledge without much practical use in the real world. But...it can also be pretty interesting if you like that kind of thing. If you can read the code from one then you should be able to understand the code from another. But writing code is a different matter. You've got to understand the specifics of each processor as mentioned before.

I personally wouldn't have the stomach for it any more. Back in the day I enjoyed that stuff. I also enjoyed D&D back in the day but wouldn't want to go learn all that crap either. Guess I'm getting old or something but it just doesn't seem fun to me any more.
 
Mame is a great tool for this for sure. Build a debug version and look at what each instruction in the rom is doing to memory and registers. Put in some debug spew to see what memory addresses change when you hit buttons. The buttons are usually memory mapped and the program reads mmory addresses to poll what's going on with input. Use and existing ROM hack to see what is exactly happening a the point in the code where the change is by setting a breskpoint when the instruction pointer for the emulated CPU ges near that address.

You can also keep stats on where the instruction pointer is during execution so that you can know which parts of the rom are code and which are data.
 
Well, with different assembly types, I guess my first step is to figure out how to recognize which type is used, unless there is a program out there that can analyze a file and tell me.

Nah it's CPU dependent. Meaning Z80 assembly will look differently than 6502 assembly. So really all you need to know is what CPU the ROMs are for, and then grab a dissasembler for that CPU. MAWS (http://maws.mameworld.info/maws/) is a great resource for identifying what CPU ran on what system.
 
What would you recommend as the things they would need to learn (as well as equipment to have) to do so? And please don't say "a six-year degree from MIT".

Let's say a favorite nephew came up to you (who know how to do this) and said, "I want to learn how to do this myself". What steps would you give them to accomplish this task?

I'd show them an example of one I'd already done, but explain to them that there are often deviations from the "happy path" that make some more difficult than others.

The basic formula is something like this:

Look at MAME source for game for helpful info (input ports, RAM locations, player start buttons)

Using Mame, run game with trace log on.

Do it again, this time coin up the game.

Compare logs to see where code deviates.

Set breakpoints nearby and this time monitor RAM, so after crediting, note which memory locations are being incremented.

Look for code referencing the inportant information retained from MAME source.

Run MAME, tracing after coin 1 input

Run again, this time tracing after pressing player 1. Compare deviations. What gets modified in that fork should be credit data (set breakpoints to verify, watching the RAM again).

So, at this point, you're familiar with where the coinup happens, the code necessary to start the game, and the necessary memory locations to update.

Then stuff forks from here...
1) Does the game have demo mode that you want to show free play during? That's extra work
2) Does the game have battery? Need to take reseting credit count into consideration.
3) Does the game have an intermediary prompt screen ones credits are added? More stuff to deal with.

Eventually it comes down to using jumps in the code to jump over stuff you don't want to happen, jumping to custom code to handle player 1/player 2 button automatically starting the game (it's added to the main demo mode loop), finding room for that custom code, removing code that resets crediting information, maybe figuring out the text writing algorithm to put "free play" on the screen, finding logic to determine when the game is in demo mode vs game mode (you don't want your code to be executing during game mode).

Then after all that, you need to find and understand the checksum logic most games have, find a free byte to set the checksum value correctly. All of this may happen over several ROMs, each needing their checksums tweaked.

I ask because I'd like to learn myself, and it seems nobody else wants to make any for the "crappy" games I want them for (without money).

I assume you'd need a ROM burner (got one). You'd need to know how to use some type(s) of programming code. You'd need to know how to read the code in a way to determine where to alter or add the Free Play option. You'd probably need some type of code software or compiler. Maybe some knowledge of modifying the hardware?

Can anyone give specifics? I have no problem getting books or whatever to teach myself....

You'll need MAME, the source for MAME, HexEdit, CompareIt!, a Disassembler for the processor the system uses, learn all the tricks of MAME debugging, the Disassembler, etc. And learn the main commands of the processor language so you can follow along in the code while debugging, then beyond reading, being able to write small samples of the assembler to do exactly what you want, all without disturbing any variables or memory locations the game might need to run properly. Not to mention all the code studying needed above. Above all that, you might find (as I have for some games), that there's just no easy way to implement it.

It's a huge investment in time to learn to do all this. Heck, people pay $50+ for freeplay kits, it's basically the same thing, so if you have a potential monetary solution to your problem, consider taking it. If you have lots of free time on the other hand, start studying your game of choice, find some tutorials for the processor language online, download mame source and some other applications and jump in; we could use some more free play modders around here.
 
It's a fairly arcane set of knowledge without much practical use in the real world.

Bah... I actually programmed in assembly for a job... not 8-bit arcade assembly, (32-bit VLIW DSP code), but assembly none-the-less...

But...it can also be pretty interesting if you like that kind of thing. If you can read the code from one then you should be able to understand the code from another. But writing code is a different matter. You've got to understand the specifics of each processor as mentioned before.

It's far easier (for me at least) to write new assembly code than the understand what someone else was thinking when they wrote their code.... If you crack and disassemble D2K, it's glaringly obvious which code Braze wrote and which code Jeff wrote... same thing if you look at code from dervatve / bootleg games that re-use code from the original game.

There is some variation between assemblies that you can ignore when reading assembly (ie. differences in addressing modes that might change how code is written), but decoding someone else's logic is much more of a pain than getting your own stuff to work.
 
Bah... I actually programmed in assembly for a job... not 8-bit arcade assembly, (32-bit VLIW DSP code), but assembly none-the-less...

Yeah, so did I. Mine was on a VAX though. What I meant by arcane is that not many people know it any more and there isn't much call for it.

Incidentally, it's really hard for me to type the word "arcane" without accidentally typing "arcade". Just flows off the fingers.
 
Back
Top Bottom