+  RHDN Forum Archive
|-+  Romhacking
| |-+  ROM Hacking Discussion
| | |-+  How does one figure out which assembly language games are written in?
Pages: 1 [2]
Author Topic: How does one figure out which assembly language games are written in?  (Read 2 times)
KaioShin
Guest
« Reply #15 on: March 30, 2008, 12:38:46 pm »

There are big misconceptions here. Read the documents in the getting started section one by one, until you truly understand them. Move on to more complex documents on topics you're interested in then. Most of your questions will answer themselves. You're entangling yourself in a huge string of what-ifs and how-to questions without a real clue.

That's really all the advice I can give you at this point, your questions aren't leading you anywhere.

Mednafen
Guest
« Reply #16 on: March 31, 2008, 10:02:55 am »

PC-FX graphics can be in the following formats(hopefully I'm not forgetting something, although I did leave out some of the more exotic possibilities that games probably don't use):

KING:
4-color bitmap mode
16-color bitmap mode
256-color bitmap mode
64K-color bitmap mode(16-bit YCbCr, 8 bits per Y, 4 bits per Cb and Cr each)
16M-color bitmap mode(24-bit YCbCr, 32-bits per 2 pixels)

4-color tile mode
16-color tile mode
256-color tile mode
64K-color tile mode(...)
16M-color tile mode(...)

VDC:

16-color BG mode(same as PCE)
16-color sprite mode(same as PCE)
240-color chained mode(in either BG or sprite format, or both combined)

RAINBOW:
16-color RLE
32-color RLE
64-color RLE
128-color RLE
JPEG-like

The PC-FX is really not a good system for you to learn how to modify/hack/translate games on, unless you want to be totally overwhelmed.  Learn something simpler first, even if it's not directly related to what you ultimately want to do.
HyperHacker
Guest
« Reply #17 on: March 31, 2008, 02:21:44 pm »

I suggest the Game Boy to start with, it's a very nice system. People recommend NES too, I haven't worked with it a lot so I couldn't tell you much about it, though personally the lack of such simple instructions like an unconditional branch makes me shudder.
Quote from: Ryusui on March 29, 2008, 07:18:27 pm
Quote from: Spikeman on March 29, 2008, 06:21:49 pm
Quote from: McKnight on March 29, 2008, 03:08:00 pm
From my experiences, these things are only accessible through decompression, which requires the use of an assembly tool.  But since I wouldn't be changing any of the games' physics by doing these things, will I still run into any of the aforementioned problems?

Most likely yes. In my experience I have to do a bit of code relocation in all but the most minuscule hacks (such as changing the hard-coded width of a sprite). Once you've done it a few times it will be easy as cake. My general technique is this:

1) Find some free space in the ROM. Say I found some at 1234 that is big enough to fit my code.
2) Change an instruction of the original routine to JMP 1234.
3) At the end of my routine at 1234 it will jump back.

More simply, you can use JSR/JSL to jump, and RTS/RTL to return. That way you can run the same code from multiple locations, since the return isn't tied to the original code location (though this may not always be an option).
This depends on the instruction set. There are two different ways to implement JSR/RTS:
1) Push PC and Pop PC. JSR pushes the return address onto the stack, RTS pops an address from the stack and jumps to it. Most older CPUs such as Z80 and 6502/65816 use this.
2) PC -> Register and Register -> PC. Typically there's a register designated for this purpose called LR or RA. JSR copies the return address into RA, RTS jumps to the address in RA. Most newer CPUs such as R4300 and ARM use this.

If the CPU in question uses method 2, it may not be safe to arbitrarily insert JSRs into a routine, since you will overwrite what's in RA already. Routines that don't already have a JSR in them typically rely on this not being changed and don't back it up. You can back it up yourself before your new JSR, but it's often easier to just use an explicit jump to your new routine and jump back again.
Pages: 1 [2]  


Powered by SMF 1.1.4 | SMF © 2006-2007, Simple Machines LLC