How can an NES game *not* be open source?

[pojr]

whats up guys? long time fan of the nesdev community, first time making account. hoenstly i wish i made one sooner, as im a big nes fan and considering learning how to develop games.

with that said, im kinda a dumbass and very inept when it comes to programming (outside of php, mysql, javascript).

so anyway...how can an nes game not be open source if we have rom files?

i think i know the answer, its similar to how passwords are encrypted and cannot be unencrypted. just because you can right click + view source, does not mean you can actually see the contents without unencrypting it somehow. am i on the right track?

if I try to right click + view source any random rom file, it will give me a shitshow of random crap that I cannot dissect.

so heres another question. lets say DuckTails on NES is not open source, that means there cannot actually be hacks of that game, right? because theres no way to append to existing code if it isn't open source, right?

sorry if i sound like a complete dumbass.

[Dwedit]

You can always try to reverse engineer anything, or load it into a debugger. But without the source code or debug symbols, it's a hell of a lot harder to do.

Also "open source" refers to the blessing of the creator, not necessarily that the source code is available. If the creator doesn't give permission (usually by means of an open-source license), then any derivative work is *copyright infringement*.

[dougeff]

But they didn't distribute the games as downloadable ROMs. They distributed the games in cartridges, with the expectation that almost none of their customers would be able to freely make copies, or make a working disassembly.

The only (partially) open source original NES games I'm aware of is a music driver that the author specifically allowed to be posted 20 years after the game was off the market.

[tokumaru]

It's true that there's nothing stopping you from looking at a game's code - all the commands being executed by the CPU, as well as the contents of the memory, are clearly visible, but it can be very hard to make sense of what that program is doing when you don't have meaningful names for the memory addresses. Finding what part of the program is responsible for specific tasks in the game is also very hard. You need to spend a lot of time reverse engineering a game's raw code in order to get something that resembles actual source code, that can be modified and assembled back into a working program.

[Controllerhead]

so anyway...how can an nes game not be open source if we have rom files?

Source code != ROM file. Source code implies the original build files, structure, comments, etc. Open source means that the author shares those or makes those public. A ROM is just the raw data that exists on a cartridge. Most (if not all) rom hacks were made by stepping through the code line by line with specialized tools and documenting what each RAM / ROM value is used for. It is a long meticulous process.

[Pokun]

Machine language - this is the binary code the ROM is written in, and the only language the CPU understands. In the case of the NES it's 6502 machine language because the CPU is a 6502. It's very hard to read as is, so if you want to reverse engineer it, you may want to convert it back into assembly (this is called disassembling) to understand what's going on.

Assembly - this is the language you normally program NES games in. You then use a program called an assembler to translate it into machine code so that the CPU understands it (in the past assembly was hand-assembled, this is much more tedious but possible). If you disassemble a ROM you can get more readable code in assembly, but the main problem with doing that is to figure out what binary values are instructions and what are just stored data (graphics, sound, level maps, lookup tables and other data used by the program). Another problem is that some assembly commands, such as comments and macro expansions doesn't exist in machine language, and these things are therefore lost in the assembly process making it even harder to understand when disassembling it again. Also like other people said, an automated disassembly process just gives generic names to labels (like variable and constant names) which also makes the code harder to read.

High-level language - C, C++, Java etc. This needs to be compiled into assembly then assembled into machine langue before it can be read by a CPU. Like for assembly, it's possible to decompile a program into a high-level language, but it's more complicated as this is more abstracted from machine language than assembly is. Whether it was originally actually written in a high-level language or not doesn't matter much though.

Executable programs on your computer are, just like the ROMs in NES cartridges, pieces of machine code and can be disassembled or even decompiled into a high-level language. So all programs has the code "open" and there for you if you are willing to spend the time to reverse-engineer and make sense of it, not just NES ROMs.


Source code refers to the files with code, including comments and other helpful metadata, that the programmer actually wrote. When compiling/assembling the program it turns into machine code which isn't the source code as people said above.