![[PukiWiki]](image/pukiwiki.png "[PukiWiki]")
前回のメモリエリアでは、カードリッジ以外のメモリ領域（IWRAM, EWRAM, PAK ROM）にコードや変数を置く方法を説明をしました。ところが電源を入れたとき、すべてのデータはROM（カードリッジ）にあります。その時点からいったいどうやってIWRAMやEWRAMに配置されていくのか、その流れを見ていきましょう。
実機にカードリッジを挿し電源をONにすると、そのカードリッジ内容はメモリの0x08000000からアクセスできるようになります。gbaファイルとは、その内容をファイル化しただけのものです。もちろんカードリッジはROM（リードオンリーメモリ）なので書き換え不可。大昔ということもあってデータは暗号化もされていませんでした。いい時代やったなあ・・・。ROM領域にアクセスされる最初のファイルは「C:\devkitPro\devkitARM\arm-none-eabi\lib\gba_crt0.ld」（github）です。よかったら平行して読んでみてください。
GBA上だと0x08000000～0x080000bf、.gbaファイル上だと0x00～0xbfまでの192（0xc0）サイズ分をヘッダと呼びます。内容は特に気にすることはないので素通りしましょう。一応次のような意味を持っています。
| 0x00 - 0x03 | 32 bit ARM B Jump to start of ROM executable |
| 0x04 - 0x9F | Nintendo Logo data |
| 0xA0 - 0xAB | Game Title |
| 0xAC - 0xAF | Game Code |
| 0xB0 - 0xB1 | Maker Code |
| 0xB2 - 0xB2 | 0x96 Fixed |
| 0xB3 - 0xB3 | Main Unit Code |
| 0xB4 - 0xB4 | Device Type |
| 0xB5 - 0xBB | Reserved Area |
| 0xBC - 0xBC | Mask ROM Version |
| 0xBD - 0xBD | Compliment Check |
| 0xBE - 0xBF | Reserved Area |
エミュレータで見るとこのようになります。（Tools -> Memory viewer）
main関数が実行されるまでの流れは以下のとおりです。
エミュレータで逆アセンブルするとこんな表示になります。
@--------------------------------------------------------------------------------- start_vector: @--------------------------------------------------------------------------------- mov r0, #0x4000000 @ REG_BASE str r0, [r0, #0x208] mov r0, #0x12 @ Switch to IRQ Mode msr cpsr, r0 ldr sp, =__sp_irq @ Set IRQ stack mov r0, #0x1f @ Switch to System Mode msr cpsr, r0 ldr sp, =__sp_usr @ Set user stack
自作ゲームを作って実機で動かそうとしたらタイトルロゴで止まる、でもエミュレータでは大丈夫という現象。こんなことがあったらロムが壊れていないかのチェックサムを疑ってください。devkitProにはgbafix（C:\devkitPro\tools\bin）と呼ばれるチェックサム変更ツールがあります。忘れずに実行してください。
マルチブートとはカードリッジを使わずに通信ケーブルなどで起動する仕組みです。たとえば実機を２台持っていて、対戦ゲームをしたい場合を想像するとわかりやすいと思います。一方はマリオカートのカードリッジを装着していて、一方は通信ケーブルのみで繋がっている。この状態でホスト側からゲスト側にデータを転送して対戦をする、という仕組みです。
devkitProではカードリッジなし状態を想定した制作も可能です。VBA-1.8.0-beta3ではファイル名で区別しており、xxx.gbaでしたらxxx.mb.gbaまたはxxx.mbとなります。インターネットでダウンロードしてきた自作ゲームがフリーズする場合、そもそもIWRAM, EWRAM領域にのみ展開されることを想定して作られているわけで、そりゃフリーズしますよね、という話です。
