Genesis-Plus-GX
Genesis-Plus-GX copied to clipboard
ekeeke
Emulation of dots artefacts on CRAM writes
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.....
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)
Please consider working on this feature. This is the only feature that's missing from Genesis Plus GX that is implemented in Blastem. If you implement this my life will be complete.
On hardware Sega Mega Drive, the game can CRAM can be written at anytime, but on most emulators, CRAM can be only written during H-Blank or V-Blank. If it increases emulation processing requriements, then how about CRAM Dots as an option that will be disabled by default?
This explains why the 512 COLORS TITANIC RECORD in TiTAN Overdrive Beta is displayed as color scanlines. This is probably also because of the emulator unknowingly displaying only 16 colors in one scanline.