Skeetendo

’Cause all games were better on the GBC

You are not logged in.

#1 2012-01-14 01:27:54

KuroiIeWa5Da
New member
Registered: 2012-01-14
Post 1/5

Is you PokeRed Disassembly 1:1 with the original file

The Pokemon Red ROM is a haphazard mix of used code, unused code, code that's almost impossible to figure out, broken code, bugs, glitches, etc... This is why I'm very impressed with your disassembly but I'm unclear as to how it's laid out.

Did you first disassemble the whole game (storing the original in a disassembly file) and then work on sorting out what code does what and which functions are where. This way it's compilable to the exact same game as before, even for the code or data sections that aren't figured out yet.

Or did you disassemble the game and the disassembly in your project is for the code you've figured out (any non-figured out code won't be there and the game is only compilable to the code you've figured out).

I'm just a little unclear, could anybody clear this up for me.

Offline

#2 2012-01-14 01:40:05

425/700

Re: Is you PokeRed Disassembly 1:1 with the original file

KuroiIeWa5Da wrote:

Or did you disassemble the game and the disassembly in your project is for the code you've figured out (any non-figured out code won't be there and the game is only compilable to the code you've figured out).

This is the closer guess. Much of the disassembly is done by hand (e.g., use BGB to find and disassemble a routine, then appropriately comment and label it). Lately quite a bit (mostly map scripts) has been automated. This has a couple of disadvantages: there are no comments, and sometimes data is incorrectly interpreted as ASM code. However, it generally produces correct code, and it’s incredibly advantageous (in the case of maps) to have access to the code from all the maps at once.

Even though it’s incomplete, the disassembly does compile to an exact ROM, by including chunks of the binary ROM. The included chunks are gradually shrinking, and eventually the whole game will be recompilable without a ROM.

Volunteers welcome, by the way.

#3 2012-01-14 03:15:25

KuroiIeWa5Da
New member
Registered: 2012-01-14
Post 2/5

Re: Is you PokeRed Disassembly 1:1 with the original file

I've taking a keen interest in this project and am wanting to volunteer. When I try to assemble the project I get the following error:

baserom.gbc pokered.gbc differ: byte 335, line 1
make: *** [pokered.gbc] Error 1

It appears I have the wrong ROM file but I've downloaded "Pokemon Red (UE) [ S ][!].gb" from at least 3 different sources and they all match the MD5 checksum you gave

EDIT:
I've filed this under issue #14 on the project, The MD5 Checksum and ROM name are the same as the requirements.

@IIMarckus: that's an interesting setup, only store converted code and leave the rest to the actual original ROM file to convert later. This is the first project I found which I believe will be successful and I'm very surprised to see a modern project - usually they're all failed and long out-of-date projects from the 90's. I've heard that Pokemon Yellow uses most of the code from R/B/G with some bad tweaking to support color and Gold and Silver use a much improved code version from the Yellow code. Since GB and GBC code are very similar do you have any plans to support the dis-assembly of those games as well? If you do, I imagine things will go somewhat more smoothly after you understand the GameEngine r/b/g use since it seems to be what y and g/s spinoff of as well.

Last edited by KuroiIeWa5Da (2012-01-14 06:55:08)

Offline

#4 2012-01-14 07:13:48

426/700

Re: Is you PokeRed Disassembly 1:1 with the original file

KuroiIeWa5Da wrote:

I've taking a keen interest in this project and am wanting to volunteer. When I try to assemble the project I get the following error:

baserom.gbc pokered.gbc differ: byte 335, line 1
make: *** [pokered.gbc] Error 1

It appears I have the wrong ROM file but I've downloaded "Pokemon Red (UE) [ S ][!].gb" from at least 3 different sources and they all match the MD5 checksum you gave

EDIT:
I've filed this under issue #14 on the project, The MD5 Checksum and ROM name are the same as the requirements.

Okay, we can continue this particular discussion (about build issues) there.

KuroiIeWa5Da wrote:

