Posted
by
Soulskill
on Tuesday September 29, 2009 @03:47AM
from the what's-a-decade-among-friends dept.

An anonymous reader writes "Costis was able to dump the elusive boot ROM from the Gameboy Color by using various voltage and clock glitching tricks. The boot ROM is what initializes the Gameboy hardware, displays the 'GAMEBOY' logo and animation, and makes the trademarked 'cling!' sound effect. Even decapping the CPU had failed previously, but now the boot image and specifics on how it was dumped (along with many photos) are available for download."

There is a mod that can allow a GB access to an IDE device such as a hard drive, so technically, yes, it could run Win 7 in a super-slow-as-fuck emulation.
For those of you who actually would like to KNOW what the boot ROM does, there is a link ON THE PAGE to a work-in-progress commented disassembly of the entire ROM, as has been previously been done with the GameBoy Mono and Super GameBoy.

The GBC uses a Sharp CPU similar to a Z80, but not quite the same. The one in the GBC is extremely fast. So fast, in fact, that once Windows finishes booting, we'll still have time to get drinks and salads and Milliways before the Big Show.

I really love reading about the lengths enthusiasts go to when trying to do this kind of thing. For some reason I had assumed that this had been done already since there is already emulation for gameboy color, right? Can someone explain the significance of this development?

I really love reading about the lengths enthusiasts go to when trying to do this kind of thing. For some reason I had assumed that this had been done already since there is already emulation for gameboy color, right? Can someone explain the significance of this development?

The gameboy bios was also "emulated" before, so this makes the emulation more "realistic".
It happens the same with the GBA. While you can emulate games for the GBA without the need for a BIOS file, if you have one, they'll run better \ more accurately (or in some cases, they run instead of not running).

It happens the same with the GBA. While you can emulate games for the GBA without the need for a BIOS file, if you have one, they'll run better \ more accurately (or in some cases, they run instead of not running).

It really just displays the logo and validates that the Nintendo copyrighted startup logo is present in the ROM. It was a trick to try and prevent third-party publishers from making their own releases. As soon as the Game Boy cartridge is started, the boot ROM is locked out completely and no longer needed.
The GBA BIOS is quite different, it has tons of functions like various decompression routines, and without it you tend to have far less accurate timing and you may miss potential edge cases. Think of it as low-level emulation with the BIOS, and high-level emulation (in the vain of N64 graphics emulation) without it.

This allows Game Boy Color emulators to display an authentic intro before running the game, including the palette selection available when running a non-color game. There's otherwise no benefit that I can see. This includes initial register values, since those could already be determined via software. Some of the other initial state, like sound registers set by the boot ROM, is more difficult to determine, so this helped there.

When reverse-engineering hardware, it's nice to figure out every detail, and this was one of the much harder ones to figure out. Decapping usually reveals all, but even that failed here.

Are you sure decapping failed here? Without any other sources to go by than the article it seems that the decapping was a success despite what the summary says.

Even decapping the CPU had failed previously...

There was great news in the GB scene a short while ago, when Neviksti from CherryRom forums announced that he had been able to extract the BIOS image from the original GameBoy by decapping the chip, staining the ROM, and using a really powerful microscope to individually resolve and read out each bit one by one.

The gameboy color decapping attempts in 2005 (after the mono was successfully decapped) was a failure because the decapping was done by a student with little experience. I sacrificed a couple gbc units for that effort and one unit for a professional decap/bit stain which cost too much so it never happened. This glitching hack was discussed for many years before someone got the right idea.This RE effort has rewarded us with info about hidden hardware registers that only the boot ROM uses.

This is also an interesting development because Costis achieved the same goal as the decapping of the original GameBoy CPU, but with vastly cheaper equipment (< $100) and probably in less time (< 1 week).

Glitching is a neat technology; it's most famously used by "card unloopers" for smartcard hacking, and is also used by modern Wii modchips. Travis Goodspeed [blogspot.com] gave a neat presentation at DefCon 2009 [defcon.org] about glitching, and has released some open-source hardware [sourceforge.net] which will eventually support glitchin

So I took a stroll through the binary and here is what it does in a nutshell.

