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

Author Topic: Question about out what addresses correspond to what in gens rom hacking  (Read 529 times)

seraphim423

  • Jr. Member
  • **
  • Posts: 10
    • View Profile
First off I am a noob to romhacking and this community.  So I want to apologize if this is the wrong place for this question, but from the descriptions and surfing other topics this seemed like the most appropriate.

I am working on a hack of the old genesis version of Shadowrun.  I am not looking to do anything crazy, just wanted to get some things in line with 2nd generation rules and take out some of the grind. 

Right now I am working on the weapons which so far has been pretty simple.  Altering their names, ammo capacity, damage, armor penetration, and pictures is just a little bit of trial and error messing with values to get what you want. 

However some data seems tied to the actual address in the code that the weapons are described in.  What I mean is I can replace everything about a pistol with the info from say a shotgun.  It will then for all purposes penetrate armor and do damage like a shotgun, but the sound effects and skill check (its an rpg) will still go to the pistol defaults.  This also affects reload speeds and fire mode.  There seems to be no changing of variables I can do to make a pistol address behave like a shotgun address or SMG or whatever.  This is especially frustrating because I wanted to reprogram some of the pistols as other things because they included 7 pistols but only 3 SMGs/assault rifles and 2 shotguns.

Does anyone have any advice on how to go about finding where the rest of the information may be?  I'm sure there is a line of programming somewhere that says go to these addresses for pistols, these for grenades, etc.  But there is no rhyme or reason to the code.  You will have sections of code that describe how mag locks work then there will be a massive section of code that is conversation lines immediately followed by sound effect information.

Also side note: Kudos to anyone that is proficient with this stuff who figured it out from.  I am pretty comfortable with programming and this is an alien world to me.  Hind sight being 20 20 I would've started off ripping the sprites and just done a rebuild in unity or something.  But I'm knee deep in and kind of want to figure it out out of spite now.

Tony H

  • Full Member
  • ***
  • Posts: 106
    • View Profile
    • The Code Hut
I made a ton of Game Genie codes for Shadowrun.  They can be converted to ROM addresses with a Game Genie conversion program.  Here are links to all the codes I made, and hopefully you can find some useful ROM addresses...

http://codehut.gshi.org/ShadowrunGGb.txt

http://codehut.gshi.org/ShadowrunGGsam.txt

http://codehut.gshi.org/ShadowrunGGa.txt

http://codehut.gshi.org/ShadowrunGGclips.txt
The Code Hut: http://codehut.gshi.org/

Game Genie codes and ROM hacking guides

seraphim423

  • Jr. Member
  • **
  • Posts: 10
    • View Profile
Awesome, I will look at these.  Thank you so much.

seraphim423

  • Jr. Member
  • **
  • Posts: 10
    • View Profile
Okay, I am continuing this thread because I have made some progress.  I apologize in advance if I am not being very clear or my English is improper.

Using the game genie code suggestion I have discovered that ROM addressed 00015150 and 00015160 correspond to the shooting mechanics in the game. 

I am relatively confident in this because I can zero out the different bytes and the only aspect that gets "broken" is the shooting mechanic. Conversation, stores, quest points, etc all seem to work fine. 

By changing the individual bytes I can change some things, such as the rate of fire (but it applies to all weapons), change the muzzle flash, or sound.  However, the majority of the bytes if changed just "break" the game, causing it to freeze as soon as something in the game tries to use a firearm. 

Where I am running into some concern is some quick math means that using hexadecimal base there are about 1.15 x 10^77 combinations for these two lines alone. It seems like trial and error is out the window for figuring this out. 

Can anyone give me some direction a way to figure out what the individual bytes will correspond to in the shooting mechanics?  I have discovered that zeroing some of them out will only break certain weapon types, but I am not sure how to begin to tell the game that different addresses correspond to a different weapon type. 

Also if I am just going about this completely wrong or illogically, please, feel free to offer criticism. 

FAST6191

  • Hero Member
  • *****
  • Posts: 2345
    • View Profile
Brute force like that is not going to get you anywhere very fast, the numbers you yourself provide illustrating why.

When it comes to changing core mechanics like this then even if it eventually ends up as just a number then to get there you will understand how the game actually does things, which is to say assembly. You can do any number of graphical, level, text and maybe even audio hacks without a knowledge of assembly (though it will help, and some games might actually need it) but this sort of thing requires it for essentially every game*. this is why most people learning hacking will start with graphics and text, or maybe cheats, and then build and build from there.

*some games on newer systems, and a select few older ones, will use scripting languages which are easier to modify but even today they are not so common.

