Need instruction on how to save.

[raydempsey]

I have been working on a game and I need it to save. I am not new to programming but I am newer to 6502 and may not be familiar with all the terminology you use in your explanation. I don't understand what needs to happen to read and write from a save file.

[lazigamer]

In order to save data in an NES game you need to set bit 1 of byte 6 in the header of your ROM. Doing so enables 8k of expanded RAM at $6000-$7FFF to be saved to a file when the emulator closes and is restored when you open it up with that ROM.

[raydempsey]

How do I set bit 1 of byte 6 in the header?

Is the only information saved from $6000 - $7FFF ?

[lidnariq]

An NES game stored in the iNES format will, if the battery bit is set in the header (i.e. the 2s bit of the 6th byte of the file is set), save the memory to disk when the emulator quits, and restore from disk when the emulator starts.

Note that this a comparatively expensive addition to the cartridge, and many original hardware never actually supported it.

Most of the games that originally came with battery backed memory (with the notable exception of Family Basic) provide the ability to disable writes to memory to prevent corruption of the save memory. For more specifics, you should tell us which mapper you're using.

[raydempsey]

I'm not sure, but this is how I have things initially set up.

.inesprg 1 ; 1x 16KB PRG code
.ineschr 1 ; 1x 8KB CHR data
.inesmap 0 ; mapper 0 = NROM, no bank swapping
.inesmir 1 ; background mirroring

Does this answer your question? I'm new at this so I still don't know what commands set bit 1 of byte 6 of the header. Also, will the only info that is saved be $6000 - $7FFF ?

[Movax12]

You could always use a password system instead.

[tokumaru]

How do I set bit 1 of byte 6 in the header?

