What is going on in the overscan area of Sega Genesis games?

I noticed that different games display different things in the overscan area.

I understand this was never intended to be seen.

However, I would still like a technical explanation. Was this useful to developers somehow?

Here is a video I found that shows it. https://youtu.be/tT9OnPjQKWY?t=94

Here is screenshot from that video. Just one example of different things that could be in the overscan area.

enter image description here

  • On youtube there is a guy talking about how for (mostyl sega) consoles he did certain hacks to make certain things possible that nobody thought were possible. I think in one of the videos he explains a bit more about them, but I couldn't find it. – PlasmaHH Jan 18 '18 at 10:17

Short answer: No. At least not for display purposes.

The pixels shown are artefacts when the VDP is operation in modes with more than 224 lines (NTSC). These lines were usually not displayed on real TV boxes. Nonetheless, the VDP did generate the lines from whatever tiles it did find at the proper locations. Depending on the game they where uninitialized, contained previous data or where used to store some game data. Some games even did carefully fill these locations with some background colour or an extension of the playfield.

So if the game used these areas for data storage, you may see funny graphics blinking. After all, the Mega Drive did only offer 64 KiB direct accessible RAM for the main CPU (plus 8 KiB for the Z80), so unused potions of the 64 KiB of Video RAM accessible via the VDP dared to be used. :)

  • 2
    According to the manual (emu-docs.org/Genesis/sega2f.htm), the Mega Drive has 64KB of dedicated VRAM, 8KB of dedicated sound RAM, and 64 KB of working RAM for the 68000 CPU game code. – Brian H Nov 22 '17 at 20:51
  • @BrianH Jup, you're right (And don't forget the 232 Words of Colour RAM :)) – Raffzahn Nov 22 '17 at 20:59
  • Raffzahn, If I understand this correctly they used the extra space as actual ram for their game code and the changing colors/etc is an artifact of that? – LateralTerminal Nov 22 '17 at 21:17
  • 2
    @LateralTerminal There is no definite answer without analyzing the game. But usually artefacts from screen (or other) data are the source. – Raffzahn Nov 22 '17 at 21:23

The color RAM in the Genesis video chip is single ported such that at any given time the color RAM data bus either contains the data being read out of it for display purposes, or the data being written into the RAM by the CPU or by DMA.

Outside of the active display area the overscan color can be defined by software. The video chip shows this color for each pixel in the display by continuously addressing and reading out the color RAM data at that address. Most games set the backdrop color to black, as in your picture.

Typically software will use DMA to load transfer palette data from system memory to color RAM during the vertical blanking period which starts right after the last line of the active display area ends. The exact point where DMA starts depends on the software, usually there is some housekeeping and setup to do.

Due to the single-ported nature of the color RAM the video hardware will attempt to show the overscan color during that time but will be interrupted every other pixel by DMA writes. This causes the video distortion you pointed out. The color data you are seeing is the new palette data for the next frame being written into color RAM over a short period of time. It isn't useful for the developers, it's just a limitation of the hardware.

This also manifests in games that do mid-frame color RAM changes such as the water levels in the Sonic games. You will see stationary dots of a solid color that flicker a bit and move up and down with the water level. Those dots come from the CPU writing in new color data and the single-ported RAM being unable to show the normally visible color at that location because the write has priority.

As dual port RAM is expensive there isn't a good solution for this. The TurboGrafx 16/PC Engine has a work-around where the last valid color shown prior to a color RAM write is latched and continuously output until the write finishes. This works well in the overscan area and isn't too bad for mid-frame writes as the pixel affected during a write will be a copy of its neighbor.

  • "data being written into the RAM by the CPU" ... does the CPU have direct access to the VDP RAM? AIUI, the display processor is an advanced variant of the TMS9918 (and therefore similar to late MSX consoles), and in other systems I've looked at that means that only the display processor has access to the RAM at all (it has an interface that lets the CPU ask it to make changes, but usually most changes are done via DMA to/from the main system memory). – Jules Jul 17 '18 at 0:54
  • That's correct, I didn't want to dig into the actual mechanism of memory access to keep things within the scope of OPs original question. When the CPU writes to a dedicated data port that data is loaded into a FIFO that is unloaded as soon as the VDP can access color RAM or video RAM which could be a short period of time (during vertical blank) or a long time (during the active display). While DMA is often used, regular CPU writes work fine too and games will mix DMA with unrolled loops of CPU writes, or won't use DMA at all and do everything manually. – raisin-wrangler Jul 17 '18 at 14:23
  • Re: the side topic of other similar machines, the Master System has exactly the same underlying mechanic of colour RAM that is not fast enough to read and to write during a single pixel clock, meaning that palette writes are visible as single pixels of noise; e.g. watch the bottom of the screen in-game in youtu.be/b68_wGrosX0 though the pixels are farther apart (slower CPU, no DMA). I really think this is the correct answer. – Tommy Oct 30 '18 at 21:51

Developers did occasionally use the overscan color as a profiling/debugging tool. By setting the overscan to a different color at the start of each major section of the game loop code, it was possible to see what proportion of a frame period was taken by different sections of game logic. You could also see how much time margin you had at different points in the game. If there was a crash, the overscan color would hint at which major section of the code was running at the time of the crash — ordinarily a developer running under a debugger would have much more information at hand, but a tester running a cartridge build might not.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.