Forums

Sega Master System / Mark III / Game Gear
SG-1000 / SC-3000 / SF-7000 / OMV
Home - Forums - Games - Scans - Maps - Cheats - Credits
Music - Videos - Development - Hacks - Translations - Homebrew

View topic - Hacking Shinobi for the Sega Master System

Reply to topic
Author Message
  • Joined: 01 Apr 2005
  • Posts: 250
  • Location: Almere, The Netherlands
Reply with quote
Hacking Shinobi for the Sega Master System
Post Posted: Fri Apr 01, 2005 3:53 pm
rom hacking "master system"

I'd like to hack the Shinobi ROM for the Master System.

For instance now, in level one, let's say at a certain point one enemy walks toward you.
I'd like to modify the ROM so that instead of just one, two enemies walk toward you.
The challenge will be higher.I don't want to alter the game too much. I only want a little more action.

Who can help me in the right direction?
Is this doable?
Who has experience in hacking Master system roms?

I hope that this type of alteration can be accomplished.
Once I can get this done I might be so pleased that I'll start altering more.
Maybe toss around a few colors. Change the main sprite a little bit. Change the badies a bit.

I know that reprogramming the rom to have a 'new' level will be very challenging.
I do not have the realistic ambition to want to accomplish this.

Shinobi SMS is a beautiful game. The playability is very good and the conversion is done with style and class.


As a note though I'd like to mention that I have read somewhere that the arcade rom has a level in the code that isn't used in the game. It is probably a (secret) level that never got finished.Perhaps one day I can reprogram the arcade rom so it does have that extra level. In the future new tools will be available as well.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 19 Oct 1999
  • Posts: 14690
  • Location: London
Reply with quote
Post Posted: Fri Apr 01, 2005 4:18 pm
Somewhere in the ROM, the level data will be stored; it will reference the makeup of the level, possibly including everything in one table, possibly having several overlaid tables, perhaps one for graphics, one for structure, one for enemies. The unified table would seem to be more likely.

This level data will have to be compressed in some way. It will be in a format specific to this game only, but the compression is likely to some form of RLE. The format can either be decoded by disassembling the game code, or (if you can isolate a particular level's data and compare it to the game) figured out manually. This was done for Teddy Boy, for example, but Shinobi is a much more complicated game.

The level data may be stored in the form of macro-blocks - values which are looked up in a table which references larger level elements. The Sonic level structures are often like this, storing the level data at several scales to aid compression while giving good detail.

Once you can decompress and interpret level data, you can go the other way. You should be able to add an enemy starting point easily enough. The hard part may be re-inserting it because more complex data will tend to compress to a larger size. Hacking the rom to be larger is possible, but hard.

You will almost certainly need to automate the process by making some sort of graphical level editor. If you don't have the ability to do that then your project will almost certainly fail. You're also going to need a talented hacker to find the level data in the first place; if that's not you then again you're going to have difficulty.

I would, however, warn that level design is a lot harder than it may seem. An amateur will tend to create rather poorly balanced levels that are frustrating to play, or are far too easy, or which do not have a coherent theme. Just adding more enemies will not make it more fun.
  View user's profile Send private message Visit poster's website
daniel
  • Guest
Reply with quote
Shinobi
Post Posted: Fri Apr 01, 2005 8:38 pm
Dear Maxim,

You rule.
You write such clear responses.
I'll try and see if I can isolate some code segments.
My gut tells me that this game is programmed in such a way that any hacking will be very difficult. Especially by me.
I'll get cracking and posts updates on my findings.
Perhaps they can help others (read: inspire)

Thank you very very much for the prompt and clear reply.
 
  • Site Admin
  • Joined: 25 Oct 1999
  • Posts: 2029
  • Location: Monterey, California
Reply with quote
Re: Shinobi
Post Posted: Fri Apr 01, 2005 8:58 pm
daniel wrote
Dear Maxim,

You rule.
You write such clear responses.
I'll try and see if I can isolate some code segments.
My gut tells me that this game is programmed in such a way that any hacking will be very difficult. Especially by me.
I'll get cracking and posts updates on my findings.
Perhaps they can help others (read: inspire)

Thank you very very much for the prompt and clear reply.


Technical questions aside, since Maxim covered it already, I always found that there were a couple gameplay elements in the SMS version Shinobi that struck me as backwards:

- Melee Weapons. I really never understood why they didn't use the upgrade system for the projectile weapons with melee weapons. Once you have a nunchaku, there's no reason to go back to sword, and once you have the chain, there's no reason to go back to nunchaku. The recoil time is the same and the chain and nunchaku just have ange increases and more power. I always thought the hostages should give melee weapon upgrades instead of just replacing it. It gets to the point where you want to avoid rescuing hostages so you don't get your chain downgraded to a sword. And not rescuing hostages just seems sort of odd.

-Projectile Weapons. Unlike Melee weapons, where the better weapons completely phase out the lesser ones, "lesser" weapons occasionally have uses. The bomb is borderline useless but good against the frogmen in 2-3 and gunmen laying on their stomachs. The knife can actually finish off Mandara faster than the gun since it's easier to shoot them off rapid fire. I'd add the ability to choose different weapons through some sort of pause menu or give the oppurtunity to collect a suitable weapon for a particular part of the game.

-Ninja Magic. Dammit they did this one so stupid. I don't mind having to earn the magics, rather than get one free at each level in the arcade, but for crying out loud let me choose which one I want so I can fly over that impossible jump in stage 4. Another use for a pause menu.

There are some smaller issues, and I wouldn't hack Shinobi just to change these (it's like rewriting history) but if someone was going to release a Hyper Fighting Rainbow Edition Shinobi anyway I'd be willing to try to hack in these changes as well.
  View user's profile Send private message Visit poster's website
  • Site Admin
  • Joined: 08 Jul 2001
  • Posts: 8644
  • Location: Paris, France
