Gameboy Bootstrap ROM - Revision history

Nitro2k01: Added links to the GB Dev file hub, and ISSOtm's disassembly

2024-11-18T09:20:43Z

Added links to the GB Dev file hub, and ISSOtm's disassembly

Bfabio: Fix the previous edit.

2019-05-11T16:35:44Z

Fix the previous edit.

Bfabio: Clarify the additional VRAM data is the data for the registered trademark symbol (®)

2019-05-11T09:51:27Z

Clarify the additional VRAM data is the data for the registered trademark symbol (®)

Lord Nightmare: fix link to Just Desserts' disassembly

2019-03-13T03:30:04Z

fix link to Just Desserts' disassembly

Mantidactyle: /* Contents of the ROM */

2016-01-05T11:10:43Z

‎Contents of the ROM

Lord Nightmare: fix pluralization

2009-11-12T22:21:02Z

fix pluralization

Lord Nightmare: correct names for cgb stuff, add more info on the pokemon stadium cart

2009-11-12T22:20:25Z

correct names for cgb stuff, add more info on the pokemon stadium cart

Nitro2k01 at 01:35, 16 October 2009

2009-10-16T01:35:07Z

Lord Nightmare: minor clarification

2009-09-29T15:50:04Z

minor clarification

Lord Nightmare: add info about CGB bootrom dumping

2009-09-29T15:48:53Z

add info about CGB bootrom dumping