Assembly then.
The CPU runs instructions. It will add numbers, compare numbers, manipulate numbers, manage the system, manage its limited resources, move/jump to other areas of code... in various ways. Different CPUs do things differently, may have different capabilities, and said manipulations are very small and low level (no** nice IF [thisnicelynamedvariable] is less than [thisvalue] DO [blah] ELSE carry on with game that anybody with some general language comprehension could probably grasp the meaning of, even if they could never spot a syntax error). On top of that you also have any other chips involved likely being different, different memory layouts and more besides.

**such things may have actually never really existed for 16 bit era and older games as the games themselves were typically programmed in assembly, albeit when you are doing that you do have some things to make it nice for you.

For the the megadrive/genesis you are looking at a Motorola 68K or 68000 for the main CPU and a Z80 for the audio core. Both of those extremely popular chips in electronics/computing in general back in their day but today considerably more obscure. Fortunately this very site aims to collect documents and tools that help with this sort of thing. It is a lot of information but for the most part it is a selection of basic instructions and instruction types that are used most of the time and anything obscure you can look up.

In your case you already have some things to look at but in the general case you would have to do some work to get there first (either work back through graphics or work up through something in the game -- most of those things you mention probably correspond to changing weapons which is easy enough to do in most games).
You would then need a debugging emulator. Alas I am not so familiar with the current ones for the megadrive/genesis and what they can do so I don't know where to point you. By the way if general emulators are lacking (and megadrive/genesis debugging side of things was when I last went looking) then we tend to point people at the TAS aka tool assisted speedrun crowd as they usually develop debugging emulators for their uses and such things can be twisted to work here.

Again as you know the numbers you have a nice starting point. What you would do is set a breakpoint (probably a break on read, sometimes termed bpr but that might vary with emulator) on one of those locations (no point doing two at once if you are learning).
The emulator will pause when the game reads it.
From here you can advance one instruction at a time and figure out how the game manipulates and interprets the number. For something like this I don't imagine you will be more than about 40 instructions before you have a grasp of what is happening, and may be somewhat less than that (if it is something which happens often within a game the devs will try to keep the numbers down, indeed that it crashes for some things being an illustration of this as checking it is valid would take extra time it does not have).

Tony H

  • Full Member
  • ***
  • Posts: 106
    • View Profile
    • The Code Hut
seraphim423, I wrote a basic guide on how to use a debugger for Genesis games (Gens Tracer).  It will show you how to find useful ROM addresses, do memory traces, breakpoints, etc.  Should help with your quest...

http://codehut.gshi.org/GensTracerGuide.txt
The Code Hut: http://codehut.gshi.org/

Game Genie codes and ROM hacking guides

seraphim423

  • Jr. Member
  • **
  • Posts: 10
    • View Profile
An update to those that have helped me out.

I am still stuck on the weapons and items in the game but will keep at it. 

However, Tony H's guide on the use of Gens Tracer has helped me a lot in tackling how the game generates payouts for shadowruns.  A goal of mine was to increase monetary and karma payouts for the missions to reduce the "grind" of the game.  I have made some strong headway in figuring out the payout system.  I all but have the money side of it figured out.  just have a few odd things happening I need to figure out.  Thanks a ton for the help.

I am comfortable enough in what I have done to post an outline on the personal projects thread.  Thanks again for the help.

August 05, 2018, 04:17:18 pm - (Auto Merged - Double Posts are not allowed before 7 days.)
I am a little confused with some assembly if someone could answer a question.

I apologize if this is simple, but I am having trouble finding an answer.  I am also sleep deprived currently, so that may be adding to the issue. 

Below is some example code.

cmpi.b    #$20,d0

The way I understand this it means "compare byte 20 that is a raw hex number to the value in d0".

What would it mean if you wrote CMPI.B  #$09,$0057(A0)

is 0057 an offset?  if so does it refer to the rom or working ram?

or does the I in the CMBI bean everything is a raw number except A0.  And if that's the case why would I need the # at the beginning?

After this point there is a BNE, another BNE, and then a BEQ command.  I think this is where the game tells you if the weapon is a pistol, shotgun, or SMG.  I think this because if I put 6002 in the first BNE it makes every gun shoot like an SMG.  If I understand correctly 6002 in hex works out to mean "bypass the next 2 commands"

I am having trouble figuring out the compare part.  I also may be completely lost.  I've been studying assembly like a week and a half when I have spare time. 
« Last Edit: August 05, 2018, 04:17:18 pm by seraphim423 »