GameBoy Program Counter behaviour

[satochan]

I am very new to low level and GameBoy programming and I have a question that I can not seem to find an answer to in any of the documentation about the GameBoy. The user ROM space is in the address range from $0000 to $7FFF and I am wondering what happens when the Program Counter is at position $7FFF and gets incremented to $8000 which marks the first byte of the character data. Or even what would happen if I try to execute a CALL/JP instruction to address $8000. There is various things that could happen at this point but I found no confirmation for a concrete answer:
A) The CPU tries to fetch whatever is at address $8000 and happily executes whatever it finds.
B) The GameBoy has some form of protection that sets the PC at this stage back to $0000.
C) The protection sets it back to $0100 to fetch and execute the JP instruction for the main entry point of the user program.
D) The system locks up (or worse gets damaged) because it is not allowed to fetch instructions from address $8000 or beyond.
E) There is a non-maskable interrupt that indicates a fetch/jump from/to an illegal address. This one is probably less likely since the GameBoy seems to only have maskable interrupts.

The Nintendo GameBoy Programming Manual has no real information on this. Even worse, the examples for the CALL and JP instructions in that manual show a jump to address $8000, which based on the memory layout should be a no no.

Has anyone here ever tried those scenarios on real hardware and knows what would happen? I only have emulators at hand at the moment and I don't really care what these would do. I would like to know how the real hardware would behave in this scenario and thought I'd ask before I have to buy a GameBoy and somehow try this for myself

[Dwedit]

The answer is A, it will happily try to execute whatever it reads out of memory at 8000. This could even happen where the first byte of an instruction is at $7FFF and the second byte at $8000.

However, VRAM is only accessible by the CPU at specific times. During VBLANK time (lcd status 'mode 1'), it is freely accessible. During HBLANK (lcd status 'mode 0') and OAM evaluation time (lcd status 'mode 2'), VRAM is freely accessible. During render time (lcd status 'mode 3'), it is not available.

During times when VRAM is not available, you get an Open Bus value instead of the byte from memory. I'm not sure exactly what the open bus values are here, but it's common to see the low byte of the address get returned on other systems.

[Jarhmander]

Open bus is whatever appeared on the data bus last; thus it is the last value the CPU have read/written. Indeed, if the last CPU fetch is the low byte of an memory address, then yes, that would be the open bus value, but if the instruction at 7FFF is a two or three byte instruction, then its remaining bytes are the same as the opcode. If the last operation of the instruction is a memory store, then the value written is the new open bus value.

[tepples]

Game Boy open bus tends to decay toward $FF a bit faster than on NES though.

[satochan]

Thank you so much for the answers! I can finally sleep properly haha