- Catch the wake interrupt- Resent the CPU- Power on the LED- Power on the LCD- Power on the audio codec- Copy the Nintendo graphic to VRAM- Play the Clang WAV- Initialize the buttons- Copy game binary to memory- Jump to game image

I doubt it powers on the LED. The LED on a GBC turns on even without a clock crystal, before the CPU runs any instructions. It may just be redundantly enabling an already enabled LED though. There's also no such thing as the clang "WAV": this is fixed-function sound hardware, so all it does is configure it to output the two notes. And it certainly doesn't copy the game binary to memory, since this is a system that uses ROM cartridges with in-place execution.

Here's my summary of how he did it, since the linked blog posting is quite long:

When the Game Boy Color powers up, a small internal boot ROM is enabled inside the CPU. This displays the logo, verifies that the game ROM is "genuine", then starts executing it. Just before it starts executing user code, it disables the boot ROM by writing to an I/O register. Once disabled, there is no way to re-enable it, thus user code can't easily read the ROM.

Costis found that if he stopped the CPU clock for a few seconds, then restarted it, many of the CPU registers (including the program counter) would take on random values. So he placed NOP instructions in all external memory, along with a small dump routine, then stopped and restarted the clock just before the boot ROM wrote to the I/O location to disable itself. This caused the program counter to take on a value outside the boot ROM, and execute all the NOPs until it hit his small dump routine.

Thanks for that excellent summary. Just one addition - he didn't just stop the clock, I believe he also had to briefly remove power from the chip in order to get the random values in the registers/ program counter.

I have to say I have nothing but the greatest respect for the guy. I'd love to be smart enough to manage something like this.

So it took us 10 years to find a reset button. Good job guys, I have real hope for the future now.
On a serious note thanks for the rundown noidentity, this acctually makes me want to read the full article more then the summary did.

Well, let me try. Imagine you're chasing a car (the Gameboy Color), and you want to know what's in the trunk (the ROM). The driver (the CPU) isn't talking. However, you've got a remote control button that can jam on the brakes (stop the clock). This by itself doesn't let you see what's in the trunk. But you find that by hitting the driver with a large blunt object (shorting the 3.3V to ground), you can daze him (randomize the registers) and eventually get him to do what you want, like listen to your re

This reminds me of the epiphanic moment during the garage scene in Primer:

"I did not remove any of the bypass caps on the mainboard for the 3.3V rail and it seems like a few seconds are actually required for the internal logic to discharge appreciably (anything less and the system continues running just fine afterward.)"

Because that's the degree of precision necessary when working with analog electronics that aren't intended to function as timing devices. Anything more precise would be unnecessary, anything less would be insufficient.

Basically, costis attempted the precise method (clock glitching during ROM disable), which didn't work. So he pulled out the sledgehammer (massive clock and power glitching to randomize CPU state). You don't need much accuracy with a sledgehammer.

Why can't you just take the rom chip out of the gameboy, put it in a socket on a computer and just read the rom 1 byte at a time?

I am just a software guy, with no real lowlevel knowledge of hardware, but I would think you could just take the chip out*, solder the legs from the rom chip, on any kind of socket that take a rom chip, and then just read it from there. But I guess there is a reason you can't just do that. So what reason is that?

*Might take som magic, but when thinking about how the *&#*$ surface mounted chips serial/io chip were changed on the Amiga 500, it can't be that impossible.

Isn't it because the CPU and ROM are together in an ASIC package and the ROM can't be accessed directly externally through the pins? I could be wrong. If the ROM is a seperate chip then I've no idea why you couldn't do this.

I am not familiar with the specifics of gameboy hardware. But increasingly (like with cellphones) the rom is melded with the cpu and has no external bus exposed. This method worked with the gameboy because it read an external cartridge at some point. Nonetheless, it certainly is an interesting method that certainly would have use elsewhere. He should get some kind of award.

Why can't you just take the rom chip out of the gameboy, put it in a socket on a computer and just read the rom 1 byte at a time?

Because the boot ROM is built into the custom CPU. The data bus to this ROM isn't exposed on any of the pins; when enabled, it bypasses whatever is being sent to the external data bus pins on the CPU, so that its contents are never seen by the outside world.