@IIMarckus: that's an interesting setup, only store converted code and leave the rest to the actual original ROM file to convert later. This is the first project I found which I believe will be successful and I'm very surprised to see a modern project - usually they're all failed and long out-of-date projects from the 90's. I've heard that Pokemon Yellow uses most of the code from R/B/G with some bad tweaking to support color and Gold and Silver use a much improved code version from the Yellow code. Since GB and GBC code are very similar do you have any plans to support the dis-assembly of those games as well? If you do, I imagine things will go somewhat more smoothly after you understand the GameEngine r/b/g use since it seems to be what y and g/s spinoff of as well.

Yellow support is on the roadmap, but a long ways away (although some parts, like wild Pokémon data, have been dumped and added simply because it doesn’t complicate things). Blue is not supported yet, although it is expected to be ready reasonably soon.

GSC would probably be best served by having their own repo (or at least their own subdirectory in the repo). Although GSC code is noticeably descended from RBY, it has diverged too much for the codebases to be reasonably integrated.

#5 2012-01-14 10:07:59

stag019
Idea Killer
Registered: 2011-01-05
Post 124/630

Re: Is you PokeRed Disassembly 1:1 with the original file

IIMarckus wrote:

Yellow support is on the roadmap, but a long ways away (although some parts, like wild Pokémon data, have been dumped and added simply because it doesn’t complicate things). Blue is not supported yet, although it is expected to be ready reasonably soon.

Let's hope so! :D (In case you couldn't tell, this aspect has been assigned primarily to me)

IIMarckus wrote:

GSC would probably be best served by having their own repo (or at least their own subdirectory in the repo). Although GSC code is noticeably descended from RBY, it has diverged too much for the codebases to be reasonably integrated.

Here's my question though: How is the line drawn? Pokemon Gold and Silver are noticeably very far away from being Yellow version, but even then, in my opinion, yellow has diverged rather far from Red and Blue itself. Sure, it shares probably a decent amount of assembly code, and a lot of code is loaded in similar locations in RAM (one byte off, but who's counting) but as for the data itself, it's probably much more scattered around the ROM as opposed to Red vs. Blue. For example, Mew's data is intermingled with all other Pokemon's data in Yellow version, whereas in Red and Blue, it's grouped together because it was a last minute addition. Not to mention not very many other pieces of data will be in the same order.

And at that rate, Japanese Red, Green, and Blue are just as far away. They don't even share the same file size. Nor are characters/Pokemon named with the same amount of characters. And there's multiple versions with bug fixes and... just a general mess.

Unless you, in the distant future, plan to separate most of pokered.asm into it's labels, and include only the common code where it's supposed to be, leaving the new pokexxx.asm to mostly ordering these things correctly, I kinda think anything that's not English Red/Blue should be separate. Probably include English Yellow in the future too. Unlikely, but possibly, in the even more distant future, Japanese Pokemon Blue.

But yeah it seems like at our current way of doing things, we're setting ourselves up for failure from including any other version unless we separate out a lot of code soon.

Also: I ramble too much when I'm tired.


You can try to hide yourself in this world of pretend; when the paper's crumpled up, it can't be perfect again.

Offline

#6 2012-01-14 15:54:08

427/700

Re: Is you PokeRed Disassembly 1:1 with the original file

stag019 wrote:
IIMarckus wrote:

Yellow support is on the roadmap, but a long ways away (although some parts, like wild Pokémon data, have been dumped and added simply because it doesn’t complicate things). Blue is not supported yet, although it is expected to be ready reasonably soon.

Let's hope so! :D (In case you couldn't tell, this aspect has been assigned primarily to me)

IIMarckus wrote:

GSC would probably be best served by having their own repo (or at least their own subdirectory in the repo). Although GSC code is noticeably descended from RBY, it has diverged too much for the codebases to be reasonably integrated.

Here's my question though: How is the line drawn? Pokemon Gold and Silver are noticeably very far away from being Yellow version, but even then, in my opinion, yellow has diverged rather far from Red and Blue itself. Sure, it shares probably a decent amount of assembly code,

More than that. Otherwise I wouldn’t consider it.

stag019 wrote:

