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

Author Topic: How were original GB/GBC games developed?  (Read 15856 times)

FernandoAiresCastello

  • Jr. Member
  • **
  • Posts: 7
    • View Profile
    • My personal blog
Re: How were original GB/GBC games developed?
« Reply #20 on: May 13, 2012, 04:52:55 pm »
You can use a code data logger if there are any GB emulators/debuggers that support this. You could also disassemble part of the ROM and see whether it looks like actual code or not.

Thanks for your replies :thumbsup:

Code from data- are you thinking about overwriting something or just trying to find the starting point?

Actually I'm not hacking anything yet, I'm just doing some reverse engineering on the portable Zelda games, so I'm trying to find out where I can find all the code and all the data within the ROM.

Now that you mentioned it I had noticed that all GB/GBC ROMS (all that I have checked) have a NOP followed by JP $0150 at address 0100, and I was wondering if that was the entry point. Thanks for the links, I have to learn more about the structure of GBC ROM images.

Lin

  • Full Member
  • ***
  • Posts: 117
    • View Profile
Re: How were original GB/GBC games developed?
« Reply #21 on: May 13, 2012, 05:28:15 pm »
I think it's pretty easy to tell what games were and weren't written in assembly. For example, a majority of the Oracles games probably wasn't, because even though the both Ages and Seasons use the exact same engine, memory addresses for stuff like map and tileset information is different when they don't need to me. Perhaps they just had a fancy assembler that accounted for variables, I don't know. I also think the code is just too space-efficient to be done by humans in a reasonable amount of time (Perhaps I'm thinking the exact opposite of what it really is). Plus, look at games like Megaman Xtreme 1/2. The constant popping and pushing and seemingly-unnecessary storing in HRAM is ridiculous and incredibly hard to follow. No human in his/her right mind would do what those games did. Honestly, I have no real answer. This is just my guess.

syntax error

  • Full Member
  • ***
  • Posts: 227
    • View Profile
Re: How were original GB/GBC games developed?
« Reply #22 on: May 13, 2012, 05:50:25 pm »
the oracles were planned as a series of 3 games,perhaps you will find remains of the third.

FernandoAiresCastello

  • Jr. Member
  • **
  • Posts: 7
    • View Profile
    • My personal blog
Re: How were original GB/GBC games developed?
« Reply #23 on: May 13, 2012, 07:18:12 pm »
the oracles were planned as a series of 3 games,perhaps you will find remains of the third.
The cancelled third game was supposed to feature color-based puzzles. As far as I know they adapted some aspects from it into Oracle Of Ages. I doubt they would throw any code away, so the entire code for the third game must have been adapted.

BTW there is a dungeon in Oracle Of Ages where you have to solve color-based puzzles.
I'm pretty sure that dungeon holds the remains of the cancelled game...

snarfblam

  • Submission Reviewer
  • Hero Member
  • *****
  • Posts: 589
  • CANT HACK METROID
    • View Profile
    • snarfblam
Re: How were original GB/GBC games developed?
« Reply #24 on: May 13, 2012, 07:49:30 pm »
For example, a majority of the Oracles games probably wasn't, because even though the both Ages and Seasons use the exact same engine, memory addresses for stuff like map and tileset information is different when they don't need to me. Perhaps they just had a fancy assembler that accounted for variables, I don't know.
I wouldn't be surprised if much of the game's code was written in C, but what you're describing is a rather basic feature for an assembler.

KingMike

  • Forum Moderator
  • Hero Member
  • *****
  • Posts: 6893
  • *sigh* A changed avatar. Big deal.
    • View Profile
Re: How were original GB/GBC games developed?
« Reply #25 on: May 13, 2012, 10:58:09 pm »

The above covers everything in detail but the basic way is the entrypoint is at 100h in the rom (which apparently most of the time just points at 150h aka the end of the header but there is nothing that requires it to be that and indeed games did do it apparently- 100h should just contain the relevant jump though).

