Hello everyone. Ill introduce myself first since this is my first post. My name is Ryan and I , only recently , started learning 6502 assembly language. I want to learn how to make small modifications to some of my favorite NES games to update them. I asked a few programmers about 6502 and they told me the best way to start is to envision your goal the. Learn all the small steps it takes to reach that goal. And to make sure you ask the right people. That's why I am here.

Even though I'm in my infancy stage of learning this I don't want anyone to do it for me. I've had a few people tell me that they would do it. I want to do it myself. But I do need a few people to hold my hand a bit.

What I am trying to do is add a save feature to the Super Mario Bros. 3 game. I figured that this was as good a place to start as any. Manipulating existing code is easier than writing it myself. I want to create a patch that I can apply to any SMB3 rom and add the save feature. But I dot know how to change the rom to use the battery backed SRAM instead of zeroing everything out when the game is turned off. I know the values in the rom that need to be saved. Such as how many coins mario has or what levels are completed or which items mario is carrying. In the rom all of those are stored from $6000 to $7FFF , so that's the area I need to save.

Does anyone here have some ideas for me. I appreciate you all taking the time to read this and help me out. I am amazed at the possibilities that learning 6502 will open up.

Thanks.

Ryan

Hi Ryan, welcome! I'm sure you can get some help here, but you'll need to help us by saying more about what you do and don't presently understand, and what you've tried, and what tools you are familiar with.
The NESDev site has lots of helpful material and people, so try that too.
Cheers
Ed

Thanks BigEd. To answer your question, not much. LOL.

I am currently just figuring out what things in the code do. Ive been manipulating the code in SMB3 slightly and watching the effects on the game. Like adding more items in mario's cache, or Switching enemies around. Things of that nature. But I habe mainly just been identifying what things are. Ive ordered and few 6502 books and hope to have a better understanding of it all in a few months after practicing up a bit. Thats why Ive been messing around with existing code.

Ive been using HxD Hex Editor mainly. I do have a Disassembly tool as well but I havent used it much.

So Far I have edited the INES header to say that it has the SRAM , But my biggest problem is that I have no idea where the actual "Save" portion of the rom is. I know wat values need to be saved but dont know where to write them in at. I have 2 roms. One that saves and one that doesn't. I have compared the 2 to try and identify something that would tell me something. But I have had no luck at all.


Thank you all for reading this. I appreciate any help I can get.


Ryan

Ryan,

You don't start small for your initial project, do you? Are you looking to have a single "save slot", a.k.a. "continue" feature such as in Final Fantasy (the first one) or Dungeon Magic, or multiple slots such as in Zelda, Crystalis, Super Mario World, and so on? Do you know approximately how much data you need to save in each slot? Do you know which parts of the "SRAM area" are unused by the game already? Do you want the game state to be saved implicitly whenever returning to the map, or explicitly under player control from the world map? Or even just to have the option when completing a fortress or boss battle (as in Super Mario World, again)? Do you really need to save the number of coins, lives, the score, and your item inventory, or is it sufficient to simply save the world map state? If you're using multiple save slots, do you select a single slot for the duration of the "game" (Zelda / Super Mario World model) or do you choose a slot each time you save (later Final Fantasy, Crystalis model)?

To begin with, I'd focus on analysis. SMB3 is apparently 16 PRG pages and 16 CHR pages, and uses MMC3. Figure out which areas of the ROM are graphics, which are level data, which is music, which are code, and so on. Once you know where the code is, disassemble it. Or just disassemble the entire ROM, look for sequences that could be code vs. sequences which are obviously not code, and use that to narrow down what is in each part of the ROM. Be aware that you may need to re-do your disassembly once you figure out more about the memory model that the game uses. Read NES programming tutorials, information about the obscure details of the hardware (some of which would have been Really Useful back when I was writing my NES emulator), and so on. Keep notes. If you can work out what parts of RAM are used for what data, that will help, and you might be able to do that by taking successive emulator save states and comparing them if you know the save state format. As a simple example, the in-level clock is monotonic-decreasing at a known rate. Take a few save states at successive seconds and compare them, one of the differences will be the clock, and the fact that you know its value will help to track it down. Do something similar in terms of before/after snapshots at the toad house on the first level to try and find the item inventory. Alter the save states to see if you can increase and decrease the amount of time remaining in the current level, or to stuff your inventory with various items. Look to see if someone else has already published an analysis of this ROM.

When working with the disassembled code, look for "leaf" routines, which don't call anything. Look for routines which access the PPU, the APU, the MMC3, and RAM. Try to build a dictionary of known RAM locations, known data areas, and known and unknown routines. Try to figure out what the RESET, NMI (PPU vblank interrupt) and IRQ (MMC3 scanline interrupt) routines do. If you know what certain areas of the ROM or RAM contain, watch for code that accesses those areas, even if you don't understand the code you'll know more-or-less what it does, which will help you to figure out what it's doing.

Find a game that you like that has a save feature that works the way that you want your save feature to work and analyze that game, with a focus on finding access to the save memory and figuring out how it works and what things it does that you might or might not have expected. Expect to be surprised.

If you don't know how to program yet (anything, not just the 6502), start learning about that, too. A 6502 system is a great place to start learning to program, as the programming model is fairly simple and yet still powerful enough to do an amazing amount of work. Start working through 6502 (and even NES-specific) programming tutorials. Find existing programs with source and read them. There will be a huge variation in quality and readability when it comes to program source code, so think about the differences and how they affect your ability to understand and possibly modify the code.

