Has anyone seen a NES game execute vectors as if they were instructions, I.E. PC >= 0xFFFA ?
It really sounds strange to me, but as it is actually possible, some game may do this.
I've read some Atari 2600 games used to re-use the last opcode of the game logic as the first byte of the sprite data, so you may expect strange things like these.
If not, then one shouldn't care about PC wrapping around to 0 after a PC++.
I don't think any game would do this, but this is perfectly possible. I don't think any emulator should rely of ROMs to NOT do this to work proprely.
But what if an emulator spit out a warning if a game did this, in order to bring possibly erroneous operation to the attention of the emulator author or game programmer?
Yes, or silently log it for later analysis
I second what Bregalad said. In fact, I don't see what purpose it would serve for an emulator to "trap" execution at such offsets; how would an emulator know what's erroneous operation and what's legitimate? It wouldn't. Best to just emulate the 6502 and let such things alone. :-)
PocketNES just emulates the program counter as a 32-bit pointer at all times, except when it needs to figure out its 16-bit value for when it goes on the stack. The memory page is looked up when it is changed from a 16-bit to a 32-bit value.
Relative jumps are relative to the 32-bit address, absolute jumps, calls, or returns look up the page again.
So PocketNES dies when a game has non-contiguous banking and crosses pages, and The Magic of Scheherazade does just that when the enemies cast spells on you.
If PocketNES reached the vectors, it would probably be on the last PRG page, so it would start executing CHR ROM.
Why bother with the 32-bit pointer and not just use a 16-bit PC at all times? Because it's so much faster.
koitsu wrote:
In fact, I don't see what purpose it would serve for an emulator to "trap" execution at such offsets; how would an emulator know what's erroneous operation and what's legitimate? It wouldn't. Best to just emulate the 6502 and let such things alone. :-)
It's like putting assertions or other debug checks in code you write; they don't indicate an error, but they aren't things anyone would normally want to do, so they
might indicate an error (either in the emulator, or in the code). I've found such checks highly useful for finding emulator bugs. Obviously I remove any which prove to be a source of useless noise due to some game intentionally doing whatever it is often.
blargg wrote:
It's like putting assertions or other debug checks in code you write; they don't indicate an error, but they aren't things anyone would normally want to do, so they might indicate an error (either in the emulator, or in the code). I've found such checks highly useful for finding emulator bugs. Obviously I remove any which prove to be a source of useless noise due to some game intentionally doing whatever it is often.
Alright, I'll bite. I can see it being a toggleable feature in an emulator, similar to halt-emulator-on-BRK or halt-emulator-on-unsupp-opcode, for those who want it.
That said, many of the checks I put in only fire in my personal debug builds, as they are too noisy for an end-user.