The GB CPU's boot ROM is mapped into 0-00FF. The last instruction of the boot ROM disables itself, mapping in 0-00FF of the cart ROM. So the first instruction of the cart ROM executed will be 0100. I believe it is always a jump instruction, because I think after that it a copy of the Nintendo logo. The GB boot ROM expects an EXACT copy of the Nintendo logo (identical to the copy stored in the boot ROM) to exist at that address in the cart ROM or else it won't boot (well, on a real console, most emulators probably don't care.)

(that was an attempt by Nintendo to stop unlicensed developers by forcing them to include Nintendo's trademark? copyright? protected logo, leaving them open to a lawsuit from Nintendo if they weren't authorized to use its logo.
Or at least in theory. From my understanding of Sega vs. Accolade, it was ruled trademark violation is permissible if it is necessary to gain access to the hardware. (Sega's protection on SMS/Genesis was similarly based on forced-trademark-violation.)
"My watch says 30 chickens" Google, 2018

BRPXQZME

  • Hero Member
  • *****
  • Posts: 4572
  • じー
    • View Profile
    • The BRPXQZME Network
Re: How were original GB/GBC games developed?
« Reply #26 on: May 13, 2012, 11:11:32 pm »
That was how Sega explained it in the case. Nintendo probably had the same idea, but they didn’t end up being the ones who had to explain that for the public record.
we are in a horrible and deadly danger

FAST6191

  • Hero Member
  • *****
  • Posts: 2576
    • View Profile
Re: How were original GB/GBC games developed?
« Reply #27 on: May 14, 2012, 03:53:56 am »
Sega vs accolade was a big one but remember before that (the original was a bit before but the appeals court that handled this also ruled on Sega vs accolade a month later) Nintendo had a case vs Atari based on a similar logic (although Atari became a licensee and broke the contract to do the reverse engineering as opposed to Accolade's straight up RE work which was different in the end)- http://digital-law-online.info/cases/24PQ2D1015.htm
I will save speculation as to whether this made Nintendo's thoughts and operating logic that different but hey.

Others that site also has a pretty good readup of sega vs accolade as well http://digital-law-online.info/cases/24PQ2D1561.htm

This being said Nintendo's lawyer happiness here had a bit of a trickle down effect- quite a few pieces of GBA homebrew came without a header (with tools to add them in being made) which caused and in some cases still causes (if carts use hard reset to launch) issues although some of that might have used leaked SDKs but this is rapidly getting off topic so back to the GB/GBC.

tc

  • Hero Member
  • *****
  • Posts: 1125
  • Lum Fan
    • View Profile
    • Eon Blog
Re: How were original GB/GBC games developed?
« Reply #28 on: May 15, 2012, 12:35:34 am »
That's right, it says to go to address 0x106000. Problem is, that address is beyond the 1 MB size of all licensed releases.

What type of bankswitching technique did Pokemon Gold/Silver use? They were expanded to 2 MB when localized outside Japan, and still run on the classic GB.

KingMike

  • Forum Moderator
  • Hero Member
  • *****
  • Posts: 6893
  • *sigh* A changed avatar. Big deal.
    • View Profile
Re: How were original GB/GBC games developed?
« Reply #29 on: May 15, 2012, 01:05:01 am »
Pokemon Gold & Silver use MBC3, according to the ROM Properties when I open it in VBA.

Sorry if it was unclear, but the quoted line meant "all authorized versions of Zelda DX are 1 MB.". I'm pretty sure ROM size alone doesn't affect compatibility. Star Ocean Blue Sphere is 4 MB (the maximum of licensed GB/GBC games. The documentation I've seen on MBC5 says it can support 8 MB, but I don't know if it was ever used.) and does have a monochrome mode.
"My watch says 30 chickens" Google, 2018

tc

  • Hero Member
  • *****
  • Posts: 1125
  • Lum Fan
    • View Profile
    • Eon Blog
Re: How were original GB/GBC games developed?
« Reply #30 on: May 15, 2012, 06:37:08 am »
Densha de Go 2 was that GBC game with 8 MB. Whole LOT of minimally colored 8 bit railroad after railroad I presume.

cret

  • Jr. Member
  • **
  • Posts: 75
    • View Profile
Re: How were original GB/GBC games developed?
« Reply #31 on: February 15, 2014, 08:17:39 pm »
I would say they used assembler.
Let me expalin why.
Let's look at a big game: Pokemon Red:
1. Did you know, that Mew is the only pokemon whose data are in rombank 0. One of the developers once said that the reason for this is, that they had some problems with the pokemon-data-structure and that they didn't want to change something on it when Mew joined the pokedex. Most of the game was done and worked fine (hahahaha). So they just overrode some debug-stuff (but not all of it) and placed Mew there.
2. what about tiny unused code-chunks. I gues no comiler would produce that
go r2, use debug. .... White hand was fainted

Myria

  • Jr. Member
  • **
  • Posts: 49
    • View Profile
Re: How were original GB/GBC games developed?
« Reply #32 on: February 15, 2014, 09:31:25 pm »
I know that it's not GB/CGB, but someone told me once that Legend of the Holy Sword 3 was written primarily in C even though it was a SNES game.  No idea whether that's true.  Is that the only Square SNES game written in C, if so?

I certainly never saw any GB/CGB games written in C.  It's just too slow to be useful.

The C language predates the Atari 2600, so of course games could be written in C...

Midna

  • Hero Member
  • *****
  • Posts: 703
  • Resident Panel de Pon Nut
    • View Profile
Re: How were original GB/GBC games developed?
« Reply #33 on: February 15, 2014, 11:03:58 pm »
1. Did you know, that Mew is the only pokemon whose data are in rombank 0. One of the developers once said that the reason for this is, that they had some problems with the pokemon-data-structure and that they didn't want to change something on it when Mew joined the pokedex. Most of the game was done and worked fine (hahahaha). So they just overrode some debug-stuff (but not all of it) and placed Mew there.

Another reason for Mew being in such an odd location might be that it was chronologically the last Pokémon to be placed into the game.

KingMike

  • Forum Moderator
  • Hero Member
  • *****
  • Posts: 6893
  • *sigh* A changed avatar. Big deal.
    • View Profile
Re: How were original GB/GBC games developed?
« Reply #34 on: February 16, 2014, 12:38:53 am »
The C language predates the Atari 2600, so of course games could be written in C...

Probably not likely.
So I hear with the Atari 2600, you pretty much HAD to write INSANELY precise (which is not C or probably any high-level language) code to pull off much of anything with the limited hardware.
"My watch says 30 chickens" Google, 2018

cret

  • Jr. Member
  • **
  • Posts: 75
    • View Profile
Re: How were original GB/GBC games developed?
« Reply #35 on: February 22, 2014, 08:16:40 pm »
What i wanted to say was, if you use a compiler you there is no need for such a hack, because you won't have those problems
go r2, use debug. .... White hand was fainted

tomaitheous

  • Hero Member
  • *****
  • Posts: 543
    • View Profile
    • PC Engine Dev
Re: How were original GB/GBC games developed?
« Reply #36 on: February 23, 2014, 09:43:39 pm »
One of the reasons why C and other high level languages weren't popular for consoles, is that the code generation was often larger than anything you did with assembly. That mattered quite a bit back then. Compilers were still rather unoptimized in the early to mid 90's (both code and speed). I would think the z80 would lend it self better to a C compiler than a 65x, but still, assembly isn't that hard. It's rather easy, actually. Macro's can help with consolidating code in the source file, so that it's easier to read - as well.

 That said, some Genesis games were coded in C, with assembly mixed in to speed it up. Ecco is one of them. But of course, 68k is very compiler friendly. Hell, coding in 68k asm is almost like a high level language compared to 65x asm - heh. 68k has got to be the easiest processor that I've ever coded for. It's almost a difficult task to write piss poor performance code for 68k.