Romhacking.net

Romhacking => ROM Hacking Discussion => Topic started by: FernandoAiresCastello on May 11, 2012, 12:57:05 pm

Title: How were original GB/GBC games developed?
Post by: FernandoAiresCastello on May 11, 2012, 12:57:05 pm
Hi. Does anybody know in which language the original Gameboy/Gameboy Color games were developed?
How would they program the games, in pure Assembly or C or C++?
Thanks.
Title: Re: How were original GB/GBC games developed?
Post by: Nightcrawler on May 11, 2012, 01:15:38 pm
Most console and portable games prior to the Playstation era were developed in assembly. The CPUs had two few registers, limited stack depth, and slow speeds to effectively use C/C++ for a performance oriented game. Leaked source code that I know of is also all in assembly. There's a few exceptions to the rule, but chances are it was assembly.
Title: Re: How were original GB/GBC games developed?
Post by: Garoth Moulinoski on May 11, 2012, 02:28:36 pm
Interesting. So the PS1 was the first console powerful enough to allow developers to code in C? What about the N64? Surely that had to have enough juice, right?

Maybe I should take a look at their specs one day...
Title: Re: How were original GB/GBC games developed?
Post by: Nightcrawler on May 11, 2012, 02:44:12 pm
First, N64 came out AFTER Playstation.

Second, developing in C was POSSIBLE on earlier platforms, it just wasn't the norm due to hardware limitations and resulting performance. The provided dev kits also played a part. There may have been no C compiler provided by the manufacturer and few companies would roll their own.

Third, I mentioned there ARE some exceptions. If nothing else, there's definitely C based homebrew code.

Lastly, I don't claim to know what all software for all platforms were coded in. I speak in terms of the normal of the era and not in absolute.  :)
Title: Re: How were original GB/GBC games developed?
Post by: Garoth Moulinoski on May 11, 2012, 04:17:52 pm
Ah, alright. I could have sworn that N64 came first... Maybe because I only got my PlayStation well into the first year of the PS2. :P My bad.
Title: Re: How were original GB/GBC games developed?
Post by: syntax error on May 11, 2012, 05:31:10 pm
If you want to start homebrew on hardware that is new to you,use a C compiler like z88dk or CC65 or gcc.
Could be a problem to find one for 65816.

The Saturn (2 CPUs, difficult 3D chip) and Jaguar (wierd chip problems)were the  first consoles that supplied C .
The N64 has a cut down "PCB cost saving" version of the CPU used in SGI OpenGL workstations and RDRAM.
It was Nintendos answer to the PS1 and the Saturn.
Title: Re: How were original GB/GBC games developed?
Post by: FernandoAiresCastello on May 11, 2012, 06:21:00 pm
Most console and portable games prior to the Playstation era were developed in assembly. The CPUs had two few registers, limited stack depth, and slow speeds to effectively use C/C++ for a performance oriented game. Leaked source code that I know of is also all in assembly. There's a few exceptions to the rule, but chances are it was assembly.
:thumbsup: Thanks.

I wanted to know because I started analyzing and reverse engineering the code for the portable Legend Of Zelda games (especially the Oracles), and I think it's important to know what language was used to develop them (C/C++ compilers usually do a lot of optimization, etc, and the resulting Assembly code sometimes gets obfuscated by the techniques used which makes it harder to understand).

I simply love those games and I want to know how they work in detail. I have even developed (in C++) a GB-Z80 disassembler that generates plain text files or HTML pages containning the entire disassembled code from any GB/GBC ROM and the raw bytes and ASCII representation, etc. I'm going to send this disassembler to the Utilities page in case someone is interested in disassembling GB/GBC game ROMs. :beer:
Title: Re: How were original GB/GBC games developed?
Post by: BRPXQZME on May 11, 2012, 09:00:36 pm
The Saturn (2 CPUs, difficult 3D chip) and Jaguar (wierd chip problems)were the  first consoles that supplied C .
The N64 has a cut down "PCB cost saving" version of the CPU used in SGI OpenGL workstations and RDRAM.
It was Nintendos answer to the PS1 and the Saturn.
I do imagine SGI workstations had something to do with both Sony and Nintendo picking MIPS. But of course, I have no way of proving that :P
Title: Re: How were original GB/GBC games developed?
Post by: goldenband on May 11, 2012, 10:27:44 pm
Most console and portable games prior to the Playstation era were developed in assembly. The CPUs had two few registers, limited stack depth, and slow speeds to effectively use C/C++ for a performance oriented game. Leaked source code that I know of is also all in assembly. There's a few exceptions to the rule, but chances are it was assembly.

