A discussion about game preservation is heating up on social media as the game industry adjusts how it distributes games and how players access its catalog, especially after the latest news that Sony ending physical disc production in January 2028. This isn’t a threat to retro games, but it is a symptom of the same trend that has been narrowing access to older media for years. In this context, one of the most concrete ways to preserve games is to make sure they remain playable on new platforms, and this is where porting enters the discussion.
But before we get into more modern ports and high-level abstractions, it helps to start with a platform whose graphics logic is fundamentally different from what we use today. Knowing its limitations can help us understand that porting a game often means reinterpreting the whole system under new rules.
In November 1990, TecToy brought the Sega Mega Drive, a 16-bit game console, to Brazil around a year after its launch in the USA (where it was known as the Sega Genesis), and it gained increasing popularity that has been maintained to this day by its active community and fans. Thanks to this lasting fan support and its relative hardware simplicity, this game console has an established development scene, and it is no surprise to find new releases for Mega Drive each year.
Brazilian Sega Mega Drive III, manufactured by TecToy
Nostalgia aside, this is a great starting point for this article, as the Mega Drive’s main graphics processor has very specific restrictions, for example, limited tiles, palettes, and sprites. These constraints are exactly what makes it a useful case to understand how porting changes across hardware generations, especially when there’s no programmable graphics pipeline to fall back on.
Graphics on Mega Drive
There is a series of questions that need to be answered to port Mega Drive games, but for this article we’re going to focus on the graphics side. Two processors (Motorola 68000 and Zilog Z80), audio chips, memory management, and the memory bus are some of the other things we need to be aware of.
Graphics processing is centered on the Video Display Processor (VDP) on the Mega Drive; it defines many of its functions and limitations. The VDP can render tile-based graphics, process movable objects (sprites), and manage the background. Also, it controls access to video memory and executes essential functions such as horizontal/vertical interrupts and fast data access using Direct Memory Access (DMA).
Sega 315-5660 (Yamaha FC1004) ASIC, with the VDP core integrated alongside I/O and FM sound
The VDP uses three separate memory regions: VRAM for most graphics data, CRAM for palette colors, and VSRAM for vertical scrolling values. The VRAM and CRAM are more directly involved in generating the final image. Meanwhile, 80B of VSRAM is used to store the Vertical Scroll (V-Scroll) data, enabling scrolling effects for the planes. Each of these regions comes with its own tight budget, and VRAM holds the bulk of what actually reaches the screen.
64KB of VRAM is used to store tile data, along with tables for the planes’ tilemaps, sprites’ positions and properties, and the Horizontal Scroll (H-Scroll) data. The Motorola 68000 CPU doesn’t access VRAM directly; it must send commands to transfer data through VDP I/O ports mapped into system address space. This access is slow during active screen drawing, but it is more practical during the Vertical Blank (V-Blank) interrupt, so it’s usually the ideal time for bulk updates. The VDP uses DMA to transfer data from system ROM/RAM to VRAM, essential to the smoothness of animation and fast tile changes.
On the other hand, 128B of CRAM is dedicated exclusively to storing palette colors. It contains 64 entries of 9-bit colors (3 for each channel, RGB) distributed into 4 palettes of 16 colors, allowing color selection from a master palette of 512 colors. Palette index 0 is commonly reserved for transparency or background color; in practice, the Mega Drive offers 61 usable colors on screen, because each palette reserves its first entry, and one of those is typically used as the background color.
Sega Mega Drive master palette (512 colors) shown in its three brightness states: shadow, normal and highlight
This fixed budget isn’t limited to memory and color, but also to screen composition. Unlike current GPUs, the VDP is organized around 8×8 tiles instead of direct per-pixel drawing. The Mega Drive composes its backgrounds and sprites by arranging these tiles within a grid-like structure, known as a tilemap. An artist, for example, needs to slice images into 8×8 tiles and assign each tile a limited palette instead of a more granular pixel-level or color-level control like in modern engines.
Because palette selection is part of the tilemap and sprite attributes, tile data can be reused with different colors; techniques such as palette swap enable reuse of the same sprites with different colors, for example, to indicate a stronger enemy variant without duplicating tile data. Using this same principle, hypothetically, it is possible to do something like Mortal Kombat does with the ninja/cyborg characters (Scorpion, Sub-Zero, Reptile, and others), using the same base sprite and rendering each one with a different palette.
An illustrative example of palette swap with Mortal Kombat’s ninja/cyborg characters
This affects how assets are made, since artists have to adapt sprites to a limited tile/color budget, often simplifying designs or reusing tiles to make them fit within the console’s constraints. The sprites, for example, live under the same fixed budget: up to 80 on screen and 20 per scanline (64 sprites/16 per scanline on H32 mode). This limitation can cause sprites to disappear once the scanline budget is exceeded, something with no equivalent on current GPUs. This is why some design decisions are born directly from hardware boundaries. This kind of decision is something any porting strategy will have to inherit, work around, or replace.
Modern approaches
Once the limitations of the Mega Drive are understood, a central challenge is in deciding how to bring the game to modern platforms without losing its original intent. The console’s constraints don’t disappear when targeting current GPUs; one cannot simply “press a button” to generate a new version of the game. The porting workflow is directly impacted by these limitations even if the current platforms don’t have them, as artists have to adapt or rebuild graphics. At the same time, programmers must decide which VDP behaviors to preserve and which ones to replace with modern approaches. These decisions dictate how sprites, palettes, animations, and effects are handled.
On modern platforms, rendering relies on programmable pipelines, direct per-pixel drawing, and significantly larger memory budgets. Consequently, Mega Drive games are typically brought to modern platforms using one of two approaches: preserving the original functions within an emulator or recreating the game using an engine and a modern rendering pipeline. Each approach has its own pros and cons, balancing factors such as fidelity, cost, and control, which determines which method makes the most sense for a given project.
Emulation
In general, emulation is often preferable when accuracy to the original hardware is most important, development time is limited, or access to the source is restricted. Emulating a game consists of simulating an older console hardware (CPU, graphics chips, memory, etc) via software. Hence, the game runs on a modern platform very close to how it would on its original platform.
In practice, this means embedding an emulator along with the game ROM within a native application for the target platform. The result is a unified package, eliminating the need for a standalone emulator like Gens or BlastEm. The player can interact with the modern platform’s input and interface, while the game runs largely as it did on the Mega Drive.
An example of this approach can be seen in the early iPhone releases (2009) of Sonic the Hedgehog and Sonic the Hedgehog 2. On a jailbroken device, for example, one could replace the internal “rom.bin” file with a different Mega Drive ROM to play a different game, confirming the nature of this implementation.
Sonic the Hedgehog (iPhone)
From the player’s perspective, the experience was that of a native app, complete with on-screen controls and an App Store listing. However, the game inherited most of the Mega Drive’s graphical limitations, which became apparent when it was displayed on modern, high-resolution screens.
Reimplementation
On the other hand, reimplementation is often more suitable when there is a need to add new features, improve graphics, or optimize for modern platforms. Still, it typically requires more time and resources. Instead of emulating the Mega Drive, the general idea is to rebuild the game logic and visual presentation using a new engine, designed specifically for current environments.
This makes it possible to treat sprites as textures, palettes as full RGB colors, and to use a modern rendering pipeline rather than faithfully replicating the VDP pipeline. The cases of Sonic 1 and 2, specifically their 2013 remakes for iOS/Android, illustrate this contrast well. While the earliest versions relied on embedded emulation, Sega released remakes based on Christian Whitehead’s Retro Engine.
Sonic the Hedgehog (2013 game)
The games were recreated from scratch, featuring native widescreen support, high-resolution graphics, 60 FPS gameplay, and additional content such as extra levels and all-new game modes. This same engine was previously used for the Sonic CD (2011) remake, establishing the Retro Engine as the foundation for modern ports of classic Sonic titles, as well as new games like Sonic Mania (2017) and Sonic Origins (2023) in updated engine versions.
This process offers much greater control over performance, input, resolution, and asset creation. It allows modernizing the experience without being limited by the Mega Drive’s tiles, palettes, and sprite limitations. However, it requires recreating a significant portion of the game, increasing development costs and effort. Also, it introduces the risk of altering subtle aspects of the original gameplay.
Conclusion
Overall, porting games from older platforms such as Mega Drive to modern platforms highlights how hardware shapes both technical limitations and creative choices. Whether through faithful emulation or reimplementation using modern custom engines, each approach offers distinct features and challenges for preserving the game experience or updating it for new players.
In this context, porting is not simply a technical matter but also a form of preservation, keeping these games accessible and playable on new platforms. This article focused on Mega Drive graphics as a case study for 16-bit consoles, but each console has its own limitations that need closer attention when beginning the porting work.