@@ Line 31: / Line 31: @@
 * [http://www.google.com/search?q=patent+%235134391 US Patent #5,134,391] - System for preventing the use of an unauthorized external memory
-== Contents of the ROM ==
+== Contents of the ROMs ==
-Below is the disassembled code of the bootstrap ROM, together with Neviksti's comments.
-A binary file of the 256 byte area can be downloaded here: [http://www.neviksti.com/DMG/DMG_ROM.bin]. The disassembled ROM file can also be found here: [http://www.neviksti.com/DMG/DMG_ROM.asm].
+The boot ROMs can be downloaded as binary files from the [https://gbdev.gg8.se/files/roms/bootroms/ GB Dev file hub].
 <pre>
 	LD SP,$fffe		; $0000  Setup Stack

@@ Line 59: / Line 59: @@
 	LD ($FF00+$47),A	; $001f
-	LD DE,$0104		; $0021  Convert and load logo data from cart into Video RAM (the tile for ®)
+	LD DE,$0104		; $0021  Convert and load logo data from cart into Video RAM
 	LD HL,$8010		; $0024
 Addr_0027:
@@ Line 70: / Line 70: @@
 	JR NZ, Addr_0027	; $0032
-	LD DE,$00d8		; $0034  Load 8 additional bytes into Video RAM
+	LD DE,$00d8		; $0034  Load 8 additional bytes into Video RAM (the tile for ®)
 	LD B,$08		; $0037
 Addr_0039:

@@ Line 59: / Line 59: @@
 	LD ($FF00+$47),A	; $001f
-	LD DE,$0104		; $0021  Convert and load logo data from cart into Video RAM
+	LD DE,$0104		; $0021  Convert and load logo data from cart into Video RAM (the tile for ®)
 	LD HL,$8010		; $0024
 Addr_0027:
@@ Line 171: / Line 171: @@
 Addr_00D8:
-	;More video data
+	;More video data (the tile data for ®)
 	.DB $3C,$42,$B9,$A5,$B9,$A5,$42,$3C

@@ Line 10: / Line 10: @@
 On September 16th, 2009, Costis Sideris was able to extract the Super Gameboy bootrom using a form of clock glitching involving an FPGA. See [http://www.its.caltech.edu/~costis/sgb_hack/ Costis' page describing the dumping]. The clock crystal for the SGB was disconnected and instead controlled by the FPGA. After viewing an address bus trace (which shows the address as the bootrom is reading/writing to the $FFxx i/o space, but not the data), he found which exact clock cycle the write to the $FF50 register (which disables the bootrom) was. He then caused the FPGA to clock the SGB CPU at 4 times the normal speed for that write cycle only. This caused the CPU to glitch, the disable write to fail to properly occur, and the program counter to continue past there to $100 and onward, into cartridge rom space. A program was placed in that area which wrote the bootrom out byte by byte to the FPGA (using a bogus cartridge-address-space address which the FPGA recognized).
-When the Super Gameboy is turned on, the first part of the bootrom is not very different from the DMG one; it sets up sound registers and clears vram, but also writes 0x30 to the $ff00 keypad port (which the sgb uses as a bit-banged serial output port in addition to its keypad reading function). After that however, it clears WRAM bytes $c05f to $c058, and then copies the cartridge header ($104 to $14f) to WRAM at $c000-$c057, placing count and sum bytes at $c000-$c001, $c010-$c011, $c020-$c021, $c030-$c031, $c040-$c041 and $c050-$c051. This data is then bit-banged as a giant packet over the $ff00 port to the snes. See Just Dessert's disassembly at [http://www.bannister.org/forums/ubbthreads.php?ubb=showflat&Number=54179#Post54179 the MESS forums]. Unlike the DMG and CGB bootroms, the bootrom does NOT lock out the cartridge if the header sum or logo is wrong; its the SNES which does that!
+When the Super Gameboy is turned on, the first part of the bootrom is not very different from the DMG one; it sets up sound registers and clears vram, but also writes 0x30 to the $ff00 keypad port (which the sgb uses as a bit-banged serial output port in addition to its keypad reading function). After that however, it clears WRAM bytes $c05f to $c058, and then copies the cartridge header ($104 to $14f) to WRAM at $c000-$c057, placing count and sum bytes at $c000-$c001, $c010-$c011, $c020-$c021, $c030-$c031, $c040-$c041 and $c050-$c051. This data is then bit-banged as a giant packet over the $ff00 port to the snes. See Just Dessert's disassembly at [https://forums.bannister.org/ubbthreads.php?ubb=showflat&Number=54179#Post54179 the Bannister MAME subforum]. Unlike the DMG and CGB bootroms, the bootrom does NOT lock out the cartridge if the header sum or logo is wrong; its the SNES which does that!
 == The CGB bootstrap ==

@@ Line 33: / Line 33: @@
 == Contents of the ROM ==
 Below is the disassembled code of the bootstrap ROM, together with Neviksti's comments.
-A binary file of the 256 byte area can be downloaded here: [http://www.neviksti.com/DMG/DMG_ROM.bin]. The disassembled ROM file can also be found here: [http://www.neviksti.com/DMG/DMG_ROM.bin].
+A binary file of the 256 byte area can be downloaded here: [http://www.neviksti.com/DMG/DMG_ROM.bin]. The disassembled ROM file can also be found here: [http://www.neviksti.com/DMG/DMG_ROM.asm].
 <pre>
 	LD SP,$fffe		; $0000  Setup Stack

@@ Line 8: / Line 8: @@
 == The SGB bootstrap ==
-On September 16th, 2009, Costis Sideris was able to extract the Super Gameboy bootrom using a form of clock glitching involving an FPGA. See [http://www.its.caltech.edu/~costis/sgb_hack/ Costis's page describing the dumping]. The clock crystal for the SGB was disconnected and instead controlled by the FPGA. After viewing an address bus trace (which shows the address as the bootrom is reading/writing to the $FFxx i/o space, but not the data), he found which exact clock cycle the write to the $FF50 register (which disables the bootrom) was. He then caused the FPGA to clock the SGB CPU at 4 times the normal speed for that write cycle only. This caused the CPU to glitch, the disable write to fail to properly occur, and the program counter to continue past there to $100 and onward, into cartridge rom space. A program was placed in that area which wrote the bootrom out byte by byte to the FPGA (using a bogus cartridge-address-space address which the FPGA recognized).
+On September 16th, 2009, Costis Sideris was able to extract the Super Gameboy bootrom using a form of clock glitching involving an FPGA. See [http://www.its.caltech.edu/~costis/sgb_hack/ Costis' page describing the dumping]. The clock crystal for the SGB was disconnected and instead controlled by the FPGA. After viewing an address bus trace (which shows the address as the bootrom is reading/writing to the $FFxx i/o space, but not the data), he found which exact clock cycle the write to the $FF50 register (which disables the bootrom) was. He then caused the FPGA to clock the SGB CPU at 4 times the normal speed for that write cycle only. This caused the CPU to glitch, the disable write to fail to properly occur, and the program counter to continue past there to $100 and onward, into cartridge rom space. A program was placed in that area which wrote the bootrom out byte by byte to the FPGA (using a bogus cartridge-address-space address which the FPGA recognized).
 When the Super Gameboy is turned on, the first part of the bootrom is not very different from the DMG one; it sets up sound registers and clears vram, but also writes 0x30 to the $ff00 keypad port (which the sgb uses as a bit-banged serial output port in addition to its keypad reading function). After that however, it clears WRAM bytes $c05f to $c058, and then copies the cartridge header ($104 to $14f) to WRAM at $c000-$c057, placing count and sum bytes at $c000-$c001, $c010-$c011, $c020-$c021, $c030-$c031, $c040-$c041 and $c050-$c051. This data is then bit-banged as a giant packet over the $ff00 port to the snes. See Just Dessert's disassembly at [http://www.bannister.org/forums/ubbthreads.php?ubb=showflat&Number=54179#Post54179 the MESS forums]. Unlike the DMG and CGB bootroms, the bootrom does NOT lock out the cartridge if the header sum or logo is wrong; its the SNES which does that!
@@ Line 16: / Line 16: @@
 Based on some limited preliminary decapsulation work done by Dr. Decapitator, it was determined that the CGB CPU die has three roms on it: one 256 bytes, one 512 bytes, and one 1792 bytes.
-On September 21st, 2009, Costis Sideris was able to extract the Gameboy Color bootrom using a combination of clock and power glitching involving an FPGA. See [http://www.fpgb.org/?p=17 Costis's page describing the dumping]. The clock crystal for the CGB was disconnected and instead controlled by the FPGA, as well as the 3.3v power pin for the CGB CPU. After viewing an address bus trace (which shows the address as the bootrom is reading/writing to the $FFxx i/o space, but not the data), he found which exact clock cycle the write to the $FF50 register (which disables the bootrom) was, but attempting a similar clock glitch attack as the SGB didn't work. Instead, he used a much more 'brute force' attack after observing that unlike the DMG and SGB, the CGB cpu uses dynamic logic and loses its state when not clocked for a few seconds. He HALTED the cpu clock before the write, and in addition dropped the 3.3v line down to near 0v (to help randomize the internal register contents). This caused both the disable write to fail to properly occur, and the CPU's program counter and other registers to be filled with random values. After doing this several times, the program counter ended up pointing into external cartridge rom space, which contained a long chain of NOPS and a dumping program. The dumping program wrote the bootrom out byte by byte to the FPGA (using a bogus cartridge-address-space address which the FPGA recognized). The rom dump includes the 256 byte rom (0x0000-0x00FF) and the 1792 byte rom (0x0200-0x08FF) which Dr. Decapitator observed, but not the 512 byte rom, which may be cpu microcode or lcd color lookup related.
+On September 21st, 2009, Costis Sideris was able to extract the Gameboy Color bootrom using a combination of clock and power glitching involving an FPGA. See [http://www.fpgb.org/?p=17 Costis' page describing the dumping]. The clock crystal for the CGB was disconnected and instead controlled by the FPGA, as well as the 3.3v power pin for the CGB CPU. After viewing an address bus trace (which shows the address as the bootrom is reading/writing to the $FFxx i/o space, but not the data), he found which exact clock cycle the write to the $FF50 register (which disables the bootrom) was, but attempting a similar clock glitch attack as the SGB didn't work. Instead, he used a much more 'brute force' attack after observing that unlike the DMG and SGB, the CGB cpu uses dynamic logic and loses its state when not clocked for a few seconds. He HALTED the cpu clock before the write, and in addition dropped the 3.3v line down to near 0v (to help randomize the internal register contents). This caused both the disable write to fail to properly occur, and the CPU's program counter and other registers to be filled with random values. After doing this several times, the program counter ended up pointing into external cartridge rom space, which contained a long chain of NOPS and a dumping program. The dumping program wrote the bootrom out byte by byte to the FPGA (using a bogus cartridge-address-space address which the FPGA recognized). The rom dump includes the 256 byte rom (0x0000-0x00FF) and the 1792 byte rom (0x0200-0x08FF) which Dr. Decapitator observed, but not the 512 byte rom, which may be cpu microcode or lcd color lookup related.
 == The 'Pokemon' CGB bootstrap ==

@@ Line 14: / Line 14: @@
 == The CGB bootstrap ==
 Neviksti has also tried to extract the bootstrap from a Gameboy Color (CGB-01) CPU. However, because that CPU uses NAND ROM and is laid out in a different way, he had no success in extracting that ROM.
-Based on some limited preliminary decapsulation work done by Dr. Decapsulator, it was determined that the CGB CPU die has three roms on it: one 256 bytes, one 512 bytes, and one 1792 bytes.
+Based on some limited preliminary decapsulation work done by Dr. Decapitator, it was determined that the CGB CPU die has three roms on it: one 256 bytes, one 512 bytes, and one 1792 bytes.
-On September 21st, 2009, Costis Sideris was able to extract the Gameboy Color bootrom using a combination of clock and power glitching involving an FPGA. See [http://www.fpgb.org/?p=17 Costis's page describing the dumping]. The clock crystal for the CGB was disconnected and instead controlled by the FPGA, as well as the 3.3v power pin for the CGB CPU. After viewing an address bus trace (which shows the address as the bootrom is reading/writing to the $FFxx i/o space, but not the data), he found which exact clock cycle the write to the $FF50 register (which disables the bootrom) was, but attempting a similar clock glitch attack as the SGB didn't work. Instead, he used a much more 'brute force' attack after observing that unlike the DMG and SGB, the CGB cpu uses dynamic logic and loses its state when not clocked for a few seconds. He HALTED the cpu clock before the write, and in addition dropped the 3.3v line down to near 0v (to help randomize the internal register contents). This caused both the disable write to fail to properly occur, and the CPU's program counter and other registers to be filled with random values. After doing this several times, the program counter ended up pointing into external cartridge rom space, which contained a long chain of NOPS and a dumping program. The dumping program wrote the bootrom out byte by byte to the FPGA (using a bogus cartridge-address-space address which the FPGA recognized). The rom dump includes the 256 byte rom (0x0000-0x00FF) and the 1792 byte rom (0x0200-0x08FF) which Dr. Decapsulator observed, but not the 512 byte rom, which may be cpu microcode or lcd color lookup related.
+On September 21st, 2009, Costis Sideris was able to extract the Gameboy Color bootrom using a combination of clock and power glitching involving an FPGA. See [http://www.fpgb.org/?p=17 Costis's page describing the dumping]. The clock crystal for the CGB was disconnected and instead controlled by the FPGA, as well as the 3.3v power pin for the CGB CPU. After viewing an address bus trace (which shows the address as the bootrom is reading/writing to the $FFxx i/o space, but not the data), he found which exact clock cycle the write to the $FF50 register (which disables the bootrom) was, but attempting a similar clock glitch attack as the SGB didn't work. Instead, he used a much more 'brute force' attack after observing that unlike the DMG and SGB, the CGB cpu uses dynamic logic and loses its state when not clocked for a few seconds. He HALTED the cpu clock before the write, and in addition dropped the 3.3v line down to near 0v (to help randomize the internal register contents). This caused both the disable write to fail to properly occur, and the CPU's program counter and other registers to be filled with random values. After doing this several times, the program counter ended up pointing into external cartridge rom space, which contained a long chain of NOPS and a dumping program. The dumping program wrote the bootrom out byte by byte to the FPGA (using a bogus cartridge-address-space address which the FPGA recognized). The rom dump includes the 256 byte rom (0x0000-0x00FF) and the 1792 byte rom (0x0200-0x08FF) which Dr. Decapitator observed, but not the 512 byte rom, which may be cpu microcode or lcd color lookup related.
 == The 'Pokemon' CGB bootstrap ==
-An interesting 'prototype' version of the CGB bootrom can be found ?accidentally? included in the "Pokemon Stadium" N64 cartridge rom. This might possibly have been a leftover from an earlier prototype "Pokemon Stadium" cartridge which actually had a variant CGB CPU on it which would retrieve its rom from the n64 rom. The final n64 cartridge does not have a CGB CPU on it; it just retrieves pokemon data from the gameboy cart SRAM.
+An interesting 'prototype' or alternate version of the CGB bootrom can be found included in the "Pokemon Stadium" N64 cartridge rom. This might possibly have been a leftover from an earlier prototype "Pokemon Stadium" cartridge which actually had a variant CGB CPU on it which would retrieve its rom from the n64 rom. The final n64 cartridge does not have a CGB CPU on it, but it does emulate the CGB hardware using N64 software, but is locked to only running the pokemon CGB games, which are copied, ram and rom, out of the cart on startup. The pokemon stadium 'emulator' code probably does use the bootstrap when starting up.
 == Impact ==

@@ Line 1: / Line 1: @@
 == The DMG bootstrap ==
 On July 17, 2003, neviksti published that he had been able to extract the contents of the Gameboy boot ROM from a DMG-01 on the Cherryroms.com forums. The boot ROM is a bootstrap program which is a 256 bytes big piece of code which checks the cartridge header is correct, scrolls the Nintendo bootup graphics and plays the "po-ling" sound.
 When the Gameboy is turned on, the bootstrap ROM is situated in a memory page at positions $0-$FF (0-255). The CPU enters at $0 at startup, and the last two instructions of the code writes to a special register which disables the internal ROM page, thus making the lower 256 bytes of the cartridge ROM readable. The last instruction is situated at position $FE and is two bytes big, which means that right after that instruction has finished, the CPU executes the instruction at $100, which is the entry point code on a cartridge.