The Legend of Zelda is being adapted for the Commodore 64 in a work-in-progress port from developer Goldfinger, and the project has already moved beyond a simple technical demo. The present build includes a complete overworld and dungeon levels, scrolling rooms, item screens, character creation and cartridge-based save progress. It also has music, sound effects and an attract-mode introduction intended to echo the original game’s presentation.

That is an ambitious list for a project whose central challenge is not merely getting an adventure game to start on different hardware, but retaining the broad structure of Nintendo’s original while fitting it into a distinctly constrained format. Goldfinger is targeting an Easy Flash 3 cartridge and says the current build is slightly larger than the original NES game’s 128 KB limit. Reducing that footprint is therefore a core part of the work still ahead.

The adaptation was built using Aldo Núñez’s commented Assembly source code hosted on GitHub. Assembly is a low-level programming language closely tied to the processor a program runs on. In practical terms, that makes it useful for a project where each feature, asset and routine needs close attention, but it also makes optimization painstaking: reclaiming memory can require revisiting how game data and code are organized rather than simply trimming a menu or two.

A full quest is the stated target, not a single-screen experiment

The most important detail is the scope of what is already represented. Goldfinger’s build is described as having the complete overworld and dungeon levels, with rooms that scroll rather than remaining limited to isolated test areas. Functional item screens and persistent saves matter for the same reason. Together, those features point to an effort to preserve the loop that defines the game: explore, enter a dungeon, gain tools, manage progression and return later without losing a file.

Save support is handled directly by the cartridge. That approach is significant because the port is being designed around an Easy Flash 3 cartridge rather than around a purely temporary session. The build also has complete save-file character creation, so the saving system is not described merely as a placeholder for testing levels.

Goldfinger has included automatic detection for both NTSC and PAL systems. Those names refer to two television and timing standards historically associated with different regions. For a Commodore 64 release, recognizing which standard is in use is useful because it lets the software account for the machine’s operating environment rather than treating every system as identical.

The current speed is said to be broadly comparable to the NES original. Goldfinger has also raised the possibility of achieving a version without slowdowns, unlike the NES game. That remains a goal rather than a confirmed final characteristic, and it should be viewed alongside the stated need for playtesting and optimization. Still, performance is clearly a major priority, not an afterthought reserved for a later revision.

Memory is the immediate engineering fight

The original NES release fits within 128 KB, while the Commodore 64 project presently goes a little beyond that size. On modern platforms, a small overage might sound trivial. On a cartridge-focused retro project, it is not. The limit turns compression, code efficiency and asset handling into creative constraints that can shape the final build.

Related coverage includes The Legend of Zelda Is Being Ported to Commodore 64, With a Full Quest Taking Shape.

Goldfinger plans to claw back the required space during development. The available description does not specify which data or systems will be changed, so it would be premature to assume any particular artwork, sound, map or feature is destined to be cut. What is clear is that the project is still in an optimization stage, with the existing feature set providing a baseline rather than a guarantee that every implementation detail is final.

The developer has self-deprecatingly characterized the graphics as “lame,” but the port is not presented as silent or stripped to bare mechanics. Music and sound effects are included, alongside the attract-mode opening. That mix illustrates the balancing act involved: a faithful-feeling port is about more than the outline of the map. Audio, transitions, menus, saves and introductory presentation all consume development attention, while the cartridge-size target remains in view.

Why scrolling rooms and menus are meaningful milestones

Scrolling rooms, item screens and saving are easy to take for granted in a contemporary game, but they are useful indicators of completeness in a retro adaptation. Room scrolling has to work while the player moves through spaces; item screens must display and manage progression information; saving must correctly retain a player’s state. None of those systems, on their own, proves the project is finished. In combination with the reported overworld and dungeon coverage, though, they show that the adaptation is pursuing the structure of a complete adventure.

That is also why the remaining minor bugs matter. Goldfinger intends to conduct further playtests, and a game that offers a full quest can expose issues that would not show up in a short demonstration. A bug in movement, menus, room transitions or saving can have consequences across an entire playthrough. The work ahead is therefore likely as much about consistency and reliability as it is about shaving down the final memory use.

A possible 1541 edition would revisit the original’s disk lineage

Goldfinger also hopes to add native support for the Commodore 1541 floppy disk drive. This is an aspiration, not a promised feature for the current build. If it happens, it would create an interesting parallel with The Legend of Zelda’s original release on Nintendo’s Famicom Disk System.

The key word is native: it indicates an intention to support the 1541 as a proper delivery or operating format rather than simply treating the cartridge version as the only route. No technical details or release timetable have been set out for that work, and it should not be confused with confirmation that a floppy version is ready. For now, the Easy Flash 3 cartridge remains the stated target.

Retro game projects can take several forms, from a visual homage to a new game inspired by an older design. This one is more complicated because it is explicitly an adaptation of a still-identifiable Nintendo game. That distinction leads directly to the project’s largest nontechnical obstacle.

Goldfinger would like to publish the complete source code so other community members can improve or repurpose the engine. However, copyright concerns involving Nintendo’s intellectual property leave any official public release uncertain. The technical progress should not be read as a confirmation that a final public version, download or open-source package will definitely arrive.

This uncertainty has two separate practical implications. First, people following the project should distinguish between what has been demonstrated in development and what will ultimately be distributed. Second, even a desire to share code does not automatically settle questions around material based on a protected game. Goldfinger’s stated ambition to let others build on the engine exists alongside, not ahead of, that unresolved legal issue.

The project nevertheless stands out as a close look at the compromises and possibilities of adapting a large, familiar console adventure to another vintage system. It has broad game coverage, platform-aware video handling, cartridge saves and sound already in place. It also has a specific memory budget to meet, further bugs to identify through playtesting, a potential disk-support path and uncertain publication prospects.

For readers interested in another case of vintage-game preservation and renewed access, Dead of the Brain’s official English Steam release offers a separate example of older software reaching a new audience through a very different route.

For Goldfinger’s Zelda effort, the next meaningful milestones are straightforward even if achieving them is not: get the build within its intended size, resolve the remaining bugs, validate the experience through playtests and determine what, if anything, can be publicly released. Until then, it is best understood as a substantial work in progress rather than a finished Commodore 64 edition.