Hi ! I just try to do a real hardware version of the Mario Adventure SMB3 Hack and it's not Working. SMB3 is working on the cart but Mario Adventure is starting but I only get a black screen with the music ! I heard that the hack is not 100% compatible with the MMC3 but some site are selling a reproduction of this hack on MMC3 cart ! Someone as find the way of getting it to work !?
I can't get it to work either. Word on the street is that it just doesn't work on real hardware.
But the guy at nesreproductions.com is able to get this mod to work. I think he got a modified version of the hack.
I've got it to work on an mmc3 board in the past without any further modifications to the game. The only problems that I saw were the different palettes and the status bar jumping up and down when picking up ice blocks. Other than that, it works fine. Your wiring is probably incorrect somewhere.
My wiring is 100% correct. I have sockets and Normal Super Mario 3 is Working. I think my problem is the CHR ROM. Mine is 160k non standard and I don't know the correct way of expending it to 256k...
Does anyone have the MMC3 hacked version?
Ever consider emailing the repro guy?
He won't send you his Hack ... I emailed him and it's his personnal work and want to make money with it !! Maybe 2 or 3 of us could get the 25us $, buy his mod and than dump the rom.
flagoss wrote:
I emailed him and it's his personnal work and want to make money with it !! Maybe 2 or 3 of us could get the 25us $, buy his mod and than dump the rom.
And then if you're feeling really evil, donate the cart to Nintendo, saying you discovered a pirate hack while working undercover.
flagoss wrote:
He won't send you his Hack ... I emailed him and it's his personnal work and want to make money with it !! Maybe 2 or 3 of us could get the 25us $, buy his mod and than dump the rom.
I'll chip in for that. I'm not too impressed with trying to earn money off of someone else's work. I appreciate the reproduction service, but claiming ownership is something else entirely.
I wouldn't mind a copy of that myself. I'd buy it, only it's not just $25, it's $25 plus YOU supply the donor cart.
I agree, I was wondering how the author of Super Mario Adventure thought of someone hacking it to run on real hardware and then selling it without giving him a cut. Also, doesn't that borderline on piracy since it's based on SMB3?
I can't spend money right now but I would be willing to dump it.
Super-Hampster wrote:
I wouldn't mind a copy of that myself. I'd buy it, only it's not just $25, it's $25 plus YOU supply the donor cart.
I agree, I was wondering how the author of Super Mario Adventure thought of someone hacking it to run on real hardware and then selling it without giving him a cut. Also, doesn't that borderline on piracy since it's based on SMB3?
Well, technically all NES reproductions are intellectual property theft unless the game is fully homebrew. Bomb Sweeper is the closest to a legitimate game on that site, but even that is a close of a Game & Watch game.
I'd be willing to supply a donor cart if necessary to get it dumped. I'd prefer to chip in cash though, as I'd be shipping from Canada, so it would take longer.
tThis site a full of the best nNES developers that curentley exsist. Perhaps you could get one of them to help hack it, in place of a dump of the title.
So everybody that would like to participate in the buying of the repro just pm me. Also if someone have a compatible donnor cart.. it would be cool to have you in ! Also if someone have the hability to dump the cart or remove the eprom and read them with a programmer pm me !
Compatible Donor Cart:
---------------------------
Bill Elliot Nascar
Bo Jackson Baseball
Bugs bunny birthday blowout
Dracula (imagesoft)
felix the cat
gauntlet 2
home alone
image fight
jurassic park
kid klown
king quest 5
MC Kids
Roundball
Silver Surfer
Star Wars
Super Mario Bros 2
Super Mario Bros 3
Tetris 2
Tiny Toon workshop
where in time is carmen
where's waldo
Wasgo wrote:
Super-Hampster wrote:
I was wondering how the author of Super Mario Adventure thought of someone hacking it to run on real hardware and then selling it without giving him a cut. Also, doesn't that borderline on piracy since it's based on SMB3?
Well, technically all NES reproductions are intellectual property theft
Using the term "intellectual property"
confuses the reader: is it a copyright issue, a patent issue, or a trademark issue? Also "theft" and "infringement" are
not the same thing under the law. In most of these cases, what you mean is "copyright infringement".
Quote:
unless the game is fully homebrew. Bomb Sweeper is the closest to a legitimate game on that site, but even that is a close of a Game & Watch game.
Clones don't necessarily infringe. The court in
Capcom v. Data East ruled that the
scenes a faire doctrine excludes a lot of game elements from copyright.
tepples wrote:
Clones don't necessarily infringe. The court in
Capcom v. Data East ruled that the
scenes a faire doctrine excludes a lot of game elements from copyright.
Whoa, that game looks so much like Street Fighter II! If they can get away with it, I sure can make a game starring "Phonic the Porcupine".
Too bad I did not know about this guy earleyer I would have had him make me a EB0, myne looks like ass.
tepples wrote:
Using the term "intellectual property"
confuses the reader: is it a copyright issue, a patent issue, or a trademark issue? Also "theft" and "infringement" are
not the same thing under the law. In most of these cases, what you mean is "copyright infringement".
Actually, in this case I meant all three. Reproductions infringe on copyright, trademarks and potentially patents. I'd have to look at the specific patents Nintendo has for the latter.
I also disagree strongly with GNU's assertion that they have no common factors and should be treated as fully separate entities. To say they have nothing in common is wrong. By analogy, the term property shouldn't exist. The parcel of rights bestowed for ownership of land, ownership of a corporation and ownership of a painting are completely different as well, but all are considered property.
Even their history of it is inaccurate. Yes, IP laws in their earliest form were brought for to protect the best interest of the public, not the IP holder. This was because it was presumed that prior to the laws, that creators had a natural right of ownership. These restriction are analogous to many physical property rights such as the restrictions created by heritage building laws, or right of first refusal on sales.
As for theft versus infringement, you're right. I choose a loaded term which is not accurate in this situation and I apologize.
Quote:
unless the game is fully homebrew. Bomb Sweeper is the closest to a legitimate game on that site, but even that is a close of a Game & Watch game.
Clones don't necessarily infringe. The court in
Capcom v. Data East ruled that the
scenes a faire doctrine excludes a lot of game elements from copyright.[/quote]
While not all clones infringe, in this case they took the name, the game design and the level design from the original Game & Watch. The Capcom v. Data East case specifically differentiates between cloned elements which are not protected by copyright, and those which are. This would likely have elements that would be deemed protected by copyright, and thus would be infringing.
Wasgo wrote:
I also disagree strongly with GNU's assertion that they have no common factors and should be treated as fully separate entities.
I think the underlying problem is that a culture of "intellectual property" encourages lawmakers to create parcels of exclusive rights around more and more fields of endeavor.
Quote:
While not all clones infringe, in this case they took the name, the game design and the level design from the original Game & Watch.
Taking the name? Nintendo might have a case. But what about the level design?
tepples wrote:
I think the underlying problem is that a culture of "intellectual property" encourages lawmakers to create parcels of exclusive rights around more and more fields of endeavor.
My primary concern with intellectual property is that the primary use has changed from protecting ideas, concepts and creative works into carving out sectors in order to make money off of future ideas, concepts and creative works that someone else comes up with. The requirements to be deemed new are inadequate, and the definition of derivative has become too broad.
That's not even attempting to address the fact that I like some derivative works, such as Mario Adventure, which could never be legal.
Quote:
Taking the name? Nintendo might have a case. But what about the level design?
The level design by itself would not be viewed as infringement, but it would be considered when determining whether or not the NES game should be considered a derivative work with regards to copyright.
If you can find a Hex editor that has the option of adding bytes then it is possible to expand the CHR to 256.
I assume you would add this extra to the end of the CHR, I have done this and put the info on the chips placed them in a test board. The title comes up runs smooth, then I hit start it works, then it runs fast and as the grafix move to select a level it freezes up on me.
This is what I have come up with today from messing around with CajoNES, HxD and CopyNES. It plays fine in NEStopia still freezes using a TSROM board (this may be my main problem not sure yet) however it doesn't work in my PowerPak. I will update when I find a TkROM board and put sockets on it.
File: MAD3.nes
Directory: C:\Documents and Settings\Emperor\My Documents\New Folder (2)\USB CopyNES\MAD3\
Soft-patched: No
CRC: 5DF04E14
SHA-1: 8183B90678F66B6F22143DDABFF9356B75A2DF32
System: NES-NTSC
Board: TKROM, Mapper 4
PRG-ROM: 256k
CHR-ROM: 256k
W-RAM: 8k
Solder Pad: H:0 V:1
Battery: Yes
File: MAD3.sav
Directory: C:\Program Files\Nestopia\save\
Dump: Unknown
marvelus10 wrote:
This is what I have come up with today from messing around with CajoNES, HxD and CopyNES. It plays fine in NEStopia still freezes using a TSROM board (this may be my main problem not sure yet) however it doesn't work in my PowerPak. I will update when I find a TkROM board and put sockets on it.
File: MAD3.nes
Directory: C:\Documents and Settings\Emperor\My Documents\New Folder (2)\USB CopyNES\MAD3\
Soft-patched: No
CRC: 5DF04E14
SHA-1: 8183B90678F66B6F22143DDABFF9356B75A2DF32
System: NES-NTSC
Board: TKROM, Mapper 4
PRG-ROM: 256k
CHR-ROM: 256k
W-RAM: 8k
Solder Pad: H:0 V:1
Battery: Yes
File: MAD3.sav
Directory: C:\Program Files\Nestopia\save\
Dump: Unknown
Where did you manage to get a copy of the mapper 4 version? I havent been able to find it anywhere =(
It has always been a Mapper 4 game even before the hack.
Good job marvelus10 !! It's a good start !
I made a working tested TKROM board with sockets and put my eproms into it, the same ones that worked then froze in the TSROM board. I get sound but a black screen and no response from the controller. I'm not sure where to go from here though.
What kind of "working"? Have you tried the authentic SMB3 on the same EPROMs?
I never tried SMB3 on the eproms but I did try 2 other sets of eproms that were meant for a TSROM board and they both worked fine on both the TSROM test board and the TKROM test board.
I got the same result on a working TKROM devcart... black screen, no sound and no controller response...
Watch out for different MMC3 revisions (MMC3A, B, etc.). I don't know if they're different or not, but I wouldn't be surprised if they were.
Has anyone emailed nesreproductions to see how its done. I'm at a loss here, I don't know what to do next.
Hardware wise its simple, on the software side the hack was developed on emulators and it is broken on actual hardware, I don't know how to correct this personally.
The guy from that site had apparently said he would not release his fix to the public, also he is apparently not selling this title because he has yet to work out all the bugs.
Perhaps some of the more knowledgeable people in the forums would like to offer some insight?
Has anyone made some progress, unfortunately I have gotten nowhere with this.
I don't understand how this game differs from the original, it must be more than just a graffix and level hacking for it to change the way the mapper works, and I don't have the time or the patients to learn how to code to figure it out.
The author of the rom hack has mentioned a few times that the game relies on a bug which only exists in emulators. The game would need to be modified to not rely on that bug.
If the PowerPak emulates mappers then why would this not work with a that.
emulateing the hole system and emulateing a device that controlls how the system accesses sertain addresses on its ROM's is differint.
the purpose of a mapper is to allow for bigger ROM's to match up data adresses past the point where the NES'es CPU no longer has addresses. or so I belive but I am ofren wrong if outhers would add more information I would be interested.
Anybody have any idea what kind of emulator bug is being exploited? Isn't it possible that in the future newer emulators will also have problems running SMA?
It uses sprites from $0000 and $1000, messing up the irq counter.
So, assuming my limited understanding is correct, to get it to run would require moving the sprite references to a different memory address and a new mapper that increases the number of available addresses. Would that be correct?
In other words, it's using sprites from both the left and right pattern tables, while a game running on an actual NES should only use the right side.
Not "an actual NES" but "an actual Nintendo MMC3 chip". An actual NES connected to a Game Pak containing an MMC3-clone CPLD that uses a different algorithm for the scanline counter (perhaps based on PPU A13 not A12) should run the game as intended. But then we first have to figure out how to make an MMC3-clone CPLD in the first place.
tepples wrote:
But then we first have to figure out how to make an MMC3-clone CPLD in the first place.
If using sprites freely doesn't break the scanline counter, it's already much better than the MMC3. The only thing missing is 1K CHR bankswitching for both pattern tables.
tepples wrote:
Not "an actual NES" but "an actual Nintendo MMC3 chip". An actual NES connected to a Game Pak containing an MMC3-clone CPLD that uses a different algorithm for the scanline counter (perhaps based on PPU A13 not A12) should run the game as intended. But then we first have to figure out how to make an MMC3-clone CPLD in the first place.
In terms of developing a PowerPak mapper and using that, how difficult would that be?
I estimate that MMC5-style scanline following would require at least
- An authentic NES or Famicom PPU. Some famiclone PPUs have a different memory access pattern that doesn't match that of the NES PPU.
- Six more flip-flops to count 42 toggles of PPU A13 on each line (32 bg, 8 sprite, 2 pre-roll).
So anyone as do some reserch on getting super mario adventure working on real hardware !?
My TKROM-01 goes to a black screen with out of sync audio on startup...but I don't see anything that'd casue this. It works fine with regular games (SMB3 being one of course).
Has anyone tried disabling IRQs on the MMC3?
According to Nintendulator and NO$NES, The numbers 1-7 on the warp pipes at the "Warp Zone" are sprites from page $0000...which is what is probably causing most of the trouble on real MMC3s...given they can get to that point...
Also, from what I can tell, you can just fill 28000-3F000 to make a 256K chip even; it appears to work fine when emulated regardless (All default graphics pages change, making initial values moot...not to mention the uneven size would require the aditional precision that'd select the banks beside the extra data anyways).
0x15184-0x1519F in PRG code has the sprite data for the numbers on the pipes. IIRC setting the Y loc (byte 0) of each sprite ro 0xEF+ (SMB3 uses 0xF8 internally) will hide it to where timing issues wouldn't occur...
At this point I'm still looking into a solution for the first screen, and I may be able to copy the number graphics to some unused graphics space on the right-hand page, eliminating the issue there without sacrificing what you see.
Turn off IRQs and Mario 3 won't be able to split the screen at all.
Update: Disabling IRQs does not change behavior...shoot...Of course this speculation would require the PPU change to only happen after the IRQ.
I'm noticing behavior with the code that seems to change sprite paging constantly. So far I have patched the code to prevent Bit 3 of $2000 being written high...There's some aditional ANDs here-and-there (probably 5 of them too, lol)...but "Fixing" them is probably unnecessary:
Code:
LDA #A8->#08 IIRC
0x3F539
0x3F5EF
0x3F646
0x3F6D8
0x3F75C
AND #FB->#F3 IIRC
0x14396
0x352C0
0x30877
0x353A7
0x353F0
LDA $xx->#A0 IIRC (Hacky; I know)
0x3F539
0x3F5EF
0x3F636
0x3F6D8
0x3F75C
Update: I didn't notice that the graphics pages flipped at the warp zone...but the pipes still use the $1000 page like normal.
...I'm still not sure what is causing it to hang on my hardware. I've patched a total of 22 potential $1000 sprite bank changes, and still nothing but some laggy music. I've also noticed a broken branch at 0xA131 (0x34131). Goes to A135 running SLO $9D then SLO $03. Patching it to A136 to do STA $307,X seems to make more sense. This can be triggered by exiting your world map inventory (B (twice) on Zone level selection screens).
Good work AWal. Thank for sharing your research !
Okay, time for an update. At this point I have patched every potential write to not flip $2000 (bit 3) high.
I also notice some uncommon/undocumented opcodes executing everytime the B button is pressed to leave the items menu at a map screen (2 SLO/ASO operations to be exact). This is caused by a branch that throws the PC in the middle of a code, executing the data misaligned. I knocked the branch forward a byte and it seems to be fine now (it was already fine, this just prevents those opcodes from running).
Although this IPS patch gets us nowhere as far as a cartridge operating version, I will dump it in the case someone catches somthing obvious that I missed.
IPS Patch For NES File <-- Clicky
P.S.: This patch is comparing my expanded patch against my expanded untouched otherwise final. It works on my originial final that's 426000 bytes as well. Let me know if there's any troble out there.
Ok Good I will test it this weekend ! hey by the way do you think that if I add a battery to the cart the save would work !? The same modification I did to add save to my Final Fantasy cart !?
Like my posts here :
http://www.ultimate-console.fr/index.php?option=com_jfusion&Itemid=69&jfile=viewtopic.php&f=70&t=365
Nevermind I should have a TKROM lying around !
Are you having a black screen with background music playing on your real hardware !? Or did your patch fixes this !?
Its still not currently working on hardware, that patch is up so people can pick up where AWal left off.......
But someone told me that he rebuild the game on real hardware and that it's working for him ! I wonder how he got it to work !!
Like this :
Quote:
shadowkn55
I've got it to work on an mmc3 board in the past without any further modifications to the game. The only problems that I saw were the different palettes and the status bar jumping up and down when picking up ice blocks. Other than that, it works fine. Your wiring is probably incorrect somewhere.
Last week he told me by PM that he got it working on hardware.... asked him to send me his ready to burn eprom .bin but no answer yet !!
Also the guy from nesreproduction told me that he have fixed all problems with this hack and can sell me the reproduction !!
Funny that flagoss sent me a PM with the exact text as above:
Code:
Ok Good I will test it this weekend ! hey by the way do you think that if I add a battery to the cart the save would work !? The same modification I did to add save to my Final Fantasy cart !?
Mario Adventure doesn't require the battery, but can save items if you decide to come back later (Not that everyone doesn't know about DD LUBSe ALL)
Code:
Nevermind I should have a TKROM lying around !
Technically a TSROM should work as well (This is what most SMB3 carts used originally), of course that board has no battery.
Code:
Are you having a black screen with background music playing on your real hardware !? Or did your patch fixes this !?
The patch seems to fix everything that'd break PPU timing (Sprites are always bank $1000), and the bad branch/undefined opcodes that I found, but this is not all of it.
When I fire it up on my TKROM board, the music plays out of sync (some channels are faster, but some are slower) and the screen is black, hence the word incomplete in the ips patch. It's good to see someone else with the same issue, it means my board isn't screwy...Then again Joy Mecha Fight pretty much helped me fix all of that.
...however, once that is fixed (I'm still looking into it) it should be fine.
P.S.: I was dorking in the Desert Dares world yesterday and I see the ice block glitch that's happening in Nestopia, but I cannot duplicate it in other emulators. It happened when I went to the part of a stage that had the coins over an "Abyss" with a block and two microgombas in ice blocks above it (The stage is desert so the ice blocks would be questionable IRL). I think my SMB3 cart does this kind of status bar jumping in 8-2 when I'm higher up onscreen, but another one that was canibalized does not.
Why doesn't someone just buy a copy from that leonk guy at reproductions and dump his cart and trace out his rewire job to whatever pcb he used?
Its more fun for some people to figure out how to get it to work. Look at all the effort people have put into this.
Or, this guy isn't a member of this forum??? So, he can tell us about his job at this cart......
Here you go, this guy is great to deal with, yery helpfull, and his products are top notch.
http://www.thenesdump.com/New%20Website ... enture.htm
I've never seen so many bootlegs from sacrificed carts/wasted EPROM potential
Bootleg of haks is particularly odious as it steals :
- People who programmed the game
- The hacker who did the job to hack for a non-commercial basis
- The custommer who pays for that
At least an analysis of this cart would help the SMB3 hacking community see how to work around MMC3 scanline counter limitations.
tepples wrote:
how to work around MMC3 scanline counter limitations.
Mapper hack it to FME7 or MMC5.
Eemmmm, guys, I have 1 idea: does everyone tested this hack on the MMC6 cart, for example on a startropics cart??? So, on emulator this is a mapper 4, but it doesn't work on the original MMC3..... I haven't got a startropics cart, so I can't test it, but somebody can do this
.
I've seen this game for sale at three different reproduction sites. Somebody must have anonymously modified the ROM to work on real hardware, and not released it to the public.
I wonder if part of the problem that we haven't solved is compatibility with MMC3 IRQs or something else? Maybe somebody could get in touch with DahrkDaiz, and have him shed some light on the matter.
Here's the listing for compatible donor boards for Mario Adventure at nesreproductions.com:
Quote:
This game also requires a special hardware modification to work. There's an extra 7$ charge to cover this modification.
Bill Elliot Nascar
Bo Jackson Baseball
Bugs bunny birthday blowout
Dracula (imagesoft)
felix the cat
gauntlet 2
home alone
image fight
jurassic park
kid klown
king quest 5
MC Kids
Roundball
Silver Surfer
Star Wars
Super Mario Bros 2
Super Mario Bros 3
Tetris 2
Tiny Toon workshop
where in time is carmen
where's waldo
What do you think the hardware modification could be? It seems that this could be an important part of the puzzle. Could it possibly allow the unmodified ROM to work?
There really isn't anything special to it. Judging from the video on thenesdeump, the game isn't modified past the normal hack. It exhibits the same issues as I mentioned very early on in the thread. You can use ucon64 to split the rom and pad it so it fits on two 27c020 eproms. Then just follow the eprom conversion guide.
ucon64 -s ma.nes
This yields two files: ma.prg and ma.chr. Additionally, you can pad the chr so its exactly 2 mbits.
ucon64 -p ma.chr
I remade the cart again a while back just to confirm that it works and it does. I used base wars as the donor since I'm not familiar with board codes.
Is there any way get SMB3 (any version) work on a TLROM, without SRAM?
FARID wrote:
Is there any way get SMB3 (any version) work on a TLROM, without SRAM?
I don't know enough about what SMB3 does technically to speak for certain but... I would say no. You'd basically have to rewrite the entire game and somehow do it with the WRAM that was originally available. Even if you were to do all that I would expect that you'd have to sacrafice a lot of effects without that extra 8KB of ram to work with.
Why do you ask though? What are you looking to do? (I assume put a Farsi translated game that requires WRAM on a TLROM board
If you've got a game that needs WRAM but the board you're working with doesn't have a spot for it, why not just add it. Even if there wasn't room on the board you could wire everything up to the chip even though it wasn't on a board. Or if the case was big enough (NES not FC) you could just use some protoboard or something.
I want to make a 4 in 1 cartridge including three TLROM games and SMB3. How can I disable using SRAM (WRAM) in SMB3?
You'll need to use a cart with SRAM as the donor for your 4-in-1. Most TLROM games except Low G Man will happily ignore SRAM if present.
FARID wrote:
I want to make a 4 in 1 cartridge including three TLROM games and SMB3. How can I disable using SRAM (WRAM) in SMB3?
You won't be able to just disable it, SMB3 needs it.
(perhaps you meant enable it?)
Either way your only real option is to get a TSROM board so you have the WRAM for SMB3. You could add WRAM to TLROM like I said earlier but it would most likely be a mess. Basically converting TLROM to TSROM.
And like tepples is saying, chances are the games that don't use the WRAM (games that originally used TLROM) won't care that there's actually WRAM there and they'll ignore it. So with that assumption all you'll need to do is use your reset bankswitch circuit for all the rom images.
FARID wrote:
How can I disable using SRAM (WRAM) in SMB3?
You can't "disable" it. The whole game was programmed to used that extra memory, which makes it essential for the game to work. Since the game was programmed to work with 10KB of RAM, you can't expect the same program to work with just 2KB.
The game could probably be reprogrammed from scratch to use only 2KB of RAM, but that would require an insane amount of work without any real reward, so I doubt anyone would want to do it.
It would be much, much, much simpler to just add the SRAM to the cart. The wiki has some information about how to do it.
I guess it would be useful to post this here as well, it's about Mario Adventure on PowerPak:
http://www.nintendoage.com/forum/messag ... =21#bottom
myself at NA wrote:
I tried it now, doesn't work.
Then I looked at it for 10 minutes in Nintendulator and figured out it simply needs to have the WRAM page 7000-7FFF cleared to work. Simply loading an empty .SAV file before starting the game does the trick.
This would also explain why some people have had it working with some RAM chips and not others (different initialization values).
If somebody wants to hack the ROM to fix this issue, remember that the game probably uses some of the RAM at 7000-7FFF for the save stuff, so you should only clear the parts that aren't used for that *OR* add some kind of signature check in the code (if there isn't one already).
EDIT: Oh yeah, you also need to pad the CHR size to 256KB. PowerPak does not support non-power-of-two bank sizes.
Really? That was the big issue? What about MMC3 scanline IRQs? Didn't the game have a problem with those?
It's not the MMC3 IRQs that stop the game from booting. They just screw with the status bar later on.
We probably need to make a "Fake MMC3" mapper, which uses a scanline counter based on a timer (like VRC6) instead of watching A12. Then the game would run flawlessly.
Dwedit wrote:
We probably need to make a "Fake MMC3" mapper, which uses a scanline counter based on a timer (like VRC6) instead of watching A12. Then the game would run flawlessly.
That or a fake-MMC3 mapper that spreads the A12 rises by 60 or so dots instead of the roughly 12 dots of authentic MMC3. That will count as expected unless all eight sprites on a given line are from $0000-$0FFF.
Can somebody please put together a combined IPS patch that applies both the Mario Adventure hack and also pads the CHR size to 256KB?
Mario Adventure was also designed for FX3's old palette, which no longer resembles what newer emulators use. For example, the dark blue is far too bright, and the dark yellow colors are instead a rich orange-brown, the red is super-bright, and in general, the colors are much lighter than the new darker palettes.
Maybe the game needs a palette hack to update it to the newer color sets.
Dwedit wrote:
It's not the MMC3 IRQs that stop the game from booting. They just screw with the status bar later on.
What level uses tiles from both pattern tables?
How about level 1-1? Climb the beanstalk, and pick up the clear block before throwing it at the brick.
Dwedit wrote:
How about level 1-1? Climb the beanstalk, and pick up the clear block before throwing it at the brick.
OK thanks. Yep, the IRQ problem is definitely there (fortunately it doesn't make the game completely unplayable, at least in that specific case). BTW I didn't mean to imply there was no problem with the IRQ, just wasn't sure if it was supposed to occur right away or later on in the game.
So, if somebody feels up to the task, change the mapper to VRC6 (shouldn't be too hard if the IRQ is only used for the status bar), pad the CHR to 256 KB and fix the WRAM initialization code. To clarify on my earlier quote, the game never clears 7000-7FFF, yet expects *some* of the values in there to be 0. It's not OK to clear all of it unless you want to lose the ability to save altogether.
Two years later and this thread is still alive...amazing in any board really, but I have some good news for everyone.
Last night I was experimenting with my copynes and a newly aquired burner (Genius G540) when I noticed somthing odd about a previously problematic game. Mario in Some Usual day started working on my TSROM board suddenly...So I figured that since it was behaving interestingly I'd give the other known problematic SMB3 Hack, Mario Adventure, a run for it's money. To my surprise it worked...suddenly, it dawned on me...I was using other games that were writing to the WRAM in the cart, that may have initialized them just right so that these 'problematic' titles could operate. So I experimented a little bit...I loaded the WRAM with a fill of FF, and Mario Adventure started doing it's usuall music rant with a black screen...then I filled the same WRAM with 00, and lo and behold, it started playing.
Checking the WRAM init code, it appears that only 6FFF-6000 are erased to 00 (I believe this point was already made in this topic), however, the upper half of the WRAM is untouched (except 7D00-7DFF when erasing a save via UP + Select at 'PRESS START').
I've completed a patch that redirects the WRAM initialization code to a code cave with more space so that I can initialize 7FFF-7E00, then 7CFF-6000, fixing the issue.
Additionally, I've added a check to WRAM byte 7DD6. It appears to be unused, but zeroed when erasing the save. This is a failsafe in case the save somehow becomes corrupted, but is not foolproof. It will erase the save if the value at 7DD6 is not 0.
The suspect bytes 7A55 freezes the game with any value other than 0 (mabye pause flag?) and 7AF7 controls some loop in the music code (needs to be 0 on init to work properly).
Here's a zip file with two versions of the ips file (one for a PRG-ROM binary, and one for a .NES file. It doesn't matter if your nes file has the CHR expanded of course).
http://www.mediafire.com/file/kcqc5zgrq7792s5/Mario%20Adventure%20Patch%20for%20Real%20Hardware-AWal.zip
Code:
Unpatched Code:
ROM Location $3C42F:
$842F:A0 00 LDY #$00
$8431:84 00 STY $0000 = #$00
$8433:A9 6F LDA #$6F
$8435:85 01 STA $0001 = #$FF
$8437:A9 00 LDA #$00
$8439:91 00 STA ($00),Y @ $FF00 = #$00
$843B:88 DEY
$843C:D0 F9 BNE $8437
$843E:C6 01 DEC $0001 = #$FF
$8440:A5 01 LDA $0001 = #$FF
$8442:C9 5F CMP #$5F
$8444:D0 F1 BNE $8437
PATCHED CODE:
ROM Location $3C42F:
$842F:20 00 DF JSR $DF00 ; Patched WRAM Init Routine
$8432:EA NOP
$8433:EA NOP
$8434:EA NOP
$8435:EA NOP
$8436:EA NOP
$8437:EA NOP
$8438:EA NOP
$8439:EA NOP
$843A:EA NOP
$843B:EA NOP
$843C:EA NOP
$843D:EA NOP
$843E:EA NOP
$843F:EA NOP
$8440:EA NOP
$8441:EA NOP
$8442:EA NOP
$8443:EA NOP
$8444:EA NOP
$8445:EA NOP
ROM Location 33F00:
$DF00:A0 00 LDY #$00
$DF02:84 00 STY $0000 = #$00
$DF04:A9 7F LDA #$7F
$DF06:85 01 STA $0001 = #$FF
$DF08:A9 00 LDA #$00
$DF0A:91 00 STA ($00),Y @ $FF00 = #$00
$DF0C:88 DEY
$DF0D:D0 F9 BNE $DF08
$DF0F:C6 01 DEC $0001 = #$FF
$DF11:A5 01 LDA $0001 = #$FF
$DF13:C9 7D CMP #$7D
$DF15:D0 F1 BNE $DF08
$DF17:A9 7C LDA #$7C
$DF19:85 01 STA $0001 = #$FF
$DF1B:A9 00 LDA #$00
$DF1D:91 00 STA ($00),Y @ $FF00 = #$00
$DF1F:88 DEY
$DF20:D0 F9 BNE $DF1B
$DF22:C6 01 DEC $0001 = #$FF
$DF24:A5 01 LDA $0001 = #$FF
$DF26:C9 5F CMP #$5F
$DF28:D0 F1 BNE $DF1B
$DF2A:AD D6 7D LDA $7DD6 = #$00 ; WRAM $1DD6 Does not appear to be used unless erasing save
$DF2D:D0 01 BNE $DF30
$DF2F:60 RTS
$DF30:4C 90 D9 JMP $D990 ; Erase Save Routine
Yeah thanks you !
Good work !
Will try that tonight !!
Good job dude, haha. So have you analyzed it and made a map of what the WRAM locations mean? Like, what's needed to save information? I'm sure if somebody would have known it'd of been fixed a while ago, I think people don't like hacking hacks, [Myself] especially that don't work for real because it's probably bad code, like this.
But still, great job dude. You're probably going to be worshiped as a saint now by most people, heh.
Very cool indeed but just wanted to point out that thefox managed to find the issue and make it work with the powerpak a few day before but now the problem is compeltly solved thansk to AWal. People waited for years to have it figured out and now we have 2 separate peoples fixing the game in the same 2 weeks?
Good job guys, I'll be sure to test AWal patch on my powerpak as soon as I can get a stupid CF card and CF card reader,(pretty hard in this SD card era we're living in:P) so I can finally see what all this fuss about
I don't know what I am doing wrong, but I have trieds appling the ips-patch using:
http://www.zophar.net/utilities/patchut ... r-ips.html
I used the rom-file:
Mario Adventure by DahrkDaiz (SMB3 PRG1 Hack).nes - found in GoodNES 3.14 ...
When trying the patched NES-file using my PowerPak the graphics gets really glitchy:
http://www.youtube.com/watch?v=4JCNIsKFjmA
Kreese wrote:
I don't know what I am doing wrong, but I have trieds appling the ips-patch using:
http://www.zophar.net/utilities/patchut ... r-ips.htmlI used the rom-file:
Mario Adventure by DahrkDaiz (SMB3 PRG1 Hack).nes - found in GoodNES 3.14 ...
When trying the patched NES-file using my PowerPak the graphics gets really glitchy:
http://www.youtube.com/watch?v=4JCNIsKFjmA
I'm going to guess that the number of CHR banks in your ROM isn't a power of two. PowerPak can't deal with non-power-of-two bank sizes, so you'll need to pad it to the next power of two (256KB). IIRC there's an IPS patch for doing this in the NintendoAGE forums...
Ah ok! I tried the "PAD" ips on the "original" ROM. It worked fine...
But am I supposed to PAD it with Dwedit's patch:
http://www.nintendoage.com/forum/messag ... adid=56245
and then patch it with AWal's?
I tried just using Dwedit's and that worked fine... Even the Padded+Patched rom worked fine... Hmm confusing.
Two patches won't work together if there is an interdependency between the two. But if two patches overwrite different parts of the ROM, they might work fine. For example, if one patch affects only PRG ROM and the other only CHR ROM, the chances of an interdependency are near zero.* All a CHR ROM padding patch does is write zeroes to the end of the ROM and change one byte in the header to say how many zeroes it wrote. It's more complicated with a PRG ROM padding patch because it will contain a copy of the entire fixed bank (and the entire CHR ROM if present), and patches that affect PRG may not know where to make changes.
* Exceptions include CHR ROM readback and changes to sprite 0 behavior, but aspects of MMC3 architecture make it less likely that either of these will be an issue.
I put together a combined IPS patch that combines three different IPS patches (original Mario Adventure hack, Dwedit's padding patch, and Awal's fix), so that all you need is two files to create a Mario Adventure ROM that works on the PowerPak:
Super Mario Bros. 3 (U) (PRG1) [!].nes
http://www.mediafire.com/?4p44hu4e4p4c23s
I've tried it and it works! Awesome!
Although I did spy some weirdness here and there. I lost my mario skills so I haven't seen a lot, but the first world's screen is half pink with some corrupted tiles. The first level on the second (I think) world would have the status screen jump around.
But still, congratulations for everyone on getting this to finally work on PowerPak!
Jagasian wrote:
I put together a combined IPS patch that combines three different IPS patches (original Mario Adventure hack, Dwedit's padding patch, and Awal's fix), so that all you need is two files to create a Mario Adventure ROM that works on the PowerPak:
Super Mario Bros. 3 (U) (PRG1) [!].nes
http://www.mediafire.com/?4p44hu4e4p4c23s
Jagasian wrote:
I put together a combined IPS patch that combines three different IPS patches (original Mario Adventure hack, Dwedit's padding patch, and Awal's fix), so that all you need is two files to create a Mario Adventure ROM that works on the PowerPak:
Super Mario Bros. 3 (U) (PRG1) [!].nes
http://www.mediafire.com/?4p44hu4e4p4c23s
I tried this and it works well! AWal, you're a freaking legend... However, the save doesn't seem to work, at least not with the blank 8KB .sav file provided by the RetroZone site.
shawnleblanc wrote:
The first level on the second (I think) world would have the status screen jump around.
This is a bug caused by the handling of cartain sprites
(they are called from the page normally used for bg graphics):
Anytime you hold a tossing block
The block that bounces up then down while a vine is comming out of it
Then end-game door trigger (yes, I beat the entire game from start to finish)
I have a technical note inside the text file I provided with my patch (nifty little zip file)
naI wrote:
However, the save doesn't seem to work, at least not with the blank 8KB .sav file provided by the RetroZone site.
Don't bother writting a save file, just make sure your ines header is correct (4E 45 53 1A 10 20 42 00 01 00 00 00 00 00 00 00). If you're using a powerpak, wasn't there a set of patched mappers that solved any issues with the whole no sav file, no save problem?
In the technical note, I also remember jotting down that my sanity check for a save file is not perfect, so if you cannot get it to proceed past the warp zone screen, 'erase' the save by pressing up+select, then A at the 'PRESS START' prompt.
I'd like to add a note at this point that all testing on actual hardware for me was done with a TSROM board from Bo Jackson's Baseball (sports games are cheap...) that has been modified with an add on backup battery (2xAAA ran through a silicon diode to pin 28, which has been lifted from the board).
[ed: a typo was annoying me...]
naI wrote:
I tried this and it works well! AWal, you're a freaking legend... However, the save doesn't seem to work, at least not with the blank 8KB .sav file provided by the RetroZone site.
Saving works for me using the 8KB .sav file from RetroZone. Remember to hold the reset button down to get the menu to load for saving the battery backed memory to the .sav file.
Props again to AWal for the fix. Any chance you can figure out how to fix the sprite glitches and the pallete? Super Mario Bros 3 was always my favorite Mario game until I played Mario Adventure... now it is my favorite
Jagasian wrote:
Any chance you can figure out how to fix the sprite glitches
Honestly I really have no intention of fixing these, not because I'm being lazy about it, but it's just not game breaking.
Jagasian wrote:
...and the pallete?
Is there something wrong with the palette? I think it looks fine on my front-loaders via A/V cables. I know Mario in Some Usual Day had some custom colors for the last world screen, but I don't think Mario Adventure used any custom colors deliberately.
Again, there's really nothing game breaking about this, so I really just don't anticipate fixing this.
AWal wrote:
Is there something wrong with the palette?
I believe the hack was developed using a fairly inaccurate old emulator palette, so it doesn't look quite right on a real console.
Does anyone have an active link to the .ips that has the combined fixes a few posts up??
ocdgamer wrote:
Does anyone have an active link to the .ips that has the combined fixes a few posts up??
I've got it here:
http://dl.dropbox.com/u/18341918/Mario%20Adventure%20Real%20Hardware%20Patch.zip
Wow, thanks so much. I can't wait to play this on my NES!
It seems like the board that works for this game is TSROM with a battery add on, but my emulator says that the game with the padded ips is a TKROM with battery. Would that work with Shadowgate or Deja Vu then?
ocdgamer wrote:
It seems like the board that works for this game is TSROM with a battery add on, but my emulator says that the game with the padded ips is a TKROM with battery. Would that work with Shadowgate or Deja Vu then?
I don't know about those games specifically, but the only difference between TSROM and TKROM is battery backing as far as I'm aware. So by adding the battery backing to TSROM you've converted it to TKROM.
infiniteneslives wrote:
ocdgamer wrote:
It seems like the board that works for this game is TSROM with a battery add on, but my emulator says that the game with the padded ips is a TKROM with battery. Would that work with Shadowgate or Deja Vu then?
I don't know about those games specifically, but the only difference between TSROM and TKROM is battery backing as far as I'm aware. So by adding the battery backing to TSROM you've converted it to TKROM.
I have tried to make this game on both TK and TS rom boards before the awal ips patch came out. Using a different ram chip I was able to get it to work on TS-ROM no problems, however I could only get it to work on one TK-ROM board the others failed, I have no idea why. These are the boards used :
TS-ROM-03 = Nintendo MMC3A 8850KP - worked fine
TK-ROM-01 = Nintendo MMC3B 9007KP049 - worked fine
TK-ROM-01 = Nintendo MMC3B S 9002 3 T - black screen perfect sound no controller reaction
Now I have not had the opportunity to try this new ips patched version on either when I get the chance I will follow up on this thread.
Great thanks for the info. I'm going to try it with a tkrom now as well. Tecmo NBA Basketball. We'll see I guess.
infiniteneslives wrote:
ocdgamer wrote:
Does anyone have an active link to the .ips that has the combined fixes a few posts up??
I've got it here:
http://dl.dropbox.com/u/18341918/Mario%20Adventure%20Real%20Hardware%20Patch.zip
I have recreated this hack on a TKROM cartridge (battery backed HVC-TKROM-02 with 8kb WRAM and MMC3B) but I'm getting those weird graphical glitches on my Famicom. I patched the PRG1 rom with the provided IPS but I have read in this topic that some extra hardware stuff must be added to make this work. Can somebody tell me what that is? Please?
jpx72 wrote:
I have recreated this hack on a TKROM cartridge (battery backed HVC-TKROM-02 with 8kb WRAM and MMC3B) but I'm getting those weird graphical glitches on my Famicom. I patched the PRG1 rom with the provided IPS but I have read in this topic that some extra hardware stuff must be added to make this work. Can somebody tell me what that is? Please?
The hack is poorly coded. It does not check if the RAM contents are invalid and load it anyway.
Try clearing the backup ram using the command on the rom readme and it will "automagically" start to work properly...
Thanks a lot! That was automagic!!!
I also think the problem reported by marvelous10 a few posts ago is related to poorly coded SRAM handling code. -_-;
To make it easier for those who don't have a patch I can whip up an NES-SRAM clearing program that sits in RAM from your powerpak or something if you'd like so you can clear it if you have the non-patched version on a cart. The game doesn't need it cleared more than once, right? It doesn't throw any bad values in there once it's cleared?
So is this correct for adding the battery or am I incorrect\missing something?
nintendo2600 wrote:
So is this correct for adding the battery or am I incorrect\missing something?
The way you connect your 22uF cap is kind of ambiguous in the picture. It looks like you're trying to put it in series with the SRAM and diodes, which would be wrong.
You basically want the SRAM Vcc pin, the 22uF (+) pin, and anode of the two diodes to all be connected in the same point. The other leg of the cap goes to ground.
Basically if you took the cap out of your picture and redrew it between the GND and Vcc on the SRAM you'd be good.
infiniteneslives wrote:
nintendo2600 wrote:
[img]
You basically want the SRAM Vcc pin, the 22uF (+) pin, and anode of the two diodes to all be connected in the same point. The other leg of the cap goes to ground.
Basically if you took the cap out of your picture and redrew it between the GND and Vcc on the SRAM you'd be good.
So like this you mean?
Both diodes are wrong way. They should prevent you from powering the NES with the battery and preventing the battery to receive current from the NES !! On your draft, the diode block the current to go from the battery to the SRAM and also block the current to go from the NES to the sram ! That should be the oposite !
flagoss wrote:
Both diodes are wrong way. They should prevent you from powering the NES with the battery and preventing the battery to receive current from the NES !! On your draft, the diode block the current to go from the battery to the SRAM and also block the current to go from the NES to the sram ! That should be the oposite !
OK I'll switch that on the next shematic. I'm gonna do a little more than a quick MSpaint job when I get it final. Thanks for the help!
nintendo2600 wrote:
So like this you mean?
Yeah and with the diode note
infiniteneslives wrote:
nintendo2600 wrote:
So like this you mean?
Yeah and with the diode note
does it matter much if I use a Zenner or Scholky diode? I got a bunch of the later but not so many of the former.
nintendo2600 wrote:
infiniteneslives wrote:
nintendo2600 wrote:
So like this you mean?
Yeah and with the diode note
does it matter much if I use a Zenner or Scholky diode? I got a bunch of the later but not so many of the former.
Zener will NOT (or atleast shouldn't) work. You want to use schottky doides if you can, however I've had some sucess with some standard switching diodes like 1N4148's You can get them at radioshack. But if you really care about not loosing your progress get some schottkys.
Here's what I use:
http://search.digikey.com/us/en/products/BAT85,113/568-1617-1-ND/763444
infiniteneslives wrote:
Are these compairable to what your using? They are do35 not do34 so I thought I'd ask before purchasing anything.
http://www.ebay.com/itm/50x-BAT85-Schot ... 4cfcf946a9
Also for the 22uf cap does it matter if I choose to use 16v over 50v or visa versa?
For electrolytic capacitor, the higher the voltage rating you choose the lower the capacitance will be if you "undervolt" it.
I don't think using an 50v part would be "too bad" if it's just being used for decoupling of the power line. You can get away with any capacitors up to 100uF. (100uF is overkill so something around 22-47uF will do.)
The schematics above should help you with the connections.
nintendo2600 wrote:
Are these compairable to what your using? They are do35 not do34 so I thought I'd ask before purchasing anything.
Yeah those should work
hey guys^^
i had a quick look at the thread and i also wanted to do a repro of Super Mario Adventures, and here is what i got:
- An already modded TSROM (SMB3)
- Two W29C020 (256x8kbit chips) (are on their way to me^^)
-the patch that has made to be compatible for hardware repro (thx to infiniteneslives)
my questions are:
i wanted to use the save function of the game and read that i have to modify pin #28 of the wram (sram) to add save function to the board and i wanted to know if the tsrom is a proper donor cart for this mod.
i also wanted to know if anyone knows if the W29C020 (Windbond) chips are compatible for nes repros ( i checked the pinout and it has the same as the 29F010 i am using for the tsrom at the moment;))
i appreciate any advice and help
If you connect the flashrom /OE pin to GND (just like Nintendo does with the WRAM chip) and use /CE to enable the flash memory (Like Nintendo does with it's original maskroms, except that most Nintendo MASKROMS have their /OE pin tied low internally so only /CE pin is exposed outside instead of both pins).
If you connect the flash memory that way, /WE pin will be ignored allowing you to use an standard EPROM/FLASH ROM pinout (27C4001 compatible pinout for example)...
l_oliveira wrote:
If you connect the flashrom /OE pin to GND (just like Nintendo does with the WRAM chip) and use /CE to enable the flash memory (Like Nintendo does with it's original maskroms, except that most Nintendo MASKROMS have their /OE pin tied low internally so only /CE pin is exposed outside instead of both pins).
If you connect the flash memory that way, /WE pin will be ignored allowing you to use an standard EPROM/FLASH ROM pinout (27C4001 compatible pinout for example)...
thx for the answer ^^
i thought someone already tried with W29C020 and can confirm that these could be used for tsrom (i am not sure if they work because of their speed)
aliman wrote:
thx for the answer ^^
i thought someone already tried with W29C020 and can confirm that these could be used for tsrom (i am not sure if they work because of their speed)
I wrote that, because if you tie /CE and /OE together and connect to the mapper chip, it will work neat with EPROMS but flash will fail (unless /WE pin from flash is tied to +5v). And it happens that /WE pin on all flash memories is A18 for 27C4001 EPROM. The mapper drives that pin low most of the time (as to read the lower 256 half of the total memory it can address).
ohh didnt got that at first
I've already done so
just a question:
my w29c020 won't work for unknown reason.
i've tested other flash roms (29f010) on the same board and it worked but the windbond w29c020 (with the exact same pinout) won't work...
any ideas why?
ps: my chip programmer says that they are equivalent to ae29f2008
aliman wrote:
just a question:
my w29c020 won't work for unknown reason.
i've tested other flash roms (29f010) on the same board and it worked but the windbond w29c020 (with the exact same pinout) won't work...
any ideas why?
ps: my chip programmer says that they are equivalent to ae29f2008
Make sure pin 31 is connected to VCC (it's the write enable pin for flash rom, used to reprogram it. While on programming mode it cannot be read hence it not working).
connecting /we to vcc didn't solve the problem.
any other suggestions?
aliman wrote:
connecting /we to vcc didn't solve the problem.
any other suggestions?
If that didn't solve the problem, then it's obvious you have a wiring problem. Does the normal MARIO 3 ROM work on your board ?
okk i've solved it thanks to l_oliveira^^
somehow the gnd pin of my chip bend up itself...
but now it works:)
Dammit, I've almost gotten this to work.
I've got a socketed NES-TSROM-04 dev cart that I've used to play many games simply by popping in other EPROMs (D-Pad Hero, D-Pad Hero 2, Super Mario 2j, Pussy City Pimps, etc.). For Mario Adventure, I applied the patch to a Super Mario 3 rom file, split it, burned the chips, and I'm getting the following results: the sound works, controller responds properly, but the graphics are pretty messed up. I don't get any intro screen displayed, but I can hit Start and it will go to the first map. Again the graphics won't be right (no info bar across the bottom of the screen, no Mario, but some of the map's "paths" will be there) , but the sound and controller functions seem to work. Just for kicks, I burned a set of chips for SMB3 and it works fine.
Any ideas? Should I try it on a different board?
if you have modded the tsrom to save your data like me then it would be the best to delete the data with (i think) up+select at title screen. i had the issue too and deleting existing data on sram helped.
another problem could be the board version. i use tsrom-08 from mario bros 3. you could try using another board version.
i hope this helps^^
@ jonnymopar - You should have read a couple of older posts:
http://nesdev.com/bbs/viewtopi ... 8290#88290
I've tried the Up+Select trick and nothing is changing. Unfortunately, the erase option doesn't make any sounds, so I can't confirm that it's even appearing.
Maybe it is a board rev issue.
I wonder if I should start thinking about swapping out the SRAM for the part specified here:
http://nesdev.com/bbs/viewtopi ... c&start=15. It must just be an oddball SRAM chip that initializes to all 0x00. I just don't want it to affect playability of other games that already work.
I have not added the extra battery circuitry to this TSROM board. If I can't get it to work on this board after some more trying, I went through my donor carts and I have one TKROM-01 (MMC3B) and one TKROM-10 (MMC3C) board available to try. I'm dying to try this on a TV instead of my laptop screen.
@jonnymopar
i would say, you should test it with the tkrom-10 as i learnd the higher a board rev the better is the compatibility of a game on it
i don't think changing the sram of the
tsrom-01 would increase the compatibility of games playable on it because the mmc3 chip has some bugs which were fixed in higher rev of the board (if i haven't uderstood that wrong)
Well, TKROM-10 did the trick. Now all I have to do is put a new battery in it and make a nice label for it. I'm still not sure why it didn't work on my TSROM dev cart. But it's working great with only the few known glitches present. I didn't even need to do the memory reset at the title screen.
This game is seriously awesome.
jonnymopar wrote:
This game is seriously awesome.
Some claim it's the best one in the series. I haven't played it myself, so I can't say if I agree or not, but it does have a good reputation.
Karatorian wrote:
jonnymopar wrote:
This game is seriously awesome.
Some claim it's the best one in the series. I haven't played it myself, so I can't say if I agree or not, but it does have a good reputation.
It is extremely difficult, but innovative. It is definitely a must play.
I just realized I thought I was in the FF3 thread when I posted that. Doh.
aliman wrote:
if you have modded the tsrom to save your data like me then it would be the best to delete the data with (i think) up+select at title screen. i had the issue too and deleting existing data on sram helped.
another problem could be the board version. i use tsrom-08 from mario bros 3. you could try using another board version.
i hope this helps^^
U need a mmc3 cart with sram(must have bettery)
next zero the sram
Now u can play the game ok!