A close comparison is the L1 cache inside a modern CPU. When the CPU is reading from it, you can't know what is in it, since the data isn't output to the bus.

The ROM is not on a chip, it's burned into the CPU die itself. There are no memory access lines which reach it. It's only able to be read from within the CPU itself, and there is a CPU register which permanently disables that data path, once that specific register is written to. The last instruction in the boot ROM writes to that register, the boot ROM eats the poison pill, and the next instruction is the start instruction of your cartridge ROM.

Great, been waiting for that for ages. So now we might finally get those original GBC colors for GB games in emulators (and especially the coloring for Metroid 2!).
For reference, if anyone is interested, here's the story how the original GB ROM got dumped by decapping the chip holding it and reading out the values with a Microscope: http://www.cherryroms.com/forums/copier-and-hardware-forum/manually-extracting-rom.html?page=2 [cherryroms.com] (two thirds down the pge, the post by nevikisti from Wed, 05/18/2005 - 10:26). Thread itself deals with how they tried to dump the SNES DSP1 chip, but ultimately failed to do so. Currently there's some effort underway by the creator of bsnes to do the same thing: http://byuu.org/ [byuu.org]

Does this mean that we will be able to colorize Non-Super Gameboy Game Boy Games?

When a Gameboy Color starts up with a Super Gameboy boy game is put into a Super Game Boy, it uses the Super Gameboy Palette with the border that would normally be used on a TV omitted.

Examples of this:

Pokemon Red/Blue/YellowDonkey Kong

Alot of people thought that Pokemon games were Gameboy Color games, and some are, like Pokemon Crystal, but alot of the games are actually Super Gameboy Games.

Classic Gameboy games such as Tetris, Super Mario Land, and Metroid II had no colorization, so the Gameboy color and Super Gameboy would color them based on an alogorithm. No emulators exist that can colorize a non-Super Gameboy game. They are displayed in Gray Scale.

My question is, will the dumping of this Bios lead to a better understanding of how Non-Super Gameboy Games are colorized on the Game Boy Color?

My understanding is that there's no "algorithm", rather the GBC has preset palettes for recognised Gameboy games such as Metroid II and a single palette for the remainder. Could be wrong though, it's not like I have the most extensive retro collection to test it out with. At any rate, having the ROM dump should finally be able to set the matter to rest.

There is a hashtable of GameBoy Mono games which are recognized by the GameBoy Color, and it applies a preset color scheme that Nintendo chose to make the game stand out better. Metroid II is a perfect example of this coloring.
All of these GBC colored B&W games are run in plain B&W mode, even if they have Super GameBoy features, as the GBC is not a Super GameBoy and doesn't have the same features.
There is a disassembled source file to the GBC Boot ROM linked on the dumper's website, with most of it commented and disassembled. (Except the game recognition hashing part, which is still being analyzed)

Does this mean that we will be able to colorize Non-Super Gameboy Game Boy Games?

We were already able to. An emulator can do whatever it pleases, including giving colors to things. Most simply, it can give each of the four shades of gray (green?) different colors. Going further, it can use one set of colors for the background shades, and another for sprites. Even further, it could divide sprites and background into multiple groups.

The colorization the GBC did for non-GBC games was the second described ab

