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

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - Pennywise

Pages: [1] 2 3
1
Help Wanted Ads / [Translation] Mitsume ga Tooru NES Translation [DONE]
« on: January 15, 2019, 04:23:12 pm »
So on a whim I decided to look into translating this game the other day and it's surprisingly easy to work on and the script is minuscule. I know it's technically translated, but that's never stopped me before. My main reason for wanting to translate it is that I thought of a great title for it. "The Evil Eye" If I were to get a license to translate, release the manga etc, that's the title I'd brand it as. Anyhow, the script if anyone wants to do a quick translation.

http://yojimbo.eludevisibility.org/Stuff/Script.txt

2
Help Wanted Ads / Need a mapper hack
« on: August 01, 2018, 11:20:46 pm »
So, I finally finished translating Jajamaru Ninpo Chou and it turns out the ROM expansion used exceeded the mapper specs. This game went through a round of testing and I thought it finished, now I discover this. I've had the ROM tested on a flashcart and it doesn't work on hardware. So, the translation is locked to FCEUX and a handful of other emulators and I'm need of a mapper hack. There was a prototype for Taro's Quest that changed the mapper to MMC1, so a mapper hack might not be that difficult, but I am thoroughly sick of this game and don't want to look at it anymore. Is there anyone capable of doing a mapper hack for me?

3
Help Wanted Ads / Pennywise's Graphic Design Help Thread
« on: November 22, 2017, 02:21:57 pm »
Hey folks, I'm looking for someone to do a new title screen design for my Double Moon translation. I'm looking for something that is a little closer to the original Japanese design. A mockup is fine and please remove the moon from the mockup as it is not part of the graphic, but a separate sprite.

Current version and original.


4
I'm looking for some feedback and ideas I have on how to deal with this title. It was released in the US as Mercenary Force, but I don't want to use that title at all. The game really doesn't have much text, but I want to retranslate it in preparation of translating the weird sequel.

https://www.gamefaqs.com/gameboy/585797-mercenary-force/images

Ryusui's suggestion to me is to leave the title alone and just romanize it with maybe a subtitle such as Mercenary Force, but I don't quite agree with that. I kinda like the title Twilight Mercs vs. the Soulless Army. That's what I might use for a subtitle.

5
Programming / Time Twist Text Compression Code
« on: August 17, 2016, 06:38:58 pm »
So I decided to start looking into the text compression for Time Twist on the FDS. It doesn't use standard NES dictionary compression and uses something a little bit more complicated. I'm actually only familiar with dictionary and RLE compression, so I'd like to figure this out so I can learn something new. But I'm gonna need a bit of help to grasp whatever it is I'm not getting. I'm trying to do a partial disassembly of the code and I've got the end result figured out, but the middle is definitely confusing. I'm guessing it's relying heavily on bitmath to do its decompression. I'm also not even sure I've got all the code as this thing is looking beastly. Anyone curious or want to help me? If so, I'll post what I've got so far.

6
So there's this character/boss in the called Kimo (きもひめ) that looks like a human, but is actually a spider in disguise. It appears the name is a typical Japanese pun a la combination of two words oni and spider or some such.

Lady Recluse was suggested, which I thought was pretty good, but I don't think it matches the game well. It's a typical medieval Japan setting and I was perhaps thinking of combining a common japanese name for a girl with some type of spider word.

Taranko
Arachnekane
Kimorantula

I'll probably just end up leaving it alone, but figured I would post here.

7
ROM Hacking Discussion / NES ROM Expansion Document
« on: December 21, 2014, 02:25:17 pm »
I had the idea to write up a document that attempts to explain and break down all the details that go into NES ROM expansion. Could I get some feedback on what I've written?

Quote
The MadHacker once said that "NES rom expansion is so difficult and time consuming that you might as well think of it as impossible."