One interesting exception, BTW, is Utopia for the Mattel Aquarius, which was apparently the only Mattel game developed in C (http://www.intellivisionlives.com/bluesky/games/credits/coleco.html#masters).  (Technically the Aquarius was a home computer, not a console in the conventional sense, but since it used carts and wasn't exactly a powerhouse, I'd say it's worth mentioning.)

I know some current ColecoVision homebrew developers write in C, but I'm not sure how their compilers and development tools compare to the original tools. (Favorably, no doubt.)

Both of these are Z80-based platforms like the GB.
Title: Re: How were original GB/GBC games developed?
Post by: Hamtaro126 on May 12, 2012, 12:00:30 am
I wanted to know because I started analyzing and reverse engineering the code for the portable Legend Of Zelda games (especially the Oracles), and I think it's important to know what language was used to develop them (C/C++ compilers usually do a lot of optimization, etc, and the resulting Assembly code sometimes gets obfuscated by the techniques used which makes it harder to understand).

I also know that Zelda GB Sound is using the same engine as For The Frog The Bell Tolls, as well as Balloon Kid, Dr. Mario, Super Mario Land 1 and 2, etc.

The Music Engine is also used in NES as that variant adjusted the notes a bit as well as having DPCM. (Hello Kitty World is a Famicom port of Balloon Kid, Same with NES Dr. Mario)
Title: Re: How were original GB/GBC games developed?
Post by: Jedi QuestMaster on May 12, 2012, 03:32:44 am
Wasn't The Wily Wars done in C? With consequences, of course >:D (http://www.youtube.com/watch?v=_hXvr-9Al2w)
Title: Re: How were original GB/GBC games developed?
Post by: FernandoAiresCastello on May 12, 2012, 02:54:13 pm
I wonder if the Zelda games for GB really haven't been developed in C, at least parts of them.

I'm just saying because sometime ago I found this rather old (2007) article entitled "Game Development Archeology: Zelda on Game Boy comes with source" (http://www.pagetable.com/?p=28). I don't know if the information there is legit (it seems legit). Supposedly the ROM image for Zelda DX includes big chunks of Borland’s Turbo C IDE (Turbo Vision interface) for DOS, as well as traces of the “QBasic” MS-DOS Editor... :huh:

What do you think about that?
Sounds interesting to me.
Title: Re: How were original GB/GBC games developed?
Post by: Vehek on May 12, 2012, 02:55:45 pm
I've heard about that. It's actually from a Chinese translation, not the original game.

Why it isn't. (http://board.byuu.org/viewtopic.php?p=31550#p31550)
Title: Re: How were original GB/GBC games developed?
Post by: FernandoAiresCastello on May 12, 2012, 04:04:24 pm
I've heard about that. It's actually from a Chinese translation, not the original game.
I didn't know that... Well then I guess the original game was entirely written in Assembly.

It's just amazing how they were able to develop entire games in Assembly language. But I'm pretty sure they used proprietary tools to create all the graphics and sound, and to design the levels.
Title: Re: How were original GB/GBC games developed?
Post by: KingMike on May 12, 2012, 10:29:44 pm
I've heard about that. It's actually from a Chinese translation, not the original game.

Why it isn't. (http://board.byuu.org/viewtopic.php?p=31550#p31550)

That's right, it says to go to address 0x106000. Problem is, that address is beyond the 1 MB size of all licensed releases.
Also, notice this source code is trying to read "zeldag.gb", obviously a ROM file. Why would the real game's source code need to read its own output? :P

About Tintin in Tibet... never played it, is the GBC version a straight port of the non-GBC version?
Does the game actually contain enough content to warrant a size increase from 256KB to 1MB? If not, that could explain junk data ending up in the ROM.
(I suspect maybe GBC PCBs had a 1MB minimum. Only reason I can think of why Pong - The Next Level is 1MB, even though the actual used data is just over 64KB (the rest is all zeros, or mabye FFs.) )
Title: Re: How were original GB/GBC games developed?
Post by: FAST6191 on May 13, 2012, 05:23:46 am
Thought I might chime in. Despite a few taking their scripting to a reasonably high level (I do not know if I can actually say Turing complete in a sensible/non esoteric manner or even known language but the scope for a total conversion without it looking like a reskin* was doable for some) I would have to agree with the assessment that late 90's vintage and especially early 90's vintage C cross compilers (the cross compiler distinction apparently still mattered then) for the z80 were not up to much so it was ASM or bust. However the situation in practice resembles something like HLA ( http://homepage.mac.com/randyhyde/webster.cs.ucr.edu/index.html although without the memory management side of things) or at least some fair libraries for basic functions not available on the GB or in the BIOS (to say nothing of the SGB- http://nocash.emubase.de/pandocs.htm ). It is still largely programming in the functional/procedural paradigm of course but if I may make a terrible analogy it was not necessarily a man and his bare metal but a man and some sheets, some I beams, some bending equipment, a crane and a welder it needed to be. Naturally then as now people threw away all but the basics from the SDK and built something from the ground up

Also although I seem to share the indifference towards pokemon many others around here and elsewhere in ROM hacking seem to share I certainly can not deny the usefulness of things like
https://bitbucket.org/iimarckus/pokered/src

*that sounded a bit nasty. For the record I quite often prefer playing and working on total conversions, alterations and such as opposed to getting in on translations.
Title: Re: How were original GB/GBC games developed?
Post by: FernandoAiresCastello on May 13, 2012, 06:47:05 am
Just some ROM related questions:

Is there an easy way to tell code from data in a GBC ROM image?
What do you guys usually do when you're hacking a ROM and you have to find out where code/data is located?
Are .GB and .GBC ROM files perfect copies from Game Boy cartridges? Or do they encode more information than a real GB cartridge (i.e. do they have a header read only by emulators, etc)?
Title: Re: How were original GB/GBC games developed?
Post by: snarfblam on May 13, 2012, 10:57:30 am
Is there an easy way to tell code from data in a GBC ROM image?
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.

What do you guys usually do when you're hacking a ROM and you have to find out where code/data is located?
It really depends on the circumstances. Usually I'm looking for something specific, and in that case there's either a pattern you can search for in the ROM, or when all else fails, use a debugger to reverse engineer the program.

Are .GB and .GBC ROM files perfect copies from Game Boy cartridges? Or do they encode more information than a real GB cartridge (i.e. do they have a header read only by emulators, etc)?
Google told me that gameboy roms are plain ol' ROM images. They contain an internal header, which is actually stored in the ROM on the cart.
Title: Re: How were original GB/GBC games developed?
Post by: KingMike on May 13, 2012, 01:13:56 pm
What surprising about one of those games in the article (I think it was the Tintin game) was that it actually stores debug text at the very beginning of the ROM (starting at address 0).
Doesn't that screw up the reset vectors? (or does the GB not automatically use them? In which case it wouldn't break the game as long it never used RST instructions? I can't remember.)
Title: Re: How were original GB/GBC games developed?
Post by: FAST6191 on May 13, 2012, 03:22:25 pm
Code from data- are you thinking about overwriting something or just trying to find the starting point?

The former is a pain and only made worse by bankswitching that some roms could use (the GBA and DS are so much nicer here). I am not aware of any "mapper change" style hacks for the GB/GBC (the theory being you could add it to the ROM and manually trigger a bank switch a la a branch instruction in a conventional "interrupt"/jump style assembly hack) but frankly I have not really looked. If it works the way I think it does it would be orders of magnitude easier than the NES mapper change hacks (will probably still see you messing around with assembly but the nicer stuff) so that was probably not the best thing to compare it to.

If you just want to find the entrypoint on the cart to get the start of the binary
http://nocash.emubase.de/pandocs.htm#powerupsequence
http://nocash.emubase.de/pandocs.htm#thecartridgeheader
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). It is pretty similar to how the GBA does it.
In theory I guess the binary works from there and is all in one piece but there is no technical reason to do so and as this thread has probably already demonstrated the GB/GBC was still assembly country and many odd things were done.

As for KingMike's question afraid I do not know enough about the reset functions to comment and the pandocs do not really cover it well either.
Title: Re: How were original GB/GBC games developed?
Post by: FernandoAiresCastello 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.
Title: Re: How were original GB/GBC games developed?
Post by: Lin 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.
Title: Re: How were original GB/GBC games developed?
Post by: syntax error 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.
Title: Re: How were original GB/GBC games developed?
Post by: FernandoAiresCastello 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 (http://www.zeldawiki.org/Oracle_Series#The_Triforce_Series). 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...
Title: Re: How were original GB/GBC games developed?
Post by: snarfblam 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.
Title: Re: How were original GB/GBC games developed?
Post by: KingMike 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.)
Title: Re: How were original GB/GBC games developed?
Post by: BRPXQZME 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.
Title: Re: How were original GB/GBC games developed?
Post by: FAST6191 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.
Title: Re: How were original GB/GBC games developed?
Post by: tc 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.
Title: Re: How were original GB/GBC games developed?
Post by: KingMike 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.
Title: Re: How were original GB/GBC games developed?
Post by: tc 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.
Title: Re: How were original GB/GBC games developed?
Post by: cret 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
Title: Re: How were original GB/GBC games developed?
Post by: Myria 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...
Title: Re: How were original GB/GBC games developed?
Post by: Midna 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.
Title: Re: How were original GB/GBC games developed?
Post by: KingMike 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.
Title: Re: How were original GB/GBC games developed?
Post by: cret 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
Title: Re: How were original GB/GBC games developed?
Post by: tomaitheous 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.