How were original GB/GBC games developed?

[FernandoAiresCastello]

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.

[Nightcrawler]

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.

[Garoth Moulinoski]

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...

[Nightcrawler]

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. 

[Garoth Moulinoski]

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. My bad.

[syntax error]

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.

[FernandoAiresCastello]

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.

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.

[BRPXQZME]

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

[goldenband]

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.  (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.

[Hamtaro126]

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)

[Jedi QuestMaster]

Wasn't The Wily Wars done in C? With consequences, of course

[FernandoAiresCastello]

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". 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...

What do you think about that?
Sounds interesting to me.

[Vehek]

I've heard about that. It's actually from a Chinese translation, not the original game.

Why it isn't.

[FernandoAiresCastello]

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.

[KingMike]

I've heard about that. It's actually from a Chinese translation, not the original game.

Why it isn't.

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?

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.) )

[FAST6191]

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.

[FernandoAiresCastello]

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)?

[snarfblam]

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.

[KingMike]

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.)

[FAST6191]

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.