That was in a time when information was scarce and emulators weren't really any good. The fact is that NES Expansion isn't that complicated despite the myriad of different mappers that do things their own way. The goal of this document is to shed light on the technical details of ROM expansion and to share some common techniques that can be used to utilize the new space.

NES Hardware Basics

PRG-ROM and CHR-ROM

Most NES games have two ROMs inside a cartridge. The first ROM is PRG-ROM and the second is CHR-ROM. They stand for Program and Character respectively with the first usually containing all the code and data and the second containing the graphics. When we say ROM expansion, we are usually referring to the PRG-ROM. The PRG-ROM is split up into different sections of equal size in what are known as ROM banks. The bank size varies depending on the game and mapper. For example, the bank size is usually either 8kb or 16kb. You can find this information out by using the emulator FCEUX. Just go to Help -> Message Log.

The 6502 CPU Memory Map

The NES accesses the PRG-ROM by loading ROM banks into a specific address area of the CPU memory map. The banks are loaded into the address range of $8000-FFFF. This makes for a total size of 32kb the NES can access of the PRG-ROM at a time.

It's story time. Once upon a time when the NES first came out, PRG-ROM sizes were only 32kb, the maximum size the NES could access at a time. This worked fine until developers said, "32kb is way too small for me to fit my game into. I want to make bigger and more complex games. I need a bigger ROM." So Nintendo developed mappers, which is what you could call fancy boards, that usually handled ROM sizes of 128kb, 256kb and 512kb. Now the NES can only handle 32kb at a time, so these mappers could "swap" banks in and out as needed, thus being able to access the entire ROM, just not at once. Take this diagram to better picture it.


Game that uses 8kb banks
+---------------------------------------------------------------+
|      1       |        2       |       3      |       <4>      |
+-------------------------------+-------------------------------+

Game that uses 16kb banks
+---------------------------------------------------------------+
|             1                 |             <2>               |
+-------------------------------+-------------------------------+

Picture that the NES CPU has slots and pretend that banks from the ROM go in there. Then mix and match however you want and that's how the NES accesses the PRG-ROM in a nutshell. But there's one very important piece of information you need to know. The very last bank in the PRG-ROM is what you would call the "fixed bank" or "hard-wired bank". It's always loaded into the the last ROM bank slot in the CPU and can never be changed or moved. The <> is there just to denote the difference.

How to determine NES ROM expansion limits

Technically speaking, the NES could supports ROMs that were 10MB in size, but there isn't a board or mapper that hasn't been designed to support such a size yet. When we talk about ROM size limits, we are referring to the maximum size a game can be that was designed for a particular board or mapper. Maximum ROM sizes are determined from the number of PRG bits a board/mapper that sets the number of ROM banks available. This is all technical mumbo jumbo that's not really necessary to explain because NESDev has an excellent wiki that just lists the max ROM size for all the NES mappers.

Question: Let's say I have a ROM that I expanded to 256kb, but the mapper/board can only support 128kb. Is that even possible?

Answer: There are two sides to the coin for this. If you wanted to play your translation on a real NES, the original board used wouldn't be able to support the ROM. However, it becomes a moot point when you factor in that flashcarts could play the expanded ROM fine. You can consider a flashcart a sort of all-in-one mapper that can handle any game size which usually maxes out at 512kb. The NES doesn't care about ROM sizes and that's the important thing to remember. A good example is the Hebreke translation that expanded the ROM which the original mapper/board couldn't support, but that a flashcart could play fine.

How does the NES "swap" banks

First off, ROM banks are numbered starting from #$00 and going up the hex scale. You take the bank number and you write them to the PRG register which is something that basically tells the NES to do the bank swap. This is what the code looks like to swap banks.

LDA #$01
STA $8000

Translating this code into English would be something like load the bank #$01 and write it to the PRG register. Think of it like if I write #$01 o $8000 then bank 1 will go into the first PRG slot in the CPU.

That is generally how the NES swaps banks, but the register value is just a made up example and will vary by game and mapper. The mapper MMC1 does its bank swaps a little different and is not the same as the above example.

