Is it possible to scale an emulator's video to see more of the level?

Short answer: No

One thing to keep in mind about older systems (both for video games and home computers) is that memory used to be a luxury. They didn't have gigabytes (or even megabytes) to spare of either storage or RAM. Rendering an entire level when only a small part would be displayed would have been a huge waste of precious computing resources.

Also, there's no reason to assume that every single NES game coded its map the same way. It's very likely that over time they figured out better ways to do it, so even in similar games (SMB1 vs SMB3) the maps would be stored in memory differently. This means that there's no reason to expect an emulator to know how to take a particular game and render the full map for the current level.

There are also a lot of other problems with this - I know that in SMB1, enemies that are off-screen don't move. Would you expect them to be moving the entire time, or only when the active portion of the screen reaches them? The former affects the gameplay of various games, while the latter would require additional logic that currently doesn't exist inside the game code.

Even if you modified the game code, an emulator isn't going to be able to handle it unless you modify the emulator as well. The emulator will need to be able to handle game maps of differing sizes, as well as expecting to give the game more resources.

There are two ways to do this: one generic and one game-specific.

Watching the scroll seam

The Nintendo Entertainment System has 2 KiB of video memory in the Control Deck. This is enough for 256x480 pixels or 512x240 pixels of the map, depending on the nametable mirroring mode that the Game Pak chooses. Because the memory in a Game Pak is so small, such as 40 KiB for Super Mario Bros., games store the map compressed and gradually decompress it to video memory as the camera moves through a level.

Nova the Squirrel © 2018 Joshua Hoffman
Animation of newly revealed areas in a scrolling level, taken from "PPU scrolling" on NESdev Wiki. Video memory is at top; the rendered background is at bottom. The orange bracket shows the current scroll position. $2000 and $2400 are the hexadecimal base addresses in video memory of the two tilemaps.

A specially modified emulator could watch for writes to the scroll register and log newly revealed areas of the map. Such a feature would only show visited areas and possibly an approximation of enemy starting positions based on sprites passing through the newly visited area. It would not show unvisited areas at all, in much the same way that a map in a PC real-time strategy game omits unexplored areas. But if a game's map isn't randomized, an emulator can cache the map from a previous play-through of the same level and reveal what is to come.

Reverse engineering

Though different games use different map data formats, several games have been reverse-engineered in enough detail to allow writing a PC program that decodes an entire map. Often the results of such reverse engineering are posted on RomHacking.net. Some games are understood in such detail that people have created level editors, such as many games in the Mario, Zelda, Metroid, and Mega Man series.

Yes, the requested goal most certainly can be done. This claim isn't just blind theory: Something very similar already has been done.

First of all, I acknowledge the difficulty mentioned by others. Since level data is likely to be stored in different ways for different games (e.g., discussion about Zelda's map data), an emulator would need custom data for each game. Through an expanding collection of plug-ins, that could be done. So I come to the opposite conclusion. It could be done for the finite amount of games that have been commercially released, just as MMCs were added. However, this would be a quite time consuming project due to some substantial difficulty.

There are multiple games with level editors. Such editors know how to read data from the cartridges, and such software has been useful for fans who have sought to have maps that they were confident were completely accurate.

However, let's look at another approach that responds to what was really intended to be asked. Another option is to capture the graphics as they are rendered. You don't get the option to "do that," (make the map), "and then" (in the specified order, after completing the first step) "still be able to play", as the question asked. So this doesn't show the entire map immediately, before the first "play through".

What you do get is a rather automated way to see the map data which was previously on the screen, stitched together rather automatically, which could create maps. (Even if changes were required, having such maps as a starting point might be a while lot easier than trying to make things from scratch.) Since most NES games use map data which is repeated upon a later "play through" (instead of random map data), such maps could be used to look at before playing through again. Based on Question poster's comment, the goal isn't necessarily to see the entire map immediately.

Based on that actual goal, this is definitely a goal that can be achieved (at least with some limited success). A video shows something very similar which has actually been done, by using:

• a real NES
• real NES controllers
• custom hardware, which combined input from multiple NES controllers
• hardware that processed the video that gets displayed

Although map data wasn't stored for long term use, because this project had some slightly different goals, the result showed map data after it was used. I expect that the technique could be modified, rather easily, to save the map data, instead of dismiss the map data. In fact, they have released some partial maps (shown in in a PDF file, and some of which are mentioned on the project's Ars Technical publication). I recall seeing at least the following games, in a video that demonstrates this system:

• Super Mario Bros. (1)
• Super Mario Bros. 2 (American release) (a.k.a. "Super Mario USA")
• Super Mario Bros. 3
• Probotector (re-skinned version of "Contra", as released in Europe)
• Castlevania
• Life Force
• ExciteBike

This is shown by this awesome video: Unfolding The 8-Bit Era (8 bits, 8 players, 8 projectors, and one Nintendo Entertainment System). Prepare to have your jaw drop due to sheer awesomeness. Additional details are provided by the web page referred to in the YouTube video's comments, and also referred to here: Ars Technica article: 8 bits, 8 players, 8 projectors, and one Nintendo Entertainment System.

From the PDF file (distributed by Unfolding the 8-Bit Era): "As our target was 360 degree projection, we focused on side-scrolling games and developed a tracking algorithm designed for this use case. Our method does not currently support vertical scrolling or more complicated camera movement." (I guess people would have had a less interesting experience if they got to far-enough levels in Life Force.)