Reply with quote
Shinobi Hacking Guide, Part 1
Post Posted: Sun Apr 24, 2005 12:44 am
D,

I've been willing to give a quick try today to hack Shinobi. Here are some pointers and a log of what I did. I used latest MEKA debugger (latest version: MEKA WIP 2005-04-23) as my hacking tool.

1) Load Shinobi. Make a savestate point (F5) when the first bad guy come over you on the bottom.

2) Open memory editor. Look in RAM, and scroll down while repeateadly reloading (F7) the save state so the guy keeps moving and you can look for a RAM variable that is changing accordingly. I found it at C346 : enemy X position. To verify this, try writing FF at C346 : the enemy teleports back to the right of the screen.

3) Try moving more to see the 2 bad guys and the gunman on the top. Gunman X location is at C316. Second moving enemy X location is at C376. Looking at the values around, seems like blocks of 48 bytes (that's 30 in hexadecimal, C376-C346) are used to store all state information for one enemy. First one uses C310-C32F, next one C340-C36F, next C370-C39F, etc...

4) Restart level so that there's no enemy. Add a write breakpoint in MEKA in what seems to be the first enemy variable block:
break w c310..c32f
This will break to any write to the given range.
Problem: c322 seems to be periodically written so that will confuse us.
Remove breakpoint (break remove 0), and let's try with break w c310..c31f (the first 16 bytes will do).

5) Move the player right a little... breakpoint is triggered at the moment the gunman is about to appear (gunman is the first enemy in level 1-1) ! Let's Look at the code around:

# d 568d 20
 568D: 2A 3C C6     LD HL,(C63Ch)
 5690: 7E           LD A,(HL)
 5691: 23           INC HL
 5692: 4E           LD C,(HL)
 5693: 23           INC HL
 5694: 46           LD B,(HL)
 5695: FD 77 00     LD (IY+00h),A <-- breakpoint triggered here
 5698: FD 71 03     LD (IY+03h),C
 569B: 3A 00 C7     LD A,(C700h)
 569E: CB 6F        BIT 5,A
 56A0: CA AE 56     JP Z,56AEh
 56A3: 3E 00        LD A,00h
 56A5: B8           CP B
 56A6: CA B6 56     JP Z,56B6h
 56A9: 06 08        LD B,08h
 56AB: C3 B6 56     JP 56B6h
 56AE: 3E FF        LD A,FFh
 56B0: B8           CP B
 56B1: C2 B6 56     JP NZ,56B6h
 56B4: 06 FF        LD B,FFh
 56B6: FD 70 06     LD (IY+06h),B
 56B9: AF           XOR A
 56BA: FD 77 02     LD (IY+02h),A
 56BD: FD 77 04     LD (IY+04h),A
 56C0: FD 77 05     LD (IY+05h),A
 56C3: FD 77 07     LD (IY+07h),A
 56C6: C9           RET

Don't worry, no need to follow all the code precisely.
IY is currently set to C310, which is what I guess as being start of the enemy data block. IX and IY are commonly used to access structures on the Z80, as they have dedicated opcode to do read/write with an offset : look at the many LD (IY+xx),A instruction.