How to expand an NES ROM

Well, that's actually quite simple. KingMike made a simple program called nflate that can expand your ROM for you in a jiff. Every once in a while there will be special cases where a ROM won't work properly after expansion and you'd need to troubleshoot it and expand the ROM manually. But the vast majority of games work fine after expansion. Expanding the ROM is the easy part, but utilizing the expanded space is where things get tricky.

How to use the expanded space

In the scope of translation hacking, the goal of ROM expansion is to increase the amount of space you have available so you can fit all the translated text back in without cutting it down. Let's say you have an entire bank of text. There's no way in hell you can fit that all back in the original space. Maybe if you compressed it, but that's a different subject. So what you do is split the text between two different ROM banks effectively doubling the space you have available.

Question: How does one split the text between banks?

Answer: I use two different methods to accomplish this. To keep things simple, we'll only talk about one.

First off, you need to code a new routine that contains our bank swap code. The new code requires space in the ROM and most games usually have free space at the end of the fixed bank. That's where we put our code.

Question: But what if there's no free space in the fixed bank?

Answer: TBD

So what you do is JSR from the game's text pointer load routine. Your common game's text pointer load routine will look something like this:

LDA $8000,Y
STA $0000
LDA $8001,Y
STA $0001

Y is the index that selects which pointer from the table to load. Here's a simple breakdown of the pointer table addresses:

$8000 = 0
$8002 = 1
$8004 = 2
$8006 = 3
$8008 = 4
$800A = 5

The numbers on the right are what Y needs to be in order to load a particular text pointer.

Let's say we want to we want the text to be in another bank for string 5. Let's also assume that the PRG-ROM was 128kb and we expanded it to 256kb. The game uses 16kb banks, which with 128kb total, that makes for 8 banks. So the banks for the expanded space are going to start at #$09 and up. So here's what we do


;Load first pointer byte
LDA $8000,Y
;Write it to RAM
STA $0000
@Branch1:
LDA $8001,Y
STA $0001
;Compare if Y is less than or equal to 4
CPY #$05
;If so, skip this code and go here
BCS @Branch1
;load bank 9
LDA #$09
;swap bank 9 into PRG slot
STA $8000
@Branch1:
RTS

9
Script Help and Language Discussion / Deciphering a graphic
« on: September 21, 2014, 09:40:50 pm »
I've got a challenge for the folks here. So there's this graphic that randomly appears on the stage select and on one seems to be able to make the upper character. I'd appreciate some help with this!


10
Script Help and Language Discussion / Translate a small manual
« on: April 20, 2014, 06:02:41 pm »
http://www.videogameden.com/fc/extra/fim.pdf

Could someone translate this small manual for me? I don't think it would take very long. Thanks.

11
Script Help and Language Discussion / Angel Marlowe Credits
« on: March 06, 2014, 06:32:52 pm »
So, it was recently brought to my attention that Angel Marlowe has some secret/alternate closing credits that are accessed with a password. If I had to guess, they're the names of the various characters in the game.












12
Script Help and Language Discussion / ドクロべえ
« on: February 27, 2014, 06:33:38 pm »
ドクロべえ is an enemy that uses another enemy as a disguise before it reveals itself. Oddly enough the ninja cat Kurobei from Ganbare Goemon uses a disguise when you first meet it. It can't be a coincidence given the similarities, but I don't know what the hell is going on. Anyone got any ideas/theories on this one?

Just to be clear, I think there's a good possibility that this name might possibly be a pun. If that is the case, I would not want to translate it as Dokurobei and would rather translate the spirit of it instead, so the player can understand the joke, if there is one.

This appears to be a Yatterman reference and/or a lazy joke. Googling the name gave me this instead.

ドクロベエ

Apparently they swapped the Katakana with a Hiragana, which I guess is the equivalent of using Caps in English.

