Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Emulation (Games) Portables (Games) Games

Gameboy Color Boot ROM Dumped After 10 Years 124

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."
This discussion has been archived. No new comments can be posted.

Gameboy Color Boot ROM Dumped After 10 Years

Comments Filter:
  • ...win 7.
    because otherwise this is a puny attempt at resurrecting obsolete tech.

    • 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 Z80, so you oughta be done starting up Windows right around the heat death of the universe
        • 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.
  • Cool (Score:5, Interesting)

    by dintech ( 998802 ) on Tuesday September 29, 2009 @03:54AM (#29577465)

    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?

    • Re:Cool (Score:5, Informative)

      by Xeon3D ( 828863 ) <{retrojogos} {at} {gmail.com}> on Tuesday September 29, 2009 @04:14AM (#29577533) Homepage

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

    • Re:Cool (Score:5, Informative)

      by noidentity ( 188756 ) on Tuesday September 29, 2009 @04:27AM (#29577599)

      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.

        Although it is late and I may be misreading that.

      • Re: (Score:2, Informative)

        by DuoDreamer ( 1229170 )

        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
    • by Jurily ( 900488 )

      Can someone explain the significance of this development?

      The same as fixing a 33 year old bug [slashdot.org].

  • 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

  • by noidentity ( 188756 ) on Tuesday September 29, 2009 @04:45AM (#29577667)

    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.

    • by tangent3 ( 449222 ) on Tuesday September 29, 2009 @05:18AM (#29577769)

      I believe he also had to short the 3.3V rail to ground during the time the clock is stopped, to randomize the registers values.

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

      • he didn't just stop the clock

        I'd love to be smart enough to manage something like this.

        Look on the bright side - even a stopped clock is right two times a day.

    • by Megane ( 129182 )
      Let's see someone try that with the Xbox 360 boot ROM.
    • 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.
  • 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.)"

    Why a few seconds, why not an exact time?

    • by mpoulton ( 689851 ) on Tuesday September 29, 2009 @05:17AM (#29577765)

      Why a few seconds, why not an exact time?

      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.

    • Re: (Score:3, Informative)

      by marcansoft ( 727665 )

      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.

    • Computer science is not an exact science. Vagueness is to be expected, even in the little things.

    • Damn I love that movie. Completely renewed my respect for engineering, made me feel good about being a nerd again :)

  • by TheSunborn ( 68004 ) <mtilstedNO@SPAMgmail.com> on Tuesday September 29, 2009 @05:09AM (#29577731)

    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.

    • by Viol8 ( 599362 )

      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.

    • Re: (Score:2, Informative)

      by eclectro ( 227083 )

      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.

      • Re: (Score:1, Funny)

        by Anonymous Coward

        He should get some kind of award.

        Don't worry... Nintendo's lawyers are already working on it.

    • by noidentity ( 188756 ) on Tuesday September 29, 2009 @07:31AM (#29578379)

      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.

    • Re: (Score:2, Informative)

      by Nobo ( 606465 )

      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.

      The ROM was read out by beating the hell out of the processo

  • Original GB Boot ROM (Score:3, Informative)

    by NorQue ( 1000887 ) on Tuesday September 29, 2009 @05:25AM (#29577813)
    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]
    • You are referring to Game Boy Color's Super Game Boy Support. Someone may have to dump the rom of the Super Game Boy to do that.

      • by NorQue ( 1000887 )
        Nope, GBC didn't have SGB support. Those colors you see in ie Metroid 2 are selected in the GBC boot process. And that guy already dumped the SGB Boot ROM, too.
      • The same guy (costis) already dumped the SGB ROM a few days earlier, using a simpler clock-glitching-only techique. See the site [fpgb.org].

  • by Zombie Ryushu ( 803103 ) on Tuesday September 29, 2009 @05:26AM (#29577821)

    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/Yellow
    Donkey 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.

    • 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

      • Neither Mednafen, nor sdlmess will colorize a non-Super Gameboy Game.

        Mednafen fails to activate the Super Game Boy Feature set of Super Game Boy Game.

        • 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).
    • by kriston ( 7886 )

      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/Yellow
      The 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

  • by netpixie ( 155816 ) on Tuesday September 29, 2009 @05:55AM (#29577961) Homepage

    "Copyright 2009. Costis Sideris."

    So copyright law is good enough for you, but not for Nintendo?

    • That is a bit hypocritical, well spotted. (I suppose he could argue it's an artistically creative work vs a piece of software, but I don't buy that argument personally even though it convinces some.)
      • Re: (Score:3, Informative)

        by bushing ( 20804 )
        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
  • by Alioth ( 221270 )

    I'm just wondering when he's going to receive his DMCA takedown notice.

  • ..that nobody from the original company leaked the information in the interim. What kind of scary NDA do they have?

Two can Live as Cheaply as One for Half as Long. -- Howard Kandel

Working...