So what do we have?

 568D: 2A 3C C6     LD HL,(C63Ch)
 5690: 7E           LD A,(HL)
 5691: 23           INC HL
 5692: 4E           LD C,(HL)
 5693: 23           INC HL
 5694: 46           LD B,(HL)
 5695: FD 77 00     LD (IY+00h),A <-- breakpoint triggered here

Loads HL with a 16-bits address stored at C63C, then read successive bytes from this address and store them to the structure pointed by IY.

Address at C63C (located in RAM) is A683 (located in ROM). So here we have a RAM variable pointing to a location on the cartridge. The code fetch data from the cartridge and use it to fill the structure.

6) Examine ROM data

# m a683
A683-A68A | 1D 60 FF 50 01 0B 3D B8 | .`.P..=.
A68B-A692 | FF 80 01 0C 3D B8 FF C0 | ....=...
A693-A69A | 01 41 59 B8 FF E0 01 02 | .AY.....
A69B-A6A2 | 1D B8 FF 40 02 42 59 60 | ...@.BY`
A6A3-A6AA | FF B0 02 83 33 60 FF D0 | ....3`..
A6AB-A6B2 | 02 43 59 60 FF 20 03 0D | .CY`. ..
A6B3-A6BA | 3D B8 FF 70 03 0E 3D B8 | =..p..=.
A6BB-A6C2 | FF F8 03 84 33 60 FF 10 | ....3`..
A6C3-A6CA | 04 44 59 60 FF 40 04 03 | .DY`.@..
A6CB-A6D2 | 1D B8 FF 70 04 0F 3D B8 | ...p..=.
A6D3-A6DA | FF C0 04 10 3D B8 FF 10 | ....=...
A6DB-A6E2 | 05 45 59 48 FF 60 05 85 | .EYH.`..
A6E3-A6EA | 33 60 FF 80 05 04 1D A0 | 3`......
A6EB-A6F2 | FF 10 06 05 1D B8 FF D0 | ........
A6F3-A6FA | 06 06 1D B8 FF FC 06 46 | .......F
A6FB-A702 | 59 B8 FF 10 07 87 33 60 | Y.....3`

This is confusing at first, but part of this contains directive to spawn the enemy.
One first strategy to verify we are on the right track there is to poke in ROM and see results.

We need to know where is this location in ROM (recall that the Z80 memory map is split in 4 parts of 16 bytes). Open "Tech Infos" applet and look at Mapper line: frame 2 is mapped to page 4 of the cartridge. Meaning that Z80 0x8000..0xBFFF (A683 is in this range) correspond to ROM 4*0x4000 .. 4*0x4000+0x3fff, thats ROM 0x10000..0x13FFF.

# p a683-8000
 2683  bin: %00100110.10000011  asc: N/A  dec: 9859

Offset 2683, that's 12683. In Memory Editor, click ROM and type 12683 in address box. Let's be brute and write FF there. Reload state, move right : gunman is not there any more. (note: FF was probably not understood by the game logic and it dropped the enemy, or executed wrong code, etc.).

Reload the ROM image to cancel the mess you just made with the memory editor :)

Right now you could randomly poke value and see what happens (write 2D to a buggy Joe Musashi sprite sending you his head :) but it would be difficult to figure things out.

7)
Let's find the ROM data location for enemies 2 and 3 (the walking guys).

break clear
break w c340..c34f
break w c370..c37f
Reload state, move until first breakpoint trigger.
# m c63c 2
C63C-C63D | 89 A6                   | ..

Enemy 2 data is located at A689 (= ROM 12689)
Disable first breakpoint (b disable 0) and continue (c). Walk until second breakpoint trigger.
# m c63c 2
C63C-C63D | 8F A6                   | ..

Enemy 3 data is located at A68F (= ROM 1268F)

So we have:

Enemy 1 (top gunman) stored @ ROM 12683
Enemy 2 (bottom walker 1) stored @ ROM 12689 (6 bytes after)
Enemy 3 (bottom walker 2) stored @ ROM 1268F(6 bytes after)

Each enemy data seems to be spaced by 6 bytes.

# m a683 #18
A683-A68A | 1D 60 FF 50 01 0B 3D B8 | .`.P..=.
A68B-A692 | FF 80 01 0C 3D B8 FF C0 | ....=...
A693-A694 | 01 41                   | .A

Enemy 1: 1D 60 FF 50 01 0B
Enemy 2 : 3D B8 FF 80 01 0C
Enemy 3 : 3D B8 FF C0 01 41

