Hello I am FAST6191 and I will be your wet blanket for today. Most of what you suggest is not impossible but some of it would trouble the best of the NES hackers and programmers. Equally most sound like fine improvements but if you are set on making emulator only ones* I do have to ask why not program something normally? Pretty much every general use language going will be able to make something as powerful as a NES game that runs on modern hardware (hint- if flash can do it then pretty much anything can). Generally speaking adding entirely new things to a game is harder than replacing existing content (easier) or increasing the scope of existing content (harder) but it can be done.
*there are quite a few of the opinion that if your NES or SNES hack (typically the only ones that really go in for this) is emulator only then it is not a NES/SNES game.
StillCastlevania II: Simon's Quest - Complete OverhaulI understand that the things listed would probably make the game itself a little too big by not being able to fit it onto an actual cartridge though that's fine with me as I just want it strictly as a ROM [emulator] only.
It sounds like the idea of mappers is going to have to be explained.
The stock has a pitiful amount of ROM space (32 kilobytes or even just 16 depending upon how you want to look at it) and it is not the greatest hardware either but more on that later.
To this end we have mappers which allow you to change the 16 kilobyte sections with another and also add extra abilities to the NES in some cases (less so than the SNES special chips but still something extra).
Changing a mapper is not that hard in terms of the basic idea but the trick comes in catching every edge case in a ROM where the stock game would load from a given bank and if your game is not presently on the bank it thinks it is then crashing, corruption, explosions, the summoning of Cthulhu...... happens. As NES games were typically not programmed in high level languages (a few people have since managed to get something resembling high level programming languages onto the NES but it is still ASM country) this is not easy to account for either. Also ever wondered why Final fantasy 1 saw amazing hacks like Dragoon X Omega II where Final Fantasy 3 saw a translation or two and not a lot else?
I have not looked up what this game uses but there are some "emulator only" mappers and tweaks to them.a graphic overhaul
The NES is not the greatest in terms of power so lots of graphics tricks were used. This means if you want to add lots of colours or increase the effective resolution then you could run into lack of memory problems.
Similarly if you want to try adding animations you could run into problems to (occasionally consoles keep sprite sheets in memory)add music then make/turn it into the VRC6 format. The music editing and adding I've been trying to find for ages now.
Returning to the mappers idea we also have to note that the famicom could have more expanded on it than the NES could and this includes the VRC6 audio extras.
Adding music is easier. There is no NES audio format (NSF is basically a cut down ROM with a given game's sound engine) and audio engineers, especially those on old consoles, are ones for making nice custom things. You will probably not find too much on general NES audio as I can describe the basic idea in a paragraph (though it would assume general debugging skills), the hardware specifics in another, music theory is well music theory and you can go as much into that as you like and the rest is all custom though still heavily revolving around the hardware.
The nes audio "chip" is the APU (some docs call is the pAPU or pseuedo-Audio Processing Unit as there is no audio chip save for those things like VRC6 and it is in the CPU itself) and it is covered rather nicely http://wiki.nesdev.com/w/index.php/APU
with the expansion stuff from http://wiki.nesdev.com/w/index.php/Category:Expansion_audio
You run the game, watch what talks to the APU (or indeed your expansion options) and then edit what goes into it and/or expand on its scope (if is does not use say an analogue section you can enable it and pipe something in there). If we were talking about the GBA or DS then there are nice near universal audio formats we can go into great depth for but here it is pretty rough and ready. That is not so bad though as what is in the ROM is likely what is going to be fed into the hardware or will be after truly minimal processing. It does also mean you might be troubled if you want to edit things at a somewhat higher level.add new bosses with also fixing the current ones it has (something similar to the Castlevania III and SotN boss features)
Changing boss AI is possible but I should also note AI is probably the wrong term- a lot of it is patterns repeated and maybe interrupted at given health milestones with anything resembling AI being a "home in on the player" option in some cases. Equally there is a reason games reuse things so revisiting an old boss (or its cousin), a normal enemy somewhat jumped up or something like that would be nicer. Still I am sure you could possibly wedge an extra sprite or two in there.add rooms for entirely new sections
Depending upon how the game does it then this could be hard or easy. I am not sure a bit of theory coding will do much good here (not that it ever does much good) so I will hold back and say something like generally you would see pointers, something in the linked list family (this room can lead to this room or that room), coordinate systems (column 4, row 6) or some hybrid of the lot. Assuming you can fit it in the ROM then you get to figure out how to get a door (or possibly teleport) into the new room and once there how to get out of it.add a map feature
This could be quite hard depending upon how the levels play out. In most cases chances are it was a distinct entity made at compile time. Even adding something like a room marker could be a feat in an of itself depending upon how the game plays it (coordinate systems are easy enough but the others are far too slow for the NES to work through in real time). Of course you can cheat and add things to the map (pass a massive statue and represent it on the map.... just like real life).
If you aspire to add a progressively drawn map then I say give up or cheat and add a second map once you get to a milestone whereupon you load the second fuller map.add a save state
If you are going for emulator only I have to ask why? I could do this for the GBA something more powerful but the NES is going to prove tricky. I would probably add an interrupt to freeze the game and add a simple loop piping the memory into the SRAM (which will probably also want to be hacked and that could be a nightmare in and of itself).edit texts
Assuming you do not want to expand any one section a ridiculous amount this is a fairly basic trick in most cases. I can envisage a situation where you might have to either hold back or do extensive hacking to work around a limitation but cross that bridge as and when.getting rid of the box transition from when it goes from day to night/night to day
I would take to assembly for this one but it is likely to be easy enough assuming the box does not mask a load or some processing (even on the NES the fraction of a second it could gain here is still quite a few cycles). As with everything else there are many ways the original coders could have made it happen. I would probably have done a timer (which the game has already) and added an interrupt at intervals to do trigger the go for night/go for day routines. The box is probably part of that so you can have it skip past the "user has pressed the button" check to the end of it, maybe skip the box loading at all or something else. Bypassing functionality like this is often what people use to learn some of the basics of assembly hacking (you either blank an instruction with a NOP or make a jump to the "all is well/end this" part of things).edit the ending by having only one true ending instead of possible 3 outcomes
Maybe slightly harder than the text box thing and could be tackled in various ways but assuming the game just has a "three choices right at the end" type arrangement (this does extend to the timer stuff) the proper way would probably be to find the checks and either jump to the "good" ending by whatever means is necessary (it could be a basic "if, elseif, else" type arrangement or it could be a variation on that- whatever happens it is just a matter of forcing the ending you want by making sure it goes to it or does not have a choice). There is a slightly hackish way if you force a timer or whatever other end conditions there might be to make for the ones you want, it is probably how I would do it were I doing it with cheats but as you are editing the ROM best do it properly.replacing the time clock feature with how long the person has played like the 00:00:00 style (would give the player an idea of how long it would be until it becomes night or day again)
I have no idea what the clock feature is but as the game has a timer this should not be quite so bad, you might have to make a routine to convert the timer which I imagine is just a counting number (be it scaled or one for every screen redraw or something)and see about adding directional whip attacks if ever possible.
The proper ways like later games would be harder. The hackish way of subvert the button checks and spin the sprite manually (hopefully without hassle for the hit detection) would be my preferred option but might not look so good.
I have kind of already taken everything else; compression works much like music hacking in that you watch how it works in a debugger and use that info to extract it in a useful manner. The older consoles do not afford the best compression either ( http://www.romhacking.net/forum/index.php?topic=15996.0
being a nice topic on the matter) but it can still be fun to work around.