and a lot of code is loaded in similar locations in RAM (one byte off, but who's counting)

Eventually RAM addresses will be dynamically assigned, rather than hardcoded, so this won’t be a problem.

stag019 wrote:

but as for the data itself, it's probably much more scattered around the ROM as opposed to Red vs. Blue. For example, Mew's data is intermingled with all other Pokemon's data in Yellow version, whereas in Red and Blue, it's grouped together because it was a last minute addition. Not to mention not very many other pieces of data will be in the same order.

And at that rate, Japanese Red, Green, and Blue are just as far away. They don't even share the same file size. Nor are characters/Pokemon named with the same amount of characters. And there's multiple versions with bug fixes and... just a general mess.

At the moment, it is not important. Red is the priority, and 99% of the work should be focused on it. Yellow is only a curiosity at this point. Notice how the only Yellow data is stuff that’s in an identical format to RBY. It is there for interest in the data only, not out of a hope for eventually merging the codebases.

stag019 wrote:

Unless you, in the distant future, plan to separate most of pokered.asm into it's labels, and include only the common code where it's supposed to be, leaving the new pokexxx.asm to mostly ordering these things correctly, I kinda think anything that's not English Red/Blue should be separate. Probably include English Yellow in the future too. Unlikely, but possibly, in the even more distant future, Japanese Pokemon Blue.

Again, these are not going to happen anytime soon. I shouldn’t even mention them. Depending on the complexity, Japanese versions and/or Yellow may be kept in a separate branch, or even a separate directory in the repo. But in cases where it doesn’t hurt the complexity to include data from those versions, I like to.

#7 2012-01-15 00:59:26

KuroiIeWa5Da
New member
Registered: 2012-01-14
Post 3/5

Re: Is you PokeRed Disassembly 1:1 with the original file

How do I get started contributing?

I was looking through the text code and noticed a lot of special control characters so I replaced them with a named constant like:
$55 -> TBLOCK_WAIT_SCROLL, because it pauses in a text-block and waits for input before scrolling 1 line.

It makes it a lot easier to read through text when the control characters are labeled

Offline

#8 2012-01-15 06:43:05

428/700

Re: Is you PokeRed Disassembly 1:1 with the original file

KuroiIeWa5Da wrote:

It makes it a lot easier to read through text when the control characters are labeled

This isn’t a big help. There are only a couple of text codes in this context, and using long constant names makes things less readable in my opinion (akin to using “elementnumber” instead of “i” in a for loop).

KuroiIeWa5Da wrote:

How do I get started contributing?

Best way is to come to the chat room.

#9 2012-01-15 15:48:17

kanzure
Member
From: Austin, Texas
Registered: 2012-01-15
Post 1/19
Website

Re: Is you PokeRed Disassembly 1:1 with the original file

Issue #4 could use some love, and is an okay task to start with.

Offline

#10 2012-01-16 06:35:55

KuroiIeWa5Da
New member
Registered: 2012-01-14
Post 5/5

Re: Is you PokeRed Disassembly 1:1 with the original file

I've filled this under issue #16 but here's my big holdup, I would love to tackle issue #4:

========================
I want to contribute to this project but I need to get up to speed on things and I can't find any answers. I would be more than happy to help out with maps, map pointers, sound, disassembly, etc... as well as connecting adjacent code.

I need to learn the binary formats like image formats, compressions, map header structures, how maps are implemeted, other binary layouts and configuration. How scripts are implemeted and tied to the maps, other stuff such as events.

I don't mind disassembling by hand or writing my own disassembler but I think you already have one in your extras section. What is the extras section used for. I have no expirience with python but I would gladly learn it if the extras section already has useful tools.

How do I commit to this project, am I allowed to commit, if not what's the procedure to become a committer. What are the rules or guidelines for commiting.

I need to be brought up to speed on Pokemon specific setups, structures, etc, in order for me to be really helpful in fishing out and decyphering content from the ROM's.

Can somebody point me in the right direction or answer these questions. I really want to spend a lot of time in developing this project but I can't be of much use without knowing the above.
========================

Offline

#11 2012-01-16 06:40:34

kanzure
Member
From: Austin, Texas
Registered: 2012-01-15
Post 3/19
Website

Re: Is you PokeRed Disassembly 1:1 with the original file

KuroiIeWa5Da wrote:

I've filled this under issue #16 but here's my big holdup, I would love to tackle issue #4:

Yep, we've responded here, here and here.

Offline

Board footer

Powered by FluxBB