8)
Now you have to crack this code. Of course, if you look at following data/enemy you get many more exemple to check.

Go back to Memory Editor, at ROM 12683.
Overwrite 1D 60 with 3D B8, reload savestate... Tada! You get 3 walking guy and no gunmen now!
Notice the 3 walking guys are at the bottom.

Guessing:
- byte 0 (eg: 1D/3D) is enemy type.
- byte 1 is Y screen position
- byte 2 is X screen position

Change 3D B8, by, for exemple, 3D 70. You get a walking guy mid air.
1D 80 you get a gunman mid air.

1D 80 80, you get a gunman mid air, appearing on the middle of the screen! Note how the X coordinate is FF (max right) for most enemy. I guess that non-FF values are being used for ninja appearing in air, etc.

9)
What are the other values? After some more analysis and study, found out more. In fact, data around 1267A is the script for level 1-1:
1267A: 10 01 40 59 60 FF 40 01 01 1D 60 FF 50 01 FF 3D B8 FF 80 01 0C...


10 01 means: screen 1, position 10
40 : not sure
59 60 FF : spawn object type 59 (hostage) at screen pos FF,60

Next item:

40 01 : means: screen 1, position 40.
01 : no sure
1D 60 FF : spawn object type 1D (gunman) at screen pos FF,60

Next item:

50 01 : screen 1 position 50.
FF : not sure
3D B8 FF : spawn object type 3D (walker) at pos FF,B8

etc.

10)
Some object code:

1D : gunman right
1E : gunman left
1F-23 : N/A (buggy stuff)
25 : gunman right (not sure if there's a difference)
26 : gunman left (not sure if there's a difference)
59 : hostage
[..]

Alright, I'll stop with this for the following reason : all enemy logic seems to be implemented, but because the graphics are not properly loaded you cannot see enemy that were not meant to be in the level. Eg: 2C i think is one of the bazooka guy, but you can't see the graphics properly, 2F launch a grenade, 3A is a jumping ninja, etc... all buggy but logic/interaction are working properly.
Hacking the game to load other sets of enemy per level may be possible, but it's another thing to do.

33 : boomerang thrower high
34 : boomerang thrower low
(but the boomerang never comes back.)

As a generic rule, bit 0 seems to be the enemy direction. 3D is walking guy walking to the left, 3E is walking guy walking to the right.


That's a first step toward hacking. Much more to figure out, but you should already be able to mess out a little and add new enemies to level 1:


Is that hard enough ?
The game engine very likely have limitation to handle too many objects, thought.

Needs to find out where and how are stored the different level pointers, to be able to expand a given level or move its data to another part of the ROM. Also need to find out about the level map itself (background tiles, collisions infos). The thing described above is only the object spawning script.

  View user's profile Send private message Visit poster's website
  • Joined: 01 Apr 2005
  • Posts: 250
  • Location: Almere, The Netherlands
Reply with quote
Shinobi IV
Post Posted: Mon Apr 25, 2005 10:16 am
Bock, I'm speechless.

There are no words for what you just did.
.......like I said no words.

What you wrote down is FANTASTIC.
I will get on it, too bad I'm at work right now, but in the evening I'll start experimenting.

What you did was just what I needed, you wrote everything very clear and understandable, thank you. I will report my findings, if I get any.

I was beginning to wonder if anything was possible with Shinobi SMS.

I wanna make a Shinobi hack.

Perhaps one day make Shinobi IV for the SMS, wow! The engine in Shinobi is very good and stable. good enough to make a sequel with.

Can't wait.
  View user's profile Send private message Visit poster's website
  • Joined: 22 Dec 2004
  • Posts: 233
  • Location: Boston, MA, USA
Reply with quote
Post Posted: Thu Jun 23, 2005 1:24 am
I made it over the impossible jump by simply jumping before.
  View user's profile Send private message
  • Joined: 24 Jul 2005
  • Posts: 57
  • Location: São Luís/MA - Brazil
Reply with quote
Amazing...
Post Posted: Mon Jul 25, 2005 8:43 pm
Simple and easy to follow.

The meka debbuger is in a wonderful stage. It remembers me soft ice, with the commands).

I started to follow your instructions and was able to do and to see the things exactly how you said.

And the most enjoyable thing: I played shinobi again... I was missing this little game!!! :)
  View user's profile Send private message Visit poster's website
Reply to topic



Back to the top of this page

Back to SMS Power!