So while chasing down that other problem (not yet complete) I noticed what seems to be a separate problem - also differing in behaviour between Hatari and HW, just a bit less severe. This affects the physbase register $ff8201/3/d
when emulating the Falcon.
I am wondering if there are any important differences between the way physbase is picked up and used by HW, and how Hatari uses it? Probably not, but if there are I'd like to know about them.
My guess is that for Falcon emulation, double-buffering can look different (or break down) in Hatari in some situations (e.g. if synchronization is relaxed) because the image is built instantaneously, from the point of view of the emulated machine. It does not take a frame of virtual-time to assemble the image.
I can see how that would either reveal (or hide) tearing effects while building the image if the display raster is chasing the CPU.
In a situation where an image takes many VBLs (say, 4 or 5) to construct, we can present the completed 'backbuffer' to physbase, and proceed immediately to modify the original 'frontbuffer' as the new backbuffer. On a real machine, there is a risk of tearing in this scenario because the display raster could be completing the last few lines of the old frame, in the same buffer you have begun to modify.
However if Hatari builds the image instantaneously, it should mean no visible tearing because the image will be built entirely and only from the new frontbuffer (old backbuffer), all at once.
What I am seeing is the opposite, when testing this situation. On real HW tearing is not visible - mainly because it takes some time before rendering begins, and doesn't overlap with the raster.
In Hatari, I see dreadful tearing no matter which buffer I view. This suggests the image is built not at the time I am expecting (on the VBL event). This is most evident when I set physbase inside the VBL (before the HW should take that value and update the physical address counters).
Changing the code to set physbase in the main game loop results in correct (or at least matching real HW) results.
So is there something special I need to know about when/how Hatari uses the physbase address to build the image? If I set physbase early in the VBL, will it build the image in the buffer at that moment, or the image in the buffer when that VBL completes and the next initiates?). I'm currently guessing it's the latter - this would probably explain why setting it in the game loop hides tearing, but setting it in the VBL guarantees a delayed result.
I suppose this is useful in a way, because it exaggerates tearing that would exist on real HW, but be either invisible or much less visible, so more likely to get noticed and fixed. But OTOH, if this is used to optimize away dead time in a game loop, it requires special handling by the programmer to treat Hatari differently.
If anyone is able to correct or confirm the above, I would appreciate the input.
Thanks
Doug.