13
Script Help and Language Discussion / Help Replacing Dejare Phrases
« on: February 14, 2014, 03:35:18 pm »
I am in need of some major creative help for a game I'm translating. I'm currently at a town that is hosting a pun contest revolving around fish. The puns are all dejare, which are Japanese wordplay puns. They cannot be both translated and the joke kept intact. So they need to be replaced. There are at around 30-50 of them and well, I need all the help I can get. The following rules:

Any type/species/kind of fish or fish-related is game.
Only 1 pun per fish
Puns can only be a maximum of 19 characters

Thanks for any help.

14
Script Help and Language Discussion / Translating stupid puns
« on: December 26, 2013, 08:29:32 am »
So I currently have a tomato pun/riddle that asks what is spelled the same forwards and backwards. In Japanese that is tomato, but in English it doesn't work. I'm think of two options here, to keep the riddle, but change the subject, or to keep the tomato and change the riddle. Anyone got any bright ideas?

15
Script Help and Language Discussion / Daruman
« on: December 05, 2013, 05:17:34 pm »
I've found this name in various video games and it seems to be based on a Daruma doll or something. Is there a translation for the name or something best left alone?

16
Script Help and Language Discussion / Moai Kun Manual
« on: November 29, 2013, 01:45:57 am »
Would anyone be willing to translate this manual of the game for me? I'm doing an article on this game for HG101 and if possible I'd like to fill out the article with information contained within the manual. The whole thing doesn't need to be translated, just the important bits.

http://www.videogameden.com/fc/extra/mku.pdf