If you're hacking an existing ROM, use an hex editor. If you're assembling from source, look for the iNEs header and change the bit. Some programmers include the iNES header as a binary file (in which case you'd also need an hex editor), others have it defined in editable form in the source code. It varies.

Is the only information saved from $6000 - $7FFF ?

Yes, but since it's RAM you can put anything you want in there. This was Nintendo's standard solution for saving games: a battery backed 8KB RAM chip mapped at $6000-$7FFF (right before the start of ROM, which is at $8000). In a ROM, all you need to do is use the header to specify that this area of memory should be preserved (i.e. it's free), but a real cart that doesn't already have SRAM must be significantly modified in order to support a game that expects this memory to be present.

Another important thing you have to consider when saving games is that data corruption does happen. This makes it important that you implement some for of error detection, to verify that the saved data is present and valid. The presence of saved data is often signaled by a few signature bytes, a sequence of specific values that isn't likely to appear at random. For example, a 4-byte signature has a chance of 1 in 18,446,744,073,709,551,616 of being created by accident, so that should be pretty safe. As for the validity of the saved data, a common approach is to checksum the data (when saving, add all bytes together, ignoring the carry, and save the resulting byte - when loading, add them all again and compare against the saved checksum). This is clearly not 100% safe, because the errors could coincidentally nullify themselves and still generate the same checksum, but that's somewhat unlikely.

BTW, the 8KB of extra RAM doesn't have to be used exclusively for saving, it can also be used as regular RAM. This means that by adding this memory to your game you not only get to save games, but you also bump the amount of RAM you have available from 2KB to 10KB.

.inesprg 1 ; 1x 16KB PRG code
.ineschr 1 ; 1x 8KB CHR data
.inesmap 0 ; mapper 0 = NROM, no bank swapping
.inesmir 1 ; background mirroring

I see you're using NESASM. I looked at the documentation and couldn't find anything related to enabling battery-backed SRAM. Apparently there are only these 4 directives controlling the iNES header, which sucks. Honestly I wouldn't be surprised if NESASM didn't support this, it isn't a very good or particularly well planned program. You can always run the final ROM through an hex editor, but that would be a pin in the ass to do every time. I suggest you start to assemble the ROM without a header and use an external 16-byte binary file containing your header, and use copy /b header.bin + rom.bin rom.nes (if you're running windows) to generate the final ROM.

You could always use a password system instead.

That is indeed a good option if the amount of data you have to save isn't that large.

[raydempsey]

What is the best environment to develop NES games in? I write the code in GVIM and have it compiled in NESASM3. Is there a better way to do this that I am unaware of?

[tepples]

The most popular assemblers around here seem to be ca65 and ASM6. ASM6 is simpler; ca65 is more flexible. I have a project file that will get you started with ca65 on SNROM (common board with save, using MMC1).

Password systems can comfortably save up to 32 bits of data and uncomfortably up to 96 or so.

[tokumaru]

NEASM3 has a lot of users because it's often used in tutorials, but it has some flaws and limitations that sometimes get in the way if you don't have the experience to know what's happening. It uses non standard 6502 syntax for some things (i.e. indirection is [], not (), like in every other 6502 assembler in existence), and is known to assemble corrupt binaries without any warnings if your source code contains certain errors (e.g. wrong addressing modes and such). It also makes the somewhat annoying assumption that all code must be broken up in 8KB banks. Apparently you can't let the code/data smoothly spill into the next bank, you have to explicitly use a .bank directive to specify the beginning of every bank, even if the specific mapper you're using doesn't deal with 8KB PRG-ROM banks.

ASM6 is as simple as NESASM to use, it's just different. It has no special directives to create the iNES header, but you can create one just as easily with .db statements. Other than that, it's practically NESASM without the annoyances.

CA65 appears to be the definitive assembler with tons of advanced features, and because of this, getting started with it is a significantly more complex process. You can't just give it an ASM file and get an NES file on the other end, first you have to write a config file detailing how the memory is supposed to be mapped (which changes from mapper to mapper), then you assemble the code and get an object file, not a ROM, which you have to link (whatever that is) using a separate program to finally get a working ROM. You can of course get config files made by other people, but if you don't understand how the process works you're bound to hit a wall sooner or later.

[3gengames]

Saying ASM6 Is easier to use is complete BS. I write with NESASM3, but the ASM6 code to set up a ROM is ridiculousness for an assembler. The NES community is large enough, we need our own NES assembler. I'm working on one I'll open source when it's done and add features and such or let users do that. It's time we get something not a POS to make NES games with the NES mappers and such in mind. No assembler does that better than NESASM3, but YES it does have tons of limitations. My end point was RAM code, too much of a bitch to do, so time to make my own tools.

Still, all you do is put memory somewhere and read it later in the 6000-7FFF range on a cart with a mapper. That can also be used as normal RAM. But you also can just use passwords, like others said.

[zzo38]

I believe that in NESASM, the INESMIR command is used for that purpose; add 2 to the number given to set bit1 (so, put 3 instead of 1).

Saving is then done in a range $6000-$7FFF; you can use part of it as ordinary RAM too, if you like to do so.

I myself prefer a variant of NESASM (I have made various changes myself). I prefer the non-standard syntax used in MagicKit. But, you are free to make your own, and let's see how well it is, too! Perhaps it is good, at least for some people.

Also, Family BASIC does come with the ability to disable writes to battery RAM, although it is a physical switch rather than software-controlled.

[tokumaru]

Saying ASM6 Is easier to use is complete BS.

I didn't say it was easier, I said it just as as easy as NESASM. It really is, it just uses different words to build the basic structure of the ROM, but the amount of typing isn't that different and the assembling process is the same (supply .asm file, get .nes file).

the ASM6 code to set up a ROM is ridiculousness for an assembler.

Eh? I don't see what's so ridiculous. Ridiculous is having to put markers every 8KB and losing code without warnings if you fail to do so.

The NES community is large enough, we need our own NES assembler.

I disagree. I like to code for other 6502 machines, such as the Atari 2600, and I'm perfectly fine with using an assembler that is versatile enough to handle code for the different machines I like to work with. I don't want to use a different assembler for each machine I work with, and have to deal with different peculiarities and limitations if the language is essentially the same! I already find it bad enough that I have to use different assemblers for different CPUs! Ideally I'd have a single assembler, with a set of features that I could use consistently across all the CPUs I write code for, with only the instructions themselves differing from CPU to CPU.

[Movax12]

we need our own NES assembler

What will it be able to do that current assemblers cannot?

[3gengames]

we need our own NES assembler

What will it be able to do that current assemblers cannot?

Output NES ROMS and include iNES 2.0+iNES 1 options right as assembler directives in clear text, for beginners. After that, it'll be able to do whatever anyone else wants to make it do. Js....expect it to be done in a long time, I'm just pointing out not everyone likes using assemblers that are dynamic, but that makes them insanely hard to use and follow. Do you see NESASM3 templated around? No, because it's not as difficult to get a more NES-focused assembler working from nothing but the readme.