The Super Game Boy isn't the only way to colorize monochrome games. For Mednafen, it seems you'd use the -gba.colormap [sourceforge.net] command-line switch. Other Game Boy emulators are sure to have a way to do the same. At the very least, you can modify their source code (the original point was that these games coulds still be colorized by emulators before this recent GBC boot ROM dump was made, even if some emulators didn't provide a UI to do so).

This is all great, but how can I display my Gameboy Color on my television screen?These were in-store kiosks with the game boy somehow displaying its image both on the little screen and a television mounted on the kiosk.

When a Gameboy Color starts up with a Super Gameboy boy game is put into a Super Game Boy, it uses the Super Gameboy Palette with the border that would normally be used on a TV omitted.No it doesn't, though it does colorise some known roms.

Pokemon Red/Blue/YellowThe colorisation of those games running in SGB mode (interestingly the way games check if they are running on a SGB is to check if the second controller exists) is pretty different from that which the gameboy color uses. The SGB colorisation changes

There's no well-defined line of what software is expressive (and eligible for copyright) and what software is merely functional. I would argue that this software is merely functional -- there's not all that much code, and there are only a few ways you can write code that performs the same function. It's largely mechanical.

On the other hand, the Nintendo logo is actually contained in the ROM, as part of the protection mechanism. This was probably done as a "copyright/trademark trick" -- the logo is cer

Copyright lasts 70 years, not 10. And you don't need to add a copyright notice to get copyright. If you made it it's yours, under your copyright. If something has no notice/license at all, then it's copyrighted. And then you shouldn't go and copy it.

I assume you refer to the United States. The US was actually late to the party. The Berne Convention [wikipedia.org] got the ridiculous-copyright-term ball rolling... Disney just gave it an extra push. In particular:

The Berne Convention states that all works except photographic and cinematographic shall be copyrighted for at least 50 years after the author's death

The Berne Convention is also what gives us the rule that daid303 stated, that you don't need to add a copyright notice to get copyright:

Under the Convention, copyrights for creative works are automatically in force upon their creation without being asserted or declared. An author need not "register" or "apply for" a copyright in countries adhering to the Convention. As soon as a work is "fixed", that is, written or recorded on some physical medium, its author is automatically entitled to all copyrights in the work and to any derivative works, unless and until the author explicitly disclaims them or until the copyright expires. Foreign authors are given the same rights and privileges to copyrighted material as domestic authors in any country that signed the Convention.

The US didn't sign on to Berne until 1988. The EU's been on board for awhile, as have many, many other countries. [wikipedia.org] So, yes, you're technically correct that there are some people that are unaffected by the US's copyright protections (or in the case of Nintendo's IP, Japan's). But, a great many places have similar restrictions.

That means there's a good chance Nintento didn't (or soon won't) renew their copyrights on some of it and it is public domain.

This is complete bullshit. Nintendo is one of the most enthusiastic defenders of their copyright properties. Watch these guys get a C&D letter as soon as Nintendo notices their existence. I'm guessing no later than the end of this week.

This article is a classic example of why you shouldn't take legal advice from slashdot posts.

Note, I am not a lawyer, but that doesn't mean I can't find credible sources/links which show this guys doesn't know jack nor shit about what he's talking about.

First, yes, as someone pointed out, copyright laws vary somewhat from country to country. However, thanks to treaties, like the Berne Convention [wikipedia.org], which has been signed by most of the world's countries (although, not all the countries necessarily enforce it vigorously) they have become fairly standardized.

For the following statements, I've referenced wikipedia articles (which, I suppose might be wrong, but I have a fair amount of confidence in the accuracy), as well as the US Copyright Office website:

1) Copyright is longer than 10 years in most countries, and particularly, in the US, Europe and Japan (50 years for Japan, 70 years for US and Europe). So there is no way this is public domain (note: I am, personally of the opinion that copyright on software *should* be about 10 years, maybe renewable for another 10, but want you or I want, and what is law, are two separate things, and you'd do well to remember that).

2) You don't have to bother to copyright something. In all Berne Convention copyright regimes, copyright is *automatic* at the moment a work is put in a fixed form. So,

"But technically, is it even copyrighted if he didn't submit it to the Copyright Office, or is it just a banner he put there to scare people?"

Yes, to the extent that something he claims copyright on is actually his original work, it *is* copyrighted. Whether he'll enforce the copyright or not, is a different question, which I cannot answer.

He is. But seriously, this is a 4kB dump of an 11-year-old boot ROM. Copyright or no copyright, I'd say the historical significance and the usefulness for preservation efforts outweighs concerns about copyright violation.

Copyright law is grossly overreaching. At some points, such as small, old, historical works, you have to draw a line.

There are many great games for gameboy color, I had a gbc and about 10 games, but I haven't been able to play them for a while becuase I lost my GBC. I want to re-play them again some day.

Sure, this rom isn't needed for re-playing them, but its also a bit of preserved history. Thats one of the main reasons for dumping roms, its not all about piracy, its preserving a bit of history for future generations.