You are at the beginning of an amazing journey, one that will be a lot of hard work, but if you stay with it you will see some truly wonderful things, and the skills and understanding that you build in your explorations will serve you well for your hobby, and possibly your professional career, and you will be able to look upon some of your projects with pride and be able to say "I did that".

As a side note, my entry into NES hacking was in '97 or '98, and I was hoping to translate FF3j to english (I never did). I had prior experience with the 6502, Marat's NES document, and a small number of ROMs. I started by writing my own disassembler (not at all difficult), but once I reached the limits of my understanding that way I ended up building the start of a CPU simulator (capable of simulating a small handful of instructions), then RAM, bankswitch controls, and the bare minimum of a PPU status port, all under single-step control. That eventually spawned a full NES emulator, which got me my first real programming job, working on 6502-based modem firmware. I knew another NES emulator developer who at one point was using his reverse-engineering skills to work out a performance model for the graphics hardware in some game console for his day job at a game development company. Even if you never apply the specific skills for working with the NES and 6502, the more general skills and approaches to problems that you develop will prove useful again and again over your lifetime.

-- Alastair

Alastair,

Thanks for all of the suggestions. I will do as much as I can. And I agree 100% about learning 6502 Programming. Ive always wanted to but life always seemed to get in the way. Now that Im older I have more patience and time to do the things Ive always wanted to do. And programming my own game is at the top of that list.

Yeah, I know that this project is not the easiest, But I think that manipulating or adding to existing code is a good way for me to practice and learn.


As far as the SMB3 Save feature project , I have been messing around with the values in the RAM area as you suggested. I can change the amount of lives MArio has or add items and coins to his inventory. So I have figured out the values in the ROM that need to be saved. ALSO, I have a ROM of another game called "Mario in Some Usual Day" that has the Save feature just like I want it. But I cant identify in the ROM what he's done to create that save featur. Thats where I am reaching out to you all here. To help me identify what code is creating that save feature. I can then take that code and write it into a smaller code that I can make into the IPS Lunar patch. I will try to attach the zip files of the games below.

Right now I want to stick with just one save slot or a "Continue" button. Maybe after I get this done and I learn more I will try and create a Multiple palyer slot like Super Mario World has. But that is waaay beyond my reach right now.

Thanks again.

Check out the files and see if you can see what I cant. I truely appreciate it.


Ryan



.........UPDATE.......... The files I tried to upload are not allowed. SO I will not be able to upload them here. I have uploaded the zip files of the patches. If you want to try them out you can.

The SMB3SUD is the ROM that has the save feature

The SMBCC is the Rom that I have been messing around with.

I just heard back from the programmer who programmed mario in some usual day. Although its been years since he did that game he had this to say

"Hmm, if I recall correctly when the 'save' is enabled, then the RAM in the range $6000 to $7FFF will automatically be saved. So you need to add a routine to write the values to this area of the RAM, and another to load them at the start of the game and store them to the appropriate original offsets."


I don't quite know what he is referring to when he says "routine".

Can anyone here understand how to do this ?

Ryan

noun
1.
a sequence of actions regularly followed; a fixed program.
"I settled down into a routine of work and sleep"
synonyms: procedure, practice, pattern, drill, regimen; More
a set sequence in a performance such as a dance or comedy act.
"he was trying to persuade her to have a tap routine in the play"
synonyms: act, performance, number, turn; More
COMPUTING
a sequence of instructions for performing a task that forms a
program or a distinct part of one.

All kidding aside, it would appear that you need to move 8 kB of data
from one spot to another, and vice-versa, at the user's request. It
would be impossible for me to provide you with any architecture-specific
detail, but Bruce gives a nice general example here:

http://6502.org/source/general/memory_move.html

If your source and destination do not overlap each other, you can use
his simple and fast MOVEDOWN routine. Maybe that can get you started
down the proper path.

Happy coding!

Mike

I'm working on an NES emulator and can fill in some more details.

The $6000-$7FFF area is where battery-backed RAM tends to show up for games that have a save feature. Just to confuse you, this area is variably called PRG RAM, SRAM (probably for Save RAM), and WRAM (which apparently stands for Work RAM - no idea why).

In the original iNES format (which 99% of roms use) it is assumed that all games have memory at $6000-$7FFF (as having memory there usually doesn't hurt even if it goes unused). For the emulator to know whether that memory is battery-backed and needs to be saved, you have a bit in flags byte 6 of the iNES header (see http://wiki.nesdev.com/w/index.php/INES).

So the basic outline to add a save feature would be as follows:

1. Set the battery bit in the iNES header so the emulator knows the memory needs to be saved.
2. When saving, put the data that needs to be saved into $6000-$7FFF.
3. When loading, read the data from $6000-$7FFF.

There is one more complication, which is that some mappers (including MMC3, which SMB3 uses) can disable and write protect the SRAM. If the emulator implements this, you might need to write to $A001 first to enable the SRAM and disable the write protection (see http://wiki.nesdev.com/w/index.php/INES_Mapper_004).

Other than that, things should just work automagically.

Seems SMB3 has 8 KB of non-battery-backed WRAM though (so essentially just a RAM extension - guess that might be where "work" comes from), which will make things much trickier. You can't just dump data there without potentially stomping on the game's data.

Hi Ryan, although I'm more into emulator development rather than 6502 programming, your idea of modifying existing games interested me because that's mainly the same idea I had that made me start writing my own emulator, so I'd like to hear about the progress of you project here.

I guess you want to make some other modifications than just adding a save feature, but just to be sure, is there a reason you want this feature injected in the ROM code rather than enforced by the emulator? because many NES emulators do already have a save feature that saves and restores the whole state of the NES so it works with any game.