ekeeke
commented
6 years ago Actually, this happens whenever the game tries to write the color palette (CRAM), this is not garbage sprite data but the color value that is being written. It happens because of bus access conflict with the current pixel readout. And it does not happen only in border area but can also occurs in active screen area if the game tries to update CRAM mid-screen, it's just more common (and more visible) in border area.
It was initially not emulated because:
- it increases emulation processing requirements and requires cycle-accurate CRAM writes
- it's more a limitation of the original hardware than really a feature
- it's the kind of stuff most people never paid attention to when they were playing with their original console back in time (I certainly didn't and I had a PAL console were the borders were quite visible compared to NTSC ones where they barely were) and which suddenly become 'important' for em ulators to 'feel right'.
That's said, there are some recent homebrew demos that kinda use this 'feature' to display pictures in 'direct-color' mode (by disabling the display then doing precisely timed and continuous DMA to CRAM) so emulating this could actually be interesting. That's why I will leave this request open as it might eventually be added sometime in the future (by me or someone else)
NTxC
getCursorsExe
retrorepair
On a real Geneis/Megadrive, the VDP will spit out garbage (sprite data?) in the overscan area, usually the bottom right.
This is evedent in lots of games (all of them?) and if you load a game in the Exodus emulator you can see it there, as well as on real hardware but although Genesis Plus GX does draw the overscan area (borders) it doesn't show this garbage.
More a nit picky thing really but I feel it adds to the overall feeling of playing on a real console as I always remember this from my childhood. In the name of accuracy.....