mattcurrie/mgbdis

Game Boy ROM disassembler with RGBDS compatible output

mgbdis's Issues

Allow ROMX banks to reference labels from ROM0

Currently, code in ROMX is unable to access labels from ROM0, despite the latter being always visible to the former (and many "common" routines reside in ROM0, too)

Allow .sym files to define labels in RAM

These would go in their own WRAM0, WRAMX, or HRAM SECTIONs.

Cg www

Support scoped local labels

The following currently isn't disassembled correctly:

; @00:0000
    nop
    jr $0004
    nop

00:0000 Glob1
00:0001 .local
00:0003 Glob2
00:0004 .local

This will produce the following:

Glob1::
    nop

.local:
    jr .local

Glob2::
    nop

.local:

where the jr .local line should instead be Glob2.local. This is because mgbdis does not treat local labels specially: in RGBDS, they are always scoped. meaning the SYM file above is actually invalid. See below for what is actually produced.

00:0000 Glob1
00:0001 Glob1.local
00:0003 Glob2
00:0004 Glob2.local

mgbdis actually treats labels as local only if they begin with a dot, whereas the RGBDS rule is if they contain one at all.

This is actually linked to gbdev/rgbds#483 (and #12, by extension), though the currently drafted spec agrees on what has been outlined above.

Correct behavior

mgbdis should instead apply special meaning to local labels, trimming off their leading part if it's currently in scope. (Implementing that properly is a different problem.) Note that while Glob1.local: is actually valid syntax, it's a lot noisier, and nobody writes code like that.

Is there support for Charmaps or other Text formatting?

I can mark a block as .text in the sym file but the ROM I'm looking at isn't using standard ASCII so I'd need a Character Map or some other option to offset and make the text readable.

Is there a way to do that? Am I going about this the wrong way?

Note on HRAM/IO R/W

From README.md:

RGBDS optimises instructions like LD [$FF40],a to LDH [$FF00+40],a, so these are encoded as data bytes using a macro to ensure exact reproduction of the original ROM (thanks to ISSOtm). RGBDS >= v0.3.7 has an option to disable this optimisation. Use --disable-auto-ldh with mgbdis to disable the macro.

This only applies to constant expressions. If you instead export the symbol from an HRAM section, it'll use the 3-byte ld instruction.

rom_path argument required

Keeps saying that is requird an path argument.

Tetris fails to match

Original ROM is Tetris with a MD5 hash of 084f1e457749cdec86183189bd88ce69

Output ROM game.gb has a MD5 hash of 389d39cb232bebe3ff7d4ccbc6269a82

See here for a difference comparison. 101 differences: 104 bytes

Garbage function calls break valid ASM instructions

I have an example of the issue.
Explanation: A garbage function call from a data section of the ROM broke what should have been a 3-byte instruction. Screenshot shows comparison in Ghidra.

Error on BIOS disassembly

I tried to disassemble the BIOS using this (nice) tool.

I create the cartridge using this python3 script

#!/usr/bin/env python3

code = bytearray([
    0x31, 0xFE, 0xFF, 0xAF, 0x21, 0xFF, 0x9F, 0x32, 0xCB, 0x7C, 0x20, 0xFB, 0x21, 0x26, 0xFF, 0x0E,
    0x11, 0x3E, 0x80, 0x32, 0xE2, 0x0C, 0x3E, 0xF3,  -- snip --
])

rom = code + bytearray([0x00] * (32768 - len(code)))

with open("bios.gb", "wb") as out_file:
  out_file.write(rom)

The mgbdis creates some files but when I looked in bank_000.asm, I found is an error

; Disassembly of "bios.gb"
; This file was created with:
; mgbdis v1.4 - Game Boy ROM disassembler by Matt Currie and contributors.
; https://github.com/mattcurrie/mgbdis

SECTION "ROM Bank $000", ROM0[$0]

RST_00::
    ld sp, $fffe
    xor a
    ld hl, $9fff

jr_000_0007:
    ld [hl-], a

RST_08::
    bit 7, h
    jr nz, jr_000_0007

    ld hl, $ff26
    db $0e  ;  <<<<<<<<<<<<<< ERROR

RST_10::
    ld de, $803e
    ld [hl-], a
    ld [c], a
    inc c
    ld a, $f3

The tool seems to skip the disassembly of the 0x09 opcode (LD c, n) that has to consume an other byte.

Too much use of RAM

I have 960 MB of RAM... When I try to decompile Pokemon (Fire Red or Fuego Rojo in spanish) it fills me all the RAM.

¿It would be possible for the program to save the content of the variables on the hard disk instead of the RAM in this case?

That way you could use less RAM and the system would not freeze. I'm talking about variables that use too much RAM.

Support 32k mode

RGBLINK supports "tiny mode", in which ROMX is treated as ROM0. It would be useful to support such a mode, treating the entire ROM space as a single bank, instead of splitting it.

Use `rst Label` if one is provided

RGBDS has supported labels as rst arguments since 0.4.0; using labels instead of plain numbers help rsts provide as much info through their argument as calls do.

Documentation on .sym files

I can't seem to find more documentation on the .sym file format.

Does mgbdis implement a subset of it?

Regression in spitting out wrong `jr` targets

commit 298ccf7 has caused a regression regardling how jr targets are calculated in non-tiny mode.
Building a disassembled pokemon crystal, for example, causes these errors:

$ make
rgbasm  -o game.o game.asm
rgblink -n game.sym -m game.map -o game.gbc game.o
error: game.asm(97) -> bank_04c.asm(14288): jr target out of reach (expected -129 < -16328 < 128)
error: game.asm(96) -> bank_04b.asm(14181): jr target out of reach (expected -129 < -16260 < 128)
error: game.asm(148) -> bank_07f.asm(16332): jr target out of reach (expected -129 < -16317 < 128)
error: game.asm(109) -> bank_058.asm(14228): jr target out of reach (expected -129 < -16257 < 128)
error: game.asm(103) -> bank_052.asm(14406): jr target out of reach (expected -129 < -16272 < 128)
Linking failed with 5 errors
make: *** [Makefile:13: game.gbc] Error 1

bdm source/win32 build

i would like to use bdm to create a sym file for this disassembler, but to my surprise the windows build (couldnt find source) is win64 only. would it be possible to provide a win32 build so i can use it in wine ? if the source is available somewhere, that would be even better of course.

Stop outputting instructions as data bytes

• RGBDS optimises instructions like LD [$FF40],a to LDH [$FF00+40],a, so these are encoded as data bytes using a macro to ensure exact reproduction of the original ROM (thanks to ISSOtm).
• RGBDS automatically adds NOP instructions after STOP and HALT, so the disassembler will output these as data bytes if the instruction is not followed by a NOP in the original ROM.

RGBDS has flags to prevent this (-L for the former since 0.3.7, -h for the latter before 0.3.5); it should be possible to pass flags to mgbdis (possibly the same ones?) to leverage this behavior, and avoid data bytes in the middle of code, which might throw people off.