How do you recognize db assembly instructions in Game Boy ROMs?

[billybob643]

So I have been working on a project of being able to reverse engineer Gameboy ROMs and I am running into a problem in being able to decipher which bytes of the binary code are used in db instructions versus which ones are actual OPcodes. In memory addresses $0104 - $0133 of Game Boy ROMS for example, is reserved for the Nintendo logo. The command in assembly for the logo section is

Code Select Expand

db $ce, $ed, $66, $66,...$3e. In the binary code however there is no OPcode that shows that the assembly db command is being used in this section, only the bytes are being displayed, many of which are also OPcodes which makes it confusing when disassembling. Is there a way to tell when the db command is being used? Or are there certain sections in the ROM's memory that are specifically allocated for the word to be read as a byte and not as OPcodes?

[KingMike]

The CPU itself has no idea of the difference between code and data.

Only that section of the ROM gets flagged as db because it is specifically known to be Nintendo logo data (which is required to be an exact copy if the boot ROMs are used).

Pretty much just that $104-14F area of the ROM (the header) is known to be db.

[billybob643]

Only that section of the ROM gets flagged as db because it is specifically known to be Nintendo logo data (which is required to be an exact copy if the boot ROMs are used).

Pretty much just that $104-14F area of the ROM (the header) is known to be db.

Interesting. So is it safe to assume that besides addresses in the ROM header section, a db command will not be present? Also, how does that get flagged? Is it in the hardware of Game Boy that checks for this. From my research it seems like it was an anti-piracy measure and I am curious how that is implemented.

[FAST6191]

https://gbdev.io/pandocs/#power-up-sequence covers the power up sequence. Will also mean you have at least the start of a binary too.

As far as determining what is code... few surefire ways and they could scatter code across banks.
You don't have multiple modes
Some debugging emulators will also be able to log executed data, some even doing really fun http://fceux.com/web/help/CodeDataLogger.html where it will note when something was executed (say you want to find a jump routine, as in jump in a platformer, get to a point in the game where you could jump, start the logger, idle, walk about... basically everything but jump, now it has a baseline of executed routines, do a jump and that shiny new code section not seen before is presumably what you want).
You can do a full playthrough of a game to get an idea for the locations of the code. Not so bad on the GB/GBC where games are normally pretty straight shot from start to finish, compared to later systems where you can teleport anywhere, load any level, maybe have some minigames...