This thread isn't so much about Mario Adventure 3, but rather, keeping a rom hack proper for full NES emulation. As everyone is aware of by now, there was a bug in FCEUxd that did not properly emulate the IRQ counter for MMC3. I had used sprites from both pattern tables, that would cause an IRQ counter change and cause the game to render a status bar much higher than it should with a sprite from the other pattern table was loaded. I've seen quite a few threads about getting Mario Adventure working on real hardware and I greatly appreciate everyone involved in getting the hack to work, it's actually very flattering.
At any rate, I'm working on a proper sequel (skipping 2 since 2 was "dropped") and I want to keep the hack proper this time. So far the mapper remains the same, I'm not using the pattern table trick from before. I _am_ expanding the CHR. It is my understanding that by expanding the CHR, I need to expand the PRG as well to pad the rom. Is this correct? Are there any other problems that people know of with the original Mario Adventure that made it hard to get working on real NES hardware?
You don't need to expand the PRG in order to expand the CHR. PRG and CHR are independent of each other on MMC3.
But when you expand CHR, you need to pad it to a power of 2 to make newer emulators happy.
Maximum sizes are 512k PRG and 256k CHR. (Some pirate MMC3 games can use 1024k PRG and 8k CHR RAM, but this is non-standard)
Good to hear you're working on a sequel!
There was one other thing that caused some issues. A patch was created a while back I reshared it at the bottom of this post:
http://forums.nesdev.com/viewtopic.php?f=9&t=5177&hilit=mario+adventure&start=90But the problem was to do with initializing SRAM. From what I remember your ROM assumed that ALL WRAM was initialized to 0. That's usually not the case, with most SRAMs. There are a few parts that do, and the trick was to find those for a while. So you'll need to either initialize WRAM at boot up or not make assumtions that it has been automatically.
There were the padding issues also, the 'requirement' is that the PRG-ROM and CHR-ROM is a power of 2. That's not just an issue with new emulators, but any hardware really.
Other than that I've got a repro copy that works like a charm, and I've also tested it out on my devcart with my own MMC3 implementation and everything worked well.
If you need any help testing things out in hardware during development or before release don't be shy. Either myself or many others on here would be more than happy to test things out for you.
Do you have any suggestions on detecting proper SRAM initialization? Is it just a matter of using a checksum to validate the SRAM pertaining to game data. If it doesn't check out then the SRAM values are garbage and wipe it out?
Just clear it all on boot up, unless you need to save stuff, then you obviously checksum that part of it somehow.
Just clear it all on boot up, unless you need to save stuff, then you obviously checksum that part of it somehow.
I apologize, I thought it was obvious that I intended to use SRAM to save game progress.
Then don't clear what you need and make sure everything else isn't trashed. Easiest was is to clear everything that's not used for saving.
Couldn't you just save a string somewhere everytime you save, and if that string is not found, erase it all. So if there is garbage there it will all be cleared, and then the first time you actually save some progress that string will be added and the SRAM will not be cleared anymore.
Also, I think it's always a good idea to make some way to force SRAM to be cleared by holding down some odd button-combination on boot-up, just in case something gets messed up.
That might work, but won't catch 1 byte corruption from power down without disabling the WRAM, which would be bad. You need to check the whole block of save data.
3gengames wrote:
That might work, but won't catch 1 byte corruption from power down without disabling the WRAM, which would be bad. You need to check the whole block of save data.
It wouldn't be bad if you didn't access save data until after the title/player select screen (where you also had a menu clear option). As long as you did that you could ALWAYS get the game to boot. Once you try to load a corrupt save and the game crashed you could hit reset and start over and create a new save.
I wouldnt make a special button combo do anything at boot (except maybe something like a cheat). Because what if the dog was sitting on the controller just right at power on and your game is destroyed... Plus the game isn't capable of informing you how to delete files before it turns on. You'd have to rely on inst manual/ Internet.
The a better solution I see is have a string tag to signify there is a current save file but then also save a checksum of the entire save block. So BEFORE tring to load a potentially corrupt save file you could verify its integrity with the checksum. If the checksum is bad you can prompt the user, tell them to hit reset when turning off console to try and prevent it next time, and then ask if they'd like to create erase the corrupt save file and create a new save. Only problem with that is if the NES gets powered off before updating the checksum you'd be pretty upset. But many newer games ask if you want to save and then tell you not to power off the console until its done to try and mitigate that issue I guess.
I guess the other question is what's the worst that could happen if you loaded a corrupt save file? You start the game on the wrong level or wrong number of coins/power ups? As long as all possible values of the save data were valid and loadable it won't be the end of the world. Seems like that would be the best solution, you'd just have to be sure that all possibilities are valid and can't crash the game.
My only other suggestion is to add save slots so you could have something like 3 different games saved. I'm kind of imaging SMB world's style load screen. Personally I enjoy playing SMB adventure with my different groups of people, and it'd be nice if each team/person could have their own.
Here's my idea for how to handle saved games:
One save:
* 'sequence number', increment this every time you save the game
* whatever data you want there
* signature byte
* checksum
Then a second complete save.
Then save it twice in two different places. If one save is corrupted, use the other one. If both are okay, use the one with the higher sequence number (wrapping around at the max size of course). You could also encode the sequence number into two bits instead of an entire byte if you need to save space.
If you decide to go with a multiple save slot system, then you only need one backup save, plus the other three saves.
Yeah that'd be a pretty fail safe option. The only other thing I can think of was something brought up recently in another thread I believe. But you could have 'golden' passwords a few times throughout the game. For things like keys and castles beat. That way you could always have a hard copy in case all data was lost. You could easily neglect coins and power ups and take em as a loss.
infiniteneslives wrote:
The only other thing I can think of was something brought up recently in another thread I believe. But you could have 'golden' passwords a few times throughout the game.
It was probably
terriblegate.
Thanks for all the information guys. I'm not sure if I'll be able to do a back-up save AND 3 save slots. As of this post, without compression, save data is 72 bytes. I have 254 bytes of unused ram, 3 slots would be 216, that's without a checksum, though a lot of this data is bit flags and would be hard to compress. From what I'm sensing, a save slot system is definitely preferred.
If
all of a particular chapter's event flags are needed to pass each chapter, then you can compress the progress into 12 bits: 4 bits for the chapter and 8 bits for the chapter's remaining event flags. You only need to store individual event flags for the whole game if you plan to make players able to come back and get the flags they missed.
Including checksum data, you can fit about 4 bits per character into a password with a 32-character alphabet. (This uses digits 0-9, symbols * and #, and the Latin alphabet minus vowels and S.) This means 72 bytes would make an unusably long password.
Table: Letters in a 32-character password alphabet
Code:
1 2 3 B C D F G
4 5 6 H J K L M
7 8 9 N P Q R T
* 0 # V W X Y Z
The thing is, while there is sequential game play, there isn't much that the player is guaranteed to be in, here's the data represented in bytes:
Player_Experience: 3
Player_Coins: 2
HammerBros_Coins: 1
Player_Level: 1
Player_Ability: 1
Game_Coins: 3
Odometer: 3
Game_Timer: 3
Current_PowerUp: 1
PowerUp_Reserved: 1
World_Number: 1
Map_X: 1
Map_XHi: 1
Map_Y: 1
Inventory_Items: 28 - there will be more than 16 available items to purchase
World_Complete_Tiles: 8
HammerBros_Coins_Collected: 16
By combining some data (hi/low nibbles), I get a total of 75 bytes (miscounted for 72). World_Complete_Tiles
are bit flags, as are HammerBros_Coins_Collected. The player isn't ever guaranteed to be in a specific area at any time since the game can be back tracked to the beginning at any time. The save data will allow the player to start where they left off on the same map, same x/y position with all stats listed.
Yeah just do whatever you can manage, in any event we'll all just be thrilled to see another game reguardless of how the saves work
If your limited by SRAM or other things, and have interest/need in more we could probably brew you up some solutions. This is really the only homebrew/hack project that actually exercises and nearly maxes out its capabilities, sounds like this new version will even more so. Work would be needed on both the emu and hardware side, but there's enough people around here who'd be interested in contributing.