Game Boy Color BG priority bit [solved]

Discussion of programming and development for the original Game Boy and Game Boy Color.
nitro2k01
Posts: 252
Joined: Sat Aug 28, 2010 9:01 am

Re: Game Boy Color BG priority bit [solved]

Post by nitro2k01 »

byuu wrote:> The purpose of BGB's DMA OAM detection is as a development aid, and has nothing to do with the emulation.

Then I guess I don't understand what the performance issue is. I'd rather the emulation run at 2fps if it means faithfully recreating what users will see on real hardware under a development environment. But, to each their own.
Ok, I guess I should explain this. Apologies to beware if I'm describing any of this incorrectly.

This has to do with how the debug code is organized. It's all about code cleanness and modularity. A debug function - we could even call it a supervisor for the sake of it - is conditionally called at the beginning of the instruction fetch/decode loop. This function checks, prior to the execution of the instruction and consumption of cycles, whether it will trip a break condition.

Now, beware's own coding guidelines are saying that the debug functionality is separate from the emulation. Essentially, the only interface between the two is that single conditional call. Debugging functionality is allowed to slow down the emulation, under the condition that it can be disabled very efficiently. This implies that the debug code isn't relied upon for normal emulation. This also means that debug code is not allowed to alter the state of the emulated machine, only break the emulation.

The other option is to place a OAM conditional in the read/write functions, which isn't exactly very attracive either. I and beware have discussed this a lot, and what really made the difference is that literally nothing, except for one game made by an asshole in France, relies on the effects of illegal memory access during DMA. But more importantly, it really has no practical uses, apart from emulator detection, so he ended up deciding it was too much cost (in terms of both speed and code complexity) for too little benefit.

Don't get me wrong, beware finds emulation accuracy very important, but there's a trade-off to everything. As far as I'm aware, this is the only inaccuracy in BGB ever that beware has explicitly decided against fixing.
byuu wrote:> Doing something like self-modifying code would very much go against his coding ideals, as far as I know them.

And mine.

Typically one who wants speed will do whatever it takes, whereas one who wants accuracy will do whatever is necessary. So he seems to be somewhere in the middle.
We have discussed this in detail in #gbdev (on EFNet), and came to the same conclusion. You/Higan are the accuracy extremist, emulators like no$*** or ZSNES are the speed extremists and BGB is somewhere in the middle. (Though scoring well on both counts.)
Post Reply