Off the top of my head, obviously the back story is important and the premise of the game as well. Who are those things you rescue etc. Who are those enemies? What that M 7.8 means (I'm guessing it has something to do with the Richter scale)? Anything else that might look important or interesting etc.

17
Script Help and Language Discussion / Yashichi of Kazuguruma
« on: October 24, 2013, 09:16:12 pm »
I bet Yashichi of
Kazuguruma looks
the same right now!

「かざぐるまのやしちも
 このざまだあ!」

Anyone have any idea what the hell this refers to. It sounds like a cultural reference that's way beyond me.

18
I've got some text for enemy German soldiers and I want to give them some flavor by having them speak Denglish to differentiate them from the good guys. There's not a whole of text that needs to be edited and the goal is to the keep the German as simple as possible so English speakers can still understand. For the record I am also using accented speech, but this is for German to German communication.

This is good.

http://www.instructables.com/id/How-To-Type-and-Talk-With-a-German-Accent/


#1

This is a hint for a malfunctioning elevator that drops you into some spikes. The original was more vague.

(original)
Captain, watch out for the elevator.
(expanded)
Captain, watch out for the elevator on the left. It's a death trap.

Got it.

#2

2nd Unit proceeding to Area 4.

Hey, if you're going to Area 4 don't forget that flare gun!

#3

An enemy! An enemy has intruded!

Where!? I'll shoot him down!

#4

Umm, would you happen to know where the garbage dump is?

Moron! How many years have you been here? It's in Area 9. Don't forget!

#5

This is hidden message from one of the devs. I believe it is a hint about getting past a wall in one of the neutral areas. Somewhat vague.

I'm Terukun. Try hitting the right wall!

#6

So you convoyed Joe?

Affirmative. Brought to the garbage dump. Not a peep all the way to the cell.

#7

Cripes! Commander, I can't get this door open!

Dammit! Then I guess I'll have to do it!

#8

It's Joe! Super Joe is here!

Unit 5, respond!

#9

I had an idea to translate a computer message to german. Just curious what it would be.

THIS BASE WILL EXPLODE IN 60 SECONDS. PLEASE EVACUATE IMMEDIATELY.

Beep beep beep  INTRUDER ALERT  COMMENCE ATTACK

That's all for now. Any help with the German stuff would be appreciated.

19
Programming / Z80 Decompression Routine
« on: April 25, 2013, 11:09:20 pm »
Alright so I recently checked out this b/w GB game and much to my surprise the game's main text is compressed and the not garden variety dictionary kind either. I was kinda surprised that a game on this platform and its age, I would find something more complicated. So I was just kinda curious if anyone recognized the compression or this is just something the devs cooked up. I realize it's going to require custom tools for me to even rip the script out. I am however not familiar with various kinds of compression other than what I've come across in the simple Dictionary and RLE stuff.

Code: [Select]
23d6: 19 ADD HL,DE A:04 F:c0 BC:0000 DE:4000 HL:0204 SP:cefe
23d7: 11 00 d9 LD DE,d900 A:04 F:c0 BC:0000 DE:4000 HL:4204 SP:cefe
23da: 2a LD A,(HL+)[4204]=d1 A:04 F:c0 BC:0000 DE:d900 HL:4204 SP:cefe
23db: fe 04 CP 04 A:d1 F:c0 BC:0000 DE:d900 HL:4205 SP:cefe
23dd: 38 03 JR C, +03 [23e0] A:d1 F:c0 BC:0000 DE:d900 HL:4205 SP:cefe
23df: c3 f1 23 JP 23f1     A:d1 F:c0 BC:0000 DE:d900 HL:4205 SP:cefe
23f2: 47 LD B,A     A:d1 F:c0 BC:0000 DE:d900 HL:4205 SP:cefe
23f3: 2a LD A,(HL+)[4205]=01 A:d1 F:c0 BC:d100 DE:d900 HL:4205 SP:cefe
23f4: 4f LD C,A     A:01 F:c0 BC:d100 DE:d900 HL:4206 SP:cefe
23f5: 2a LD A,(HL+)[4206]=a4 A:01 F:c0 BC:d101 DE:d900 HL:4206 SP:cefe
23f6: e5 PUSH HL     A:a4 F:c0 BC:d101 DE:d900 HL:4207 SP:cefe
23f7: 67 LD H,A     A:a4 F:c0 BC:d101 DE:d900 HL:4207 SP:cefc
23f8: 78 LD A,B     A:a4 F:c0 BC:d101 DE:d900 HL:a407 SP:cefc
23f9: cd 1e 24 CALL 241e A:d1 F:c0 BC:d101 DE:d900 HL:a407 SP:cefc
241f: cb 3f SRL A            A:d1 F:c0 BC:d101 DE:d900 HL:a407 SP:cefa
2421: cb 3f SRL A        A:68 F:c0 BC:d101 DE:d900 HL:a407 SP:cefa
2423: 12 LD (DE),A A:34 F:c0 BC:d101 DE:d900 HL:a407 SP:cefa
2424: 13 INC DE     A:34 F:c0 BC:d101 DE:d900 HL:a407 SP:cefa
2425: c9 RET     A:34 F:c0 BC:d101 DE:d901 HL:a407 SP:cefa
23fc: 79 LD A,C     A:34 F:c0 BC:d101 DE:d901 HL:a407 SP:cefc
23fd: cb 38 SRL B     A:01 F:c0 BC:d101 DE:d901 HL:a407 SP:cefc
23ff: 1f RRA     A:01 F:c0 BC:6801 DE:d901 HL:a407 SP:cefc
2400: cb 38 SRL B            A:80 F:c0 BC:6801 DE:d901 HL:a407 SP:cefc
2402: 1f RRA     A:80 F:c0 BC:3401 DE:d901 HL:a407 SP:cefc
2403: cd 1e 24 CALL 241e A:40 F:c0 BC:3401 DE:d901 HL:a407 SP:cefc
241f: cb 3f SRL A             A:40 F:c0 BC:3401 DE:d901 HL:a407 SP:cefa
2421: cb 3f     SRL A       A:20 F:c0 BC:3401 DE:d901 HL:a407 SP:cefa
2423: 12 LD (DE),A A:10 F:c0 BC:3401 DE:d901 HL:a407 SP:cefa
2424: 13 INC DE A:10 F:c0 BC:3401 DE:d901 HL:a407 SP:cefa
2425: c9 RET A:10 F:c0 BC:3401 DE:d902 HL:a407 SP:cefa
2406: 7c LD A,H A:10 F:c0 BC:3401 DE:d902 HL:a407 SP:cefc
2407: cb 39 SRL C    A:a4 F:c0 BC:3401 DE:d902 HL:a407 SP:cefc
2409: 1f RRA A:a4 F:c0 BC:3400 DE:d902 HL:a407 SP:cefc
240a: cb 39 SRL C A:d2 F:c0 BC:3400 DE:d902 HL:a407 SP:cefc
240c: 1f RRA A:d2 F:c0 BC:3400 DE:d902 HL:a407 SP:cefc
240d: cb 39 SRL C A:69 F:c0 BC:3400 DE:d902 HL:a407 SP:cefc
240f: 1f RRA A:69 F:c0 BC:3400 DE:d902 HL:a407 SP:cefc
2410: cb 39 SRL C A:34 F:c0 BC:3400 DE:d902 HL:a407 SP:cefc
2412: 1f RRA A:34 F:c0 BC:3400 DE:d902 HL:a407 SP:cefc
2413: cd 1e 24 CALL 241e A:1a F:c0 BC:3400 DE:d902 HL:a407 SP:cefc
241f: cb 3f SRL A A:1a F:c0 BC:3400 DE:d902 HL:a407 SP:cefa
2421: cb 3f SRL A A:0d F:c0 BC:3400 DE:d902 HL:a407 SP:cefa
2423: 12 LD (DE),A A:06 F:c0 BC:3400 DE:d902 HL:a407 SP:cefa
2424: 13 INC DE A:06 F:c0 BC:3400 DE:d902 HL:a407 SP:cefa
2425: c9 RET A:06 F:c0 BC:3400 DE:d903 HL:a407 SP:cefa
2416: 3e 3f LD A,3f A:06 F:c0 BC:3400 DE:d903 HL:a407 SP:cefc
2418: a4 AND H A:3f F:c0 BC:3400 DE:d903 HL:a407 SP:cefc
2419: 12 LD (DE),A A:24 F:c0 BC:3400 DE:d903 HL:a407 SP:cefc
241a: 13 INC DE A:24 F:c0 BC:3400 DE:d903 HL:a407 SP:cefc
241b: e1 POP HL A:24 F:c0 BC:3400 DE:d904 HL:a407 SP:cefc
241c: c3 d9 23 JP 23d9 A:24 F:c0 BC:3400 DE:d904 HL:4207 SP:cefe

So just some context, $D900 is the beginning of the spot in WRAM where the decompressed bytes are stored after having had some bit math done to them. $4205 etc are the compressed bytes. From what I can tell, it works in groups of 3 and end up with 4 decompressed bytes each time.

20
ROM Hacking Discussion / Pennywise's Guide to Debugging
« on: April 10, 2013, 04:06:33 pm »
Hey folks, I had this idea to do a document that details the fundamentals of debugging and the stuff behind it. I came up with the idea today and finished the rough draft today. Feel free to give me feedback, but keep in mind I was lazy on the memory map stuff on purpose. Ideally I'd like to make this into an HTML file and PDF to cover the basics, but I need help doing that. Anyone? Pictures will be of benefit when everything's finalized.

Quote
Of all the topics to read up on in Romhacking, debugging doesn't seem to be a topic covered all that much. Sure, there are plenty of documents for the basics and source code for various hacks and reverse-engineering, but not much for debugging. For those looking to take the next step, learning how to use a debugger is a paramount in attaining that goal. Not only just learning the concepts of debugging, but knowing how to apply them to help hack a game.

Before I even begin with explaining the debugging aspects, there are certain hardware details that must be known before anyone can even begin to learn debugging. Otherwise it's kinda like wanderering through the dark with no clue where you're going. Since the NES is my area of expertise, we'll be using that as an example. Keep in mind that Romhacking and debugging concepts are more or less universal concepts that can be applied to other systems.

What you need to know about the NES:

-Be able to differentiate between RAM and ROM addresses.
-ROM is pretty simple, that's the physical ROM on your computer and the addresses you are viewing in a hex .
-ROM is usually split into two parts: PRG-ROM and CHR-ROM. PRG stands for Program(Code) and CHR stands for Character(Graphics). Some games/mappers only have one ROM with the graphics lumped into the PRG-ROM.
-Now RAM refers to the memory of the NES and there are three types of memory for the NES: CPU, PPU and Sprite. Each memory mode has it owns memory map which basically tells the NES what to put where in memory
-Here are the general memory maps for the CPU and PPU

CPU
Internal RAM
$00-800
RAM Mirrors
$800-2000
Registers galore etc (not important for our purposes)
$2000-6000
Cartridge RAM (Not all games have/use this)
$6000-8000
PRG-RAM
$8000-FFFF

PPU
Pattern Table #0
$00-1000
Pattern Table #1
$1000-2000
Name Table #0
$2000-23C0
Attribute Table #0
$23C0-2400
Background Palette
$3F00-3F10
Sprite Palette
$3F10-3F20

Now let me breakdown what some of these terms are.

First there's RAM and Cartridge RAM which are basically the same thing. The only difference between the two is that Internal RAM is located within the NES and Cartridge RAM is located in the cartidge itself for extra RAM. The game stores various variables in this area. Stuff like HP, Strength, enemy counter rates, text positions. RAM is dynamic.

Then there's PRG-RAM. You must know the difference between PRG-ROM and -RAM. The NES cannot access the entire ROM banks at one time. It is limited to accessing 32kb's of ROM banks at a time and that 32kb goes straight into PRG-RAM. Bank sizes are dependent on mapper and setup and vary like so:

32kb(note some PRG-RAM/ROM sizes are 32kb therefore the entire PRG-ROM can be accessed in one shot)
16kb
8kb

The last bank in the PRG-ROM is always mapped to $C000 or $E000 in the PRG-RAM depending on bank size. This is what is referred to as the fixed bank. It cannot be moved or changed with another bank.

Name Table is basically the screen coordinates graphics appear on and the attribute table details colors for the graphics etc.

Keep in mind that a game does not use/access ROM addresses. They do not exist. A game will only use RAM addresses. That is why something like text pointers don't always match up with their ROM addresses. It's not pointing to the ROM, it's pointing to wherever the text is stored in RAM.

That should cover most of it, let's move onto actual debugging concepts now.

A debugger is mainly used to have the a break/stop/whatever just before certain ASM instructions are executed by the game. You set the conditions in which that happens with a debugger. We call them breakpoints, if you want to keep it simple think of it as a point in which to take a break. There are three main types of breakpoints they are:

Read - This is when we want to know when the game is accessing variables in RAM, text being accessed from PRG-RAM etc. Breaking when reading data and variables.
Write - This is mainly for when we want to know when variables are being written to RAM by the game like player stats. We don't usually use it for something like PRG-RAM because that's more like static data, but for something like RAM as it is dynamic aka ever changing.
Execute- This is when we want to know when the game is accessing specific ASM instructions from the PRG-RAM.

Breakpoints can be used for the three types of memory the NES has. Want to know when/how a graphic tile appears on the screen, set a write breakpoint for the PPU address etc.

Now onto the actual debugger.

What you want to do is load up the FCEUX emulator with a game of your choice, which by the way is one of the best emulators/debuggers I have ever used, and at that top bar you'll see a bunch of options. Click Debug -> Debugger. Don't let it overwhelm you, but the main thing you should is that on the left is the entire scrollable memory map of the CPU. Then to the right, you'll see a bunch of buttons. The important ones are Run and Step Into which are used for when you want the game to "Run" normally etc for the former and to go through each ASM instruction step by step for the latter. Then there's the breakpoint screen to the right of the button. There's the Add, Delete and Edit which are all self explanatory (add breakpoint, delete...). Click Add and it'll bring up the breakpoint menu where you input the address you want to break on and the type of breakpoint etc.

Now let's try applying this to game. Let's do Mad City the Japanese version of Bayou Billy.

We are going to start a hypothetical translation for the game and the first step is to build a table and find the text in the ROM. Building a table is quick and easy by using the PPU Viewer in FCEUX. So let's fire up Mad City and get past the title screen. Pause the game when some text appears as Gordon holds Annabelle at knife point. You'll see the katakana characters on the right side of the PPU viewer starting at $70. So let's make a basic Japanese table from those values.

Once you've finished the basic table, let's try searching for that first bit of intro text by loading the table into the hex editor along with the game. Search for the hex values or use your hex editor's kana search feature, if it has one.

We're gonna focus on モラッユク because those dakuten that precede can make things more complicated for us.

What the hell! I'm not finding the text! It's compressed!

Ok, we gotta figure out what's going on here. Let's do some debugging. Make a savestate before the text appears in the intro.

What we're gonna do is see how the text gets written to the screen. That is the end of the process of the text being read from PRG-RAM and finally appearing on the screen. When you don't know where to start, start at the end and work your way.

So let's get that text up again and open up the Name Table Viewer. You're gonna see a recreation of the screen albeit with messed up graphics in parts. Pause/unpause so that you can see the text ok. You'll also see multiple screens and only the top halfs are usually used by the game, the bottom half is mostly for mirroring. Move your cursor over to the text were interested in and there will be some information for it. The tile is $9A, the X/Y coorinates and that the PPU address 20B0. We are going to set a write breakpoint for that address. So let's pause the game and load our savestate to reset the screen.

When you've done that load up the debugger and add a PPU write breakpoint to 20B0. Before we unpause the game we're also going to use the Trace Logger. A Trace Logger is a tool that logs the code as it's executed and it's complimentary to debugging by keeping track of past code in case we need to look at it. So we're gonna log the last 10,000 instructions to window and click start logging. Now unpause the game.

The game should stop when we get just before that text and the debugger snaps. Keep in the mind the goal of all this is find out how $9A gets to $20B0 in the PPU. If you look at the trace logger, you will see this:

LDA $0700,Y @ $0704 = #$9A

This is where $9A came from. If you're savestate is before the screen appears, you'll have to click run on the debugger as there is usually a blank tile loaded to clear the screen etc.

Now we want to know how $9A got to $0704. So we're gonna delete our breakpoint, stop the trace logger, pause the game and reload our state. We're gonna add a new breakpoint now. Set a write breakpoint for $0704 to the CPU. Unpause the game.

The game is going to break a lot. We're going to continue to keep clicking run until we see

LDA $B0BE,Y @ $B0E0 = #$9A

in the trace logger.

So $9A comes from that, but how does that get $9A?

Well data is being read from a table with a Y index. Y($22) gets added onto the base of $B0BE and becomes $B0EO. Where does $22 come from?

Well if we look up a bit we see this:

LDA ($00),Y @ $B1E4 = #$22

This appears appear to be the code that reads the text from the PRG-RAM, the text read routine. Maybe the text data is not the same as what appears in the PPU and hence requires an additional table to adjust for the difference. Let's try building a table from this table.

Fire up the hex editor in FCEUX and go to $B0BE. You should see 70, 71, 72... Those look like the actual tile values that are in the PPU. Let's make a table based on those values. We're gonna start the table values at 00 because that is the beginning of the table.

Now let's try searching for that text. You should wind up at 171F4 in the ROM.

Hey we found the text! It's not compressed after all! Crazy Konami, just what the hell were they thinking! :D

Pages: [1] 2 3