Keep in mind that the GB has a 256-byte rom which you *DO* rely on as it sets up all the default values to all the registers. so you have to add that to your total as per rules

The 256-byte bootstrap rom also has some DRM part that checks for the authenticity of the GB cartdridge and scrolls the Nintendo Logo:

https://realboyemulator.wordpress.com/2013/01/03/a-look-at-the-game-boy-bootstrap-let-the-fun-begin/

I don't think those parts should count. I think that what would be fair would be to only count the instructions that are really used. For example if there is a very accurate emulator that allows the user to use a custom bootstrap, we could use a bootstrap where the useless parts are replaced by NOPs and count what's left.

Should or should not is a futile argument. Rules say that if you repent on piece X in the system, the entirety of X's code counts.

there's nothing happening in mGBA :(

Does it have a memory viewer? In VBA I just get a white screen, but you can see everything at memory address 0xC000.

only now I get what this is about :) k, but the memory viewer of mGBA doesn't work either :( 

I'll see if I can get it working with that emulator.

I don't know if the rules will accept this. I mean, "use the memory viewer at 0xC000" doesn't work on the real thing. If the target system is a Game Boy, shouldn't it be able to run on the real hardware? Given that the Game Boy works with easily accessible sprites and tiles, you should be able to add normal LCD output to the game.

All the address and data pins are available on the real Gameboy.

You could use the upper bits to enable/disable a latching type chips, then you could have an array of LEDs showing the data. But an FPGA would make this work far more simpler than glue logic.

I could do some simple graphics with OAMs and tile mapping, but that would require setup of the LCD video registers, GFX ram, OAM attributes, and the OAM DMA.

It's been a few decades since I've written anything GB-related, but I don't recall my setup being too complicated. I don't even recall "OAM DMA" to be honest. Don't forget the GB initializes most of the hardware by itself when booting.

See yvan256.net/projects/gameboy/ for links to documentations at the bottom of the page.

The DMA is used because you can only update the OAM memory while the LCD is off or in VBL/HBL, I'm not sure if the CPU stalls until the write works, or if nothing happens.

Most emulators take a lot of shortcuts, normally hardware is in a off state, but they will make sure that the register pairs have the correct values at the ROM entry point, as not to break Super/Color/Advance Gameboy exclusive games. I guess if the emulator supports and uses a BIOS, minimal setup would be required.